Cómo optimizar su sitio para los elementos básicos de la web de Google

Google tiene la misión de mejorar el rendimiento web con Core Web Vitals. ¿Por qué? Debido a que el negocio de Google se basa predominantemente en la web, los sitios lentos y las aplicaciones web empujan a los usuarios a las aplicaciones nativas.

Su ubicación en los resultados de búsqueda de Google está determinada en gran medida por las palabras clave del término de búsqueda, el uso de esas palabras clave dentro de su página y la popularidad de su página de acuerdo con el número (y la calidad) de los enlaces de otros lugares. Desde agosto de 2021, Google también se esfuerza por evaluar las páginas en función del rendimiento.

Este artículo le mostrará cómo puede optimizar su sitio para las métricas de Core Web Vitals de Google.

¿Por qué Core Web Vitals?

El contenido sigue siendo crucial. Pero si compara dos sitios con texto y popularidad similares, el que ofrece la mejor experiencia web tendrá una mayor prioridad en los resultados de búsqueda de Google.

Además de una clasificación de página mejorada, los sitios de alto rendimiento son elegibles para su inclusión en el carrusel de búsqueda móvil. Anteriormente, esto estaba reservado para Accelerated Mobile Pages (AMP), que requería que transfiriera contenido a un sitio separado alojado por Google. AMP ha atraído críticas, especialmente porque las páginas no siempre son más rápidas que un WordPress o un sitio estático bien optimizado. Sin embargo, eso ya no es un requisito.

Independientemente de lo que elija, cuanto más rápido y receptivo sea su sitio, más posibilidades tendrá de obtener una clasificación más alta en los resultados de búsqueda de Google.

Cuando considere que la página promedio es de alrededor de 2 MB, realiza más de 60 solicitudes HTTP y tarda 16 segundos en procesarse en un dispositivo móvil por completo, verá que hay cierto margen para mejorar su sitio. Le mostraremos las mejores formas de lograr esas mejoras.

Factores de clasificación clave de Google

Hay cuatro factores clave de clasificación que debe examinar antes de comenzar a evaluar el desempeño:

1. HTTPS: HTTPS es esencial. ¿Su sitio establece una conexión segura entre el navegador del usuario y el servidor web?
2. Compatibilidad con dispositivos móviles: Su sitio debe funcionar bien en un dispositivo móvil. ¿Su sitio se puede utilizar en dispositivos de pantalla pequeña? ¿Se renderiza sin desbordamientos de contenido? ¿Es el texto lo suficientemente grande? ¿Las áreas en las que se puede hacer clic son suficientes para el control táctil?
3. Sin intersticiales: Evite los intersticiales intrusivos que requieren una cantidad excesiva de espacio en la pantalla. ¿Tu contenido es siempre legible? ¿Está parcialmente oculto por anuncios publicitarios o intersticiales emergentes? ¿Su publicidad o promociones de marketing dificultan el uso del sitio?
4. Navegación segura: Su sitio debe estar libre de malware, virus, phishing, fraude y otras estafas.

Una vez que cumpla con estos requisitos, se evaluará el rendimiento de su sitio.

Cuanto más rápido y receptivo sea su sitio, más posibilidades tendrá frente a sus competidores. 💪Haz clic para tuitear

¿Cómo evalúa Google el rendimiento web?

Hacer que su sitio se cargue rápidamente, se renderice rápidamente y responda antes es vital. Pero, ¿se siente rápido para los usuarios?

Las aplicaciones de medición del rendimiento, como DevTools del navegador, informan mediciones técnicas como:

