Nuestros amigos de WP Engine lanzaron recientemente una nueva y hermosa página de inicio creada con Beaver Builder. Compartimos un enlace a la página en el grupo de Facebook de Beaver Builders y algunas personas notaron que el tiempo de carga general de la página fue bastante alto. Nuestro buen amigo y extraordinario desarrollador de WordPress, Jon Brown, vino al rescate con una gran explicación.

La conversación de Facebook

Permítanme parafrasear la conversación aquí muy rápidamente:

Beaver Builder preocupado: ¡Hice una prueba de carga de página con la herramienta de prueba XYZ y tardó casi 10 segundos en cargarse!

Jon: La velocidad y el rendimiento son una elección de diseño y son fundamentales para las conversiones de ventas, pero eso no significa que no sean una compensación frente a otras herramientas MÁS valiosas.

Veo que la gente mira las calificaciones con letras y el tiempo total de carga a menudo sin comprender la cascada. Eso te llevará por mal camino a menos que estés mirando sitios muy simples...

Esas calificaciones de herramientas de prueba son realmente toscas e ignoran muchas realidades prácticas. Dirán que se eviten las redirecciones cuando sean para anuncios, scripts de seguimiento y otras cosas que necesariamente funcionan de esa manera. A menudo ignoran HTTP/2 y recomiendan reducir las solicitudes y concatenar activos que no importarían e incluso podrían perjudicar... No se centran en el índice de velocidad y el renderizado en la mitad superior de la página...

La carga real de la página es <1,5 s

Profundicemos más

Le pregunté a Jon si podía hacer algunas preguntas más sobre el tema del desempeño y aceptó muy amablemente. Estas son mis preguntas (de Robby) con las respuestas de Jon.

Ah, ¿mencioné que Jon dirige un taller de desarrollo personalizado llamado 9seeds, por lo que está disponible para contratarlo para ayudarlo a ajustar el rendimiento de su sitio web de WordPress?

1. Mencionaste la "cascada". ¿Puedes explicarnos un poco más qué es la cascada?

Existen muchas herramientas para evaluar el rendimiento de un sitio web. Muchos de estos dan un informe que incluye una calificación con letras fácil de entender. Sin embargo, esas calificaciones con letras son herramientas bastante contundentes, y si bien es bueno cuando obtienes todas las A, no es particularmente revelador, y mucho menos útil, cuando no ves las A directamente. La única calificación con letras que encuentro útil es para la compresión de imágenes, que es una solución fácil: ejecute sus imágenes a través de un optimizador.

Con demasiada frecuencia veo que los desarrolladores novatos y no profesionales quedan cegados por las letras. Hay muchos factores que influyen en el rendimiento web frontend y uno realmente necesita mirar la "cascada", que es solo un gráfico que muestra todas las solicitudes HTTP, cuándo comenzaron y cuándo se completaron. Utilizo WebPageTest.org para generarlos.

La "cascada" es donde "ve" cuál es el activo específico que tarda demasiado en cargarse y/o que está bloqueando la carga de otras cosas.

Finalmente, reconozca que obtener excelentes calificaciones puede requerir opciones de diseño (como eliminar controles deslizantes) y eliminar activos de terceros (como Google Analytics, HotJar, etc.) que son más valiosos para el propietario del sitio que obtener una A. No todos los sitios pueden ser diseñados para Obtener excelentes calificaciones sin sacrificios dolorosos.

2. Recomendó WebPageTest como su herramienta de prueba preferida. ¿Por qué lo prefieres y en qué se diferencia de herramientas como Pingdom, GTmetrix (y/o Google Page Speed)?

Personalmente, nunca encontré nada mejor y más flexible para hacer esto que WebPageTest.org. Sin embargo, también he usado GTMetrix, Pingdom, Google Page Speed ​​y otros en el pasado y están bien. Algunas de las nuevas, como Lighthouse, son realmente interesantes para aplicaciones web progresivas (no para el 99% de los sitios de WordPress). Ciertamente no le estoy diciendo a la gente que cambie de herramienta, use la herramienta que conoce y comprende. Si no conoce ninguna herramienta, WPT es una excelente herramienta gratuita para aprender. Simplemente vaya más allá de las calificaciones con letras y comience a comprender qué está causando esas calificaciones con letras.

