Blog sobre desarrollo WordPress en Español Desarrollo WordPress en Español
minify html

Reduce el HTML de tu WordPress para bajar el peso de la página

La parte pública de una web o expresado de otro modo, lo que el navegador pinta, no es más que un documento HTML, donde encontraremos etiquetas de todo tipo: imgs, links, sections, articles, headers, footers, etc… A grosso modo algo tipo:

Este es el HTML (he reducido algunas cosas) que pinta el tema twentyseventeen de WordPress basándonos en la instalación inicial, sin plugins y únicamente con la página de ejemplo y la entrada Hola Mundo. Físicamente ocupa 12.124 bytes. Vamos a ver qué podemos hacer para reducir el tamaño del HTML que se genera en la parte pública de un WordPress.

 

Limpiar el HTML de la cabecera de WordPress

En la cabecera <head> se cargan una serie de etiquetas como wlwmanifest, generator, emojis (script y css), etc… que probablemente no utilices y no hacen más que ocupar espacio y generar más peticiones http innecesarias. Podemos añadir una función en nuestro functions.php para limpiar la cabecera:

Nuestra cabecera pasaría de tener todo este código HTML:

A reducirse a esto:

El peso total del HTML se reduciría hasta los 9.171 bytes.

 

Limpiar las clases que no utilizamos en body, articles y menús

Podemos observar en varias etiquetas que WordPress pinta una serie de clases con el fin de darnos la opción de personalizar un template concreto, o un post, o incluso los post pertenecientes a una categoría o etiqueta, etc… Ejemplo:

Etiqueta <body>:

Etiquetas de menú (<ul><li>):

Etiqueta <article>:

Si no vas a utilizar estas clases para maquetar o dar estilo a partes de tu web, mejor elimínalas. Ojo, quizá te interese mantener algunas, en los ejemplos de abajo crearemos unas listas blancas.

Para eliminar las clases de la etiqueta body haremos uso del filtro body_class. Este filtro pinta una serie de clases en función de la plantilla en la que estemos (por ejemplo: home, error404, category…):

Lo mismo para las clases añadidas a los articles, pero en esta ocasión utilizando el filtro post_class:

También para los menús, utilizando el filtro nav_menu_css_class:

No es mucho pero hemos pasado de 9.171 bytes a 8.868 bytes. Recuerdo que es una instalación inicial básica, la ganancia sería mayor en un entorno real con más posts, más elementos de menú, etc…

 

Eliminar el parámetro de versión de los query strings

WordPress suele añadir a la URL de los archivos CSS y JS un parámetro al final con el número de la versión, por ejemplo: ?ver=4.7.4. Para eliminarlo bastará con añadir esta función:

En este ejemplo aparece en 10 ocasiones, eliminándolo conseguimos reducir el HTML a 8.775 bytes. Además, algunos analizadores de rendimiento como Pingdom Tools ó GT Metrix te recomiendan eliminarlos porque con cada cambio de versión la caché quedaría “anulada”, y el cliente tendría que descargarse de nuevo el recurso que probablemente sea el mismo.

 

Minificar el HTML para terminar

La mayoría de plugins de caché ofrecen la posibilidad de minificar el HTML. Minificar el HTML significa eliminar todos los espacios, tabulaciones, saltos de línea, comentarios, etc… quedando todo el HTML en una única línea, quedándote algo tan feo como la imagen de portada de esta entrada.

En nuestro ejemplo bajamos el peso hasta los 7.758 bytes. Desde los 12.124 bytes iniciales, todas estas acciones han supuesto una mejora de 4.366 bytes. No es mucho, pero hay que tener en cuenta que este ejemplo es única y exclusivamente con los contenidos generados en una instalación limpia de WordPress.

En la vida real, con plugins instalados y bastante más contenido la mejora puede ser de varios KB. Sigue siendo poca, pero aún con este ejemplo siempre cargarán más rápido 7,7 KB que 12,1 KB, aunque apenas sean unas milésimas imperceptibles para el ojo humano.

Estas técnicas hay que enfocarlas en el sentido de que son un granito de arena más que nos va a ayudar a tener un mejor rendimiento. Si en lugar de un plugin de caché, quieres aventurarte a hacerlo a mano y tener el control de cómo minificar el HTML, te invito a visitar este post de Manuel Canga donde explica cómo hacerlo.

Una reflexión para terminar: En listados de posts donde podemos mostrar los últimos 10 posts, si cada post tiene una imagen, un título, un enlace, un botón, un extracto, etc…y reducimos el listado a los 8 últimos, el HTML pintado no sólo será menor, la query es más rápida y también hay menos peticiones http por ejemplo a las imágenes, además de evitar la carga de estas dos imágenes en sí.

Puede que también te interese