1. Tiempo de bloqueo: El tiempo que se tarda en esperar a que se inicie una descarga, normalmente porque otros activos, como hojas de estilo y scripts, tienen una prioridad más alta.
2. Resolución de DNS: El tiempo para convertir un nombre de host en una dirección IP para recuperar un activo.
3. Tiempo de conexión: El tiempo para inicializar una conexión TCP.
4. Tiempo hasta el primer byte (TTFB): El tiempo total entre la solicitud y el primer byte de la respuesta.
5. Recibir tiempo: El tiempo para recuperar todo el activo.
6. Tiempo de carga de DOM: El tiempo para descargar y renderizar el modelo de objetos de documento HTML. Este suele ser el primer punto en el que los scripts que analizan o modifican el DOM pueden ejecutarse de forma fiable.
7. Tiempo de carga de la página: El tiempo para descargar la página y todos los activos, como imágenes, hojas de estilo, scripts, etc.
8. Peso total de la página: El tamaño total de todos los activos. A menudo se informa tanto en tamaño comprimido (descarga) como sin comprimir.
9. El número de elementos DOM: El número total de elementos HTML en la página. Cuantos más elementos, más tiempo tarda la página en procesarse.
10. Primera pintura con contenido (FCP): El tiempo que tarda el navegador en renderizar el primer píxel de contenido.
11. Primera pintura significativa (FMP): El tiempo transcurrido antes de que el contenido de la página principal sea visible para el usuario.
12. Tiempo para interactuar (TTI): El tiempo que se tarda antes de una página es completamente interactivo y puede responder de manera confiable a la entrada del usuario.
13. Primera CPU inactiva: El tiempo para que la CPU procese la página y ejecute todos los scripts de inicialización, esperando más datos.
14. Uso de CPU: La actividad de procesamiento requerida al representar la página y responder a la entrada del usuario.
15. Diseños por segundo: La velocidad a la que el navegador tiene que volver a calcular estilos y diseños de página.

Estos se pueden usar para determinar cuellos de botella específicos, como la carga del servidor, el almacenamiento en caché del CMS, el almacenamiento en caché del navegador, las velocidades de descarga y la eficiencia de JavaScript. Pero no pueden determinar si una página ofrece una experiencia de usuario buena o mala. Por ejemplo:

• Una aplicación podría descargarse y aparecer rápidamente, pero dejar de responder después de la primera interacción porque está ejecutando una gran cantidad de código JavaScript no optimizado.
• Una aplicación de chat podría descargar datos continuamente a medida que los usuarios publican mensajes. Una herramienta de evaluación puede suponer que nunca se completó la carga, a pesar de que la página se siente receptiva.

Core Web Vitals es el intento de Google de resolver estos dilemas.

¿Qué son los elementos fundamentales de la Web?

Core Web Vitals (CWV) de Google son tres métricas de rendimiento que evalúan la experiencia del usuario en el mundo real:

• Pintura con contenido más grande (LCP): Rendimiento de carga
• Retardo de la primera entrada (FID): Rendimiento de interactividad
• Cambio de diseño acumulativo (CLS): Rendimiento de estabilidad visual

Esta nueva actualización del algoritmo de Google comenzó a implementarse a nivel mundial a fines de agosto de 2021. Las métricas de Core Web Vitals afectan principalmente a los resultados de búsqueda móvil, pero los equivalentes de escritorio seguirán si el experimento tiene éxito.

Las puntuaciones de LCP, FID y CLS de una página se basan en los últimos 28 días de métricas de usuarios reales recopiladas de forma anónima a través del navegador Chrome. Estas medidas pueden variar según el dispositivo del usuario, la conexión y otras actividades simultáneas, por lo que se calcula el percentil 75 en lugar de un promedio.

En otras palabras, las métricas de todos los usuarios se ordenan de mejor a peor y se toma la cifra en el punto de las tres cuartas partes. Por lo tanto, tres de cada cuatro visitantes del sitio experimentarán ese nivel de rendimiento o mejor.

Cualquier página que logre una buena puntuación (verde) para las tres métricas de Core Web Vitals recibirá una clasificación más alta en los resultados de búsqueda y se incluirá en el carrusel de «Noticias destacadas» en la aplicación Google News.

En las siguientes secciones, describiremos el algoritmo utilizado para calcular una métrica, las herramientas que puede utilizar para identificar la puntuación de una página, las causas típicas de las puntuaciones bajas y los pasos que puede seguir para resolver problemas de rendimiento.

Pintura con contenido más grande (LCP)