3. En cuanto a “reducir solicitudes y concatenar activos”, ¿ya no es esta una mejor práctica? ¿Por qué?

Cuando la mayoría de los sitios eran HTTP, a diferencia de HTTPS, y todos los servidores web usaban el protocolo HTTP/1.1, los servidores web solo podían enviar una cantidad limitada de activos en paralelo. Cada activo (imagen, guión, hoja de estilo) se envió por separado y cada uno tenía su propia sobrecarga, lo que ralentizó el proceso. Concatenar todo lo posible redujo la cantidad de solicitudes HTTP y tuvo enormes beneficios de rendimiento.

En los últimos años, ha habido un gran impulso hacia HTTPS en todas partes y los servidores web han comenzado a admitir el nuevo protocolo HTTP/2. HTTP/2 tiene enormes ventajas como la captación previa y la carga previa, pero también puede enviar todos esos pequeños activos en paralelo, por lo que no es necesario concatenarlos. De hecho, puede ser mejor no hacerlo para que cada pequeño activo pueda almacenarse en caché de forma independiente.

Es importante tener en cuenta que esto sólo entra en juego si su servidor web admite HTTP/2 y eso sólo es posible si su sitio es HTTPS.

Dicho esto, todos los sitios en los que trabajamos estos días son HTTPS y se ejecutan en servidores compatibles con HTTP/2, por lo que ya ni siquiera pienso en concatenar activos, ¡y ciertamente no lo extraño!

4. ¿Existen otros “mitos” o recomendaciones de rendimiento obsoletas que usted desaconsejaría?

La más importante es simplemente que cada sitio puede obtener excelentes calificaciones sin hacer concesiones dolorosas, como cambios de diseño o eliminar activos de terceros que no controla. Sin embargo, eso está realmente bien porque deberías empezar a buscar algo llamado Índice de velocidad. WPT tiene un buen artículo sobre esto, pero básicamente considera cuándo el usuario percibe que la página "arriba del pliegue" está completamente cargada. Se trata de que la experiencia del usuario sea rápida, más que de que la página esté realmente completa. Esta fue una de las cosas sobre el nuevo diseño de la página principal de WP Engine, el índice de velocidad fue increíble. Eran los scripts diferidos los que tardaban mucho en cargarse y completarse.

5. ¿Tiene alguna otra herramienta, consejo o truco de rendimiento que recomendaría a alguien?

Herramientas en las que he llegado a confiar a lo largo de los años:

• WebPageTest.org – ¡Mi favorito!
• ImageOptim: aplicación de escritorio para comprimir JPG/PNG
• ImageAlpha: aplicación de escritorio para comprimir archivos PNG (principalmente reduciendo la cantidad de colores)
• CloudFlare: gratuito como CDN global masivo y WAF básico. Además de impresionantes funciones profesionales pagas, como optimización de imágenes sobre la marcha, optimización de rutas y más.

Complementos:

• WP Rocket: incluso en WP Engine, usamos WP Rocket, simplemente funciona.
• Imagify.io: optimización de imágenes basada en WordPress/nube.
• BeaverBuilder – ¡No me pagaron por decir esto! Nos llaman para realizar auditorías de rendimiento en muchos sitios y, a menudo, vemos problemas importantes de frontend y backend con otros creadores de páginas populares que no mencionaré por su nombre, pero no con Beaver Builder, razón por la cual lo usamos en nuestro propio sitio como ¡Bueno!

Gracias de nuevo, Jon, por tomarte el tiempo de guiarnos a través de un enfoque más moderno del rendimiento. Quería darle un último complemento a la agencia de Jon, 9seeds. Si estás buscando ayuda con algún tipo de desarrollo personalizado de WordPress, ¡llámalos!

Acerca de Jon Brown

Vagabundo. Desarrollador WordPress. Fotógrafo. Hígado de la Vida.