El recurso más rápido y mejor optimizado es aquel que no se envía. Debes eliminar los recursos innecesarios de tu aplicación. Es una buena práctica cuestionar y volver a revisar periódicamente las suposiciones implícitas y explícitas con tu equipo. Estos son algunos ejemplos:
- Siempre incluiste el recurso X en tus páginas, pero ¿el valor que ofrece al usuario compensa el costo de descargarlo y mostrarlo? ¿Puedes medir y probar su valor?
- ¿El recurso (en especial si es de terceros) ofrece un rendimiento coherente? ¿Se encuentra o debe estar este recurso en la ruta crítica? Si el recurso se encuentra en la ruta crítica, ¿podría ser un punto único de fallo para el sitio? Es decir, si el recurso no está disponible, ¿afectará el rendimiento y la experiencia del usuario en tus páginas?
- ¿Este recurso tiene o necesita un ANS? ¿Sigue este recurso las prácticas recomendadas de rendimiento: compresión, almacenamiento en caché, etc.?
Con frecuencia, las páginas contienen recursos que son innecesarios, o peor aún, que dificultan el rendimiento de la página sin ofrecer mucho valor al visitante o al sitio en el que se alojan. Esto se aplica de la misma manera a recursos y widgets propios y de terceros:
- Para el sitio A se decidió mostrar un carrusel de fotos en la página principal para permitir que el visitante obtenga una vista previa de varias fotos con un clic rápido. Todas las fotos se cargan con la página y el usuario avanza por ellas.
- Pregunta: ¿Midió cuántos usuarios ven varias fotos en el carrusel? Podrías generar una gran sobrecarga por descargar recursos que la mayoría de los visitantes nunca ven.
- En el sitio B, se decidió instalar un widget de terceros para mostrar contenido relacionado, mejorar la participación en las redes sociales o brindar algún otro servicio.
- Pregunta: ¿Realizaste un seguimiento de la cantidad de visitantes que usan el widget o hacen clic en el contenido que este proporciona? ¿La participación que genera este widget es suficiente para justificar su sobrecarga? Además, ¿es factible usar una estrategia de carga para garantizar que la secuencia de comandos no se cargue hasta que sea necesaria?
Determinar si se deben eliminar las descargas innecesarias a menudo requiere de mucho tiempo de análisis cuidadoso y medición. Para obtener los mejores resultados, haz un inventario y repasa periódicamente estas preguntas para cada recurso de tus páginas.
Efectos en las Métricas web esenciales
Google introdujo la iniciativa de Métricas web esenciales para proporcionar un conjunto de métricas que reflejan lo que experimentan los usuarios cuando usan la Web. Si bien existen muchas estrategias de optimización para las Métricas web esenciales, cuestionar si debes cargar un recurso específico en una página puede servirte para mejorar estas métricas en tu sitio web. A continuación, se muestran algunos ejemplos, agrupados por cada Métrica web esencial, que vale la pena considerar. Aunque esta no es una lista exhaustiva de ejemplos (y son muchos), leerlos puede ser una buena idea.
Procesamiento de imagen con contenido más grande (LCP)
El procesamiento de imagen con contenido más grande (LCP) mide cuándo se carga el contenido más grande (por ejemplo, una hero image o un título). Se considera una métrica perceptiva importante que da al usuario la impresión de que un sitio se carga rápidamente.
En general, descargar menos recursos significa que el ancho de banda que tiene el usuario se asignará a menos recursos, lo que puede traducirse en una mejora en el LCP. Un ejemplo clásico es el de la carga diferida, en la que las imágenes fuera del viewport durante la carga de la página no se descargarán hasta que el navegador determine que es más probable que el usuario las vea. Si tienes una gran galería de miniaturas de, por ejemplo, 50 imágenes, la carga diferida de todas menos las diez principales significa que el navegador puede hacer un uso más eficiente del ancho de banda disponible, y las primeras imágenes que verá el usuario se cargarán más rápidamente.
Sin embargo, no solo se trata de cargar, necesariamente, menos imágenes. El navegador cuenta con un esquema de priorización interno que determina cuánto ancho de banda debe recibir cada recurso. Sin embargo, incluso con estos todos recursos (especialmente los descargados con prioridad alta), pueden privar a un posible recurso dependiente de un elemento de LCP. Esto es especialmente cierto en conexiones de red lentas. Ese recurso dependiente puede ser un archivo de imagen que represente el elemento LCP de la página, pero también podría ser un recurso de fuente web que el navegador necesita para renderizar un nodo de texto que puede determinarse como el elemento LCP de la página.
Si tu sitio web tiene mucho texto, es posible que el elemento LCP de una página sea un nodo de texto. Si bien hay muchas buenas estrategias de carga y optimización de fuentes, puede valer la pena considerar si una fuente de sistema es suficiente para las necesidades de tu sitio web, de modo que los elementos LCP que son nodos de texto se puedan cargar sin depender de un recurso de fuente web y se puedan pintar casi de inmediato a medida que el CSS y el HTML llegan desde el servidor.
Cambio de diseño acumulado (CLS)
Cada recurso que cargues puede contribuir al Cambio de diseño acumulado (CLS) de una página, sobre todo si no terminó de descargarse en el momento de la pintura inicial. En el caso de las imágenes, evitar CLS implica prácticas como la configuración de dimensiones explícitas. En el caso de las fuentes, administrar la carga de fuentes y, potencialmente, la coincidencia de fuentes de resguardo puede minimizar los cambios durante el período de intercambio de una fuente web. En el caso de JavaScript, podría estar administrando la manera en que esa secuencia de comandos manipula el DOM para que los cambios de diseño se reduzcan a una cantidad aceptable.
Cada recurso que contribuye al CLS de una página requiere cierto esfuerzo para garantizar que el diseño de la página sea lo suficientemente estable. Cuando se cuestiona si necesitas o no un recurso específico, no solo estás acelerando las cargas de páginas, también estás reduciendo el esfuerzo cognitivo necesario para preservar la estabilidad del diseño. Esto conduce no solo a una experiencia del usuario mucho menos frustrante, sino también a una experiencia de desarrollador menos frustrante, ya que tendrás más tiempo para perseguir otros objetivos en tus proyectos.
Interacción con el siguiente procesamiento de imagen (INP)
Interaction to Next Paint (INP) mide la capacidad de respuesta a las entradas del usuario a lo largo del ciclo de vida de una página. El INP de una página puede verse notablemente influenciado por el JavaScript que carga, ya que JavaScript es lo que impulsa la mayor parte de la interactividad que se experimenta en la Web. En particular, la cantidad de recursos de secuencias de comandos descargados durante la carga de la página puede iniciar trabajo potencialmente costoso relacionado con la evaluación y la compilación de secuencias de comandos. Cuanto menos código JavaScript cargues durante el inicio, menor será el trabajo que deba hacer el navegador en ese punto crítico de la experiencia de página, donde los usuarios podrían estar tratando de interactuar con él.
Si bien existen estrategias para reducir el tamaño de los recursos de JavaScript descargados durante el inicio, como la división de código y la eliminación de código no utilizado, es conveniente auditar los paquetes que usas en tus proyectos para ver si son necesarios. Por ejemplo, lodash tiene muchos métodos que aún son útiles en la actualidad, pero incluye métodos que el navegador proporciona de forma predeterminada, como funciones específicas de Array
para asignar, reducir y filtrar, y muchos otros.
La mejora progresiva también es un enfoque útil de JavaScript, ya que te permite ofrecer a los usuarios una experiencia de referencia (pero aún funcional) que puedes agregar para los usuarios con dispositivos más potentes y conexiones de red más rápidas. Independientemente de si cumples o no con el principio de la mejora progresiva, la cuestión sigue siendo que cada recurso JavaScript que puedas evitar que se descargue puede generar una experiencia que responda más rápido a las interacciones de los usuarios, lo que es un aspecto fundamental del rendimiento web.
Conclusión
Auditar tu sitio web para detectar descargas innecesarias es solo un aspecto de la entrega de experiencias del usuario rápidas, pero es algo que tiene el potencial de tener un gran impacto. En resumen:
- Haz un inventario de tus propios recursos y de terceros en tus páginas.
- Mide el rendimiento de cada recurso: su valor y su rendimiento técnico.
- Determina si los recursos están proporcionando suficiente valor.
- Comprende el efecto de las descargas innecesarias en las Métricas web esenciales y las métricas compatibles.
Si optimizas la eficiencia del contenido de esta manera, no solo mejorarás el rendimiento general, sino que también te cuidarás de no desperdiciar el ancho de banda de los usuarios, sino que, posiblemente, mejorarás las métricas centradas en los usuarios y proporcionarás una mejor experiencia del usuario.