WordPress-is-not-slow.jpg

¿WordPress va lento? Cómo medir y optimizar la velocidad de WordPress

¿Quién no quiere un website WordPress rápido?

Para aquellos familiarizados con la fotografía, cuando ajustamos la velocidad de disparo, entran en juego dos diales: la sensibilidad (la ISO speed) y el anillo de abertura. Las combinaciones son muchas pero el escenario de resultados es bastante predecible (aunque hay que decirlo, un buen resultado técnico no es suficiente para una buena fotografía).

Pero cuando intentamos ajustar la velocidad de un web site WordPress, no ocurre lo mismo. La lista de «ajustes» que afectan la velocidad es bastante más larga y el escenario en el que nos desenvolvemos no es en absoluto predecible.

En este post Parte 1/2, aprenderemos «Quién es Quién» en términos de velocidad, con qué herramientas medir y luego analizaremos los parámetros que afectan la velocidad del lado «servidor»: El lado que implica a nuestro proveedor de alojamiento y al motor WordPress encargado de construir nuestras páginas web.

En la Parte 2/2 –Mejorando la descarga de contenido y pintado de Página de nuestro WordPress –, nos trasladaremos al lado «cliente» para enfrentarnos al mundo del –cómo se reciben los contenidos– y del –cómo los digiere un navegador–.

El objetivo de ambas publicaciones es evitar caer en el «ensayo técnico» o en la superficialidad de un listado de plugins y aprender a identificar y controlar los puntos clave causantes del 95% de los problemas de rendimiento de nuestro WordPress.


La velocidad y sus fases

Antes de empezar a jugar con los ajustes de WordPress, necesitamos entender las bases de la velocidad de una página web y cómo poder medirla.

El auténtico camino para saber si una página WordPress es rápida es medirlo todo de extremo a extremo: desde el lado server al usuario, lo que llamamos –Tiempo de carga– o «Browser page load time». Éste –Tiempo de carga– que percibimos como usuarios es la suma de cuatro fases diferenciadas. En cada una de estas fases intervienen factores distintos, por eso suelen medirse y tratarse por separado.

En éste gráfico de Newrelic es fácil visualizar la separación:

Las distintas fases que necesitamos mejorar par tener un website wordpress rápido

Tiempo de Carga graficado con Newrelic monitor

Es importante como mínimo saber que existe esta división (en negrita está destacada la tarea principal) pues son términos que mencionaremos más adelante.

  • Web application (Aplicación web): El tiempo que emplea el servidor para construir la página web que queremos ver.
  • Network (Red): La fase Red incluye tanto los tiempos de petición, transmisión como los dedicados a redireccionamientos.
  • DOM processing: (proceso de DOM) El tiempo invertido por el navegador en interpretar el código recibido convirtiéndolo en una estructura DOM, junto al tiempo destinado a interpretar y ejecutar los scripts síncronos.
  • Page rendering (Pintado de la página): En esta fase el navegador ya sabe lo que tiene que mostrar y empieza a pintar contenidos. En esta fase se incluyen los tiempos de descarga de scripts y recursos estáticos. A partir de aquí pueden sucederse cargas de contenidos asíncronas, que el usuario percibirá pero que no todas las herramientas de medición capturan.

¿Pero quién arruina la velocidad de mi WordPress?

Si quieres un website WordPress realmente rápido, tendrás que poner atención a todas las fases de velocidad del Tiempo de Carga.

WordPress es una herramienta de doble filo. Su facilidad para construir y expandirse puede convertirse en un problema de velocidad si no prestamos atención. Podemos tener el mejor y más caro de los servicios de hosting y arruinar nuestro Page load time por tener mal resuelto los tiempos de carga en el Navegador. Éste es precisamente el ejemplo mostrado en la anterior gráfica: se invierte 1 segundo en las fases web application y red, pero se necesitan 4 segundos en el navegador!!!

Un detalle a tener presente! Como administradores o editores WordPress tenemos dos velocidades!

No debemos olvidar que en WordPress hay dos entornos, luego dos velocidades. La velocidad que como usuarios percibimos al navegar por nuestro web site, la velocidad que como administradores sufrimos al manejar nuestro WordPress desde el panel de administración.

