Theme WordPress. Bifurcando el código

El pasado 14 de noviembre me hice eco de un articulo publicado por Manuel Canga, titulado ‘3 líneas de código para optimizar tu WordPress sobremanera’. Trataba acerca de un sencillo truco para optimizar un theme WordPress.

Como andaba muy liado con mis plugins de la serie Gallery, me dejé el artículo en el tintero, para recuperarlo más tarde. Y ahora ha sido el momento.

Pruebas con el theme WordPress ‘Ancora’

Para probar el acierto del código y las modificaciones propuestos por Manuel Canga, lo mejor es emplear un theme cuyo código conozcas.

En mi caso, el que tengo más reciente es el theme Ancora, terminado el pasado octubre.

Este tema se compone de una página principal ‘front-page’, en la que puedes disponer páginas estáticas en el orden que tú quieras, al estilo del nuevo ‘Twenty seventeen’. Se añade un Custom Post Type para artículos y/o servicios y una taxonomía para la clasificación de los anteriores. Se complementa con un ‘slider’ y un ‘fade’ para amenizar.

La ‘front-page’ permite poner imagen de fondo de pantalla, e imágenes de fondo y ‘slider’ en cada una de las páginas incluidas.

Theme WordPress Ancora v.1.0
Theme WordPress Ancora v.1.0

Pero, en lo que destaca este theme WordPress es en su back-end, ya que está diseñado para ofrecer nosotros una página web a nuestros clientes ya montada. Posteriormente, serán ellos quienes introduzcan la información que quieran, evitándonos nosotros las tareas administrativas que ello conlleva.

Pero, para ello, he tenido que realizar fuertes modificaciones en el back-end de WordPress, para evitar posibles errores.

El tema ‘Ancora’, pues, contiene más de 1.500 líneas de código php. Si bifurcamos el código del back-end a un archivo ‘admin.php’, el archivo functions.php principal del plugin queda en ¡poco más de 100 líneas de código!.

 

Los resultados

Previo al cambio, realizamos una comprobación con GTmetrix, dando estos resultados:

  • PageSpeed Score, 52%
  • YSlow Score, 72%
  • Page Load Time, 3.1 s.
  • Total Page Size, 2.05 MB.
  • Requests, 35

Una vez hecho el cambio, y comprobado que funciona (por supuesto), volvemos a GTmetrix, que nos da:

  • PageSpeed Score, 52%
  • YSlow Score, 73%
  • Page Load Time, 4.2 s.
  • Total Page Size, 1,97 MB.
  • Requests, 29

Parece que el resultado es el mismo, pero no tanto. Porque, si observamos, veremos que el tamaño de la página ha disminuido unos 80 KB, que es lo que hemos adelgazado nuestro ‘index.php’.

¿Que ocurre? Sobre todo, el peso de mi página reside en las imágenes, que sí o sí, pesan desproporcionadamente más que el código, por lo que el cambio no afecta.

 

Conclusiones

Pudiera parecer que no abogo por la modificación del código. Sin embargo, no es así. Me explico.

En primer lugar, encuentro muy acertado separar el código entre ‘admin’ y ‘front-end’. Además, puede suponer una forma más estructurada de codificar para nosotros.

También sería interesante (me lo apunto en mi lista de buenas prácticas) hacerlo con los plugins. En el mismo artículo de Manuel Canga, realiza un comentario final Nilo Velez sobre su plugin ‘Machete’, donde realiza esta praxis.

Debido a la cantidad de imágenes que aparecen en la página en carga directa, la reducción del peso de la ‘front-page’ ha sido mínimo. Sin embargo, estaréis de acuerdo conmigo que un tema sin tanta imagen agradecería mucho más este cambio. Por lo tanto, deberemos combinar esta técnica con otras de carga de imágenes, como CDNs o ‘lazy loads’.

 

En conclusion, apoyo totalmente esta propuesta, y me la añado a mi lista de buenas prácticas.

Un saludo a tod@s.

2 opiniones en “Theme WordPress. Bifurcando el código”

  1. Buenas tardes, Sergio,

    En primer lugar, gracias por probar mi código y hacer público los resultados.

    En segundo lugar, ten en cuenta que el nivel de optimización dependerá de las características del tema.
    En tu caso, el número de peticiones pasa de 35 a 29. Por lo que la web está cargando 6 elementos menos( puede ser de CSS o Javascript o llamadas AJAX ). Eso de por si ya es una buena noticia, porque suponen 6 peticiones menos que el servidor tiene que resolver por cada visitante, lo que conlleva poder atender a más usuarios simultáneos.

    También influye, y mucho, a nivel de velocidad. En tu caso no lo aprecias porque estás cayendo en un fallo típico( lo explico en: https://trasweb.net/blog/wpo/fallo-tipico-a-la-hora-de-medir-la-velocidad-de-una-pagina-web ) .

    Estas mejoras aumentarían conforme aumenta el tamaño del sitio.

    Gracias de nuevo, Sergio,

    Un saludo

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *