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 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) tiene un rendimiento coherente? ¿Se encuentra este recurso en la ruta crítica o debe estarlo? 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étera?
Muy a menudo, las páginas contienen recursos que son innecesarios o, lo que es peor, obstaculizan el rendimiento de la página sin ofrecer demasiado 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:
- En 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 cuando se carga la página y el usuario pasa las fotos.
- Pregunta: ¿Midió la cantidad de usuarios que miran varias fotos en el carrusel? Podrías generar una gran sobrecarga al descargar recursos que la mayoría de los visitantes nunca ven.
- Para el sitio B, se decidió instalar un widget de terceros para mostrar contenido relacionado, mejorar la participación en las redes sociales o proporcionar algún otro servicio.
- Pregunta: ¿Registraste la cantidad de visitantes que usan el widget o hacen clic en el contenido que proporciona? ¿Es suficiente la participación que genera este widget para justificar su sobrecarga? Además, ¿es posible usar una estrategia de carga para asegurarte de que la secuencia de comandos no se cargue hasta que sea necesaria?
Determinar si se eliminan las descargas innecesarias a menudo requiere mucho tiempo de análisis cuidadoso y mediciones. 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 reflejen la experiencia de los usuarios cuando usan la Web. Si bien existen muchas estrategias de optimización para las Métricas web esenciales, preguntar si se debe cargar un recurso específico en una página puede iluminar una ruta para que mejores estas métricas en tu sitio web. A continuación, te mostramos 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 pensar en ellos.
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 tenga el usuario se asignará a menos recursos y esto podría traducirse en una mejora en el LCP. Un ejemplo clásico es la carga diferida, en la que las imágenes fuera del viewport durante la carga de la página no se descargan hasta que el navegador haya determinado 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 ellas excepto 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á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 todos estos recursos, en especial los descargados con prioridad alta, tienen el potencial de privar al recurso dependiente de un posible elemento LCP. Esto es más evidente en 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 podría ser un recurso de fuente web que el navegador necesita para renderizar un nodo de texto que pueda 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 existen muchas buenas estrategias de optimización y carga de fuentes, puede valer la pena considerar si una fuente del sistema es suficiente para las necesidades de tu sitio web, de modo que los elementos LCP, que son nodos de texto, puedan cargarse sin depender de un recurso de fuente web y pintar casi de inmediato a medida que lleguen el CSS y el HTML del servidor.
Cambio de diseño acumulado (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 ha terminado de descargarse en el momento del procesamiento de imagen inicial. En el caso de las imágenes, evita el CLS implica prácticas como configurar 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 ser la administración de 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 cierta cantidad de trabajo para garantizar que el diseño de la página sea lo suficientemente estable. Al preguntarte si necesitas o no un recurso específico, no solo aceleras las cargas de página, sino que también estás reduciendo el esfuerzo cognitivo necesario para preservar la estabilidad del diseño. Esto implica no solo una experiencia del usuario mucho menos frustrante, sino también menos frustrante para los desarrolladores, ya que tendrás más tiempo para alcanzar otros objetivos en tus proyectos.
Interacción con el próximo procesamiento de imagen (INP) y retraso de primera entrada (FID)
Las métricas de Interacción a la siguiente pintura (INP) y Retraso de primera entrada (FID) son métricas que miden la capacidad de respuesta a las entradas de los usuarios. Si bien el INP está programado para reemplazar FID como una Métrica web esencial en marzo de 2024, las estrategias de optimización para FID tienden a aplicarse también a INP. Además, el INP suele ser más difícil de optimizar que el FID, ya que realiza un seguimiento de la latencia de interacción completa de todas las interacciones de la página, no solo del retraso de entrada de la primera interacción como mide el FID.
INP y FID tienden a ser más afectados por JavaScript, ya que JavaScript es lo que impulsa la mayor parte de la interactividad que experimenta en la Web. Tanto para INP como para FID, la cantidad de recursos de secuencias de comandos descargados durante la carga de la página iniciará trabajos potencialmente costosos relacionados con la evaluación y compilación de secuencias de comandos. Cuanto menos JavaScript cargues durante el inicio, menos trabajo deberá realizar el navegador en ese punto crítico de la experiencia de página.
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, vale la pena auditar los paquetes que usa en sus proyectos para ver si son necesarios. Por ejemplo, lodash tiene muchos métodos que aún son útiles en la actualidad, pero se incluye con métodos que el navegador proporciona de inmediato, como funciones específicas de Array para asignar, reducir y filtrar, y muchas otras.
La mejora progresiva también es un enfoque útil de JavaScript, ya que te permite ofrecer una experiencia de referencia (pero que sigue siendo funcional) para los usuarios, que puedes agregar a aquellos con dispositivos más potentes y conexiones de red más rápidas. Independientemente de que cumplas con el principio de mejora progresiva o no, el punto permanece: cada recurso de JavaScript que puedas evitar descargar puede generar una experiencia que responda más rápido a las interacciones del usuario, lo cual 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 podría tener un alto impacto. En resumen:
- Haz un inventario de tus propios recursos y los 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 complementarias.
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 y de mejorar potencialmente las métricas centradas en el usuario y entregar una mejor experiencia del usuario.