Prueba de velocidad
El impacto empresarial de Pagespeed
La velocidad de página (o el tiempo de carga) influye directamente en las conversiones, el tiempo de permanencia en la página, la tasa de rebote, el tiempo de lectura, el posicionamiento en los resultados de Google, la experiencia del usuario y los ingresos. En los sitios de comercio electrónico, mejorar la velocidad de página aumenta las ventas, reduce la cantidad de carritos abandonados y aumenta el porcentaje de usuarios que completan el proceso de compra.
La optimización del rendimiento es una de las cosas más importantes que puede hacer para mejorar un sitio web, ya sea para mejorar la experiencia del usuario o aumentar la cantidad de ingresos generados por la empresa.
Artículo de Web.dev
https://web.dev/case-studies/vitals-business-impact
Análisis del impacto empresarial de las mejoras de Core Web Vitals directamente desde Google.
Artículo conductor
https://www.conductor.com/academy/page-speed-resources
Otro artículo con estudios de casos sólidos de las mejoras en muchas métricas que los sitios han visto después de mejorar su PageSpeed.
Informe de Deloitte
https://www.deloitte.com/ie/en/services/consulting/research/millisegundos-make-millions.html
Un análisis exhaustivo del impacto de la mejora de PageSpeed en los ingresos de la empresa.
Métricas explicadas
Artículo de Escape Creative
Esta página tiene una descripción general decente de las métricas y lo que significan.
Artículo de Corelogix
https://coralogix.com/guides/real-user-monitoring/core-web-vitals
Otro artículo útil con explicaciones bastante detalladas de varias métricas de Core Web Vitals y sus definiciones.
Documentación de Core Web Vitals de Google
https://web.dev/articles/vitals
Documentación y definiciones de Core Web Vitals directamente de Google.
Artículo de MultiDots
También tiene un desglose decente de las métricas de CWV.
¿Por qué los puntajes de las pruebas cambian cada vez que realizo una prueba de velocidad?
Hay muchos factores que influyen en la puntuación obtenida en estas pruebas. Estas variables pueden variar desde tu ubicación en relación con el sitio web, la actividad en tu servidor, las rutas y la variabilidad de la red, e incluso la actividad en segundo plano de tu dispositivo local. Siempre habrá variabilidad entre pruebas; entre todos los proveedores de pruebas de velocidad, cada prueba será diferente, independientemente de la utilizada.
Si su sitio web está bien optimizado, el rango de valores será menor y obtendrá puntuaciones más consistentes dentro del mismo rango. Sin embargo, un sitio web no optimizado tendrá puntuaciones muy variables entre pruebas. Sin embargo, como se mencionó anteriormente, siempre habrá variación entre pruebas, tanto para dispositivos móviles como para computadoras de escritorio.
Nota: Sus puntuaciones reales se miden mejor como promedio de varias pruebas de velocidad de página. Generalmente realizo tres pruebas antes de promediarlas.
Las puntuaciones de PageSpeed para dispositivos móviles son las únicas que importan
La razón por la que el rendimiento móvil es lo único que importa es múltiple.
Mejorar las puntuaciones móviles mejora inherentemente las puntuaciones de escritorio.
La fuente de los problemas de velocidad de la página (CSS, JS, imágenes no optimizadas, etc.) no es específica de los dispositivos móviles o de escritorio, sino que sus impactos son universales y los sienten tanto los usuarios de computadoras de escritorio como los móviles.
Sin embargo, los impactos de cada problema de rendimiento se agravan en los dispositivos móviles y el impacto de estos perjuicios en el rendimiento es mayor.
No existen optimizaciones únicas que solo mejoren el rendimiento en dispositivos móviles o en computadoras de escritorio. Al mejorar el rendimiento en dispositivos móviles, se mejora el rendimiento en general, incluido el de computadoras de escritorio.
Los dispositivos móviles presentan una mayor variabilidad entre los resultados de las pruebas
Existe una mayor variabilidad en las puntuaciones. Si solo se basara en las puntuaciones de escritorio, podría fácilmente caer en el error de pensar que no es necesario optimizar nada más.
Es bastante fácil lograr que un sitio de escritorio tenga un tiempo de carga inferior a 1 segundo, y obtener 90+ o 100/100 en escritorio generalmente es pan comido, pero eso es solo en escritorio.
Los problemas de rendimiento tienen un mayor impacto en los dispositivos móviles
El tiempo de carga de una computadora de escritorio en menos de 1 segundo puede ser de entre 2 y 6 segundos en un dispositivo móvil, potencialmente peor debido a que las computadoras de escritorio son mucho más potentes que los dispositivos móviles.
Esto se debe a que las condiciones de la red pueden cambiar (la cobertura celular o la distancia desde un punto de acceso a la red Wi-Fi), y la carga del dispositivo también está en constante cambio. Cada kilobyte adicional de datos (especialmente imágenes) tiene un efecto mucho mayor en el rendimiento de un dispositivo móvil que en el de un ordenador de escritorio.
Una imagen de 60 KB frente a una de 30 KB puede no afectar la puntuación total de rendimiento en computadoras de escritorio (sobre 100), pero la diferencia de tamaño sin duda puede tener un impacto notable en dispositivos móviles. Las puntuaciones en computadoras de escritorio pueden mostrar 0 CLS, pero esto puede ser engañoso, ya que los dispositivos móviles pueden tener una gran cantidad de CLS al acceder al mismo sitio web.
Las pruebas de velocidad de página móvil se realizan en condiciones simuladas controladas
Estas condiciones simuladas son equivalentes al «peor escenario posible» de un dispositivo con poca potencia (actualmente, el objetivo simulado es un Moto G Power).
La ponderación de PageSpeed de Google en las clasificaciones se clasifica según la velocidad de la página móvil primero, siempre , sin excepción.
El hecho de que la mayor parte del tráfico de tu sitio web provenga de ordenadores o dispositivos móviles es irrelevante para la clasificación de Google. A Google no le importa el rendimiento en ordenadores al clasificar un sitio web. Más del 80 % del tráfico de internet proviene de dispositivos móviles, y Google calcula su clasificación en consecuencia. Incluso si la mayoría de los usuarios de tu sitio web navegan desde ordenadores, tu puntuación en dispositivos móviles es la única que se tendrá en cuenta como factor de clasificación.
Las puntuaciones de escritorio son irrelevantes
Las puntuaciones de escritorio tienen tan poco valor diagnóstico que resultan prácticamente inútiles. De hecho, su único valor diagnóstico es como métrica inversa. Unas puntuaciones bajas en escritorio indican una sola cosa: una gran cantidad de problemas de rendimiento que deben resolverse. Unas puntuaciones buenas en escritorio no indican nada sobre la optimización de un sitio web.
Tienen tan poco valor que pueden ignorarse sumariamente; las puntuaciones de escritorio son irrelevantes.
La gran mayoría de las veces, las capturas de pantalla de un sitio web con puntuaciones altas de 90 puntos muestran puntuaciones de rendimiento de escritorio. Quien elogie sus puntuaciones de rendimiento de escritorio se está engañando a sí mismo y a sus clientes, y la reacción inmediata debería ser el escepticismo y abrir la consola del navegador inmediatamente con Inspeccionar para ejecutar una prueba móvil Lighthouse en su sitio web.
La cantidad de “expertos” en rendimiento que afirman que un buen rendimiento de escritorio significa que su sitio está bien optimizado es demasiado alta.
Ejemplo de rendimiento de escritorio vs. rendimiento móvil
Este es un excelente ejemplo de un sitio con un buen rendimiento en computadoras de escritorio y un bajo rendimiento en dispositivos móviles. Siempre verifique las puntuaciones móviles de un sitio cuando afirma tener un rendimiento excelente, ya que casi siempre se refieren a computadoras de escritorio.
La versión de escritorio obtiene muy buenos resultados, con un CLS prácticamente nulo y todas las métricas muestran una carga en menos de un segundo. Sin embargo, las puntuaciones para móviles difieren completamente de las puntuaciones de rendimiento para escritorio. Google incorporará las bajas puntuaciones de PageSpeed para móviles de este sitio como métricas de rendimiento en su puntuación de posicionamiento, sin dar ninguna importancia a la puntuación para escritorio.
TTFB
Componentes TTFB
DNS
El tiempo de búsqueda DNS es el tiempo que se tarda en consultar y recibir una respuesta de un servidor DNS con la dirección IP del dominio. Si la respuesta DNS no se almacena en caché local, este proceso puede aumentar considerablemente el tiempo de respuesta total (TTFB).
Cómo optimizar la parte DNS de TTFB
Usa un proveedor de DNS rápido con caché DNS, como Cloudflare. Aunque no lo uses como CDN, te recomiendo encarecidamente que lo uses como tu proveedor de DNS.
Conectar
El tiempo de conexión incluye el tiempo que tarda en realizarse el protocolo de enlace TCP, esencial para establecer una conexión TCP antes de poder enviar datos. Esto suele implicar el envío de paquetes SYN y ACK entre el cliente y el servidor para confirmar la conexión.
Cómo optimizar la parte de conexión de TTFB
Siga los pasos de la parte de optimización de TCP de la sección VPS a continuación.
SSL
El tiempo de enlace SSL/TLS es el tiempo que se tarda en autenticar el servidor (y opcionalmente el cliente), así como en negociar el cifrado y el intercambio de claves para la sesión. Este proceso implica varios pasos de intercambio de mensajes y puede añadir un tiempo considerable al TTFB, especialmente cuando se establece una nueva sesión sin utilizar técnicas de reanudación de sesión.
Cómo optimizar la parte SSL de TTFB
La sección de optimización SSL a continuación tiene una multitud de recursos sobre cómo optimizar la velocidad de conexión SSL.
Envío
Este componente mide el tiempo que tarda el servidor en enviar el primer byte de la respuesta al cliente una vez que este termina de procesar la solicitud. Esto incluye el tiempo que tarda en enviar los datos iniciales del encabezado de respuesta HTTP.
Cómo optimizar la parte de envío de TTFB
Compresión Brotli/Gzip
Utilice técnicas de compresión como GZIP o Brotli para comprimir los datos enviados desde el servidor. Esto reduce el tamaño de los datos transmitidos, lo que reduce el tiempo que tarda el primer byte en llegar al cliente. Es especialmente eficaz para contenido de texto como archivos HTML, CSS y JavaScript.
Optimice la configuración de su servidor
Asegúrese de que su servidor esté bien configurado para gestionar las solicitudes de forma eficiente. Esto incluye ajustar la configuración del software del servidor web (como Apache o Nginx) para un mejor rendimiento mediante el ajuste de los procesos de trabajo, la configuración de keep-alive y la gestión de las solicitudes de los clientes.
Considere utilizar un proxy inverso o un balanceador de carga que pueda administrar las conexiones y distribuir el tráfico de manera efectiva, minimizando los retrasos en el envío de datos.
Utilice HTTP/2 o HTTP/3
Implemente HTTP/2 o HTTP/3, ya que ambos protocolos ofrecen mejoras con respecto a HTTP/1.1 al reducir la sobrecarga asociada al envío de datos. HTTP/2 introduce la multiplexación, que permite combinar múltiples solicitudes y respuestas en una sola conexión, lo que reduce la latencia asociada al establecimiento de múltiples conexiones TCP. HTTP/3 mejora aún más el proceso al reducir el tiempo de establecimiento de la conexión y minimizar el impacto de la pérdida de paquetes.
.
Minimizar los retrasos en el protocolo de enlace TLS
- Si usa HTTPS (recomendado), optimice la configuración de SSL/TLS eligiendo conjuntos de cifrado más rápidos que requieran menos potencia computacional y que admitan técnicas como el inicio falso TLS y la reanudación de sesión. Estos métodos pueden reducir significativamente el tiempo necesario para establecer una conexión segura, acelerando así la fase de envío.
- Considere utilizar una red de distribución de contenido (CDN) con nodos de borde que admitan funciones TLS modernas y estén más cerca de sus usuarios para disminuir la distancia que deben recorrer los datos.
(En la sección de optimización de SSL anterior encontrará estrategias de optimización de SSL adicionales)
Revisar y optimizar el código de la aplicación
Analice y optimice el código backend de su aplicación. Asegúrese de que cualquier script del lado del servidor (como PHP, Python o Node.js) esté optimizado para un rendimiento óptimo. Esto incluye reducir los tiempos de consulta a la base de datos, optimizar algoritmos y garantizar un procesamiento de datos eficiente.
Utilice herramientas de rendimiento del lado del servidor para supervisar e identificar cuellos de botella en tiempo real.
Esto también abarca todas las optimizaciones de WordPress a continuación.
Red de distribución de contenido (CDN)
Implementar su contenido a través de una CDN puede reducir significativamente el tiempo de envío. Las CDN almacenan copias de sus datos en múltiples ubicaciones geográficas, lo que reduce la distancia física entre el servidor y el cliente, minimizando así el tiempo de transferencia de datos.
Optimización de bases de datos
Optimice las consultas de la base de datos para garantizar que se ejecuten con rapidez y no se conviertan en un cuello de botella. Una indexación eficiente, la optimización de consultas y las estrategias de almacenamiento en caché adecuadas pueden reducir el tiempo que tarda el servidor en recuperar datos y comenzar a enviarlos al cliente.
(Optimización de bases de datos tiene una sección a continuación)
Esperando (Tiempo de procesamiento del servidor)
Este es el tiempo que tarda el servidor en procesar la solicitud y preparar una respuesta. Incluye el tiempo que tarda en ejecutar scripts del servidor, consultar bases de datos y cargar los recursos necesarios para generar la respuesta.
Cómo optimizar la parte de espera de TTFB
Optimiza WordPress a nivel de aplicación. Aquí es donde entra en juego la optimización de WordPress. JavaScript en línea, el peso del HTML, CSS en línea, etc. Aquí es donde el DOM HTML y el tamaño del documento entran en juego.
Recepción
Este componente final representa el tiempo que tarda el cliente en recibir el primer byte de datos del servidor.
Cómo optimizar la parte de recepción de TTFB
1. Reducir el tamaño de respuesta del servidor
Para la parte receptora, tanto los archivos CSS y JavaScript en línea como los externos son importantes, ya que pueden influir en el tamaño de la respuesta inicial del servidor. Mientras que los recursos en línea aumentan directamente el tamaño del documento HTML, los archivos externos contribuyen a la cantidad total de bytes que el navegador debe procesar tras recibir el HTML inicial.
Reducir el tamaño total de estos recursos (tanto internos como externos) puede reducir el tiempo que tarda el cliente en recibir datos del servidor. Técnicas como la minificación y compresión (mediante GZIP o Brotli) de estos recursos son directamente aplicables en este caso.
2. Optimice la carga útil inicial
Entregue solo lo necesario para la renderización inicial de la página. Esto podría implicar optimizar el HTML para incluir solo los CSS/JS esenciales en línea y posponer todo lo demás.
Para los recursos externos, ajuste el tiempo de su obtención (a través de los atributos async y defer en las etiquetas de script) para que no obstruyan la carga inicial, retrasando potencialmente el inicio de la transmisión de datos.
Siga los pasos de optimización de WordPress a continuación
3. Utilice HTTP/2 o HTTP/3
Tanto HTTP/2 como HTTP/3 mejoran la eficiencia de la transferencia de datos. La función de multiplexación de HTTP/2 permite combinar múltiples solicitudes y respuestas entre el cliente y el servidor en una sola conexión, lo que reduce la sobrecarga causada por múltiples conexiones.
HTTP/3 mejora esto aún más al reducir la latencia de conexión y transporte, utilizando QUIC, que puede comenzar a enviar datos tan pronto como se establece la conexión, disminuyendo potencialmente la demora en la recepción del primer byte.
4. Uso eficiente de TCP y ajuste de ventanas TCP
Optimice la configuración de TCP, incluyendo la ventana de congestión inicial, que puede afectar la cantidad de datos que se pueden enviar al inicio de la conexión. Una ventana más grande permite que haya más datos en tránsito en la red, lo que podría reducir el tiempo hasta la recepción del primer byte.
Asegúrese de que la pila TCP del servidor esté optimizada para una entrega rápida, lo que incluye consideraciones de inicio lento de TCP, reconocimientos y retransmisiones.
La optimización de TCP es una subsección de la sección VPS
ByteCheck (gratis)
Byte Check proporciona un desglose muy claro de TTFB y lo divide en sus componentes constituyentes (DNS, tiempo de conexión, SSL, envío, espera, recepción).
Byte Check indica un tiempo de procesamiento de 16 MS desde el servidor de origen, que se divide en un componente independiente denominado TTFB. En la mayoría de las demás pruebas de velocidad, se muestra el valor total de 154 MS, que comprende los 6 componentes de la derecha, como TTFB.
Esto significa que GTMetrix, Debug Bear, etc., mostrarán el TTFB como el tiempo total antes de que los archivos comiencen a mostrarse en el navegador del usuario. Si bien Debug Bear y GTMetrix incluyen pequeñas subsecciones en sus gráficos de cascada para la solicitud inicial del documento HTML, Bytecheck es mucho más fácil de interpretar y leer, y es la mejor herramienta para medir el TTFB.
Byte Check es una prueba de velocidad útil para utilizar como complemento junto con Debug Bear/GtMetrix/Pagespeed Insights.
Nota
Aviso a quienes usan Bytecheck: asegúrense de que el código de respuesta HTTP no sea un 403. Cloudflare suele bloquear Bytecheck, devolviendo un 403, pero Bytecheck no lo muestra inmediatamente a menos que revisen el código de respuesta HTTP. Por lo tanto, sus resultados pueden parecer excelentes, pero en realidad se deben a que solo carga una página de error 403 básica.
Crédito a /u/TTEH3 en Reddit.
¿Qué es un buen TTFB?
Menos de 300 MS para escritorio y menos de 500 para dispositivos móviles.
Al contrario de lo que dicen muchas guías en línea, un TTFB superior a 300 ms en una computadora de escritorio es inaceptable . Muchos sitios web indican un TTFB inferior a 800 ms, lo cual, dicho de otro modo, es… generoso. Es un TTFB ridículamente alto, un valor reservado para los perezosos. En los sitios que optimizo, el TTFB suele rondar los 200 ms después de la optimización. Me enojo conmigo mismo cuando no puedo bajar de 300. En un buen proveedor de alojamiento web, puedo alcanzar los 150-200 ms cuando el sitio está completamente optimizado, dependiendo de cómo se haya creado. Cuando tu sitio web tiene un TTFB alto, lo notas. Reducir el TTFB es fundamental para el rendimiento de la velocidad de la página.
TTFB móvil
Nota: El TTFB móvil siempre será mayor que el de escritorio . El TTFB inferior a 300 MS corresponde a puntuaciones de escritorio; se recomienda un máximo de ~400-500 MS para el TTFB móvil, si es posible. Dado que el TTFB tiene 6 componentes diferentes, puede ser un poco difícil reducir el tiempo de TTFB a un valor razonable, así que prepárese para un poco de prueba y error.
Si su sitio está probando con un TTFB de escritorio superior a 300 MS o un TTFB móvil superior a 500 MS, es probable que aún tenga oportunidades de optimización sin implementar.
No necesitas planes de prueba de velocidad pagados
Todo lo necesario para optimizar un sitio web se puede obtener con pruebas de velocidad gratuitas. Los planes de pago para pruebas de velocidad son completamente innecesarios a menos que se desee una monitorización continua. Aun así, al final de esta sección se incluyen dos herramientas gratuitas de código abierto y alojadas por el usuario para una monitorización continua.
Gráficos de cascada
Cómo analizar un gráfico de cascada
https://www.keycdn.com/blog/waterfall-analysis
Peso de la página y reducción de la cantidad de archivos que se cargan.
Uno de los principales objetivos al optimizar es reducir el peso total (tamaño en KB/MB) de una página al mínimo absoluto posible.
Para las siguientes secciones, utilizo un gráfico de cascada de GTMetrix para las capturas de pantalla; sin embargo, cualquier gráfico de cascada tendrá la misma información.
- Ingrese la URL que desea probar para acelerar:
- Puedes ver el peso del archivo de una página en la parte inferior del gráfico de cascada en GTMetrix, otra razón por la que es una de las herramientas más útiles que puedes usar para pruebas de velocidad.
- La otra métrica importante que estás intentando reducir es la cantidad de solicitudes, que se muestra en la parte inferior de la cascada de GTMetrix.
Tanto el peso total de la página como la cantidad de solicitudes deben reducirse a los valores mínimos posibles que pueda alcanzar.
- Así es como se ordena por tamaño de archivo:
¿Cuál es el peso de página ideal?
El peso ideal de una página es de 500 kb o menos. La página de inicio de mi sitio web, que ejecuta Elementor y WooCommerce, pesa 168 kb antes de la interacción del usuario.
Cómo filtrar por tipo de archivo
Así se filtra por tipo de archivo en GTMetrix. Debug Bear tiene filtros similares:
Cada solicitud adicional (incluso si son increíblemente pequeñas, incluso una solicitud de 0,3 kb) añade latencia. Elimine tantas solicitudes como sea posible. Retrasar los archivos JavaScript anulará por completo su impacto en la velocidad de la página, ya que no se descargarán antes de la interacción del usuario. Así es como se prueba el peso de la página de mi sitio con 168 kb.
La página parecerá cargarse instantáneamente y el JavaScript no afectará el tiempo de carga inicial. El usuario no experimentará retrasos ni impactos visibles en el rendimiento al cargar el JavaScript retrasado.
Cómo identificar qué archivos necesitan ser optimizados
Los principales objetivos de optimización son sus archivos de Javascript e imagen. Los archivos CSS se pueden gestionar de una sola vez eliminando los CSS no utilizados (salvo que sea necesario agregar exclusiones a la función de eliminación de CSS, por supuesto).
Basándonos en la imagen de arriba, analicemos cada archivo. Lazysizes.min.js no se puede retrasar ni diferir. Esto se debe a que lazysizes es un archivo JS de optimización que modifica la carga de imágenes para mejorar la velocidad de la página.
Tingle.js, aunque pequeño (3 kb), probablemente sea un archivo superfluo que no necesita cargarse inmediatamente. Debería retrasarse (y añadirse una exclusión si falla al retrasarlo con «delay all js» o simplemente eliminar la palabra clave). Se recomienda reducir al máximo la carga de archivos, incluso si son pequeños.
Keen_slider.js se puede retrasar sin problemas. Un control deslizante requiere la interacción del usuario para funcionar, por lo que, a menos que esté configurado para reproducirse automáticamente entre diferentes fotos y esta función se necesite inmediatamente después de cargarlo, se puede retrasar sin problemas. Si el plugin del control deslizante es sensible al retraso y el archivo no se puede retrasar, agregue una exclusión.
Global.js parece algo que Klaviyo cargaría. Si expandes el elemento de cascada, puedes ver de dónde proviene el archivo: un plugin, un tercero, etc. Con base en esa información, puedes determinar si es un buen objetivo para retrasarlo.
Main.js y Klaviyo.min.js son archivos de terceros, de Order Groove y Klaviyo, respectivamente. De los dos, Order Groove tiene más probabilidades de presentar algún fallo, ya que parece formar parte del conjunto de funciones de comercio electrónico. Klaviyo se utiliza para análisis y se puede retrasar sin problemas. El archivo de Order Groove requiere pruebas para garantizar que no afecte a ninguna funcionalidad.
Recomiendo probar retrasando cada archivo .js individualmente, uno a la vez, para estar seguro. No se debe comprometer el rendimiento al no retrasarlos, si es posible. Reitero, se debe reducir al máximo la cantidad de archivos que se cargan al cargar la página inicial.
¿Qué prueba de velocidad utilizar para el diagnóstico?
Para dispositivos móviles, la mejor herramienta para realizar pruebas será Debug Bear .
Debug Bear es superior a Pagespeed Insights para puntuaciones móviles y proporciona información más práctica sobre lo que necesitas optimizar. Puedes acceder al gráfico de cascada para ver los tiempos de carga de archivos específicos, así como una lista de todos los archivos CSS y JS que se cargan en la página que estás probando. Puedes ejecutar la prueba en URLs individuales, como la página de inicio, la página «Acerca de», la página de servicio o cualquier otra página que quieras probar en el sitio.
Si tu puntuación móvil es buena en Debug Bear, debería ser lo suficientemente buena para Google.
Pestaña de red de las herramientas de desarrollo de Chrome
Se puede acceder a la pestaña de red de las herramientas de desarrollo de Chrome haciendo clic derecho en una página, seleccionando «Inspeccionar» y luego haciendo clic en la pestaña de red en la parte superior del panel. Si bien la pestaña de red en las herramientas de desarrollo proporciona información menos detallada que Debug Bear , se puede acceder a ella simplemente haciendo clic derecho en una página y seleccionando «Inspeccionar». Resulta útil para un análisis rápido del árbol de solicitudes de un dominio, pero se recomienda Debug Bear para un análisis exhaustivo .
Prueba de velocidad de páginas móviles
Nota: Para las pruebas de velocidad móvil (las únicas que realmente importan), Pagespeed Insights es la solución definitiva, pero su utilidad diagnóstica (para determinar qué se necesita optimizar) es prácticamente nula. Es necesario usar herramientas de terceros para identificar los problemas.
Google PageSpeed Insights (gratis)
Necesitas superar las pruebas de velocidad de Google para tu SEO. Otros sitios pueden ofrecer pruebas de velocidad de página para móviles y quizás tengan un gráfico de cascada para móviles, pero la mejor opción para las pruebas móviles es la herramienta PageSpeed Insights de Google.
Mientras intentas ofrecer al usuario la mejor experiencia posible en dispositivos móviles (ya que la mayor parte del tráfico del sitio web provendrá de dispositivos móviles), la única empresa que debes consultar para las pruebas de velocidad es Google, ya que son los guardianes del SEO. Bing deriva menos del 5% del tráfico a tus sitios que Google, y si tus métricas satisfacen a Google, también lo harán Bing. Solo te importa optimizar para Google y el SEO.
Debug Bear (Gratis)
https://www.debugbear.com/test/website-speed
Utilizo Debug Bear para diagnosticar mis problemas, pero Pagespeed Insights para evaluar cuánto más me queda por optimizar.
Siempre buscas optimizar tu puntuación móvil en PageSpeed Insights. PageSpeed Insights es la única métrica que Google utiliza para posicionar los resultados de búsqueda. Debug Bear te permite realizar diagnósticos para que sepas qué corregir.
No puedo enfatizar esto lo suficiente: las métricas que PageSpeed Insights mide para dispositivos móviles son las únicas que importan. Las puntuaciones de Debug Bear solo tienen valor real como indicador de tu progreso y de lo que necesitas corregir.
Si su puntuación móvil mejora en Debug Bear, sus puntuaciones de rendimiento móvil en Pagespeed Insights mejorarán junto con ella.
Herramientas de depuración de Bear (gratuitas)
https://www.debugbear.com/tools
Colección muy útil de herramientas gratuitas para probar la velocidad de la página.
Herramientas de laboratorio amarillas (gratis)
Versión en línea (gratis)
Yellow Lab Tools tiene algunas métricas únicas que pueden ser útiles en algunos casos para diagnosticar problemas que otros escáneres pueden no indicar.
Imagen de Docker (gratuita)
https://github.com/YellowLabTools/YellowLabTools
Imagen de Docker para Yellow Lab Tools.
Pruebas de velocidad de PageSpeed en masa
Experto (Gratis)
Pruebe en masa varias páginas de un sitio a la vez.
Optimice las puntuaciones de datos de laboratorio de PageSpeed Insights
Optimice siempre para datos de laboratorio. Casi todos los tutoriales le indicarán que se centre en los datos de campo, es decir, los tiempos de carga en los dispositivos de los usuarios reales. Al realizar un análisis de velocidad de página, las puntuaciones que se reportan inmediatamente (independientemente del servicio utilizado) son «datos de laboratorio». Al mejorar las métricas de las pruebas de laboratorio, se mejora inherentemente el tiempo de carga real (los datos de campo) para los usuarios. Las métricas de datos de laboratorio existen por una razón. Las pruebas de velocidad de página «sintéticas» (datos de laboratorio) son las únicas puntuaciones que realmente se pueden optimizar, ya que eso es lo que generan las pruebas de velocidad de página. Las métricas del mundo real (datos de campo) se recopilan durante un período de 30 días, lo cual no tiene ninguna utilidad de diagnóstico.
Rendimiento en el mundo real
La velocidad puede parecer artificialmente más rápida en las pruebas de velocidad (es decir, sus puntuaciones han mejorado); sin embargo, podría cargar más rápido que lo reportado en las pruebas de velocidad en condiciones reales. Las mejoras en los tiempos de carga en condiciones reales son más importantes que los resultados de los datos de laboratorio de Pagespeed Insights, pero están directamente relacionadas con los datos de campo. Las mejoras en los datos de laboratorio implican mejoras en condiciones reales, y esto se reflejará en la siguiente ronda de datos de campo recopilados durante los 30 días posteriores a la implementación de las optimizaciones.
Los resultados de laboratorio de las pruebas de PageSpeed suelen ser precisos (y tener PageSpeed Insights es fundamental para el SEO), pero la medición en situaciones reales debe basarse en la propia percepción y siempre en la observación. En algunos casos, una prueba de PageSpeed puede indicar un rendimiento bueno y sólido, pero cargarla y ver los tiempos puede indicar que es más lento (raramente).
Es muy raro que la velocidad en el mundo real no coincida con el resultado de una prueba de velocidad, pero ocurre en ocasiones, por lo que siempre verifique qué tan rápido se carga el sitio en sus propios dispositivos, en lugar de realizar pruebas de velocidad sintéticas (herramientas de medición de velocidad de página).
Si hay una discrepancia entre el rendimiento en el mundo real y sus pruebas de velocidad, algo anda mal y debe diagnosticarlo, y es posible que deba restaurar una copia de seguridad si no puede revertir los efectos de los cambios que realizó por algún motivo.
Es necesario mejorar tanto el tiempo de carga en el mundo real como los resultados de la prueba de PageSpeed en PageSpeed Insights, pero los datos de laboratorio son siempre la mejor heurística para utilizar y el desajuste es tan poco probable que debería considerarse un caso extremo.
No todas las pruebas de velocidad son iguales
Algunos proveedores de pruebas de velocidad arrojan resultados extremadamente inexactos. Dotcom Tools es uno de ellos. Para reiterar, los únicos resultados de las pruebas que realmente importan son los de Google. Todo lo demás es solo para análisis.
¿Cuál es la puntuación PageSpeed móvil ideal en PageSpeed Insights?
Cualquier sitio web que optimice debería tener idealmente una puntuación móvil de 90 o más una vez optimizado. Para la gran mayoría de los sitios, esto es fácil de conseguir. Cualquiera que lea esta guía debería poder lograrlo en cualquier sitio web normal una vez implementados la mayoría de los pasos. Algunos sitios web dinámicos requieren estrategias especiales adicionales que aún no se han incluido en la guía, pero estos son casos especiales y no la norma.
¿Cómo es una puntuación móvil ideal?
Monitoreo continuo
El Monitoreo Continuo medirá las puntuaciones de sus datos reales y de laboratorio a lo largo del tiempo, lo cual es una métrica útil, ya que las fluctuaciones tienen utilidad diagnóstica. Estas dos herramientas son autoalojadas y no son herramientas/servicios SaaS. Recomiendo obtener un VPS independiente para alojarlas y así evitar una carga innecesaria en un servidor que aloja sitios web en producción o de prueba. Existen proveedores de VPS económicos mencionados en la sección de alojamiento que son útiles para este propósito.
Herramientas autoalojadas
Estos pueden alojarse en su máquina local o en un servidor VPS económico.
Lighthouse CI (Gratis)
https://github.com/GoogleChrome/lighthouse-ci
Lighthouse CI es un conjunto de herramientas que hacen que ejecutar, guardar, recuperar y afirmar continuamente los resultados de Lighthouse sea lo más fácil posible.
Lighthouse CI requiere un servicio de CI, estos se enumeran aquí, opciones gratuitas incluidas:
https://github.com/GoogleChrome/lighthouse-ci/blob/main/docs/introduction-to-ci.md
Gitlab CI (gratis)
https://docs.gitlab.com/ee/ci/quick_start
Servidor CI Lighthouse (gratuito)
https://github.com/GoogleChrome/lighthouse-ci/blob/main/docs/server.md
Frontend visual/panel de control de Lighthouse CI
SiteSpeed.io (Gratis)
https://github.com/sitespeedio/sitespeed.io
Otro kit de herramientas de monitoreo continuo gratuito de código abierto, que presenta visualmente datos más útiles que Lighthouse CI.
Disponible como una imagen Docker (multiplataforma, incluida compatibilidad con Windows) o un paquete NPM NodeJS (Linux).
Análisis de la competencia y comparativo
La aplicación más ligera (gratuita)
Pruebas de velocidad de comparación/competencia gratuitas contra múltiples dominios.
Debug Bear (Gratis)
https://www.debugbear.com/docs/compare-pages
Nota 1: Requiere una cuenta gratuita
Nota 2: Según mis pruebas, las estadísticas de las pruebas de velocidad de comparación no coinciden y tienen peores puntuaciones que una prueba de velocidad estándar de Debug Bear. Las pruebas de velocidad estándar de Debug Bear son más precisas.
Prueba de página web (gratis)
https://www.webpagetest.org/video/ Interfaz bastante deficiente, pero ofrece pruebas de velocidad comparativas con múltiples URL