La pintura con contenido más grande mide el rendimiento de carga. En esencia, ¿qué tan rápido se procesa el contenido utilizable en la página?

LCP analiza cuánto tiempo tarda la imagen o el bloque de texto más grande en ser visible dentro de la ventana del navegador (arriba del pliegue). En la mayoría de los casos, el elemento más destacado será una imagen principal, un banner, un encabezado o un bloque de texto grande.

Cualquiera de los siguientes elementos es elegible para el análisis de pintura con contenido más grande:

• imágenes<img> elemento)
• imágenes dentro de gráficos vectoriales (un <image> incrustado en un <svg>)
• miniaturas de video (un atributo de póster establecido en una URL de imagen dentro de una <video> elemento)
• elementos con imágenes de fondo (normalmente cargadas con CSS background-image url() propiedad)
• elementos a nivel de bloque que contienen texto

Las páginas en las que se completa la pintura de contenido más grande dentro de los primeros 2,5 segundos de la carga de la página se consideran buenas (verdes). Las páginas que superan los 4,0 segundos se consideran malas (rojas):

Las mayores herramientas de análisis de pintura con contenido

LCP es la métrica Core Web Vital más fácil de comprender, pero puede que no sea obvio qué elemento se elegirá para el análisis.

Las DevTools Faro El panel se proporciona en navegadores basados ​​en Chromium como Chrome, Edge, Brave, Opera y Vivaldi. Abra DevTools desde el menú del navegador, generalmente en Más herramientas > Herramientas de desarrollo o los atajos de teclado Ctrl | Cmd + Mayús + i o F12 – luego navega al Faro pestaña (las ediciones anteriores pueden nombrarla Auditoría).

Genere un informe de rendimiento móvil, luego examine el resultado Rendimiento sección. El tiempo de pintura con contenido más grande se muestra con una sección expandible, que identifica el elemento elegido:

Puede generar información idéntica en las herramientas en línea PageSpeed ​​Insights y web.dev Measure si no tiene acceso a un navegador basado en Chromium:

Las DevTools Rendimiento El panel también muestra un indicador LCP. Para comenzar, haga clic en la circular Registro , vuelva a cargar su página, luego haga clic en el Parada para ver el informe. Haga clic en el icono de LCP en el Tiempos sección para identificar el elemento y ver un resumen de estadísticas.

La extensión Web Vitals está disponible para Google Chrome, pero se puede instalar en la mayoría de los navegadores basados ​​en Chromium. Calcula las métricas de Core Web Vitals para cada sitio que visita y su icono se vuelve verde, naranja o rojo según el resultado. También puede hacer clic en el icono de la extensión para ver más detalles de LCP:

La Consola de búsqueda de Google ahora ofrece una sección de Core Web Vitals si su sitio se agrega como una propiedad. El informe ilustra cómo las métricas de CWV han cambiado con el tiempo. Tenga en cuenta que no identifica métricas específicas de LCP y que solo están disponibles los sitios con un tráfico razonablemente alto:

El Informe de experiencia del usuario de Chrome le permite consultar estadísticas de uso real, incluido LCP en diferentes países, conexiones y dispositivos, para una URL específica. Es un proyecto público en Google BigQuery, por lo que debe registrarse para obtener una cuenta de Google Cloud Platform y proporcionar detalles de facturación. Nuevamente, el informe solo será útil cuando una URL tenga un nivel de tráfico razonablemente alto.

Finalmente, la biblioteca JavaScript de web-vitals es un pequeño script de 1 kB que puede calcular LCP y otras métricas de Core Web Vital para usuarios reales en su sitio en vivo. Como se puede descargar desde un CDN, puede agregar el siguiente script a su HTML <head>:

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>My page</title>
<script type="module">
import { getLCP } from 'https://unpkg.com/web-vitals?module';
getLCP(console.log);
</script>
<!-- rest of page -->

getLCP() es una función asincrónica a la que se le pasa una devolución de llamada que se activa cuando se calcula el valor de LCP (aunque es posible que nunca se active si la página se carga en una pestaña en segundo plano). A la función de devolución de llamada se le pasa un objeto que contiene:

