Existen muchos factores que contribuyen al rendimiento de las páginas web. Las puntuaciones de rendimiento de Lighthouse suelen cambiar debido a la variabilidad inherente de las tecnologías web y de red, incluso si no hubo un cambio en la página.
Fuentes de variabilidad
La variabilidad en la medición del rendimiento se introduce a través de varios canales con diferentes niveles de impacto. A continuación, se muestra una tabla que contiene varias fuentes comunes de variabilidad de métricas, el impacto típico que tienen en los resultados y la medida en la que es probable que ocurran en diferentes entornos.
| Origen | Impacto | Usuario final típico | PageSpeed Insights | Lab controlado |
|---|---|---|---|---|
| No determinismo en la página | Alto | PROBABLE | PROBABLE | PROBABLE |
| Variabilidad de redes locales | Alto | PROBABLE | ES POCO PROBABLE | ES POCO PROBABLE |
| Variabilidad de red de nivel 1 | Medio | POSIBLES | POSIBLES | POSIBLES |
| Variabilidad del servidor web | Bajo | PROBABLE | PROBABLE | PROBABLE |
| Variabilidad del hardware del cliente | Alto | PROBABLE | ES POCO PROBABLE | ES POCO PROBABLE |
| Contención de recursos de cliente | Alto | PROBABLE | POSIBLES | ES POCO PROBABLE |
| No determinismo en el navegador | Medio | SEGURO | SEGURO | SEGURO |
A continuación, se incluyen descripciones más detalladas de las fuentes de varianza y el impacto que tienen en las combinaciones más probables de tiempo de ejecución y entorno de Lighthouse. Si bien los enfoques de limitación aplicada y simulados podrían usarse en cualquiera de estos tres entornos, el usuario final típico usa una limitación simulada.
No determinismo de la página
Las páginas pueden contener una lógica no determinista que cambia la forma en que un usuario experimenta una página; es decir, una prueba A/B que cambia el diseño y los recursos cargados o una experiencia del anuncio diferente según el progreso de la campaña. Esta es una fuente de variación intencional e irremovible. Si la página cambia de una manera que afecta el rendimiento, Lighthouse debería poder identificar este caso. La única mitigación es por parte del propietario del sitio para garantizar que se pruebe la misma versión de la página entre ejecuciones diferentes.
Variabilidad de la red local
Las redes locales tienen una variabilidad inherente de la pérdida de paquetes, la priorización de tráfico variable y la congestión de la red de la red de acceso. Los usuarios con routers económicos y muchos dispositivos que comparten ancho de banda limitado suelen ser los más susceptibles de esto. La limitación aplicada mitiga parcialmente estos efectos mediante la aplicación de una latencia de solicitud mínima y una capacidad de procesamiento máxima que enmascara los reintentos subyacentes. La limitación simulada mitiga estos efectos reproduciendo la actividad de la red por su cuenta.
Variabilidad de red de nivel 1
Las interconexiones de red suelen ser muy estables y tienen un impacto mínimo, pero las solicitudes entre ubicaciones geográficas, es decir, cuando se mide el rendimiento de un sitio chino de EE.UU., pueden comenzar a experimentar un alto grado de latencia ingresada a partir de los saltos de red de nivel 1. La limitación aplicada enmascara de forma parcial estos efectos con la limitación de la red. La limitación simulada mitiga estos efectos reproduciendo la actividad de la red por su cuenta.
Variabilidad del servidor web
Los servidores web tienen una carga variable y no siempre responden con la misma demora. Por lo general, los sitios con menos tráfico con infraestructura de hosting compartida son más susceptibles a este problema. La limitación aplicada enmascara parcialmente estos efectos mediante la aplicación de una latencia de solicitud mínima en la limitación de la red. La limitación simulada es susceptible a este efecto, pero el impacto general suele ser bajo en comparación con otra variabilidad de la red.
Variabilidad del hardware del cliente
El hardware en el que se carga la página web puede tener un gran impacto en el rendimiento. La limitación aplicada no puede hacer mucho para mitigar este problema. La limitación simulada mitiga parcialmente este problema porque limita el tiempo de ejecución teórico de las tareas de la CPU durante la simulación.
Contención de recursos del cliente
Otras aplicaciones que se ejecutan en la misma máquina mientras se ejecuta Lighthouse pueden causar contención de los recursos de CPU, memoria y red. El software malicioso, las extensiones de navegador y el software antivirus tienen impactos particularmente fuertes en el rendimiento web. Los entornos de servidor multiusuario (como Travis, AWS, etc.) también pueden sufrir estos problemas. La ejecución de varias instancias de Lighthouse a la vez suele distorsionar los resultados debido a este problema. La limitación aplicada es susceptible a este problema. La limitación simulada mitiga parcialmente este problema si vuelve a reproducir la actividad de la red por su cuenta y limita la ejecución de la CPU.
No determinismo en el navegador
Los navegadores tienen una variabilidad inherente en la ejecución de tareas que afecta la forma en que se cargan las páginas web. Esto es inevitable para la limitación aplicada, ya que, al final del día, solo informan lo que observó el navegador. La limitación simulada puede mitigar parcialmente este efecto simulando la ejecución por sí sola y solo reutilizando los tiempos de ejecución de tareas del navegador en su estimación.
Efecto de las estrategias de regulación
A continuación, se muestra una tabla que contiene varias fuentes comunes de variabilidad de métricas, el impacto típico que tienen en los resultados y en qué medida las diferentes estrategias de limitación de Lighthouse pueden mitigar su efecto. Obtén más información sobre las diferentes estrategias de regulación en nuestra documentación.
| Origen | Impacto | Limitación simulada | Limitación aplicada | Sin regulación |
|---|---|---|---|---|
| No determinismo en la página | Alto | SIN MITIGACIÓN | SIN MITIGACIÓN | SIN MITIGACIÓN |
| Variabilidad de redes locales | Alto | MITIGADO | PARCIALMENTE MITIGADO | SIN MITIGACIÓN |
| Variabilidad de red de nivel 1 | Medio | MITIGADO | PARCIALMENTE MITIGADO | SIN MITIGACIÓN |
| Variabilidad del servidor web | Bajo | SIN MITIGACIÓN | PARCIALMENTE MITIGADO | SIN MITIGACIÓN |
| Variabilidad del hardware del cliente | Alto | PARCIALMENTE MITIGADO | SIN MITIGACIÓN | SIN MITIGACIÓN |
| Contención de recursos de cliente | Alto | PARCIALMENTE MITIGADO | SIN MITIGACIÓN | SIN MITIGACIÓN |
| No determinismo en el navegador | Medio | PARCIALMENTE MITIGADO | SIN MITIGACIÓN | SIN MITIGACIÓN |
Estrategias para lidiar con la variación
Aísla factores externos
- Aísla tu página de la influencia de terceros en la mayor medida posible. Nunca es divertido culpar a los demás por las fallas de las variables.
- Aísla el no determinismo de tu propio código durante las pruebas. Si tienes una animación que aparece de forma aleatoria, las cifras de rendimiento pueden ser también aleatorias.
- Aísla tu servidor de prueba de la mayor volatilidad de red posible. Usa localhost o una máquina en la misma red cuando la estabilidad sea un problema.
- Aísla el entorno del cliente de las influencias externas, como el software antivirus y las extensiones del navegador. Cuando sea posible, usa un dispositivo dedicado para realizar pruebas.
Si tu máquina tiene recursos muy limitados o te resulta difícil crear un entorno limpio, ejecuta las pruebas por ti con un entorno de lab alojado, como PageSpeed Insights o WebPageTest. En situaciones de integración continua, usa servidores dedicados cuando sea posible. Los entornos de CI gratuitos y las instancias “de alto rendimiento” suelen ser bastante volátiles.
Ejecutar Lighthouse varias veces
Cuando crees los umbrales de fallas, ya sean mentales o programáticos, usa valores agregados como la mediana, el percentil 90 o incluso el mínimo en lugar de pruebas individuales.
La mediana de la puntuación de Lighthouse de 5 ejecuciones es el doble de estable que la de 1, y herramientas como pwmetrics pueden ejecutar Lighthouse automáticamente. El uso del valor mínimo también es una gran mejora con respecto a no realizar pruebas y es muy fácil de implementar. Solo debes ejecutar Lighthouse hasta 5 veces hasta que pase.