Cada una de estas «velocidades» podrá tener un tratamiento diferenciado. Usaremos pués los términos «velocidad de usuario» y «velocidad admin» para referirnos a cada una de ellas.


Por dónde empezar a mirar.

En este post trabajaremos con las velocidades Web application y network (red)

Deberemos identificar los cuellos de botella de ambas velocidades centrando la atención en estos tres actores involucrados:

  • El set de Plugins y el Tema WordPress: principales responsables de la carga de trabajo que entregamos a nuestro servidor para que éste lleve a cabo la fase deconstrucción.
  • Nuestro servidor de hosting: responsable de la construcción de las páginas (Web Application).
  • La red: involucrada en la recepción de la petición y distribución de la página y sus contenidos (Network speed).

Una única métrica para medirlo todo

!Tenemos suerte! Disponemos de una simple métrica, muy buena, para medir la suma de las fases de velocidad Web application y red, es el TTFB – Time to first byte. (Transcurso de Tiempo del Primer Byte).

TTFB nos mide el tiempo que empleamos en contactar nuestro servidor (latencia de la red), más el empleado en la construcción de la página (Web Application) y el tiempo empleado en hacernos llegar por la red el primer «bloque» o byte.

DO IT: es bueno manejarse con soltura con esta métrica. El TTFB nos ayudará a comparar de forma correcta configuraciones de servidor de red. Es un aliado para poder evaluar si las cosas van bien del lado proveedor de alojamiento.

Nuestro objetivo: TTFB < 500ms para «velocidad de usuario» (p.e. al cargar la página de inicio) , <1000ms para «velocidad admin» (p.e. al actualizar un post desde nuestro panel administración de WordPress).

Usando el navegador para medir el TTFB

No es necesario instalar ninguna herramienta, la mayoría de navegadores permiten medir el TTFB desde su sección «developers». En nuestro caso usaremos el panel Developers Tools de Chrome y en concreto la pestaña Network.
(En la documentación oficial encontrareis más información).

Cómo acceder al panel: (seleccionamos «Menu→View→Developer→Developer Tools. La combianción de téclas es ⌥+⌘+I en OSX Mac y F12+Ctrl+Shift+I en Win. Tras abrirse el panel seleccionamos la pestaña Network.

En la columna de la izquierda aparecerán filas para cada una de las peticiones que componen una página. No hay que alarmarse pues para empezar con la página principal tendremos suficiente. Es la primera petición y la que desencadena las restantes. En la siguiente captura de pantalla vemos resaltada la petición de nuestra propia página web wetopi.com:

un website WordPress rápido como este solo necesita 162.00ms

La página de inicio de Wetopi tiene un TTFB de 162.00 ms

En la captura el TTFB es de 162 ms. Éste es un excelente resultado. Más adelante detallamos el checklist a seguir para conseguir un resultado como este.

En la siguiente captura medimos la «admin speed«. Éste TTFB es bastante mayor. Es la espera que sufrimos constantemente cuando le damos al botón «Guardar» mientras escribimos artículos desde nuestro Panel WordPress.

optimizar la velocidad de WordPress en el apartado administración

Wetopi TTFB of 736.23 ms. Measuring wetopi-com/wp-admin/post.php time when saving this current post.

En el Panel Administración de WordPress, no podemos aprovechar la mayoría de técnicas de cacheado (prefabricación de páginas y consultas). Aquí necesitamos que brille la potencia de nuestro servidor y sobretodo disponer de un WordPress ligero

¿Cómo optimizar WordPress y el servidor que lo aloja?

La lista de comprobación – El Checklist

1 Validar la latencia de la conexión de nuestro proveedor.

La latencia es la parte del TTFB relacionada con la red; es el tiempo en milisegundos que tarda una unidad mínima de datos en desplazarse entre un origen y un destino.

IMPRESCINDIBLE: una latencia inferior a los 100ms dentro del continente origen, y menos de 200ms en continentes remotos.

Puedes construir tu mapa de latencias aquí: http://www.maplatency.com/

A fast WordPress site with latency from The North of France

wetopi.com sirve los contenidos desde el Norte de Francia. De ahí que las latencias inferiores se den a lo largo de Europa.

RECOMENDADO: La latencia esta estrechamente ligada a la infraestructura de tu proveedor. Si tienes problemas de latencia, a) comunícaselo a tu proveedor, b) busca proveedores de hosting que trabajen en el continente donde tu audiencia reside y traza un mapa de latencias de cada uno de ellos.