• name: el nombre de la métrica («LCP» en este caso)
• value: el valor calculado
• id: un ID único que representa esta métrica para la página actual
• delta: el delta entre el valor actual y el último valor informado
• entries: una matriz de entradas utilizadas en el cálculo del valor

El script anterior envía el objeto a la consola, aunque es más práctico enviar los datos a un servidor o Google Analytics para un análisis más detallado.

Causas comunes de las puntuaciones de pintura con contenido más alto y pobre

Las puntuaciones de LCP bajas suelen deberse a páginas de carga lenta que impiden que el bloque más grande aparezca rápidamente:

• La respuesta del servidor puede ser lenta porque está sobrecargada o porque hace demasiado trabajo para representar una página. Es posible que esto no sea necesariamente culpa de su sitio; podría deberse a limitaciones del servidor si está utilizando un servicio de alojamiento compartido.
• CSS y JavaScript que bloquean el procesamiento pueden retrasar la carga de la página si se hace referencia a ellos en el HTML encima del contenido principal.
• Otros recursos, como imágenes y videos grandes, pueden reducir el ancho de banda disponible y demorar más en renderizarse.
• El contenido de la página generado en el cliente en lugar del servidor también tarda más en aparecer.

Cómo mejorar las puntuaciones de pintura con mayor contenido

Una auditoría exhaustiva puede identificar problemas de carga, pero generalmente se trata de reducir la cantidad de datos enviados al navegador. Los siguientes consejos ayudarán a lograr una puntuación LCP más saludable:

1. Actualice su servidor y / o servicio de alojamiento. Asegúrese de que las velocidades de descarga sigan siendo rápidas incluso en momentos de alto uso.
2. Active la compresión del servidor y HTTP / 2 +. ¡No hay razón para no hacerlo!
3. Reduzca el esfuerzo del servidor. Elimine el código no utilizado y los complementos de CMS, luego habilite el almacenamiento en caché efectivo.
4. Asegúrese de que el navegador pueda almacenar archivos en caché de manera eficaz. Establezca los hash de Expires, Last-Modified y ETag apropiados en el encabezado HTTP, para que los archivos no se soliciten nuevamente.
5. Utilice una red de distribución de contenido (CDN) para dividir la carga y alojar los activos en servidores geográficamente más cercanos a los usuarios.
6. Optimiza tus imágenes. Reducirlos a sus dimensiones más pequeñas y utilizar un formato adecuado para minimizar el tamaño de los archivos. Asegúrese de que cualquier imagen en el bloque de contenido más grande se solicite lo antes posible; una precarga podría ayudar.
7. Imágenes de carga diferida agregando un loading="lazy" atributo. Agregue atributos de ancho y alto para garantizar que se reserve el espacio adecuado en la página antes de que la imagen se complete la carga.
8. Minimice las solicitudes de terceros y considere mover activos a su dominio principal para evitar búsquedas de DNS extrañas.
9. Minimice la cantidad y el tamaño de los archivos solicitados, especialmente en la parte superior de su HTML.
10. Asegúrese de cargar solo las fuentes web necesarias. Cambie a fuentes compatibles con la Web para obtener el máximo rendimiento.
11. Elimine los archivos CSS y JavaScript no utilizados.
12. Concatenar y minimizar sus archivos JavaScript y CSS.
13. Evite las declaraciones @import de CSS: bloquean la representación y cargan estilos en serie.
14. Evite la codificación Base64: aumenta el tamaño de los archivos y requiere procesamiento adicional.
15. Considere CSS en línea crítico. Inserte CSS esencial «en la mitad superior de la página» en un <link> block en la parte superior de la página, luego cargue más hojas de estilo de forma asincrónica.
16. Utilice JavaScript asincrónico, diferido o de módulo ES para ejecutar scripts más tarde. Ejecute procesos de JavaScript de larga ejecución en un trabajador de servicios.

Retardo de la primera entrada (FID)

First Input Delay mide la capacidad de respuesta de su página. En esencia, ¿con qué rapidez responde a las acciones del usuario, como hacer clic, tocar y desplazarse?

