Optimiza y acelera tu WordPress hasta las estrellas

Aumentar 20 puntos en PageSpeed Insights no es fácil y requiere varias etapas de optimización. La primera parte de este caso real de Optimización de WordPress trató sobre Hosting, Backups, Plugins e Imágenes, poco complejas técnicamente, consolidando los cimientos necesarios para etapas siguientes. Continuamos ahora con áreas más sensibles de WordPress: Base de Datos, Aceleración de descargas y, ejem, Optimizaciones Extremas.

Tiempo medio de lectura: 28 min (8.800 palabras).
Si no tienes tiempo ahora, puedes saltar directamente a las conclusiones del artículo.

Tabla de contenidos

  1. Acerca de la Base de Datos
    1. 4.1 Configurando el comportamiento de WordPress
    2. 4.2 Desfragmentando la Base de Datos
    3. 4.3 Sí, también hay plugins para optimizar la Base de Datos
    4. 4.4 La Base de Datos después de optimizarla
  2. Acerca de ficheros y descargas
    1. 5.1 Reduciendo los ficheros que bloquean el renderizado
    2. 5.2 Cachea WordPress y no generes las mismas páginas una y otra vez
    3. 5.3 CDN: Externaliza tus imágenes
  3. Optimizaciones extremas
    1. 6.1 Revisando las optimizaciones ya realizadas
    2. 6.2 Analizando los informes de rendimiento

Raiola NetWorks: alojamiento WordPress
¡El mejor hosting Wordpress con un 20% de descuento!

Recapitulando la primera parte de la optimización

Repasar las optimizaciones y aceleraciones de WordPress ya realizadas
Repasemos lo que ya hemos optimizado…

Si también quieres conseguir un aumento espectacular del rendimiento de tu sitio en WordPress, pero no has leído la primera parte de este artículo, mi recomendación es que lo hagas.

No, no es que quiera aumentar las visitas de ese artículo 😉 Como explico al principio de la primera parte, para conseguir estos impresionantes resultados no me he limitado a aplicar diferentes optimizaciones sin orden ni concierto, sino que he seguido un proceso sistemático que, desde mi punto de vista, permite conseguir mejores resultados y de forma más segura.

Si sólo estás interesado en conocer los detalles técnicos de las optimizaciones que he aplicado, tampoco está de más que también leyeras al menos ese primer apartado, para ponerte en contexto y que conozcas mis motivaciones y propósitos cuando decidí acelerar mi sitio Web.

Sin más preámbulos, paso a resumir las áreas que se cubrieron en la primera parte:

  • Optimizar WordPress no es necesariamente complicado, pero puede ser arriesgado, sobre todo cuando se tocan elementos muy sensibles de este gestor de contenidos. Por tal motivo, las copias de seguridad son cruciales: no hagas ninguna operación delicada sin tener un backup actualizado. Cuidado: hacer las copias de seguridad suele ser muy fácil, pero restaurarla puede ser enrevesado. Asegúrate de dominarlo.
  • Raro es el blog o sitio web que no incluya plugins para ofrecer servicios adicionales o mejorar la experiencia de usuario. Sin embargo, ni todos los plugins son iguales, desde el punto de vista de rendimiento, ni todos son necesarios. Analizar y elegir cuidadosamente nuestros plugins reducirá su impacto en el tiempo de descarga de nuestras páginas.
  • Hoy en día no se concibe un sitio Web con una importante carga visual y ya sabemos que las imágenes son los elementos de una página Web que más peso añaden a su descarga. Aunque en un principio puede parecer que es suficiente con optimizarlas, un conocimiento más interno de WordPress nos descubre que también debemos tener en cuenta otros aspectos para asegurarnos que ofrecemos las imágenes óptimas en diversas situaciones.

Otro aspecto importante que cubrimos en la primera parte, y que no es “exactamente” una optimización, fue la importancia de un buen proveedor de alojamiento. Si nuestro proveedor de hosting es lento, con elevados tiempos de respuesta, por mucho que mejoremos nuestro WordPress, el sitio Web seguirá siendo lento.

A este respecto, mi proveedor de Hosting con el que he conseguido estos excelentes resultados es WebEmpresa (si lo necesitas y tienes a bien utilizar mi enlace de afiliación, con el código “cupon20” obtienes un 20% de descuento):

WebEmpresa: alojamiento 100% WordPress

 

En otros sitios webs, también he obtenido resultados similares con Raiola Networks (pinchando en el enlace también obtienes directamente un descuento del 20%):

Raiola NetWorks: alojamiento WordPress

 

Bien, ya estamos en condiciones para continuar esta aventura. ¡Cuidado! Si la primera parte te pareció fácil, no te confíes, porque ahora entramos en los aspectos más intrincados y traicioneros de WordPress: ¡no te olvides de armarte con una buena copia de seguridad actualizada!

 

4. Acerca de la Base de Datos

Optimizar la Base de Datos para mejorar su eficiencia
Manos a la obra para optimizar la BD

Si hasta ahora siempre he insistido en la importancia de tener una copia de seguridad, ahora, cuando vamos a manipular directamente la base de datos de WordPress, hay que ser todavía más escrupulosos en este sentido.

Así que, antes de continuar, haz una copia de seguridad completa, base de datos incluida. En los sucesivos pasos de optimización de la Base de Datos, será suficiente con que vayas haciendo la copia de la base de datos. Aunque también editaremos algunos ficheros de configuración de WordPress, con tener una copia de estos ficheros en su mismo directorio será más que suficiente.

Otro punto también muy importante: esta optimización la trabajaremos tanto desde el escritorio de WordPress como del Panel de Administración del Hosting. Como ya indicaba en la primera parte, mi Panel de Administración es cPanel y los pantallazos que ponga están tomados de ahí, al igual que las herramientas administrativas que utilizo, pero todos tienen su equivalente en otros Paneles de Administración, como Plesk, Webmin u otros. Procura familiarizarte con tu propio Panel de Administración antes de acometer cualquier acción.

¿Por qué WordPress utiliza una Base de Datos? En realidad, todos nuestros artículos y páginas de WordPress están almacenados en la Base de Datos, mientras que en el sistema de ficheros lo único que hay son las imágenes, los ficheros de código PHP y las hojas de estilo CSS, además de diversos ficheros de configuración del servidor y de WordPress.

En la base de datos también se guardan otros datos, gestionados por el propio WordPress:

  • Las revisiones de nuestros artículos y páginas. Cada vez que escribimos un artículo o una página, WordPress realiza copias, denominadas revisiones, de cada modificación. Esta característica nos proporciona un control de revisiones, que nos permite recuperar y reeditar versiones anteriores de nuestro artículo.
  • Cada vez que borramos un post, una página o un comentario, éste no desaparece completamente, sino que queda en una especie de limbo, la papelera, y de donde se puede recuperar si más tarde nos arrepentimos. Esta papelera, de nuevo, está almacenada en la Base de Datos.
  • Los comentarios de los lectores. Evidentemente, estos comentarios deben guardarse en alguna parte y estar asociados con el artículo al que se refieren.
  • La información adicional, o “meta”, que añadimos a cada imagen, como el texto alternativo, el title o los estilos, y que WordPress asocia con el fichero de imagen correspondiente.
  • Datos de los plugins. Los plugins también almacenan datos, como su configuración o para proporcionar su funcionalidad.
  • Gestión del sistema. Además, WordPress almacena datos que necesita para su propia gestión, como la configuración de los ajustes o los plugins instalados, entre otros.

La Base de Datos es el centro neurálgico de WordPress, de ahí que haya que ser muy cuidadoso con su manipulación y que cualquier defecto en ella afecta directamente al rendimiento del gestor de contenidos. Por ejemplo, si la Base de Datos es demasiado grande, WordPress necesita más tiempo para gestionarla, tiempo que se añade al tiempo de respuesta de nuestro sitio Web. De ahí que cuanto hagamos para reducir su tamaño redundará en un uso más eficiente y rápido de la Base de Datos.

4.1 Configurando el comportamiento de WordPress

Base de Datos de WordPress se configura a través de wp-config.php
Ficheros de configuración de WordPress

Bien, pues la primera tarea será limitar, en parte, el comportamiento por defecto de WordPress. Concretamente, las revisiones y la papelera. Porque, sí, WordPress es muy “generoso” con su gestión. Demasiado…

En el caso de la papelera, WordPress mantiene los elementos borrados durante 30 días. En función de la actividad de nuestro sitio Web, en este tiempo se pueden acumular demasiados elementos “borrados” que no hacen más que engordar la Base de Datos y comprometer su rendimiento.

La forma más rápida y eficaz para cambiar esta configuración es editando uno de los ficheros de configuración de WordPress, wp-config.php, que se encuentra en la carpeta raíz de nuestro sitio web; esto es, /public_html/.