Mejora la puntuación de Google PageSpeed Insights: Eliminar el CSS que bloquea la visualización del contenido de la mitad superior de la página
Mejora la puntuación de Google PageSpeed Insights: Eliminar el CSS que bloquea la visualización del contenido de la mitad superior de la página
1. Optimizar imágenes 2. Minificar CSS y JS 3. Especificar caché de navegador 4. Habilita la compresión 5. Reducir el tiempo de respuesta del servidor…
Cómo cambiar el título del meta box de la imagen destacada en WordPress
Cómo cambiar el título del meta box de la imagen destacada en WordPress
En algunas ocasiones puede resultar de utilidad cambiar o renombrar el texto o título que aparece en el meta box de Imagen destacada. Por ejemplo…
Me han hackeado mi página web de WordPress, ¿qué puedo hacer?
Me han hackeado mi página web de WordPress, ¿qué puedo hacer?
Un día nos podemos levantar y encontrarnos con la desagradable noticia de que nuestro sitio ha sido infectado. Esto puede ocurrir por multitud de factores:…
Sidebar diferente para cada página en WordPress
Sidebar diferente para cada página en WordPress
En algunas ocasiones podemos necesitar tener un sidebar o barra lateral diferente para cada página o sección de nuestro sitio. Esto lo podemos hacer de…




  • Hola Pablo!!

    A mi me gusta el uso de los query strings con la versión. Precisamente porque “con cada cambio de versión la caché quedaría anulada”, es una forma muy fácil de actualizar el script y que el cliente se descargue la nueva versión. Si no se pone el query string con la versión habría que poner la versión en cualquier otra parte de las URL del script, de lo contrario no habría forma de que el cliente tenga la versión más nueva hasta que la caché expire; las dos son técnicas de invalidación de caché válidas:

    Pero utilizar el query string en WordPress me parece mucho más cómodo, pues viene integrado en el sistema de manejo de scripts.

    • Hola Juan!

      Efectivamente, con una versión nueva anularías la caché, que si hay cambios en esos archivos te viene bien.

      Del lado contrario, test como pingdom tools te marcan como punto a mejorar: Remove query strings from static resources. Precisamente porque cachear estos recursos es una buena práctica para mejorar la velocidad del sitio.

      Si no hay cambios en estos archivos estaríamos haciendo descargar el mismo recurso “con otro nombre”. Que tampoco es nada dramático… 😉

      • Claro, pero yo entiendo que no se va a cambiar de versión si no hay una nueva versión, ¿no?. Así que ese problema de descargar el mismo recurso de forma innecesaria no existe si se hace bien. Por eso yo nunca le hice caso a ese aviso de algunas herramientas, herramientas que encima no te dan ningún aviso si utilizas la versión como ruta del URL y es exactamente lo mismo.

        En WordPress, lo que hay que hacer, en mi opinión, es no dejar la versión del script sin especificar, hay que poner la versión, o como mucho null. Si se pone null WordPress no añadirá el query string con la versión, pero si deja en el valor por defecto (cadena vacía), entonces WordPress añade como versión la versión de WordPress, y eso si que no estaría bien porque se cambiaría de versión del script sin que el script haya cambiado realmente.

        En cualquier, creo que sería mucho peor actualizar un script o un css y no tener forma de que los usuarios se descarguen la nueva versión y que sigan utilizando la versión en caché. En el caso de scripts y css las cachés suelen ser muy muy largas, del meses hasta un año, imagina todo ese tiempo con usuarios que actualicen los scripts y estilos de tu web. Yo esa situación la veo mucho peor.

        • Si, por eso digo siempre lo de no obsesionarse con estas herramientas. No siempre tener mejor puntuación significa que la web vaya más rápido. Espero que se me entienda con un ejemplo:

          Google Fonts. El propio google te dice que las cargues en el , sin embargo si lo haces ahí PageSpeed te dice que tienes un recurso que está bloqueando la visualización del contenido de la mitad superior de la página

          Si lo pones en el footer desaparece ese “aviso”, pero aparece el FOUT. Es decir, pasas el filtro, tienes mejor puntuación, pero sin embargo aparece un flashazo de las fuentes en tu web que queda muy feo.

          Con esto pasa lo mismo, si un visitante tiene cacheado un recurso estático por un año, bien porque pasas el filtro, obtienes mejor nota y el usuario no tiene que descargarse ese recurso la próxima vez que te visite. Ahora, si hay modificaciones en ese recurso no lo verá a menos que borre la caché de su navegador regularmente, etc…

          • Jejeje, justo edité el comentario con el ejemplo de Google Fonts y el tema de las versiones sin ver que me habías respondido.

            Es evidente que esas herramientas son automáticas y no todos los detalles son aplicables a todas las situaciones.