La métrica FID se calcula como el tiempo entre la interacción del usuario y el navegador que procesa su solicitud. No mide el tiempo para ejecutar la función del controlador, que normalmente procesa la entrada y actualiza el DOM.

Las páginas con un tiempo FID de 100 milisegundos o menos se consideran buenas (verde). Las páginas que superan los 300 milisegundos se consideran deficientes (rojo):

Herramientas de análisis del retardo de la primera entrada

El retraso de la primera entrada es imposible de simular porque solo se puede medir cuando la página se sirve a un usuario real que interactúa con la página. Por lo tanto, el resultado depende de la velocidad y las capacidades del procesador de cada dispositivo.

El FID no se calcula en el panel DevTools Lighthouse ni en PageSpeed ​​Insights. Sin embargo, pueden determinar el tiempo total de bloqueo (TBT). Ésta es una aproximación razonable para el retardo de la primera entrada. Mide la diferencia de tiempo entre:

1. La primera pintura de contenido (FCP), o el momento en el que el contenido de la página comienza a mostrarse, y
2. El tiempo para interactuar (TTI), o el momento en el que la página puede responder a la entrada del usuario. Se presume TTI cuando no hay tareas de larga ejecución activas y menos de tres solicitudes HTTP aún no se han completado.

La extensión Web Vitals para Google Chrome también puede mostrar una métrica FID después de interactuar con la página desplazándose o haciendo clic. Haga clic en el icono de la extensión para revelar más información:

Al igual que LCP, el Informe de experiencia del usuario de Chrome le permite consultar estadísticas FID reales registradas en diferentes países, conexiones y dispositivos para una URL específica.

La biblioteca JavaScript de web-vitals también puede calcular métricas FID para usuarios reales en su sitio en vivo. Puede agregar la siguiente secuencia de comandos a su HTML <head> para generar métricas de FID a una función de devolución de llamada:

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>My page</title>
<script type="module">
import { getFID } from 'https://unpkg.com/web-vitals?module';
getFID(console.log);
</script>
<!-- rest of page -->

Causas comunes de puntajes deficientes de retraso en la primera entrada

Los puntajes deficientes de FID y TBT generalmente son causados ​​por el código del lado del cliente que acapara al procesador, como:

• Cantidades significativas de CSS y JavaScript que bloquean la representación, que detienen la carga de la página a medida que se descarga y analiza el código.
• Scripts de gran tamaño que requieren gran cantidad de procesos que se ejecutan inmediatamente cuando se carga la página
• Tareas de JavaScript de ejecución prolongada o mal optimizadas

De forma predeterminada, los navegadores se ejecutan en un único hilo, que solo puede procesar una tarea a la vez. Si una función de JavaScript tarda un segundo en ejecutarse, todos los demás procesos de representación se bloquean durante ese segundo. La página no puede reaccionar a la entrada del usuario, actualizar el DOM, mostrar animaciones, etc. Incluso las animaciones GIF se pueden bloquear en navegadores más antiguos.

Cómo mejorar las puntuaciones de retraso de la primera entrada

Una auditoría de JavaScript del lado del cliente puede identificar problemas, pero generalmente se trata de eliminar el código redundante y garantizar que las tareas se ejecuten rápidamente.

Los siguientes consejos ayudarán a lograr una puntuación FID más saludable:

1. Genere y almacene en caché tanto contenido HTML estático en el servidor como sea posible. Trate de no depender de los marcos de JavaScript del lado del cliente para representar el mismo HTML para todos.
2. Asegúrese de que el navegador pueda almacenar archivos en caché de manera eficaz. Establezca los hash de Expires, Last-Modified y ETag apropiados en el encabezado HTTP, para que los archivos no se soliciten nuevamente.
3. Adopte técnicas de mejora progresiva, por lo que la interfaz se puede utilizar en HTML y CSS antes de que se ejecute JavaScript.
4. Elimine los archivos CSS y JavaScript no utilizados.
5. Concatenar y minimizar sus archivos JavaScript y CSS.
6. Evite el uso excesivo de costosas propiedades CSS como box-shadow y filter.
7. Utilice JavaScript asincrónico, diferido o de módulo ES para ejecutar scripts más tarde.
8. Minimice las solicitudes de JavaScript de terceros para análisis, widgets de redes sociales, foros de discusión, etc. Estos pueden acumularse rápidamente hasta varios megabytes de JavaScript.
9. Componentes de JavaScript de carga diferida a pedido, por ejemplo, widgets de chat, reproductores de video, etc.
10. Retrase la carga de scripts menos críticos, como análisis, anuncios y herramientas de redes sociales.
11. Divida las tareas de JavaScript de larga ejecución en una serie de trabajos más pequeños que se ejecutan después de un breve retraso de requestIdleCallback, setTimeout o requestAnimationFrame.
12. Considere la posibilidad de ejecutar procesos de JavaScript de ejecución prolongada en un trabajador web, que utiliza un subproceso en segundo plano.

Cambio de diseño acumulativo (CLS)

CLS mide la estabilidad visual de la página. En esencia, ¿el contenido de la página se mueve o salta inesperadamente, especialmente durante la carga inicial?

CLS calcula una puntuación cuando los elementos se mueven sin advertencia o interacción del usuario. Probablemente haya experimentado esto al leer un artículo en un dispositivo móvil: el texto salta repentinamente de la pantalla y pierde su lugar. Los peores ejemplos pueden hacer que haga clic en un enlace incorrecto.

Los problemas de CLS son más prominentes cuando una imagen grande o un anuncio se carga por encima de la posición de desplazamiento actual y un espacio de altura cero crece instantáneamente en varios cientos de píxeles.

Las puntuaciones acumuladas de cambio de diseño se calculan multiplicando las siguientes métricas:

• La fracción de impacto: Esta es el área total de todos los elementos inestables en la ventana gráfica, es decir, aquellos que «saltarán». Si los elementos que cubren el 60% de la ventana gráfica se desplazan durante la carga de la página, la fracción de impacto es 0,6. Tenga en cuenta que los elementos que causaron ese cambio, como una imagen o un anuncio, se consideran estables porque no necesariamente se mueven después de ser renderizados.
• La fracción de distancia: Ésta es la mayor distancia recorrida por cualquier elemento inestable en la ventana gráfica. Si el mayor desplazamiento ocurre en un elemento que se mueve de 0,100 a 0,800, se ha desplazado 700 píxeles verticales. Si la ventana gráfica del dispositivo tiene una altura de 1000 px, la fracción de distancia es 700 px / 1000 px = 0,7. Por lo tanto, la puntuación acumulada de cambio de diseño calculada es 0,6 x 0,7 = 0,42.

Google ha realizado cambios en la métrica CLS para adaptarse a las siguientes situaciones:

• Los cambios de diseño se agrupan en «sesiones» que duran cinco segundos pero se cierran después de un segundo si no se producen más cambios de diseño. Si se producen dos o más cambios en un segundo, se suman sus puntuaciones.
• Los cambios de diseño no se registran durante 500 ms después de la interacción del usuario, como un clic. En algunos casos, esto desencadena actualizaciones de DOM (por ejemplo, abrir un menú, mostrar un mensaje de error, mostrar un diálogo modal, etc.).
• Las aplicaciones de una sola página que permanecen abiertas durante períodos más prolongados y realizan numerosas actualizaciones de DOM no se ven afectadas negativamente.

Las páginas que tienen una puntuación CLS de 0,1 o menos se consideran buenas (verde). Las páginas que superan 0,25 se consideran malas (rojas):

Herramientas de análisis de cambio de diseño acumulativo

Las métricas de CLS se calculan en DevTools Faro panel, PageSpeed ​​Insights y herramientas de medición de web.dev:

La extensión Web Vitals para Google Chrome también muestra la métrica CLS:

Al igual que LCP y FID, el Informe de experiencia de usuario de Chrome le permite consultar estadísticas CLS reales registradas en diferentes países, conexiones y dispositivos para una URL específica.