¡Cuidado! Cualquier error en este fichero puede provocar la caída de todo nuestro sitio web, así que comprobad que escribís correctamente cualquier comando.

Afortunadamente, estos errores son muy fáciles de recuperar. Basta con que, antes de modificar el wp-config.php, le hagamos una copia desde el Administrador de Archivos de cPanel (o el Panel de Administración que tengas).

Por ejemplo, en mi WordPress tengo dos copias de este fichero. El original (con otro nombre de fichero) y el modificado. Si algún cambio produce un efecto negativo en mi sitio web, tan solo tengo que borrar el wp-config.php modificado y renombrar el original al nombre correcto. Qué fácil, ¿verdad?:

Copia de seguridad del fichero de configuración para caso de error

Otra precaución más al editar este fichero. Para que funcione, cualquier comando que añadas debe colocarse ANTES de las siguientes líneas, que normalmente son las últimas de tu wp-config.php:

/** WordPress absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
                define('ABSPATH', dirname(__FILE__) . '/');
/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');

Mantén limpia tu papelera

Ahora sí podemos seguir. Para cambiar el tiempo que los elementos borrados permanecen en la papelera, por ejemplo para dejarlo en 7 días, insertaremos en el fichero wp-config.php la siguiente línea:

define ('EMPTY_TRASH_DAYS', 7);

donde podemos cambiar 7 por el número de días que queramos.

También podemos desactivar completamente la función de la papelera, poniendo cero en el número de días:

define ('EMPTY_TRASH_DAYS', 0);

Sin embargo, no lo recomiendo. Siempre podemos borrar algo accidentalmente y no tendríamos ninguna posibilidad de recuperarlo. Una semana creo que es un tiempo prudencial.

Está bien revisar, pero ¿tanto?

Donde la generosidad de WordPress llega a límites insospechados (sin límite, en realidad) es en las revisiones de posts y páginas: ¡¡almacena absolutamente todas las revisiones!!

Cuando revisé este punto, tenía artículos con más de ¡100 revisiones! De acuerdo que WordPress no almacena todo el post cada vez en la Base de Datos, sino sólo las modificaciones con respecto a la revisión anterior, pero a poco que tengamos 50, 100 ó 150 posts, el número de registros en la base de datos se multiplicaría por esta cantidad. ¡Inconcebible!

Pero, de nuevo, es muy fácil poner límites a este comportamiento tan descarriado de WordPress, añadiendo la siguiente línea a nuestro wp-config.php:

define ('WP_POST_REVISIONS', 5);

Donde 5 es el número máximo de revisiones que WordPress controlará por cada post o página. Ponle el número que consideres necesario, pero no creo que hagan falta más de diez.

También es posible desactivar las revisiones, con la siguiente instrucción, pero tampoco lo recomiendo: sólo hace falta que lo necesitemos una vez para que nos arruine una jornada de trabajo:

define ( 'WP_POST_REVISIONS', 0);

Para terminar, siempre que añadáis una línea al fichero wp-config.php, seguid la buena práctica de incluir un comentario de lo que hace. Mañana os acordaríais de porqué hicisteis algo pero ¿y dentro de un mes?:

/* Número máximo de días en la papelera */
define ('EMPTY_TRASH_DAYS', 7);

/* Número máximo de revisiones */
define ('WP_POST_REVISIONS', 5);

4.2 Desfragmentando la Base de Datos

Aumentr la eficiencia de la Base de Datos reduciendo su tamaño
Desfragmentación para que ocupe menos

Imaginaos una base de datos como una carpeta de anillas donde cada hoja guarda un dato. A medida que se añadan datos a la carpeta, se añaden más hojas, engrosando la carpeta. Hasta aquí, lo que cabe esperar.

Si en esta carpeta queremos borrar un dato, la acción más inmediata es arrancando la hoja correspondiente. Cuantas más hojas arranquemos, menos gruesa será la carpeta. Tampoco nada fuera de lo corriente.

Sin embargo, el borrado no ocurre de esta forma con una base de datos real, sino que la hoja con el dato a borrar seguiría permaneciendo en la carpeta pero con una marca para indicar que está borrado. Como resultado, la carpeta mantendría el mismo tamaño, pero con “huecos” de datos irrelevantes en medio de los datos reales en activo.

Aunque pueda parecer ilógico, este comportamiento de la Base de Datos no es por capricho, sino que permite una mayor eficacia en la gestión de la base de datos durante su funcionamiento continuado: es mucho más eficiente marcar un elemento como borrado que borrarlo realmente.

Una primera consecuencia de este mecanismo es que, después muchas operaciones sobre la base de datos, los datos reales están “dispersos”, y el tamaño de la base de datos crece inexorablemente, afectando negativamente a su rendimiento a medio-largo plazo. Continuando con el símil de la carpeta, su grosor seguiría creciendo y creciendo, aun cuando gran parte de sus hojas estuvieran “borradas”, con el consiguiente desperdicio de espacio.

Por este motivo, una de las tareas de mantenimiento que debe realizarse periódicamente con las bases de datos, la de WordPress incluida, consiste en deshacerse de esas hojas “vacías”, agrupando todas las hojas que realmente tienen datos y desechando el resto. Esto es lo que se conoce como desfragmentar la base de datos.

Después de desfragmentarla, ganaremos dos cosas con la base de datos:

  • Ocupará bastante menos espacio, por lo que nuestras copias de seguridad ocuparán también mucho menos y tardarán menos tiempo en hacerse.
  • Los accesos de WordPress a la Base de Datos serán mucho más eficientes, lo que redundará en la generación más rápida de las páginas HTML de nuestra Web.

Bien comprendido el concepto de desfragmentación de bases de datos, veamos cómo hacerlo. Para ello, ¿recordáis la herramienta phpMyAdmin que utilizamos en la primera parte para hacer copias de seguridad?:

Sección de Base de Datos en el Panel de Administración cPanel

La volveremos a utilizar ahora, pues entre sus utilidades dispone de una que precisamente hace esta operación de desfragmentación. Veamos cómo:

  1. Entra normalmente en phpMyAdmin (recordatorio: ¿has hecho una copia de seguridad de la base de datos?).
  2. En la barra lateral izquierda, selecciona la base de datos de tu WordPress.
  3. En el panel principal se muestran todas las tablas de la base datos. Ve al final de la página y selecciona la casilla “Check All” (Seleccionar todas). Verás que marca todas las tablas de la base de datos.
  4. En la lista desplegable a la derecha de la casilla “Check All”, selecciona la opción “Optimize table”.
  5. Pulsa el botón “Go”.

Cómo desfragmentar la Base de Datos con phpMyAdmin en cPanel

¡Y ya está! Dependiendo del tamaño de tu base de datos, puede tardar varios segundos, pero no será una espera larga.

4.3 Sí, también hay plugins para optimizar la Base de Datos

La configuración de las revisiones y la papelera de WordPress a través del fichero wp-config.php sólo tenemos que hacerla una vez y dejarla como está a partir de ese momento.

Sin embargo, el proceso de desfragmentación de la Base de Datos es un poco tedioso: acceder a cPanel, acceder a phpMyAdmin, seleccionar la Base de Datos (sin equivocarnos), seleccionar todas las tablas, seleccionar la operación a realizar y, ya por fin, desfragmentar.

¿No habría un método más directo, sin tantos pasos, y, sobre todo, desde el propio WordPress?

Estando en WordPress, la solución viene bajo la forma de plugins, ¡cómo no!, que facilitan esta tarea hasta el punto que basta pulsar un botón e incluso programar optimizaciones automáticas (aunque no lo recomiendo totalmente, ya discutiremos porqué). Pero que esta facilidad de utilización no nos haga confiados: asegurémonos de tener siempre una copia de seguridad ANTES de hacer la desfragmentación de la Base de Datos.

El rey indiscutible para estas tareas es WP-Optimize: más de 400.000 descargas (que se dice pronto), más de 300 opiniones de 5 estrellas y sólo 7 de 1 estrella. La única pega: lleva un año sin ser actualizada en el repositorio de WordPress, aunque el autor sí que ofrece soporte y actualización a través de GitHub, por lo que no parece que vaya a ser discontinuada.

He aquí un breve resumen de las funcionalidades que ofrece este plugin:

  • Borrar las revisiones y el contenido de la papelera, preservando las más recientes en el periodo de tiempo que indiquemos.
  • Borrar los borradores automáticos de WordPress (Auto-saved Drafts).
  • Borrar los comentarios Spam o sin aprobar.
  • Optimizar (desfragmentar) la Base de Datos.
  • Programación automática de la limpieza y optimización de la Base de Datos.
  • Activar/Desactivar los trackbacks y comentarios de todas las publicaciones.

