Acelera tu WordPress con estas optimizaciones, paso a paso (II)

Tabla de contenidos

• Recapitulando la primera parte de la optimización

4. 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
5. Acerca de ficheros y descargas
   1. 5.1 Reduciendo los ficheros JS y CSS 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
6. Optimizaciones extremas
   1. 6.1 Revisando las optimizaciones ya realizadas
   2. 6.2 Analizando los informes de rendimiento

• ¿Cómo afecta el PageSpeed al SEO?
• Conclusiones

¡CON UN 20% DE DESCUENTO!

Recapitulando la primera parte de la optimización

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):

 

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%):

 

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

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

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?:

 

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

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?:

 

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”.

 

¡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:

 

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 (!!!):

 

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:

 

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í:

 

“¡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:

 

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 JS y CSS 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):

 

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:

 

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:

 

¡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

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;
}

4. 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

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:

• Comet Cache (antes Zen Cache). https://cometcache.com/
• W3 Total Cache. https://es.wordpress.org/plugins/w3-total-cache/
• WP Super Cache. https://es.wordpress.org/plugins/wp-super-cache/
• WP Fastest Cache. https://es.wordpress.org/plugins/wp-fastest-cache/

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:

 

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:

 

5.3 CDN: Externaliza tus imágenes

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 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):

 

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 (como este analizador del camino crítico en el CSS).
• 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:

 

¡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:

 

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

É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.