2 Aligera tu WordPress

El más común de los problemas cuando estamos frente a un elevado TTFB es un WordPress cargado de plugins.

RECOMENDADO: Instala solo los necesarios. Lanzar una cifra de «qué son muchos plugins» no es hacer ciencia, pero sí que podemos levantar una «luz de alarma» si nos enfrentamos a más de 20 plugins. Dan Norris, co-fundador de la empresa de servicios de soporte WordPress «WP Curve», tiene un buen artículo en el que recomienda no ir más allá de los 20 plugins. En wetopi estamos usando 16 plugins!

RECOMENDADO: Utiliza de forma temporal el plugin P3 Plugin Profiler
para medir el impacto de los plugins que tienes instalados.

IMPRESCINDIBLE: Valida el tema. Muchos temas de «propósito general» suelen venir con infinidad de opciones. Lo que a priori parece una ventaja, suele tener en la mayoría de los casos una contrapartida: bajo rendimiento. Una simple prueba para ver si tu tema es el causante de bajo rendimiento es comparar el TTFB de una de las páginas de tu site usando uno de los temas por defecto de WordPress.

PRECAUCIÓN: Antes de realizar experimentos con tu web site production, haz una copia de seguridad, o mejor aún: experimenta siempre en un clon o en un entorno «sandboxing».
Recuerda que cada plugin o tema que añadimos implica cambios en la base de datos y en la estructura de archivos. Y hay que tener presente que el proceso inverso «desinstalar», no siempre volverá a dejar nuestro WordPress en el mismo estado en el que estaba inicialmente.

!El sandboxing o trabajar en clones no es perder el tiempo!
Hoy en día experimentar sobre un clon del site producción está al alcance de cualquiera. Éste es uno de esos servicios añadidos que deberemos siempre exigir a cualquier hosting especializado en WordPress.

3 Optimiza la base de datos

Si nuestro WordPress lleva tiempo en marcha, es imprescindible optimizar y «limpiar» la base de datos.

RECOMENDADO: Optimiza la base de datos. Si no te sientes cómodo administrando la base de datos, puedes ayudarte de plugins como WP-Optimize. Éste plugin te asistirá en el proceso de optimizar tablas de datos y en la limpieza de registros «prescindibles». En este tutorial encontraremos un «paso a paso» detallado. Ah! no olvidemos desactivar o eliminar este plugin tras realizar las tareas de limpieza.

4 Servir las páginas rápido

Éste es otro de los puntos con impacto en el TTFB: el Hardware y el software encargados de construir y servir las páginas de nuestro WordPress

IMPRESCINDIBLE: un hosting con recursos reservados: Por ejemplo en wetopi.com usamos contenedores. El uso de contenedores permite ofrecer aislamiento y reserva de recursos tal como haríamos con máquinas virtuales, reduciendo los costes de mantenimiento y administración. Es ahí en realidad donde recae el verdadero coste de los servidores dedicados.

IMPRESCINDIBLE: un alojamiento con SSD (Solid State Disks).

EVITAR: un hosting con SSD pero sin RAID o sin solución equivalente para disponer de redundancia. Si, los SSD son más fiables pero también fallan.

RECOMENDABLE: Un servidor de páginas Nginx configurado para servir páginas WordPress. Nginx bien sintonizado junto a PHP-fpm puede sin problemas ir el doble de rápido de lo que iría una configuración estándar Apache+mod_php.

IMPRESCINDIBLE: revisa la configuración de PHP, es imprescindible tener activado el sistema de cache Opcache o equivalente, más información. Es la primera de las etapas de cacheado que debemos introducir. Dado que su gestión resulta casi transparente es una opción que podemos considerar imprescindible.