La interacción con WP-Optimize y la selección de las distintas opciones de optimización es realmente sencilla, como se puede ver en este pantallazo, en el que se pueden ver también las opciones con las que utilizo la herramienta:

Panel de configuración de WP-Optimize para Bases de Datos

Hay que tener cuidado con las opciones marcadas en rojo (por algo están en ese color), aunque no porque supongan algún riesgo adicional al propio de manipular la Base de Datos. En el caso de eliminar los pingbacks y trackbacks, nos advierte que entendamos bien las consecuencias de borrar los pingbacks y los trackbacks (si no estás muy seguro de su utilidad, te recomiendo este detallado artículo para entenderlo bien).

Con respecto a la opción para eliminar las opciones transitorias, estas opciones se refieren a las configuraciones de los plugins que hayamos ido instalando/desinstalando de nuestro WordPress. Dependiendo del plugin, cuando se desinstala también borra todos sus datos de la Base de Datos, pero algunos pueden dejar, por ejemplo, los datos de configuración. Así, si en el futuro decides instalarlo de nuevo y no has borrado las opciones transitorias, te encontrarías con la misma configuración con que lo desinstalaste.

La opción “Optimizar tablas de la Base de Datos” se refiere a la desfragmentación. De esta forma, puedes limpiar y desfragmentar la Base de Datos en un solo paso o hacerlo por separado, según como marques estas opciones de configuración.

El periodo de tiempo de las revisiones y el contenido de la papelera que no se borrará se configura en una pantalla aparte. Curiosamente, sólo permite indicar semanas pares (!!!):

Configurar el periodo de validad de revisiones y papelera en AutoOptimize

Por último, el plugin incorpora la posibilidad de programar la limpieza y desfragmentación de la Base de Datos, con varias opciones de periodicidad, desde diariamente hasta mensualmente:

Programación automática de limpieza y desfragmentación de la Base de Datos

Esta funcionalidad no la utilizo, sino que prefiero estar presente por si hubiera algún problema, para restaurar rápidamente la Base de Datos. Aún no tengo decidido ningún periodo para hacerlo, pero iré comprobando semana a semana cómo va creciendo la Base de Datos y cuando supere un 10% el tamaño que tenía inicialmente, la limpiaré y desfragmentaré. Y ya en función de los resultados de la operación decidiré si ampliar o recortar el periodo transcurrido.

Pero si decidís programarla, os recomiendo que también utilicéis un plugin de backups y programéis la copia de seguridad de la Base de Datos, para que se realice un poco antes (dadle margen suficiente para que le dé tiempo al backup a terminar) de hacer la limpiera y desfragmentación automáticas.

Otro plugin, con prácticamente las mismas opciones, es Optimize Database after Deleting Revisions. No tiene tantas descargas ni valoraciones como WP-Optimize, pero se ha actualizado recientemente y es compatible con la última versión de WordPress. Si tienes algún problema con WP-Optimize (nunca se sabe), puedes intentarlo con éste.

4.4 La Base de Datos después de optimizarla

Ya hemos terminado todo lo relativo con la optimización de las Bases de Datos y quizás te estés preguntando los beneficios que he obtenido como resultado. No te voy a contestar yo, sino que voy a dejar que WP-Optimize lo haga por mí:

Comparativa de Base de Datos antes y despues de desfragmentar

“¡Guau!”, dirás, “¡qué barbaridad de ganancia!”. Sin embargo, no será lo habitual que al desfragmentar la base de datos se reduzca más de un 75%. De hecho, el que se haya reducido tanto significa que tenía la base de datos bastante mal: había mucho más espacio desocupado, sin datos útiles, que espacio ocupado. Algo razonable rondaría entre un 10% y 20%.

Esta reducción de espacio tan importante se debe a la concurrencia de varias circunstancias:

  1. Era la primera vez que desfragmentaba la Base de Datos.
  2. Debido a los cambios que hice en el Theme, el sitio Web estuvo varios meses funcionando con hasta una docena de réplicas por cada imagen.
  3. Las revisiones y la papelera estaban configuradas en las demasiado generosas opciones por defecto de WordPress.

Sabiendo que el tamaño de mi Base de Datos optimizada ronda los 8-9 Mb, hasta que no supere los 10Mb no debería necesitar desfragmentarla de nuevo.

Como efecto colateral, mis copias de seguridad ocupan ahora mucho menos espacio y se harán en menos tiempo. Si recordáis de la primera parte del artículo, había reducido unos 50 Mb optimizando las imágenes. Ahora han sido cerca de 30 Mb. Esto significa que mi copia de seguridad se ha reducido en unos 80 Mb; de una copia de seguridad de casi 200 Mb me he quedado en otra de poco más de 100 Mb. ¡Casi la mitad!

Recomendación final: introduce la desfragmentación de la base de datos en tu rutina de mantenimiento periódico de WordPress y observa cuánto espacio se reduce cada vez que lo hagas. Si ves que se libera mucho espacio, más de un 20%, hazlo con más frecuencia. Por el contrario, si se liberase menos de un 10%, reduce la frecuencia.

5. Acerca de ficheros y descargas

Hasta ahora, hemos revisado muchos aspectos de WordPress, que han ido reduciendo tanto el espacio ocupado por nuestro sitio Web (imágenes, base de datos) como a acelerar el propio funcionamiento del gestor de contenidos (plugins, base de datos). Veamos cuánto beneficio hemos obtenido en PageSpeed Insights con estas medidas:

Mejora de PageSpeed Insights para móviles y ordenadores después de optimizar

Una media de 10 puntos de mejora tanto en móviles como en ordenadores. No está nada mal, pero ¿podemos hacerlo aún mejor?

5.1 Reduciendo los ficheros que bloquean el renderizado

Analicemos con más detenimiento el informe que proporciona Google PageSpeed; concretamente, el apartado de los ficheros JS y CSS que bloquean el renderizado del código “above-the-fold” (es decir, el primer contenido de la parte superior de la página, que se muestra nada más cargarla):

Código que bloquea el renderizado "above-the-fold" en PageSpeed Insights

En total, hay 7 ficheros que están bloqueando el renderizado. ¿Qué significa esto? Que la primera parte de la página (above-the-fold) no será visible hasta que todos estos ficheros se carguen, puesto que contienen códigos JavaScript y estilos CSS que afectan a esa área.

Un inciso: ahora aparecen “sólo” 7 ficheros bloqueantes, pero antes de optimizar el sitio Web había 11. ¿Dónde han ido a parar el resto?

Normalmente, estos ficheros son debidos al Theme o a los Plugins, que los necesitan para su correcto funcionamiento. Como recordaréis, en la primera parte de esta optimización ya estuvimos optimizando los plugins, quitando algunos que eran innecesarios o sólo cargándolos en las páginas dónde se utilizan. Pues un efecto secundario de esa optimización ha sido precisamente éste: el de reducir el número de ficheros bloqueadores.

Veamos ahora cómo reducir los ficheros que aún nos quedan.

Hay dos formas de solucionarlo. La vía difícil, consistente en analizar cada uno de los ficheros y modificar el plugin o Theme para colocar los estilos CSS bloqueantes en la cabecera o los códigos JavaScript en el footer, posiblemente incluyendo código personalizado para cada uno de ellos.

Como ya habréis imaginado, esta vía tiene varios escollos:

  • Requiere bastante conocimiento técnico, no sólo para escribir el código personalizado, sino para comprender cómo funciona el plugin o el Theme para esos casos.
  • Al actualizar el Theme o el plugin también habría que copiar el código personalizado o, en el peor de los casos, reescribirlos para adaptarlos a los cambios en el Theme o plugin. Se podría evitar en el caso del Theme con un tema hijo, pero no para los plugins.

Sí que parece complicado, así que mejor pasemos a la vía fácil, ¿no?… Usando, claro, un plugin.

Hay bastantes plugins que prometen reducir el número de ficheros bloqueantes, pero hay uno que destaca claramente con respecto al resto, AutOptimize, con más de 100.000 descargas, casi 300 votos de 5 estrellas, sólo 9 votos de 1 estrella, y plenamente activo (su última actualización fue hace tan solo hace una semana al escribir esto).

Además, ofrece funcionalidades adicionales, como concatenar y minimizar los códigos HTML, JavaScript y CSS, de forma que ocupen bastante menos y, por tanto, descargan en menos tiempo. También incluye características avanzadas que nos permitirán empujar un poquito más nuestro índice PageSpeed. En definitiva, un plugin muy, pero que muy jugoso.

