El recurso más rápido y mejor optimizado es el que no se envía. Debes eliminar los recursos innecesarios de tu aplicación. Es una buena práctica cuestionar y 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 costo de descargarlo y mostrarlo compensa el valor que le ofrece al usuario? ¿Puedes medir y demostrar su valor?
- ¿El recurso (especialmente si es de terceros) ofrece un rendimiento constante? ¿Este recurso está en la ruta crítica o debe estarlo? Si el recurso está en la ruta de acceso crítica, ¿podría ser un punto único de fallo para el sitio? Es decir, si el recurso no está disponible, ¿afecta el rendimiento y la experiencia del usuario de tus páginas?
- ¿Este recurso necesita o tiene un ANS? ¿Este recurso sigue las prácticas recomendadas de rendimiento, como la compresión, el almacenamiento en caché, etcétera?
Con demasiada frecuencia, las páginas contienen recursos que son innecesarios o, lo que es peor, que dificultan el rendimiento de la página sin aportar mucho valor al visitante ni al sitio en el que se alojan. Esto se aplica de igual manera a los recursos y widgets propios y de terceros:
- El sitio A decidió mostrar un carrusel de fotos en su página principal para que el visitante pueda obtener una vista previa de varias fotos con un clic rápido. Todas las fotos se cargan cuando se carga la página, y el usuario avanza por las fotos.
- Pregunta: ¿Mediste cuántos usuarios ven varias fotos en el carrusel? Es posible que estés generando una sobrecarga alta por descargar recursos que la mayoría de los visitantes nunca ven.
- El sitio B decidió instalar un widget de terceros para mostrar contenido relacionado, mejorar la participación en redes sociales o proporcionar algún otro servicio.
- Pregunta: ¿Hiciste un seguimiento de cuántos visitantes usan el widget o hacen clic en el contenido que proporciona? ¿La participación que genera este widget es suficiente para justificar su sobrecarga? Además, ¿es posible que uses una estrategia de carga para asegurarte de que la secuencia de comandos no se cargue hasta que sea necesaria?
Determinar si se deben eliminar las descargas innecesarias suele requerir mucha reflexión y medición cuidadosas. Para obtener los mejores resultados, haz un inventario periódico y vuelve a revisar estas preguntas para cada recurso de tus páginas.
Efectos en las Métricas web esenciales
Google presentó la iniciativa de Core Web Vitals para proporcionar un conjunto de métricas que reflejen lo que experimentan los usuarios cuando usan la Web. Si bien existen muchas estrategias de optimización para las Core Web Vitals, cuestionar si se debe cargar un recurso en particular en una página puede ayudarte a mejorar estas métricas en tu sitio web. A continuación, se incluyen algunos ejemplos, agrupados por cada métrica web esencial, que vale la pena tener en cuenta. Si bien esta no es una lista exhaustiva de ejemplos (¡y hay muchos!), leerlos puede darte ideas.
Largest Contentful Paint (LCP)
La métrica Largest Contentful Paint (LCP) mide cuándo se carga el contenido más grande (por ejemplo, una imagen hero o un título). Se considera una métrica de percepción importante que le da al usuario la impresión de que un sitio se está cargando rápidamente.
En general, descargar menos recursos significa que el ancho de banda que tiene el usuario se asignará a menos recursos y puede traducirse en una mejora en el LCP. Un ejemplo clásico es el de la carga diferida, en la que las imágenes que se encuentran 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 galería de miniaturas grande de, por ejemplo, 50 imágenes, la carga diferida de todas las imágenes, excepto las diez primeras, significa que el navegador puede hacer un uso más eficiente del ancho de banda disponible y que las primeras imágenes que verá el usuario se cargarán más rápido.
Sin embargo, no se trata solo de cargar menos imágenes, necesariamente. El navegador tiene un esquema de priorización interno que determina cuánto ancho de banda debe recibir cada recurso. Sin embargo, incluso con esto, todos los recursos, en especial los que se descargan con prioridad alta, tienen el potencial de privar a un recurso dependiente de un elemento de LCP potencial. Esto es especialmente cierto en las 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 necesite para renderizar un nodo de texto que se pueda determinar 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 existen muchas estrategias de carga y optimización de fuentes adecuadas, puede ser conveniente considerar si una fuente del sistema es suficiente para las necesidades de tu sitio web, de modo que los elementos de LCP que son nodos de texto se puedan cargar sin depender de un recurso de fuente web y se rendericen casi de inmediato a medida que el CSS y el HTML llegan desde el servidor.
Cumulative Layout Shift (CLS)
Cada recurso que cargas tiene el potencial de contribuir al Cambio de diseño acumulado (CLS) de una página, en especial si no se terminó de descargar en el momento de la pintura inicial. En el caso de las imágenes, evitar el CLS implica prácticas como establecer dimensiones explícitas. En el caso de las fuentes, administrar la carga de fuentes y, posiblemente, 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 ser administrar cómo 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 cierta cantidad de trabajo para garantizar que el diseño de la página sea lo suficientemente estable. Si te preguntas si necesitas o no un recurso específico, no solo aceleras las cargas de página, sino que también reduces el esfuerzo cognitivo necesario para preservar la estabilidad del diseño. Esto no solo genera una experiencia del usuario mucho menos frustrante, sino también una experiencia del desarrollador menos frustrante, ya que tendrás más tiempo para alcanzar otros objetivos en tus proyectos.
Interaction to Next Paint (INP)
La Interaction to Next Paint (INP) mide la capacidad de respuesta a las entradas del usuario durante la vida útil de una página. El INP de una página puede verse muy 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 secuencia de comandos que se descargan durante la carga de la página puede iniciar un trabajo potencialmente costoso relacionado con la evaluación y compilación de secuencias de comandos. Cuanto menos JavaScript cargues durante el inicio, menos trabajo tendrá que hacer el navegador en ese punto crítico de la experiencia de página, en el que los usuarios podrían estar intentando interactuar con ella.
Si bien existen estrategias para reducir el tamaño de los recursos de JavaScript que se descargan durante el inicio, como la división de código y la eliminación de código muerto, vale la pena 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 hoy en día, pero se envía con 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 para JavaScript, ya que te permite ofrecer una experiencia de referencia (pero aún funcional) para los usuarios que puedes agregar para los usuarios con dispositivos más potentes y conexiones de red más rápidas. Ya sea que te adhieras al principio de mejora progresiva o no, el punto sigue siendo el mismo: cada recurso de JavaScript que puedas evitar descargar puede dar como resultado una experiencia que responda más rápido a las interacciones del usuario, lo que es un aspecto vital del rendimiento web.
Conclusión
Auditar tu sitio web para detectar descargas innecesarias puede ser solo un aspecto de la entrega de experiencias del usuario rápidas, pero es uno que tiene el potencial de generar un gran impacto. En resumen:
- Haz un inventario de tus propios recursos y de los recursos de terceros en tus páginas.
- Mide el rendimiento de cada recurso: su valor y su rendimiento técnico.
- Determinar si los recursos proporcionan un valor suficiente
- Comprender el efecto de las descargas innecesarias en las Core Web Vitals y las métricas de respaldo
Si optimizas la eficiencia del contenido de esta manera, no solo mejorarás el rendimiento general, sino que también tendrás cuidado de no desperdiciar el ancho de banda de los usuarios, además de mejorar potencialmente las métricas centradas en el usuario y brindar una mejor experiencia del usuario.