RECOMENDADO: php7. Busca un proveedor de hosting que te permita crear un entorno sandboxing o simplemente clonar tu sitio web para que así puedas validar el nuevo motor php7.
WordPress core lleva tiempo siendo compatible con php7, solo tendrás que validar que tu tema y plugins también lo son.

Em nuestro caso, esta misma página, está alojada en un «containerized server» de tamaño «Medium» donde por defecto tanto hardware, como Nginx web server estan configurados pensando en WordPress.

5 Cache

Después de introducir las mejoras de los puntos 2, 3 y 4, el siguiente paso es ayudarnos de un sistema de «Cache» en la etapa final de construcción de la página. Éste tipo de cache consiste en dejar las páginas de nuestro website «prefabricadas», quitándole trabajo a nuestro servidor. Aquí podremos mejorar mucho la velocidad de usuario pero poco podremos hacer para ayudar a la velocidad admin, la del entorno de administración de WordPress.

RECOMENDADO: Usar un plugin de cache: WP Super Cache (sencillo y eficaz), W3 Total Cache (potente pero muy complejo).
Más información: https://premium.wpmudev.org/blog/top-wordpress-caching-plugins/

6 HTTP/2

Éste es un nuevo protocolo de red. Es nuestro servidor de páginas web quien lo implementa y ofrece importantes mejoras de rendimiento. Su único punto débil es que requiere de una conexión segura.

IMPRESCINDIBLE: Si ya usas HTTPS pero no estás trabajando con este nuevo protocolo, aquí tienes mucho por mejorar. Las conexiones HTTPS ya de por sí añaden tiempos extra necesarios para el intercambio de llaves, lo que llamamos negociación. Cuenta por lo menos con 100 ms de más. HTTP/2 puede compensar sobradamente ese tiempo mediante técnicas de multiplexación. Imprescindible habilitar este protocolo.

RECOMENDADO: un moderno web server que sea capaz de negociar HTTP/2 y soporte el moderno protocolo de negociación ALPN. Las nuevas ventajas que aporta como el «Multiplexing» y la compresión de cabeceras «HTTP» te ayudarán a mejorar el –Tiempo de carga– o «Browser page load time».

Es importante que el proveedor de servicios proporcione una sencilla plataforma para gestionar los Certificados Seguros. En Wetopi por ejemplo todo site WordPress puede habilitar en segundos un certificado HTTPS LetsEncrypt gratis pasando a trabajar con HTTP/2 al instante.

Más información: https://www.keycdn.com/blog/http2-statistics/

RECOMENDADO: Si estás investigando varios proveedores de hosting, puede resultar práctico instalar un plugin de navegador. HTTP/2 and SPDY indicator es un excelente plugin para Google Chrome que permite visualizar mientras navegas si el site esta utilizando HTTP/2


Y aquí termina el checklist! Solo 6 puntos, pero los más efectivos para optimizar la velocidad de WordPress en las etapas iniciales de construcción de la página y su distribución red

NOTA: En esta primera parte, no entraremos a analizar la calidad, cantidad o estructura del contenido de un website ni las técnicas para minimizar el impacto de distribución utilizando CDNs o Multiplexación HTTP/2.

Si estás leyendo estas líneas, realmente te estás tomando en serio el cómo optimizar WordPress. No nos malinterpretes si hemos dejado por el camino algún aspecto que consideras crucial. Optimizar la velocidad de WordPress es algo complejo y este artículo intenta mostrar el camino más efectivo!

Resumidamente, somos unos techies apasionados por WordPress que hemos creado Wetopi, un hosting especializado en WordPress, para minimizar la fricción a la que todo profesional se enfrenta al trabajar y alojar proyectos WordPress.

¿No tienes una cuenta en wetopi?

Prueba gratis - Descubrirás una manera eficiente de trabajar con WordPress

Incluye servidores desarrollo Gratis.
Sin tarjeta de crédito.


[ratings]
Marc Barrobés¿WordPress va lento? Cómo medir y optimizar la velocidad de WordPress
Share this post