La biblioteca JavaScript de web-vitals también puede calcular métricas CLS para usuarios reales en su sitio en vivo, tal como lo hace con LCP y FID. La siguiente secuencia de comandos podría agregarse a su HTML <head> para generar métricas CLS a una función de devolución de llamada:

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>My page</title>
<script type="module">
import { getCLS } from 'https://unpkg.com/web-vitals?module';
getCLS(console.log);
</script>
<!-- rest of page -->

Causas comunes de puntuaciones de cambio de diseño acumulativas deficientes

Los puntajes de CLS bajos generalmente son causados ​​por activos de página de carga lenta y elementos DOM dinámicos o sin tamaño:

• El espacio de la página no está reservado para imágenes, iframes, anuncios, etc.
• El contenido se inyecta dinámicamente en el DOM, generalmente después de una solicitud de red de anuncios, widgets de redes sociales, etc.
• La carga de fuentes web provoca un notable destello de texto invisible (FOIT) o destello de texto sin estilo (FOUT).

Cómo mejorar las puntuaciones acumulativas de cambio de diseño

Una auditoría del lado del cliente puede identificar problemas, pero generalmente se trata de garantizar que se reserve espacio para el contenido antes de que se descargue. Los consejos de optimización del servidor sugeridos para la pintura con contenido más grande tendrán algunos beneficios, pero es posible realizar más mejoras:

1. Agregar atributos de ancho y alto a HTML <img> y <iframe> etiquetas o utilice la nueva propiedad CSS de relación de aspecto para garantizar que se reserve el espacio adecuado en la página antes de que se descarguen los elementos.
2. Establezca las dimensiones adecuadas para los elementos del contenedor que incluyen contenido de terceros de carga más lenta, como anuncios y widgets.
3. Asegúrese de que las imágenes y otros recursos que aparecen en la parte superior de la página se soliciten lo antes posible; una carga previa podría resultar útil.
4. Minimice el uso de fuentes web y considere usar fuentes de sistema operativo comúnmente disponibles cuando sea posible.
5. Cargue fuentes web y configure la visualización de fuentes CSS como opcional o intercambiable. Asegúrese de utilizar una fuente alternativa de tamaño similar para minimizar el cambio de diseño.
6. Evite insertar elementos hacia la parte superior de la página a menos que responda a una acción del usuario, como un clic.
7. Asegúrese de que las interacciones del usuario se completen dentro de los 500 milisegundos del disparador de entrada.
8. Utilice la transformación CSS y la opacidad para obtener animaciones más eficientes que no requieran un rediseño.
9. Considere CSS en línea crítico. Inserte CSS esencial «en la mitad superior de la página» en un <link> block en la parte superior de la página, luego cargue hojas de estilo adicionales de forma asincrónica.
10. Cuando sea necesario, considere la contención, una nueva función de CSS que le permite identificar subárboles aislados de una página. El navegador puede optimizar el procesamiento mediante la representación, o no renderizado: bloques de contenido DOM específicos.

¿Quiere ver un sitio más rápido … y asegurarse de ser elegible para funciones como el carrusel de búsqueda móvil de Google? 👀 Empiece aquí ⤵Haz clic para tuitear

Resumen

Los desarrolladores no siempre están dispuestos a bailar con la melodía de Google. La empresa tiene un poder considerable y las actualizaciones menores del motor de búsqueda pueden afectar negativamente la productividad y la rentabilidad de las organizaciones basadas en la web.

Dicho esto, Core Web Vitals adopta un enfoque de “zanahoria” en lugar de un enfoque de “palo”. Los sitios bien optimizados y utilizables que renuncian a los patrones oscuros tienen más posibilidades de éxito que los sitios inflados y con muchas ventanas emergentes que ofrecen una IU móvil deficiente.

Core Web Vitals proporciona una forma medible de evaluar la experiencia del usuario para ayudarlo a concentrarse en las mejoras más críticas. Es posible que los cambios en sus signos vitales no aumenten los ingresos, pero sus usuarios estarán más felices y serán más leales.

¿Tiene otros consejos sobre cómo mejorar Core Web Vitals? Compártelos en la sección de comentarios!