Sólo una precaución debemos tener con él: comprobar que toda la funcionalidad de nuestro sitio Web opera correctamente, tanto en su versión para ordenador como para móvil. Aquí os mostraré la configuración que he encontrado más segura y estable, pero puede variar en función del Theme y los plugins instalados.

Mi recomendación es que utilicéis la configuración por defecto y que vayáis añadiendo otras opciones, una a una, asegurándoos cada vez que el sitio web funciona perfectamente. Es un poco tedioso, pero así os evitáis sorpresas desagradables y tener que volver a empezar hasta dar con la opción que introdujo el problema.

Partamos, pues, de la configuración por defecto de AutOptimize:

Configuración por defecto de AutoOptimize en WordPress

Si con esta configuración tenéis algún problema con vuestro sitio Web, entonces deberéis ir desactivando cada una de las opciones, para identificar cuál es la que introduce el problema.

Para que os hagáis una idea de lo que puede fallar y de lo sutil que puede llegar a ser, en mi caso utilizar la opción “Force JavaScript in <head>?“desactivaba el funcionamiento del menú desplegable en la versión para móviles. Curiosamente, el slider, que pensaba que sería el candidato idóneo para fallar, funcionaba sin problemas.

Observar que la opción “¿Mantener comentarios HTML?” está desmarcada. No debería ser así, pues muchos Themes utilizan comentarios condicionales para comprobar si el navegador es Internet Explorer. Si no lo marcáis, es posible que vuestra web presente algún problema en este navegador. De todas formas, no es habitual que los themes y plugins incluyan muchos comentarios HTML, así que no debería tener efecto en el tiempo de descarga de las páginas.

Con solo estas opciones ya habréis conseguido un enorme impacto en el informe de Google PageSpeed sobre los ficheros bloqueantes:

AutoOptimize reduce los ficheros bloqueadores del renderizado a solo uno

¡Sólo queda un fichero bloqueante! Este fichero lo genera, y cachea para servirlo más rápido, el propio AutOptimize, concatenando y minimizando todos los ficheros de hojas de estilo que había antes.

Aún sería posible eliminar este único fichero bloqueante, utilizando la opción avanzada “Inline and Defer CSS?” o “Inline all CSS?”. Sin embargo, la primera requiere un análisis detallado de todos los estilos utilizados para identificar aquellos que están “above-the-fold” e introducirlos en la configuración del plugin. Mientras que la segunda supone una sobrecarga a la página HTML que puede comprometer su rápida descarga (el propio plugin avisa a este respecto).

Del resto de opciones avanzadas, activar las siguientes puede reducir el tamaño de las páginas HTML en algunos casos y sin necesidad de hacer ninguna operación adicional o análisis previo:

  • Also aggregate inline JS? Minimiza el código JavaScript que está embebido en la página HTML, reduciendo su tamaño.
  • Also aggregate inline CSS? Hace lo propio con los estilos CSS embebidos.
  • Remove Google Fonts? Si tu Theme utiliza Google Fonts (fuentes de texto de Google), éstos se descargan de un servidor externo cada vez que el usuario accede a tu sitio Web y no están en la caché de su navegador. Esto puede retrasar el renderizado de la página, si el servidor responde lentamente. El plugin te da la opción de no descargarlos, en cuyo caso el navegador utiliza otra fuente de texto, de las que tiene instaladas, para mostrar la página. Si activas esta opción, comprueba que la apariencia del texto de su sitio Web no cambia “demasiado”.

Ninguna de estas opciones las tengo activadas en mi sitio Web. Las fui activando una a una y comprobando el posible efecto con las herramientas Pingdom Tools y GTMetrix, pero no hubo ninguno apreciable.

Sobre los ficheros Google Fonts

WordPress puede utilizar fuentes de Google
¿Qué hace una fuente en WordPress?

Mi Theme utiliza la fuente de Google “Lato”, que debe descargarse de un servidor de Google cada vez que el usuario accede a mi sitio Web y su navegador no lo tenga cacheado o instalado anteriormente. Los ficheros de fuentes tienen la particularidad de que son bloqueantes.

Lógico: el navegador necesita las fuentes para presentar el texto. Si el navegador no dispone de una fuente, presenta el texto en una fuente alternativa entre las que tenga disponibles, aquella que tenga mayor semejanza.

En líneas generales, los ficheros de fuentes constan de dos partes:

  • Un hoja de estilo CSS, que define e identifica la fuente, a través de la regla “@font-face”.
  • El fichero de fuentes propiamente dicho, que no es legible como fichero de texto y que contiene la representación de esa fuente de texto.

Si vuestro Theme utiliza fuentes de Google, veréis que tenéis dos ficheros bloqueantes: el generado por el propio AutOptimize y el fichero CSS de las fuentes. AutOptimize no lo puede concatenar ni minimizar porque no está en el servidor local, sino en un servidor externo.

Marcando la opción “Remove Google Fonts?” evitamos que se descarguen estos ficheros de fuentes y ya no aparecerían como ficheros bloqueantes. Sin embargo, quizás la apariencia de nuestros textos varíe demasiado y no nos guste o no quede bien.

En vez de desactivar las fuentes de Google, y para mantener la misma fuente de texto, la alternativa es descargarlos en nuestro servidor y modificar el Theme para que en vez de descargarlos desde el servidor de Google, lo descargue desde el nuestro.

Veámoslo paso a paso:

  1. Descargar del servidor externo el fichero CSS que definen la fuente. En mi Theme, es el fichero “fonts.googleapis.com/css?family=Lato”.
  2. Editar este fichero para ver los nombres de los ficheros fuente que utiliza y descargarlos también. En mi Theme, son los ficheros “1YwB1sO8YE1Lyjf12WNiUA.woff2” y “UyBMtLsHKBKXelqf4x7VRQ.woff2”.
  3. Modificar el fichero CSS para que ahora apunte a estos ficheros fuente, pero con la dirección de nuestro servidor. Quedaría algo parecido a esto:
