Una colección de las prácticas recomendadas que el equipo de DevRel de Chrome considera que son las formas más eficaces de mejorar el rendimiento de las Métricas web esenciales en 2023.
A lo largo de los años, en Google hemos hecho muchas recomendaciones a los desarrolladores web sobre cómo mejorar el rendimiento.
Si bien cada una de estas recomendaciones puede mejorar individualmente el rendimiento de muchos sitios, el conjunto completo de recomendaciones es realmente abrumador y, en realidad, no hay forma de que una sola persona o sitio pueda seguirlas a todos.
A menos que el rendimiento web sea tu trabajo diario, es probable que no sea obvio qué recomendaciones tendrán el mayor impacto positivo en tu sitio. Por ejemplo, es posible que hayas leído que la implementación de CSS esenciales puede mejorar el rendimiento de carga y que también hayas escuchado que es importante optimizar tus imágenes. Pero, si no tienes tiempo para trabajar en ambas cosas, ¿cómo decidirías cuál elegir?
En el equipo de Chrome, pasamos el año pasado tratando de responder esta pregunta: ¿cuáles son las recomendaciones más importantes que podemos dar a los desarrolladores para ayudarlos a mejorar el rendimiento de sus usuarios?
Para responder de forma adecuada a esta pregunta, tenemos que considerar no solo los méritos técnicos de cualquier recomendación determinada, sino también los factores humanos y organizacionales que influyen en la probabilidad de que los desarrolladores realmente puedan adoptar estas recomendaciones. En otras palabras, algunas recomendaciones pueden tener un gran impacto en teoría, pero, en realidad, muy pocos sitios tendrán el tiempo o los recursos para implementarlas. Del mismo modo, algunas recomendaciones son fundamentales, pero la mayoría de los sitios web ya las siguen.
En resumen, queríamos que nuestra lista de las principales recomendaciones de rendimiento web se centrara en lo siguiente:
- Las recomendaciones que creemos que tendrán el mayor impacto en el mundo real
- Recomendaciones que son relevantes y aplicables a la mayoría de los sitios
- Recomendaciones realistas de implementar por la mayoría de los desarrolladores
Durante el último año, dedicamos mucho tiempo a auditar el conjunto completo de recomendaciones de rendimiento que realizamos y a evaluar cada una de ellas (de forma cualitativa y cuantitativa) en función de los tres criterios anteriores.
En esta publicación, se describen nuestras principales recomendaciones para mejorar el rendimiento de cada una de las métricas de Métricas web esenciales. Si es la primera vez que utilizas el rendimiento web o si estás tratando de decidir qué es lo que más te permite aprovechar tu dinero, creemos que estas recomendaciones son el mejor punto de partida.
Procesamiento de imagen con contenido más grande (LCP)
Nuestro primer conjunto de recomendaciones es para el Procesamiento de imagen con contenido más grande (LCP), que es una medida del rendimiento de carga. De las tres métricas web esenciales, el LCP es el que más usuarios enfrentan actualmente (solo alrededor de la mitad de todos los sitios de la Web alcanzan el umbral recomendado), así que comencemos por ahí.
Asegúrate de que el recurso de LCP sea detectable desde la fuente HTML
Según el Almanac web de 2022 de HTTP Archive, el 72% de las páginas para dispositivos móviles tienen una imagen como elemento de LCP, lo que significa que, para que la mayoría de los sitios optimicen su LCP, deberán asegurarse de que esas imágenes puedan cargarse rápidamente.
Lo que puede no ser obvio para muchos desarrolladores es que el tiempo que lleva cargar una imagen es solo una parte del desafío. Otro aspecto fundamental es el tiempo antes de que una imagen comience a cargarse, y los datos de HTTP Archive sugieren que ese es el momento en el que muchos sitios se cometen errores.
De hecho, de las páginas en las que el elemento LCP era una imagen, el 39% de esas imágenes tenían URLs que no se detectaron en la fuente del documento HTML. En otras palabras, no se encontraron esas URLs en los atributos HTML estándar (como <img src="..."> o <link rel="preload" href="...">), lo que permitiría que el navegador las detectara rápidamente y comenzara a cargarlas de inmediato.
Si una página debe esperar a que los archivos CSS o JavaScript se descarguen, analicen y procesen por completo antes de que la imagen pueda comenzar a cargarse, es posible que ya sea demasiado tarde.
Como regla general, si tu elemento LCP es una imagen, la URL de la imagen siempre debe ser detectable desde la fuente HTML. Estas son algunas sugerencias para hacerlo posible:
Carga la imagen usando un elemento
<img>con el atributosrcosrcset. No uses atributos no estándares, comodata-src, que requieren JavaScript para el procesamiento, ya que siempre serán más lentos. El 9% de las páginas oculta su imagen de LCP detrás dedata-src.Prefiere la renderización del servidor (SSR) en lugar de la renderización del cliente (CSR), ya que la SSR implica que el lenguaje de marcado de la página completa (incluida la imagen) está presente en la fuente HTML. Las soluciones de CSR requieren que se ejecute JavaScript antes de que se pueda descubrir la imagen.
Si necesitas hacer referencia a tu imagen desde un archivo externo CSS o JS, puedes incluirla en el código fuente HTML con una etiqueta
<link rel="preload">. Ten en cuenta que el análisis de precarga del navegador no puede detectar las imágenes a las que hacen referencia los estilos intercalados. Por lo tanto, aunque se encuentren en la fuente HTML, su descubrimiento podría seguir bloqueado durante la carga de otros recursos, por lo que la precarga puede ser útil en estos casos.
Para ayudarte a comprender si tu imagen de LCP tiene problemas de visibilidad, Lighthouse lanzará una nueva auditoría en la versión 10.0 (se prevé enero de 2023).
Garantizar que el recurso LCP sea detectable desde la fuente HTML puede llevar a mejoras medibles y también desbloquea oportunidades adicionales para priorizar el recurso, que es nuestra próxima recomendación.
Asegúrate de que se priorice el recurso de LCP
Asegurarse de que el recurso LCP se pueda descubrir desde la fuente HTML es un primer paso fundamental para garantizar que el recurso de LCP pueda comenzar a cargarse anticipadamente, pero otro paso importante es garantizar que la carga de ese recurso se priorice y no quede en cola detrás de muchos otros recursos menos importantes.
Por ejemplo, incluso si tu imagen LCP está presente en el código fuente HTML con una etiqueta <img> estándar, si tu página incluye una docena de etiquetas <script> en el <head> de tu documento antes de esa etiqueta <img>, puede pasar un tiempo antes de que tu recurso de imagen comience a cargarse.
La forma más sencilla de solucionar este problema es indicarle al navegador una sugerencia sobre los recursos con mayor prioridad configurando el nuevo atributo fetchpriority="high" en la etiqueta <img> o <link> que carga tu imagen de LCP. Esto indica al navegador que la cargue antes, en lugar de esperar a que se completen esas secuencias de comandos.
Según el Almanac web, solo el 0.03% de las páginas aptas aprovechan esta nueva API, lo que significa que la mayoría de los sitios de la Web tienen muchas oportunidades de mejorar el LCP con muy poco trabajo. Si bien actualmente el atributo fetchpriority solo se admite en los navegadores basados en Chromium, esta API es una mejora progresiva que otros navegadores ignoran, por lo que recomendamos que los desarrolladores la usen ahora.
En el caso de los navegadores que no son de Chromium, la única forma de garantizar que el recurso de LCP se priorice sobre otros recursos es hacer referencia a este antes en el documento. Si volvemos a usar el ejemplo de un sitio con muchas etiquetas <script> en el <head> del documento, si deseas asegurarte de que tu recurso de LCP tenga prioridad por sobre esos recursos de secuencias de comandos, puedes agregar una etiqueta <link rel="preload"> antes de cualquiera de esas secuencias de comandos o puedes mover esas secuencias a menos de <img> más adelante en el <body>. Si bien esto funciona, es menos ergonómico que usar fetchpriority, por lo que esperamos que otros navegadores agreguen compatibilidad pronto.
Otro aspecto crítico de priorizar el recurso de LCP es asegurarte de no hacer nada que lo menorice, como agregar el atributo loading="lazy". Hoy en día, el 10% de las páginas establece loading="lazy" en su imagen de LCP. Ten cuidado con las soluciones de optimización de imágenes que aplican indiscriminadamente comportamientos de carga diferida a todas las imágenes. Si proporcionan una forma de anular ese comportamiento, asegúrate de usarlo para la imagen LCP. Si no sabes con certeza qué imagen será el LCP, intenta utilizar una heurística para elegir una candidata razonable.
Aplazar los recursos no críticos es otra forma de aumentar de manera efectiva la prioridad relativa del recurso de LCP. Por ejemplo, las secuencias de comandos que no impulsan la interfaz de usuario (como las secuencias de comandos de Analytics o los widgets sociales) se pueden posponer de forma segura hasta después de que se active el evento load, lo que garantiza que no compitan con otros recursos críticos (como el recurso LCP) por el ancho de banda de la red.
En resumen, debes seguir estas prácticas recomendadas para asegurarte de que el recurso de LCP se cargue antes y con alta prioridad:
- Agrega
fetchpriority="high"a la etiqueta<img>de tu imagen de LCP. Si el recurso de LCP se carga a través de una etiqueta<link rel="preload">, no temas porque también puedes configurarfetchpriority="high"en eso. - Nunca configures
loading="lazy"en la etiqueta<img>de tu imagen de LCP. Si lo haces, se anulará la prioridad de tu imagen y se retrasará el momento en que comience a cargarse. - Aplaza los recursos que no sean críticos cuando sea posible. Puedes moverlas al final del documento, usar la carga diferida nativa para imágenes o iframes o cargarlos de forma asíncrona a través de JavaScript.
Usa una CDN para optimizar el TTFB de documentos y recursos
Las dos recomendaciones anteriores se enfocaron en asegurarse de que tu recurso de LCP se descubra temprano y se priorice para que pueda comenzar a cargarse de inmediato. La última pieza de este rompecabezas es asegurarse de que la respuesta inicial del documento llegue lo más rápido posible.
El navegador no puede comenzar a cargar ningún subrecurso hasta que recibe el primer byte de la respuesta inicial del documento HTML y, cuanto antes suceda, más pronto empezará a suceder todo lo demás.
Este tiempo se conoce como tiempo hasta el primer byte (TTFB) y la mejor manera de reducir el TTFB es la siguiente:
- Publica tu contenido lo más cerca posible de tus usuarios geográficamente
- Almacena en caché ese contenido para que el contenido solicitado recientemente pueda volver a publicarse con rapidez.
La mejor manera de realizar estas dos acciones es mediante una CDN. Las CDN distribuyen tus recursos a servidores perimetrales, que se distribuyen por todo el mundo, lo que limita la distancia que tienen esos recursos para llegar a los usuarios. Las CDN también suelen tener controles de almacenamiento en caché detallados que se pueden personalizar y optimizar según las necesidades de tu sitio.
Muchos desarrolladores están familiarizados con el uso de una CDN para alojar elementos estáticos, pero las CDN también pueden entregar y almacenar en caché documentos HTML, incluso aquellos que se generan de forma dinámica.
Según el Almanac web, solo el 29% de las solicitudes de documentos HTML se entregaron desde una CDN, lo que significa que los sitios tienen una oportunidad importante de afirmar ahorros adicionales.
Estas son algunas sugerencias para configurar tus CDN:
- Considera aumentar el tiempo durante el cual se almacena en caché el contenido (por ejemplo, ¿es realmente fundamental que el contenido esté siempre actualizado? ¿O pueden quedar inactivos durante unos minutos?).
- Tal vez quieras almacenar en caché el contenido de forma indefinida y, luego, borrar definitivamente la caché cuando realices una actualización.
- Analiza si puedes mover la lógica dinámica que se ejecuta actualmente en el servidor de origen al perímetro (una función de la mayoría de las CDN modernas).
En general, cada vez que puedes entregar contenido directamente desde el perímetro (evitar un viaje al servidor de origen), es una ventaja de rendimiento. Incluso en los casos en los que sí tienes que hacer el recorrido de regreso a tu servidor de origen, las CDN generalmente están optimizadas para hacerlo mucho más rápido, por lo que es una ventaja en ambos casos.
Cambio de diseño acumulado (CLS)
El siguiente conjunto de recomendaciones es para el Cambio de diseño acumulado (CLS), que es una medida de estabilidad visual en páginas web. Si bien CLS mejoró mucho en la Web desde 2020, aproximadamente un cuarto de los sitios web aún no cumplen con el umbral recomendado, por lo que sigue siendo una gran oportunidad para que muchos sitios mejoren la experiencia del usuario.
Configura tamaños explícitos en cualquier contenido que se cargue desde la página
Los cambios de diseño suelen ocurrir cuando el contenido existente se mueve después de que otro contenido termina de cargarse. Por lo tanto, la forma principal de mitigar esto es reservar el espacio requerido con la mayor anticipación posible.
La forma más directa de corregir los cambios de diseño causados por imágenes sin tamaño es configurar explícitamente los atributos width y height (o propiedades de CSS equivalentes). Sin embargo, según HTTP Archive, el 72% de las páginas tiene al menos una imagen sin tamaño. Sin un tamaño explícito, los navegadores establecerán inicialmente una altura predeterminada de 0px y pueden provocar un cambio notable en el diseño cuando la imagen se cargue finalmente y se descubran las dimensiones. Esto representa una gran oportunidad para la Web colectiva, y esa oportunidad requiere mucho menos esfuerzo que algunas de las otras recomendaciones sugeridas en este artículo.
También es importante tener en cuenta que las imágenes no son los únicos que contribuyen a CLS. Los cambios de diseño pueden deberse a otro contenido que normalmente se carga después de que se renderiza la página inicialmente, como anuncios de terceros o videos incorporados. La propiedad aspect-ratio puede ayudar a combatir esto. Es una función de CSS relativamente nueva que permite a los desarrolladores proporcionar explícitamente una relación de aspecto a las imágenes y a los elementos que no son de imagen. Esto te permitirá establecer un width dinámico (por ejemplo, basado en el tamaño de la pantalla) y hacer que el navegador calcule automáticamente la altura adecuada, de manera muy similar a como lo hace con las imágenes con dimensiones.
A veces no es posible determinar el tamaño exacto del contenido dinámico, ya que, por su propia naturaleza, es dinámico. Sin embargo, incluso si no sabes el tamaño exacto, puedes tomar medidas para reducir la gravedad de los cambios de diseño. Configurar un min-height razonable casi siempre es mejor que permitir que el navegador use la altura predeterminada de 0px para un elemento vacío. El uso de un min-height también suele ser una solución fácil, ya que permite que el contenedor crezca hasta la altura final del contenido si es necesario. Acaba de reducir esa cantidad de crecimiento de la cantidad total a un nivel más tolerable.
Asegúrate de que las páginas sean aptas para la bfcache
Los navegadores usan un mecanismo de navegación llamado memoria caché atrás/adelante (o bfcache) para cargar instantáneamente una página anterior o posterior en el historial de navegación directamente desde una instantánea de la memoria.
La bfcache es una optimización de rendimiento significativa a nivel del navegador y elimina por completo los cambios de diseño durante la carga de la página, que en muchos sitios es donde ocurre la mayor parte de su CLS. La introducción de la bfcache generó la mayor mejora en CLS que observamos en 2022.
A pesar de ello, una cantidad significativa de sitios web no son aptos para la bfcache, por lo que se están perdiendo esta mejora del rendimiento web gratuito debido a una cantidad significativa de navegaciones. A menos que tu página esté cargando información sensible que no quieras que se restablezca de la memoria, debes asegurarte de que tus páginas sean aptas.
Los propietarios de los sitios deben verificar que sus páginas sean aptas para la bfcache y solucionar los posibles motivos por los que no lo son. Chrome ya tiene un verificador de bfcache en Herramientas para desarrolladores y este año planeamos mejorar las herramientas aquí con una nueva auditoría de Lighthouse que realiza una prueba similar y una API para medir esto en el campo.
Si bien incluimos la bfcache en la sección CLS, como vimos las mayores ganancias hasta ahora, la bfcache también, por lo general, también mejorará otras Métricas web esenciales. Es una de las varias navegaciones instantáneas disponibles que permiten mejorar drásticamente las navegaciones de páginas.
Evita las animaciones/transiciones que utilizan propiedades de CSS que inducen el diseño.
Otra fuente común de cambios de diseño es cuando se animan los elementos. Por ejemplo, los banners de cookies y otros banners de notificación que se deslizan desde la parte superior o inferior suelen contribuir a CLS. Esto es particularmente problemático cuando estos banners despliegan otro contenido, pero incluso cuando no lo hacen, animarlos puede afectar CLS.
Si bien los datos de HTTP Archive no pueden conectar de forma concluyente las animaciones con los cambios de diseño, los datos muestran que las páginas que animan cualquier propiedad de CSS que podría afectar el diseño tienen un 15% menos de probabilidades de tener un CLS “bueno” que las páginas en general. Algunas propiedades están asociadas con un CLS peor que otras. Por ejemplo, las páginas con animaciones de ancho de margin o border tienen un CLS "deficiente" casi al doble del índice que las páginas se evalúan como deficientes.
Quizás no te sorprenda, ya que cada vez que realices la transición o la animación de cualquier propiedad de CSS que induzca el diseño, se producirán cambios de diseño y, si esos cambios de diseño no se producen dentro de los 500 milisegundos de una interacción del usuario, afectarán al CLS.
Lo que podría sorprender a algunos desarrolladores es que esto es así incluso en los casos en que el elemento se saca del flujo normal de documentos. Por ejemplo, los elementos de posicionamiento absoluto que animan top o left generarán cambios de diseño, incluso si no están empujando otro contenido. Sin embargo, si en lugar de animar top o left, animas transform:translateX() o transform:translateY(), no se hará que el navegador actualice el diseño de la página y, por lo tanto, no se producirán cambios de diseño.
Por mucho tiempo, preferir la animación de las propiedades de CSS que se pueden actualizar en el subproceso compositor del navegador ha sido una práctica recomendada para el rendimiento porque mueve ese trabajo a la GPU y fuera del subproceso principal. Además de ser una práctica recomendada de rendimiento general, también puede ayudar a mejorar CLS.
Como regla general, nunca animes ni transfieras ninguna propiedad de CSS que requiera que el navegador actualice el diseño de la página, a menos que lo hagas en respuesta a la presión de un usuario o a presionar una tecla (aunque no hover). Siempre que sea posible, prioriza transiciones y animaciones con la propiedad transform de CSS.
La auditoría de Lighthouse Evita las animaciones no compuestas mostrará una advertencia cuando una página anime propiedades de CSS potencialmente lentas.
Retraso de primera entrada (FID)
Nuestro último conjunto de recomendaciones corresponde al Retraso de primera entrada (FID), que mide la capacidad de respuesta de una página ante las interacciones del usuario. Si bien actualmente la mayoría de los sitios de la Web obtienen una buena puntuación en cuanto a FID, documentamos las deficiencias de la métrica de FID en el pasado y creemos que aún hay muchas oportunidades para que los sitios mejoren su capacidad de respuesta general ante las interacciones de los usuarios.
Nuestra nueva métrica de Interacción con la próxima pintura (INP) es un posible sucesor de FID, y todas las recomendaciones que aparecen a continuación se aplican de la misma manera tanto a FID como a INP. Dado que los sitios tienen un peor rendimiento en INP que en FID, especialmente en dispositivos móviles, recomendamos a los desarrolladores que consideren seriamente estas recomendaciones de capacidad de respuesta, a pesar de tener un FID "bueno".
Evitar o dividir las tareas largas
Las tareas son cualquier trabajo discreto que realiza el navegador. Las tareas incluyen la renderización, el diseño, el análisis, la compilación y la ejecución de secuencias de comandos. Cuando las tareas se convierten en tareas largas (es decir, de 50 milisegundos o más), bloquean el subproceso principal y no pueden responder rápidamente a las entradas del usuario.
Según el Almanac web, existe mucha evidencia que sugiere que los desarrolladores podrían estar haciendo más para evitar o dividir tareas largas. Si bien dividir las tareas largas puede no ser tan sencillo como el de otras recomendaciones de este artículo, requiere menos esfuerzo que otras técnicas que no se ofrecen en él.
Si bien siempre debes esforzarte por hacer el menor trabajo posible en JavaScript, puedes ayudar bastante al subproceso principal si divides las tareas largas en otras más pequeñas. Para ello, ingresa al subproceso principal con frecuencia para que las actualizaciones de renderización y otras interacciones del usuario ocurran con mayor rapidez.
Otra opción es considerar usar APIs como isInputPending y la API de Scheduler. isInputPending es una función que muestra un valor booleano que indica si una entrada del usuario está pendiente. Si muestra true, puedes ceder al subproceso principal para que pueda controlar la entrada pendiente del usuario.
La API de Scheduler es un enfoque más avanzado que te permite programar el trabajo en función de un sistema de prioridades que considera si el trabajo que se realiza es visible para el usuario o se ejecuta en segundo plano.
Al dividir las tareas largas, le estás dando al navegador más oportunidades de adaptarse al trabajo crítico visible para el usuario, como lidiar con las interacciones y las actualizaciones resultantes de la renderización.
Evita el uso de JavaScript innecesario
No hay duda de ello: los sitios web envían más JavaScript que nunca, y parece que la tendencia no cambiará pronto. Cuando envías demasiado JavaScript, creas un entorno en el que las tareas compiten por la atención del subproceso principal. Esto definitivamente puede afectar la capacidad de respuesta de tu sitio web, especialmente durante ese período crucial de inicio.
Sin embargo, este no es un problema que no se puede resolver. Tienes algunas opciones:
- Usa la herramienta de cobertura en las Herramientas para desarrolladores de Chrome para encontrar el código que no se usa en los recursos de tu sitio web. Al reducir el tamaño de los recursos que necesitas durante el inicio, puedes asegurarte de que tu sitio web dedique menos tiempo a analizar y compilar código, lo que genera una experiencia del usuario inicial más fluida.
- En ocasiones, el código sin usar que encuentras en la herramienta de cobertura se marca como "sin usar" porque no se ejecutó durante el inicio, pero sigue siendo necesario para algunas funciones en el futuro. Es un código que puedes mover a otro paquete mediante la división de código.
- Si utilizas un administrador de etiquetas, asegúrate de revisar tus etiquetas de forma periódica para asegurarte de que estén optimizadas o incluso si todavía se están usando. Puedes borrar las etiquetas antiguas con código sin usar para que el código JavaScript de tu Administrador de etiquetas sea más pequeño y eficiente.
Cómo evitar actualizaciones de renderización grandes
JavaScript no es lo único que puede afectar la capacidad de respuesta de tu sitio web. Por sí solo, la renderización puede ser un tipo de trabajo costoso y, cuando se producen grandes actualizaciones de renderización, estas pueden interferir en la capacidad de tu sitio web para responder a las entradas del usuario.
Optimizar el trabajo de renderización no es un proceso sencillo y, a menudo, depende de lo que quieras lograr. Aun así, existen algunas medidas que puedes tomar para asegurarte de que las actualizaciones de renderización sean razonables y no se propaguen en tareas largas:
- Evita usar
requestAnimationFrame()para realizar trabajos no visuales. Las llamadas arequestAnimationFrame()se controlan durante la fase de renderización del bucle de eventos y, cuando se realiza demasiado trabajo durante este paso, es posible que se retrasen las actualizaciones de renderización. Es fundamental que cualquier trabajo que realices conrequestAnimationFrame()se reserve estrictamente para tareas que implican actualizaciones de renderización. - Mantén el tamaño del DOM pequeño. El tamaño del DOM y la intensidad del trabajo de diseño están correlacionados. Cuando el renderizador debe actualizar el diseño de un DOM muy grande, el trabajo necesario para volver a calcular su diseño puede aumentar de manera significativa.
- Usa la contención de CSS. La contención de CSS se basa en la propiedad
containde CSS, que brinda instrucciones al navegador para realizar el trabajo de diseño del contenedor en el que está establecida la propiedadcontain, incluido el aislamiento del alcance del diseño y la renderización en una raíz específica en el DOM. No siempre es un proceso sencillo, pero, si aíslas áreas que contienen diseños complejos, puedes evitar realizar trabajos de diseño y renderización que no sean necesarios.
Conclusión
Mejorar el rendimiento de la página puede parecer una tarea abrumadora, especialmente si se tiene en cuenta una gran cantidad de guías en toda la Web. Sin embargo, si te enfocas en estas recomendaciones, puedes abordar el problema con un enfoque y un propósito, y hacer cambios en las Métricas web esenciales de tu sitio web.
Si bien las recomendaciones que se mencionan aquí no son exhaustivas, creemos, según un análisis cuidadoso del estado de la Web, que estas son las formas más eficaces en que los sitios pueden mejorar su rendimiento en las Métricas web esenciales en 2023.
Si deseas ir más allá de las recomendaciones que se enumeran aquí, consulta estas guías de optimización para obtener más información:
Celebremos un nuevo año y una Web más rápida para todos. Que tus sitios sean rápidos para los usuarios en todas las formas más importantes
Foto de Devin Avery