El recurso más rápido y mejor optimizado es un recurso que no se envió. 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 brinda al usuario? ¿Puedes medir y demostrar su valor?
- ¿El recurso (especialmente si es de terceros) ofrece un rendimiento coherente? ¿Este recurso está en la ruta crítica o debe estarlo? Si el recurso está en la ruta 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 compresión, almacenamiento en caché, etcétera?
Con demasiada frecuencia, las páginas contienen recursos innecesarios o, lo que es peor, que dificultan el rendimiento de la página sin proporcionar mucho valor al visitante o al sitio en el que se alojan. Esto se aplica de la misma 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 permitir que el visitante obtenga 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 entre ellas.
- Pregunta: ¿Midiste cuántos usuarios ven varias fotos en el carrusel? Si descargas recursos que la mayoría de los visitantes nunca ven, es posible que generes una sobrecarga alta.
- 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: ¿Realizaste 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 necesario?
Determinar si se deben eliminar las descargas innecesarias a menudo requiere mucho pensamiento y medición cuidadosos. Para obtener los mejores resultados, haz un inventario de forma periódica 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 Métricas web esenciales 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 Métricas web esenciales, 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 muestran algunos ejemplos, agrupados por cada métrica web esencial, que vale la pena considerar. Si bien esta no es una lista exhaustiva de ejemplos (¡y hay muchos!), leerlos puede darte algo en qué pensar.
Largest Contentful Paint (LCP)
El procesamiento de imagen con contenido más grande (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 perceptiva importante que le 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 y puede traducirse en una mejora en la 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, excepto las diez primeras, significa que el navegador puede usar de manera más eficiente el 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. El navegador tiene un esquema de priorización interno que determina la cantidad de ancho de banda que debe recibir cada recurso. Sin embargo, incluso con estos todos recursos, en particular los que se descargan con alta prioridad, existe la posibilidad de privar al recurso dependiente de un posible elemento de LCP. Esto es especialmente cierto en las conexiones de red lentas. Ese recurso dependiente puede ser un archivo de imagen que representa el elemento LCP de la página, pero también puede ser un recurso de fuente web que el navegador necesita para renderizar un nodo de texto que se puede 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 buenas estrategias de carga y optimización de fuentes, 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 pintar casi de inmediato a medida que llegan el CSS y el HTML 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 terminó de descargarse 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 la forma 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 cierta cantidad de trabajo para garantizar que el diseño de la página sea lo suficientemente estable. Cuando 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 perseguir otros objetivos en tus proyectos.
Interaction to Next Paint (INP)
Interaction to Next Paint (INP) mide la capacidad de respuesta a las entradas del usuario durante el ciclo de vida de una página. El INP de una página puede verse muy influenciado por el código JavaScript que carga, ya que este es el responsable de 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 que implica 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 la página, en el que los usuarios pueden intentar interactuar con él.
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 árboles, 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 en la actualidad, 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 publicar una experiencia de referencia (pero aún funcional) para los usuarios a la que puedes agregar más contenido para los usuarios con dispositivos más potentes y conexiones de red más rápidas. Independientemente de si sigues o no el principio de mejora progresiva, el punto sigue siendo el mismo: cada recurso de JavaScript que puedas evitar descargar puede generar 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 en busca de descargas innecesarias puede ser solo un aspecto de la entrega de experiencias del usuario rápidas, pero es uno que tiene el potencial de tener 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.
- Determina si los recursos proporcionan suficiente valor.
- Comprende el efecto de las descargas innecesarias en las Métricas web esenciales 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 te asegurarás de no desperdiciar el ancho de banda de los usuarios, además de mejorar potencialmente las métricas centradas en el usuario y ofrecer una mejor experiencia del usuario.