@font-face {
   font-family: 'Lato';
   font-style: normal;
   font-weight: 400; 
   src: local('Lato Regular'), local('Lato-Regular'), 
url(http://www.miservidor.com/micarpeta/UyBMtLsHKBKXelqf4x7VRQ.woff2) 
format('woff2');unicode-range: U+0100-024F, U+1E00-1EFF, U+20A0-20AB, 
U+20AD-20CF, U+2C60-2C7F, U+A720-A7FF;
}
  1. Localizar en el Theme el fichero PHP donde se descarga desde el servidor externo el fichero CSS de las fuentes, replicarlo en un tema hijo y modificarlo para que ahora lo descargue desde nuestro servidor. El Theme debería hacerlo con una instrucción “wp_register_style”, por lo que se puede localizar fácilmente. En mi Theme, sustituí la línea
wp_register_style( 'google_fonts', '//fonts.googleapis.com/css?family=Lato' );

por

wp_register_style( 'google_fonts', '//www.miservidor.com/micarpeta/Lato.css' );

Con esta solución, AutOptimize ya puede concatenar el fichero CSS de las fuentes con el resto de hojas de estilo y PageSpeed sólo detectaría un fichero bloqueante.

5.2 Cachea WordPress y no generes las mismas páginas una y otra vez

Acelerar las descargar de WordPress con un plugin de caché
Descargas más rápidas con caché

Para comprender la importancia de disponer de una caché en WordPress, parémonos un poco a ver cómo este gestor de contenidos genera las páginas HTML que los usuarios ven a través de sus navegadores.

Cuando un usuario pretende navegar a través de un sitio Web en WordPress, esta es la secuencia de pasos, en líneas muy generales, que se producen hasta que la página HTML se muestra en su navegador:

  1. El usuario introduce la dirección de la página que desea visitar o pincha en un enlace.
  2. Esta petición llega al servidor y la recoge el gestor de contenidos.
  3. El gestor de contenidos comprueba que la dirección solicitada corresponde a una página que existe y, si es así, accede a la base de datos a recoger todos los datos que conforman la página: plantilla, texto, plugins, campos meta de las imágenes, etc. De no existir dicha página, genera una página de error 404.
  4. Con estos datos, WordPress crea una página HTML, posiblemente con código JavaScript y estilos CSS embebidos.
  5. El gestor de contenidos entrega la página HTML generada al navegador del usuario, que se la muestra a éste.

Repasad de nuevo esta secuencia… ¿Dónde creéis que podríamos mejorar el tiempo de respuesta del gestor de contenidos? Una pista: estos pasos se repiten una y otra cada que un usuario, ya sea el mismo o cualquier otro, accede a una página… ¡En efecto, has acertado! En los pasos 3 y 4, WordPress genera una y otra vez la misma página, accediendo a la Base de Datos y creándola de nuevo para cada visita.

¡¡ Vaya derroche de recursos !!

Para solventarlo, podemos utilizar un mecanismo denominado caché. Consiste en almacenar temporalmente una copia de la página HTML que un usuario ha solicitado, de forma que la siguiente vez que este u otro usuario pida esa misma página, WordPress no la genera de nuevo, sino que entrega la copia almacenada en la caché.

De hecho, el plugin AutOptimize utiliza un mecanismo similar cuando concatena y minimiza los ficheros JavaScript y hojas de estilos CSS: para no tenerlos que concatenar y minimizar una y otra vez, guarda en su caché el fichero resultante de concatenarlos y minimizarlos, y a partir de ese momento entrega directamente este fichero.

Veamos de nuevo la secuencia de pasos anterior, pero esta vez con una caché:

  1. El usuario introduce la dirección de la página que desea visitar o pincha en un enlace.
  2. Esta petición llega al servidor y la recoge el gestor de contenidos.
  3. El gestor de contenidos comprueba que la dirección solicitada corresponde a una página que existe y, si es así, comprueba si está disponible en la caché. De no existir dicha página, genera una página de error 404.
  4. Si la página está en la caché, el gestor salta directamente al paso 7.
  5. Si la página no está en la caché, sigue el proceso habitual de generación de la página HTML a partir de la Base de Datos.
  6. Con estos datos, WordPress crea una página HTML, posiblemente con código JavaScript y estilos CSS embebidos.
  7. El gestor de contenidos entrega la página HTML, ya sea de la caché o recién generada, al navegador del usuario, que se la muestra a éste.

Llegados a este punto, seguramente ya habréis observado un “pequeño” detalle: si una página HTML ya está en la caché y se modifica, ¿no estaría WordPress entregando una página obsoleta? En efecto, pero la caché puede utilizar diferentes métodos para mantenerse actualizada; por ejemplo:

  • Cada cierto tiempo, la caché se “precarga” con todas las páginas del sitio Web, garantizando que estén los más actualizadas posibles.
  • La caché detecta si el original de una página de la caché ha sido modificado y, si es así, la genera de nuevo cuando un usuario la solicita.
  • La caché desecha aquellas páginas que ya lleven mucho tiempo en ella y las genera de nuevo cuando sean solicitadas.

WordPress no incorpora caché de serie, pero no pasa nada: disponemos de un amplio repertorio de plugins que nos ofrecen esta funcionalidad.

Así que me puse manos a la obra e hice una preselección de plugins, con las mismas condiciones de siempre: buen número de descargas, muchas valoraciones positivas, pocas valoraciones negativas y actualizadas recientemente.

Estos son los que elegí inicialmente:

Los probé de uno en uno, con sus configuraciones por defecto y testeando con cómo afectaban al índice de PageSpeed. Y sucedió el primer percance…

WP Fastest Cache tiene muy buenas referencias; sin embargo, a mí me desbarataba el sitio Web. Afortunadamente, no tuve necesidad de restaurar mi copia de seguridad: con desactivarlo, todo volvía a la normalidad.

Seguramente, podría haber indagado entre las opciones de configuración y descubrir qué estaba pasando, incluso podría ser debido a alguna interacción indebida con otro plugin, el Theme o con el código propio que yo había añadido (que sospecho como lo más probable). Pero como disponía de otras tres opciones con igual de buenas referencias, lo dejé aparte, al menos hasta que comprobara el funcionamiento del resto.

Nada anormal sucedió con los demás plugins: los tres funcionaron a la primera, sin ningún efecto negativo en el sitio Web… y con los mismos resultados en PageSpeed.

Por tanto, a igualdad de resultados, ¿por cuál decantarse? Y aquí ya entrarían criterios subjetivos. En mi caso, no quería un panel de configuración demasiado complejo ni infinitas opciones de configuración.

Un plugin de caché tan  versátil, con amplias opciones de configuración, puede ser necesario para un sitio Web con una elevada carga de visitas y un gran número de páginas, que debe potenciar al máximo su caché para atender a tanta demanda. Pero seamos realistas, para una Web con unas cuantas decenas de páginas y artículos, o incluso centenares, al igual que el número de visitas, sería como matar moscas a cañonazos… Por no mencionar el tiempo necesario para comprender y refinar todas esas opciones de configuración.

Así que, con este criterio, resultó un claro ganador: WP Super Cache. Su panel de configuración no tiene un elevado número de opciones y son relativamente fáciles de comprender, incluso en el Avanzado:

Configuración avanzada de WP Super Cache en WordPress

Además, su configuración avanzada recomendada (que no coincide con su configuración por defecto, menos agresiva) funcionó a la primera con mi sitio Web, proporcionando los mismos resultados que Comet Cache y W3 Total Cache.

Para la actualización del contenido de la caché, WP Super Cache proporciona dos mecanismos, de los que sólo uno puede estar en funcionamiento:

  • Tiempo de caducidad y recogida de basura (pestaña Avanzados), donde se puede indicar el número de segundos que una página permanece cacheada. Por defecto, son 3600 segundos (una hora), que parece un tiempo razonable.
  • Precarga (pestaña Preload), en el que todas las páginas se generan y almacenan en la caché cada cierto tiempo (por defecto, 1440 minutos, que corresponde a 24 horas). Los sitios grandes, con decenas de miles de páginas, deben usar esta opción con precaución (¡prácticamente estamos haciendo un duplicado de la Web!).

Una última cosa quisiera añadir: con todos los plugins de caché acabé teniendo algún pequeño problema cuando trasteaba con sus opciones de configuración. Si os pasa a vosotros, es algo completamente normal. El caché es un tema complejo, con muchas interacciones tanto con el núcleo de WordPress como con el resto de componentes de un sitio Web, los plugins o el Theme. Es imposible predecir todas las posibles interacciones, por lo que desde el primer momento tened siempre a mano vuestra copia de seguridad por si fuera necesario y la incidencia no se resolviera al desactivar el plugin de caché.

Y con la caché llegó la magia… Es decir, PageSpeed 90 para móviles y PageSpeed 96 para ordenadores:

Valores PageSpeed Insight con WP Super Cache activado

 

5.3 CDN: Externaliza tus imágenes

Acelerar descargas de imánges con CDN (Content Delivery Network)CDN son las siglas de “Content Delivery Network” y consiste en un mecanismo para que los ficheros estáticos de nuestro sitio Web (fundamentalmente, imágenes) no estén alojadas en nuestro servidor de hosting, sino en servidores externos. Con una particularidad, estos servidores están repartidos alrededor del mundo (y ahora veremos porqué este detalle es tan importante).

El propósito de un CDN es doble:

  • Libera a nuestro servidor de alojamiento de tener que entregar las imágenes al navegador del usuario. Como hay un límite en el número de conexiones que un navegador puede hacer simultáneamente a un mismo sitio Web, esto significa que el servidor puede utilizar esas conexiones para servir exclusivamente el contenido textual de la página, mientras el navegador descarga paralelamente las imágenes desde los servidores CDN. Resultado: mejores tiempo de descarga.
  • Diversifica las descargas alrededor del mundo. Los usuarios de nuestro sitio Web pueden venir de cualquier parte del mundo… pero nuestro servidor de alojamiento sólo está en un punto geográfico. La distancia física entre un usuario y nuestro servidor puede suponer un retardo en la descarga de la página. Esto no ocurre con los servidores CDN: como están repartidos alrededor del mundo, el proveedor CDN se asegura de que el usuario descargue desde el servidor CDN más próximo a su localización geográfica. Resultado: mejores tiempos de descarga (creo que me he repetido…).

Ahora bien, si todo son ventajas, ¿por qué no he implantado un servidor CDN? La implantación de un CDN en WordPress es bastante sencilla y, por ejemplo, los plugins de caché también lo contemplan en su configuración. Pero son otros los factores que me han llevado a decidir a no tenerlo:

  • Su verdadero potencial se hace patente cuando hay un alto número de visitas. El CDN libera a mi servidor de Hosting, sí, pero, seamos realistas, unos pocos centenares de golondrinas no hacen primavera y no se puede decir que mi servidor esté al 90% (ni al 80%… ni al… 😉 ).
  • Mis usuarios son en su mayoría de España, al igual que mi proveedor, con lo que también desaprovecharía la otra gran ventaja del CDN.
  • Podría añadir que los buenos CDN son de pago, pero no sería completamente cierto. Los hay gratuitos con muy buen nivel de servicio, cuando no haya excesiva demanda. Además, los precios son casi ridículos, apenas unos euros al mes (aunque depende del tráfico).

Por tanto, por ahora no tendré CDN, pero si aún sigues interesado en incorporar un CDN en tu WordPress, te recomiendo este completo artículo (+vídeo) sobre CDN de Víctor Campuzano, que explica todo el proceso que hizo para elegir su plugin caché y su proveedor CDN.

Nota añadida: Después de intercambiar varios comentarios con Víctor Campuzano en su artículo y con RaMGoN en los comentarios de la primera parte (¡gracias a ambos!), me lo he replanteado y voy a experimentar con varios proveedores CDN. Lo peor que puede pasar es que no haya ninguna mejoría, pero será camino andado para ese día que los necesite 🙂 ¡¡Os mantendré informados!!

6. Optimizaciones extremas

Cinco son las áreas de WordPress que hemos revisado y optimizado para conseguir mejorar y acelerar su rendimiento sin necesidad de cambiar de Theme o rediseñar el sitio Web: Hosting, Plugins, Imágenes, Bases de Datos y Descargas.

Ya habrás observado que casi ninguna de las optimizaciones discutidas requería una preparación técnica elevada; prácticamente cualquier usuario medio de WordPress puede acometer la mayoría de ellas, con las debidas precauciones de disponer siempre de una copia de seguridad actualizada.

Las únicas que revestirían mayor dificultad y que requieren conocimientos de programación PHP y WordPress son la mencionada en el apartado anterior (enlace a 5.1) acerca de los ficheros de fuentes Google (“Google Fonts”) y el código personalizado visto en la primera parte para que un plugin sólo se cargue en las páginas que lo utilizan.

Sin embargo, a pesar de su relativa sencillez, estas optimizaciones han permitido superar la barrera de los 90 puntos en Google PageSpeed Insights. Difícilmente podríamos seguir acelerando el rendimiento de nuestro WordPress a través de ellas.

Aún podría haber espacio para intentar arañar algún punto más. Eso sí, a partir de ahora no esperemos incrementos espectaculares del rendimiento; no sólo porque ya no hay tanto espacio para ello, sino porque las optimizaciones que podamos seguir realizando requerirán cada mayor especialización y conocimiento técnico del entorno, y habría que valorar si realmente vale la pena tanto esfuerzo para tan poca ganancia.

Llegados a este punto: ¿cómo podríamos acelerar WordPress aún más?

6.1 Revisando las optimizaciones ya realizadas

Un primer curso de acción podrá ser repasar rápidamente lo que hemos hecho anteriormente, para comprobar, rizando el rizo, si aún podría quedar algún elemento aislado susceptible de ser optimizado… Y, en el caso de mi sitio Web, he encontrado dos posibles candidatos:

  • El plugin de votaciones “Yet Another Rating Stars” consume más recursos que ningún otro plugin. Como mencioné en el apartado de optimización de plugins, este plugin lo instalé sustituyendo al “kk Star Ratings”, que tenía opciones que yo no necesitaba y consumía bastante más. ¿Se podría sustituir también por otro menos voraz todavía?
  • El plugin Forms 2 también consume muchos recursos, el segundo más voraz. Como sólo lo utilizo para crear formularios de contacto sencillos y sin funcionalidad añadida: ¿podría sustituirlo por código HTML y estilos CSS, como hice, por ejemplo, con los botones de redes sociales?

Sin embargo, a pesar de su voracidad, estos dos plugins sólo se cargan en las páginas que los utilizan, por lo que el efecto de optimizarlos apenas afectaría al resto de sitio Web. Esta circunstancia, y el hecho de que no obtendría demasiado beneficio, son los que me hacen no abordarlos. Si mi sitio Web sigue creciendo, demandando cada vez más recursos, entonces sí que me plantearía llevarlos a cabo.

Otra área susceptible de optimización, y posiblemente con más margen, sería a través de los plugins de caché. Algunos de ellos son extremadamente versátiles, con decenas y decenas de opciones, pero requieren un conocimiento más profundo tanto de WordPress como de nuestro Theme e incluso los plugins para anticipar las interacciones y prevenir efectos secundarios indeseables.

En este caso, el proceso podría ser bastante tedioso: supone estudiar cada una de las opciones, determinar si puede proporcionar algún beneficio a nuestro entorno en particular e intentar anticipar interacciones negativas con otros componentes de WordPress. En muchos casos, seguiríamos un método de prueba y error, con el consiguiente riesgo de corromper el sitio Web y tener que restaurarlo (no, no es complicado, pero consume nuestro precioso tiempo).

6.2 Analizando  los informes de rendimiento

Otra opción es utilizar los informes de las distintas herramientas de medición del rendimiento, no sólo PageSpeed, sino también, por ejemplo, Pingdom Tools y GTMetrix.

Estos informes no sólo ponen una puntuación a nuestro sitio Web, sino que emiten informes con los problemas que hayan podido detectar y proponen algunas soluciones.

Veamos algunos ejemplos. Primero, el informe de PageSpeed Insights para móviles (similar al de ordenadores):

Informe de rendimiento y optimización de Google PageSpeed Insights

Hay tres posibles puntos de mejora:

  • Ficheros JavaScript y CSS bloqueantes. El único fichero bloqueante que queda es el CSS que genera el propio AutOptimize, resultado de concatenar y minimizar todos los demás. La solución no es nada sencilla: consiste en identificar qué código o estilo está bloqueando el renderizado e insertarlo en la página HTML. AutOptimize dispone de una opción para incluir dicho código o estilo, pero es nuestra responsabilidad determinar cuál es. Hacerlo a mano puede ser una locura, pero hay herramientas que pueden ayudarnos (https://jonassebastianohlsson.com/criticalpathcssgenerator/).
  • Aumentar el tiempo de caché del navegador para el recurso analytics.js. Este fichero JavaScript forma parte de la herramienta de análisis Google Analytics, y es una de las paradojas de Google: por un lado, PageSpeed nos dice que un recurso tiene habilitado poco tiempo de caché para el navegador; por otro lado… ¡este recurso lo suministra la propia Google! La solución es tan sencilla como arriesgada: copiar este fichero en nuestro propio servidor y aumentarle el tiempo de caché para el navegador. ¿Por qué es arriesgado? Porque si Google modifica el recurso, nosotros seguiríamos utilizando el antiguo, pudiendo perder las estadísticas de acceso de nuestro sitio.
  • Reducir el tiempo de respuesta del servidor… ¿Aún menos de 22 centésimas de segundo? No creo que ningún proveedor de Hosting, entre su catálogo de planes de alojamiento estándar, ofrezca algo que baje de las 2 décimas de forma regular. Y, bueno, la cosa no está como para alojamientos personalizados…

Veamos ahora el informe de Pingdom Tools:

Informe de rendimiento y optimización de Pingdom Tools

¡Uf, qué poquito margen tenemos aquí! Hasta donde he podido rastrearlo, ese enorme y desagradable cero, que tanto desentona con el resto de indicadores, lo produce AutOptimize cuando concatena y minimiza los ficheros JavaScript y CSS. Desactivarlo sería la solución, pero la pérdida es mucho mayor que cualquier beneficio que pudiera reportar.

El resto de indicadores, entre 90 y 96, hacen referencia a aspectos del servidor, del Theme o del fichero analytics.js que ya vimos con PageSpeed. Los dos primeros se podrían tratar de resolver a través del fichero de configuración .htaccess del servidor y revisando/reescribiendo parte del código PHP del Theme.

Por último, veamos el informe de GTMetrix:

Informe de rendimiento y optimización de GTMetrix

Aquí tampoco hay mucho margen de mejora, salvo mediante la combinación de imágenes usando Sprites CSS (en concreto, se refiere a las imágenes de las distintas redes sociales en el pie de página). No es difícil de realizar, pero tiene el inconveniente que hay que rehacer el sprite CSS cuando se modifica, añade o borra alguna imagen. Como el impacto es muy bajo, he preferido preservar la comodidad de tener las imágenes por separado.

GTMetrix también recomienda la utilización de un CDN. Ya expuse anteriormente porqué creo que mi sitio Web no se beneficiaría de incorporar tal tecnología, aunque no lo descarto a medida que vaya creciendo y aumentando el número de visitas.

Como hemos visto en tres distintas herramientas de medición del rendimiento, la mayoría de los indicadores están al máximo o en valores próximos al máximo. Aunque hay margen de mejora, éste está desperdigado entre varios indicadores, lo que significa que habría que acometer bastantes acciones de optimización, algunas de ellas delicadas o complejas, para apreciar algún efecto significativo en el rendimiento.

Desde mi punto de vista, este tipo de acciones sólo tienen sentido para sitios Webs de gran tamaño y alto número de visitas, que entonces sí que necesitarían de soluciones especializadas.

Cómo afecta PageSpeed al SEO

La optimización de WordPress afecta al posicionamiento SEOÉsta es la pregunta del millón… ¿He observado algún beneficio en el posicionamiento de mi sitio Web después de todas estas optimizaciones?

Cronológicamente, el día 9 de marzo fue el primer día que me percaté de la bajada de rendimiento de mi sitio Web y en que empecé a analizarlo y optimizarlo. Terminé de implantar todas las optimizaciones el día 16 de marzo.

Apenas han pasado diez días desde entonces, por lo que puede ser un poco prematuro aventurar cómo ha afectado en el posicionamiento SEO de mi sitio Web, pero en los últimos días han pasado tres cosas muy llamativas que me han llamado la atención:

  • Empiezo a posicionar en la segunda página por varias palabras clave por las que no competía, aunque sí es cierto que tienen relación con mi actividad. No sé exactamente dónde aparecían antes del 16 de marzo, pero a través de Search Console ese día marca una frontera: antes apenas había impresiones, sin clicks, y, desde ese día, se han disparado las impresiones, con un CTR incluso mejor que algunas de mis palabras clave objetivo.
  • Empiezo a posicionar en el Top 100 por una palabra clave muy competida que sí está en mi punto de mira. No es un gran resultado (¿quién llega hasta el resultado ochenta y pico de Google?), pero de nuevo el salto se produce poco después del 16 de marzo.
  • Finalmente, varias palabras clave, de competencia media, con las que posicionaba en la parte final de la primera página, ahora posiciono en la parte media. De nuevo, alrededor del 16 de marzo.

Aunque nunca se puedan entender los designios del Señor Google, sólo acatarlos, la confluencia de estos tres hechos me hace pensar que la optimización ha ayudado de alguna forma a mejorar el SEO.

Conclusiones

Con esta segunda parte concluye la serie dedicada al caso real de optimización de un sitio Web, consiguiendo un asombroso PageSpeed 96 para ordenador y 90 para móviles y un tiempo de respuesta del servidor rondando las dos décimas de segundo. Esta vez han sido cerca de 9.000 palabras para que nada quede en el tintero y todo, todito, todo quede bien cubierto y suficientemente claro.

Para conseguir estos resultados no ha sido necesario ni cambiar el Theme ni rediseñar el sitio Web, sino que ha bastado con optimizar diversas áreas del entorno de WordPress. Tampoco ha sido necesario el desarrollo de código a medida, salvo contadas excepciones, sino el adecuado ajuste de algunos parámetros u opciones de configuración.

Repasemos las distintas áreas optimizadas, incluidas las de la primera parte:

  • Proveedor de Hosting. Sólo podemos acelerar nuestro WordPress hasta donde alcance el servidor de alojamiento. Por muy buenas que sean nuestras optimizaciones, si el servidor es lento, el sitio Web será lento.
  • Copias de seguridad (backups). Optimizar significa cambiar muchas opciones de configuración de WordPress, plugins e incluso la Base de Datos. Todo ello puede dejar caída nuestra web: tengamos siempre una copia de seguridad actualizada a mano para restaraurla rápidamente.
  • Plugins de WordPress. Los plugins son el pan de cada día del WordPress, pero no todos son iguales, aunque hagan lo mismo. Instalemos sólo los plugins que necesitemos, descartemos aquellos que consuman demasiados recursos y carguémoslos sólo en las páginas que los utilizan.
  • Optimización de imágenes. Optimizar imágenes no es sólo comprimirlas para que ocupen el mínimo espacio sin apenas perder calidad, sino también dimensionarlas correctamente y controlar que las réplicas que WordPress, los plugins y el Theme puedan hacer también estén optimizadas.
  • Base de datos de WordPress. Toda la información que hace que WordPress funcione como funciona está almacenada en una Base de Datos. A medida que se modifica nuestro sitio Web, con nuevas páginas, artículos o plugins, la Base de Datos no para de crecer. Mediante la desfragmentación periódica de la Base de Datos nos aseguramos que ocupe poco espacio y que su gestión sea rápida y eficiente.
  • Gestión de descargas y ficheros de WordPress. Para que un usuario vea una página HTML en su navegador, se deben descargar diversos ficheros desde el servidor y el navegador renderiza la página a partir de ellos. Cuanto más aceleremos esta descarga y renderizado, antes nuestro usuario podrá visualizar la página.

Un área que no se ha cubierto en esta serie de artículos es la optimización del servidor web, a través de los ficheros .htaccess y robots.txt, porque ya la había realizado en mi primera optimización del sitio web, dos meses atrás, así que no han afectado en esta ocasión para conseguir este índice de PageSpeed. Prometo hacer un artículo monográfico al respecto para compartir mis impresiones.

Hemos terminado, pero esto no es un adiós ni es el final del camino. La optimización es un proceso continuo. A medida que el sitio Web crece y aumentan sus visitas, sus requerimientos y demandas también van cambiando y hay que adaptar las optimizaciones a ellas. Pero ésa, amigos, “es otra historia y debe ser contada en otra ocasión“… 😉


17.000 palabras… que se dice pronto. Y, aún así, todavía se podría seguir optimizando el sitio Web, aunque quizás el esfuerzo no valiera la pena. ¿Qué otras optimizaciones harías tú? El tema de la Base de Datos es bastante delicado; además de desfragmentarla, ¿se puede optimizar en algo más?

Imágenes: freepik, Icon finder, elaboración propia.

 

¿El post te ha resultado útil? ¡Ayúdame a mejorar y puntúalo!

[ Hasta ahora habéis votado 9, con nota media 4.9 ]
 
Tweet about this on Twitter3Share on Facebook0Share on Google+12Pin on Pinterest2Share on LinkedIn1Buffer this pageEmail this to someone

Quizás también te interese...

Acelera tu WordPress con estas optimizaciones, paso a paso (II)
Etiquetas: base de datos    caché    cdn    guía    optimización    rendimiento
Sobre el autor,
Consultor SEO Freelance, Ingeniero Superior de Informática, Certificado en Google Adwords y Experto Universitario de Social Media Marketing, con más de 20 años de experiencia en el sector de Internet y las Nuevas Tecnologías.

Hay 13 comentarios acerca de:
    “Acelera tu WordPress con estas optimizaciones, paso a paso (II)

  • Pingback: Bitacoras.com

    • 03/04/2016 a las 13:40
      Enlace permanente

      ¡Gracias a ti, Julio, por compartir tu experiencia! Me alegra mucho saber que esta guía te haya sido tan útil, y más para un tema como la optimización de WordPress, que a veces puede ser muy quisquilloso.

      ¡Un saludo!

      Responder
  • 04/04/2016 a las 9:26
    Enlace permanente

    Hola Antonio!!

    Muchas gracias por la mención tío. Menuda currada de artículo de 2 partes que te has pegado, si señor!! Yo me los he guardado los dos en favoritos para revisarlos más adelante porque me parece que tengo aún cambios que aplicar.

    Abrazos!

    Pd. Ya me contarás qué tal con el CDN, seguro que genial! 🙂

    Responder
    • 04/04/2016 a las 14:27
      Enlace permanente

      Gracias a ti, Víctor, por buscar un rato y pasarte por aquí. Espero que algunos de los consejos del artículo te sean útiles. Si tienes alguna duda, aquí me tienes para lo que necesites.

      Sí, ya estoy mirando lo del CDN. ¡Te mantengo informado tan pronto tenga resultados!

      Un abrazo!

      Responder
  • 04/04/2016 a las 10:13
    Enlace permanente

    Excelente esta segunda parte que te has marcado Antonio y que además me ha venido muy bien para poner en práctica. Ya te digo que he conseguido mejorar pero que hay varios puntos que no consigo mejorar como el caso de Ficheros JavaScript y CSS bloqueantes que Autoptimize me destroza la web si marco alguna de las opciones. Y luego el tema de la compresión de las imágenes, las subo siempre optimizadas previamente pero no me fío de poner en manos de un plugin que me comprima el resto de tamaños que autogenera WordPress.

    Saludos.

    Responder
    • 04/04/2016 a las 15:22
      Enlace permanente

      Hola, RaMGoN.

      Gracias por la visita. Me alegro que te haya gustado el artículo 🙂

      Sobre el Autoptimize, a mí me pasó algo parecido con el W3 Total Cache, que tiene una opción de minificación de JS y CSS que destrozaba el diseño. ¿Te ocurre con cualquiera de las opciones de Autoptimize por separado? Es decir, solo marcando HTML, JavaScript o CSS, de uno en uno. Quizás no puedas quedarte con solo un fichero bloqueante, pero sí reducirlos. El problema con los ficheros bloqueantes es que depende muchísimo del Theme y plugins instalados, por lo que no existe una solución universal.

      Lo que puede estar pasando es que haya alguna incidencia relacionada con el orden de carga de los ficheros JS y CSS. Autoptimize no garantiza que lo mantenga y, por la forma en que funciona, concatenando todos los ficheros en uno solo, quizás no sea posible. Hay una alternativa, Better WordPress Minify, que sí lo respeta, pero que no concatena los ficheros, con lo que seguirías teniendo los mismos ficheros bloqueantes, aunque deberías observar también una mejora en PageSpeed por minimizarlos.

      A mí me pasa un poco lo mismo que tú con las imágenes: no acaba de gustarme la idea de tener un plugin trabajando a mis espaldas 🙂 Pero es muy útil cuando ya tienes centenares de imágenes subidas más sus copias. Sí, se podría hacer por FTP, descargando las imágenes, comprimiéndolas y después subirlas de nuevo, pero puede ser un proceso muy tedioso con tantas imágenes.

      Ahora bien, para las imágenes de un solo artículo, hacerlo a mano es totalmente viable (y casi preferible para nuestra salud mental 😉 ). ¿Cómo haces para optimizar las imágenes autogeneradas por WordPress: las descargas por FTP y las optimizas, o las creas tú mismo y las subes entonces también por FTP? A este respecto, si no has probado Kraken.io, échale un vistazo, porque puede optimizar varias imágenes de una vez, tan solo arrastrándolas sobre la página, y entonces puedes descargarlas en un ZIP. La versión gratuita tiene algunas limitaciones pero son suficientes para las imágenes que pueda haber en un solo artículo.

      Espero que consigas resolver, o al menos reducir, el tema de los ficheros bloqueantes 🙂

      Un saludo!!

      Responder
      • 04/04/2016 a las 22:17
        Enlace permanente

        Ostras la de cosas que me comentas en la respuesta, a ver por partes…

        Antes de leer tus dos artículos, sólo hace unos días,decidí abandonar W3 Total Caché e instalarme WP Súper Caché junto a Better WP minify que es el que me recomiendas y la verdad es que combinado con Cloudflare que ya venía usando desde hace un año la mejora ha sido estupenda.

        Con las imágenes, a ver, optimizo y comprimo la original, las versiones que luego autogenera WordPress no, aunque como dices quizás debería. El problema es que no me fío de la compresión que me pueda hacer un plugin y de la calidad de las fotos etc resultantes (ya de por sí es nefasta la edición que hace WordPress en la autogeneración de otros tamaños)

        Probé el otro día tinypng que también tiene plugin con límite de 125 mensuales, pero lo dicho, que no me fío jeje.

        Lo de los ficheros bloqueantes es lo que no le veo solución… A todo esto ahora mismo estoy contento, en pingdom desde estocolmo estoy por debajo de 1 segundo y en gtmetrix en doble A, es el page speed insight el que peores resultados me da, en escritorio casi 90 y en móvil dependiendo del momento a veces 65 y otras 60.

        Saludos

        Responder
        • 05/04/2016 a las 11:21
          Enlace permanente

          Hola, RaMGoN:

          Espero que no te importe, pero me he permitido mirar tu página con Pagespeed y creo que lo que está lastrando mucho tu página son los plugins, que son los que más ficheros JS y CSS están metiendo. Cuando lo he probado, el servidor también estaba respondiendo bastante lento, pero diría que es algo temporal si en escritorio obtienes normalmente 90 en PageSpeed. Para el resto de puntos, la veo bastante, bastante bien.

          Creo que deberías centrar tu esfuerzo en reducir al mínimo los plugins que utilices, que es donde notarías mayor mejoría. En la primera parte del artículo hago referencia a ello, pero no siempre es fácil o posible. Por ejemplo, la caja de botones sociales, ¿es un plugin? Por el código HTML, parece que no, pero si fuese un plugin, puedes poner directamente código HTML en su lugar.

          El cuadro de suscripción a tu newsletter parece ser el Magic Box Action. No lo he usado nunca, pero quizás también podrías poner código HTML en su lugar, aunque si este plugin ofrece otros servicios (no sé, como seguimiento de las suscripciones) ya no podrías utilizarlos, claro, ni tampoco las comprobaciones que imagino que hará con los datos introducidos.

          También veo que la portada muestra “post que te puedan interesar”, “entradas recientes” y “comentarios recientes”. Ten en cuenta que cada uno de ellos supone acceder a la base de datos, hacer una búsqueda y generar la lista de elementos. Si son plugins, ¿necesitas los tres? Quizás alguno de ellos no esté generando apenas tráfico y podrías quitarlo.

          La portada es muy limpia y poco recargada, por lo que sospecho que muchos plugins no se están utilizando en la portada, sino solo en páginas interiores. Hay plugins que permiten configurar en qué páginas o posts se cargarán. Mira si tus plugins tienen esta opción. Si no, aquí entramos en terreno delicado, a veces se puede hacer por código PHP, pero eso significa que hay que analizar el PHP del plugin y eso sí que puede ser más dificil. También tienes el jetpack; este plugin tiene muchos módulos: asegúrate de tener activos sólo los que utilices.

          Para lo de las imágenes, como también me han preguntado por mensaje privado, voy a preparar un post para explicar cómo hacerlo manualmente también para las autogeneradas por WordPress con FTP y Kraken (no te preocupes, después de terminar con lo del CDN 😉 ), pero yo creo que en tu caso el principal cuello de botella no son las imágenes, sino los plugins.

          Otra opción es probar los plugins que exclusivamente optimizan “above the fold”. No los he usado, pero tienen tan pocas descargas que me hace suponer que no son muy resolutivos.

          Otra cosa, que se me olvidaba: cuando consigas reducir el número de plugins, prueba otra vez el autoptimize. Al hablar menos plugins, hay menos dependencias y posibles conflictos, con lo que quizás ahora ya no te diera problemas.

          Suerte con tu optimización 🙂

          Responder
          • 08/04/2016 a las 13:11
            Enlace permanente

            Gracias Antonio por tu análisis.

            9 plugins actualmente tengo, y nunca he tenido más. Eso no es problema. Prescindo de cualquier plugin que no me es imprescindible y los que tengo son los que necesito.

            Y en cuanto a optimización estoy contento, tengo mi WordPress bien optimizado, además con buenos tiempos de carga por debajo de 1 segundo ahora mismo al analizar en Pingdom, Gtmetrix con valoración doble A. La única cuestión o pega a mejorar que hacía en el anterior comentario era con respecto a Google Page Speed y su indicación de elementos bloqueados.

            Saludos 😉

          • 12/04/2016 a las 10:07
            Enlace permanente

            Hola, RaMGoN:

            Dejarlo en solo 9 plugins es todo un reto. Yo ahora mismo estoy con 14 plugins (he añadido dos más en las últimas semanas, pero no me han afectado al PageSpeed) y ya no sé qué hacer para reducirlos más. Lo cierto es que esa parte la tienes optimizada a tope. Lo que no entiendo es que tengas tantos ficheros CSS y JavaScript bloqueantes. Antes de que yo empezara ninguna optimización, tenía 16 plugins pero solo 11 ficheros bloqueantes. Creo que la única opción que te queda para optimizar es meterte a nivel de código de plugins y CSS para ver qué se puede hacer, pero esto ya requiere conocimientos avanzados de WordPress, y mucha paciencia.

            Por cierto, por si aún no lo has visto, ya he terminado de probar el CDN CloudFlare y he publicado una artículo para compartir los resultados, pero ya te adelanto que han sido bastante, bastante buenos, con mejoras de hasta el 30% en tiempos de descarga. La puntuación de Google PageSpeed no ha cambiado, pero sí que ha mejorado en otras herramientas de medición (Pingdom, GTMetrix y WebPageTest). La única pega que le veo, por ponerle alguna, es que funcione como un proxy y me preocupa que esto pueda afectarle al SEO o las analíticas web, aunque en CloudFlare insisten que no.

            En fin, gracias por tu recomendación de probar un CDN: ¡ha sido muy fructífero!

  • 05/09/2016 a las 19:20
    Enlace permanente

    Hola ,
    he puesto en funcionamiento algunos de los consejos que das, y de categoría, muchas gracias por tu aportación.
    Si quieres echar un vistazo a mi puntuación lo puedes ver en https://cucatu.com
    Es una tienda de complementos de moda
    Muchas gracias y un saludo

    Responder
    • 06/09/2016 a las 20:46
      Enlace permanente

      Hola, Miguel:

      Me alegro que el artículo te haya resultado útil. En efecto, tienes bastante buenas puntuaciones. Aún queda margen de mejora para reducir el código JS y CSS bloqueante del renderizado, pero éste es uno de los aspectos más complejos de optimizar y no siempre posible, pues requiere un análisis intensivo de código y diseño.

      ¡Gracias por tu comentario y un saludo!

      Responder

Deja un comentario

Tu dirección de correo electrónico no será publicada.