--- title: "Cómo mejorar los Core Web Vitals: guía de campo — Dardo" description: "Encuentra qué métrica y plantilla fallan en Search Console, corrige LCP, INP y CLS según su causa y confírmalo en datos de campo, con notas para sitios 3D." url: "https://dardo.studio/es/blog/mejorar-core-web-vitals/" language: "es" translations: {"en":"https://dardo.studio/en/blog/pass-core-web-vitals/","pt":"https://dardo.studio/pt/blog/melhorar-core-web-vitals/"} updated: "2026-10-15T14:06:23.714Z" --- [Blog](https://dardo.studio/es/blog/) # Cómo mejorar los Core Web Vitals: guía basada en datos de campo para sitios de marketing Encuentra qué métrica y plantilla fallan en Search Console, corrige LCP, INP y CLS según su causa y confirma el resultado en datos de campo 28 días después. Por [Nicolás Cerón](https://dardo.studio/es/nicolas-ceron/) ·15 de octubre de 2026 ![Un patio ferroviario con neblina en la hora azul bajo lámparas ámbar, donde una sola vía carmesí atraviesa filas de rieles grises hacia una caseta de señales iluminada junto a una puerta abierta.](https://dardo.studio/_astro/01M4YY262MHNX487SWZ7QSA1V6_Z1igRsR.webp) ## Puntos clave - Empieza por el informe de Core Web Vitals de Search Console: agrupa URL similares, etiqueta cada grupo por su peor métrica y ordena sus páginas por impresiones, así que corriges una plantilla, no una página. - En el análisis de Google sobre datos de campo de Chrome, el sitio mediano con LCP deficiente esperaba 1,29 segundos antes de solicitar su imagen LCP y tardaba 350 milisegundos en descargarla, así que corrige primero el descubrimiento y la prioridad, y después la compresión. - El INP cuenta solo clics, toques y pulsaciones de tecla; en los sitios de marketing, el lento suele ser el botón Aceptar de un banner de consentimiento o una etiqueta que corre durante la carga. - Lighthouse ve una sola carga de página, mientras que CrUX cuenta los desplazamientos de layout de toda la visita, incluido el contenido de carga diferida durante el scroll y los provocados por pasar el cursor. - Los datos de campo de Google son una ventana móvil de 28 días, así que anota la fecha de cada versión y juzga una corrección unas cuatro semanas después. ## La respuesta corta Mejorar los Core Web Vitals empieza por los datos de campo de Google, no por la puntuación de Lighthouse. Averigua qué métrica falla, si en móvil o en computador, y en qué plantilla de página, en el informe de Core Web Vitals de Search Console. Después corrige la causa detrás de esa métrica: en Largest Contentful Paint (LCP) suele ser lo tarde que el navegador descubre la imagen o el texto principal; en Interaction to Next Paint (INP), un script que mantiene ocupado el hilo principal cuando alguien toca la pantalla; y en Cumulative Layout Shift (CLS), contenido que llega sin espacio reservado. Corrige la plantilla, anota la fecha de publicación y juzga el resultado unos 28 días después, cuando la ventana móvil de Google solo contiene visitas al código nuevo. Si tus visitantes están en Latinoamérica, empieza por [Core Web Vitals en Latinoamérica](https://dardo.studio/es/blog/core-web-vitals-latinoamerica/): en septiembre de 2026, solo un tercio de los sitios aprobó en móvil en Colombia. Es el método que seguimos en nuestro propio sitio y en las auditorías de clientes. Si prefieres delegarlo, es lo que hace nuestro servicio de [optimización de velocidad web](https://dardo.studio/es/servicios/optimizacion-de-velocidad-web/); esa página también explica costos y posicionamiento. En el celular, LCP es la métrica que más sitios reprueban. El [Web Almanac 2025](https://almanac.httparchive.org/en/2025/performance) de HTTP Archive, construido con datos de campo de Chrome, encontró un buen LCP en el 62% de los sitios móviles, frente al 77% en INP y al 81% en CLS; el 48% aprobó las tres. ## Paso 1: encuentra la métrica que falla y la plantilla Una página aprueba cuando el 75% de sus visitas obtiene un LCP de 2,5 segundos o menos, un INP de 200 milisegundos o menos y un CLS de 0,1 o menos, medido por separado en móvil y en computador. Abre el informe de Core Web Vitals de Search Console y empieza por móvil. Agrupa páginas similares y le da a cada grupo el estado de su peor métrica, así que un grupo con buen LCP y mal CLS se marca como deficiente ([Ayuda de Search Console](https://support.google.com/webmasters/answer/9205520)). Cada URL de ejemplo representa un grupo cuyas páginas se ordenan por impresiones, lo que te dice qué plantilla corregir primero. Para ver cómo les va en promedio a los sitios de tu plataforma en el país de tus visitantes, nuestro [informe de velocidad de plataformas web](https://dardo.studio/es/herramientas/velocidad-plataformas-web/) ordena 31 plataformas por Core Web Vitals de usuarios reales, con datos mensuales de HTTP Archive. Luego afina: - **PageSpeed Insights** muestra los últimos 28 días de una URL, con actualización diaria, y recurre a todo el origen cuando la página tiene pocas visitas. Revisa cuál de los dos estás leyendo. - **CrUX Vis**, en cruxvis.withgoogle.com, grafica los mismos datos semana a semana durante las últimas 40 semanas ([Chrome for Developers](https://developer.chrome.com/docs/crux/history-api)). Una métrica que se volvió deficiente en una semana suele apuntar a una publicación, una etiqueta nueva o una campaña. - **La API de CrUX** también informa el tipo de recurso del LCP y, en los LCP de imagen, cada subparte del LCP en el percentil 75, así que ves en qué se va el tiempo antes de abrir DevTools. Cuando no hay datos de campo, el sitio suele estar por debajo del umbral de popularidad de Chrome. Es nuestro caso: el 14 de octubre de 2026, PageSpeed Insights no tenía datos de campo de dardo.studio, ni de la página ni del origen. Por eso medimos nuestras visitas con la biblioteca de código abierto web-vitals de Google, sin cookies, agrupadas por tipo de página y tamaño de pantalla. Dos reglas que aprendimos al usarla: una visita sin toques ni teclas no tiene INP, así que nunca la registres como cero, y nuestros grupos de pantalla pequeña y grande no son el móvil y el computador de Google, por lo que no los comparamos uno a uno con CrUX. Montar esta medición es parte de nuestro trabajo de [configuración de analítica web](https://dardo.studio/es/servicios/configuracion-de-analitica-web/). ## Paso 2: reproduce el problema en laboratorio y lee la causa Las herramientas de laboratorio encuentran causas; los datos de campo dicen si apruebas. Graba una traza en el panel Performance de Chrome DevTools con la limitación de CPU calibrada para un celular de gama media, disponible desde Chrome 134. La limitación frena el procesador, no el chip gráfico, así que los efectos pesados para la GPU solo muestran su costo real en un teléfono físico ([Chrome for Developers](https://developer.chrome.com/blog/devtools-grounded-real-world)). Nuestra página de inicio muestra por qué la puntuación es solo un punto de partida. En esa medición de PageSpeed Insights, el Moto G Power emulado por Lighthouse con 4G lenta dio un LCP de 6,0 segundos, mientras que nuestra propia medición, con una muestra pequeña, daba a la página de inicio un LCP de 1,1 segundos en el percentil 75 en pantallas pequeñas durante los siete días hasta el 3 de octubre. Lo útil fue el diagnóstico: el elemento LCP es el titular h1, no la escena 3D, y el desglose mostró 10 milisegundos de respuesta del servidor seguidos de 1.460 milisegundos de retraso en el renderizado del elemento. Eso apunta a fuentes y trabajo que bloquea el renderizado, no a imágenes. ## Corrige el LCP según la subparte demasiado larga Todo LCP se divide en cuatro partes consecutivas: tiempo hasta el primer byte, retraso de carga del recurso hasta que el navegador lo solicita, duración de la carga del recurso y retraso en el renderizado del elemento ([web.dev](https://web.dev/articles/optimize-lcp)). Corrige la parte desproporcionada. | Subparte del LCP | Proporción sana del LCP | Qué suele alargarla | Primera corrección | | -------------------------------------- | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | | Tiempo hasta el primer byte | Cerca del 40% | Cadenas de redirecciones, HTML sin caché, un servidor lejano, cadenas de consulta que saltan la caché | Poner el HTML en caché en una CDN y quitar redirecciones | | Retraso de carga del recurso | Menos del 10% | Una imagen principal definida en CSS o JavaScript, con carga diferida, dentro de un carrusel o en otro host | Una etiqueta img en el HTML con fetchpriority="high", o un preload cuando el CSS debe definirla | | Duración de la carga del recurso | Cerca del 40% | Archivos sobredimensionados y un solo tamaño para todas las pantallas | Tamaños adaptables en AVIF o WebP | | Retraso en el renderizado del elemento | Menos del 10% | CSS y scripts que bloquean el renderizado, fuentes web en un LCP de texto, una imagen principal que espera a JavaScript para aparecer | CSS crítico en línea, scripts diferidos, imagen principal en el HTML, font-display | Las proporciones son la guía de web.dev para una página bien optimizada, no metas en segundos. Empieza por los retrasos. En el análisis de Google sobre datos de campo de Chrome, el sitio mediano con LCP deficiente esperaba 1.290 milisegundos entre el primer byte y la solicitud de su imagen LCP, y luego tardaba 350 milisegundos en descargarla; la mayoría de los sitios con LCP deficiente gasta menos del 10% en la descarga ([web.dev](https://web.dev/blog/common-misconceptions-lcp)). Comprime la imagen principal de todos modos; por sí sola, rara vez arregla un LCP que falla. El Almanac aún encontró que cerca del 16% de las páginas cargan de forma diferida su imagen LCP. Dos detalles que afectan a los sitios de marketing: - **Las imágenes principales a pantalla completa no cuentan.** El LCP trata los elementos que cubren todo el viewport como fondo y los omite, así que el LCP suele ser el titular; el texto fue el elemento LCP en el 23,7% de las páginas móviles. El texto no se considera pintado mientras su fuente web está en el periodo de bloqueo, así que la carga de fuentes se vuelve trabajo de LCP. - **La prioridad es relativa.** Poner fetchpriority="high" en más de una o dos imágenes anula el beneficio, y cada preload compite con lo que se pinta primero. La sección de 3D más abajo muestra ese equilibrio en nuestra página de inicio. ## Corrige el INP nombrando primero el script El INP es el clic, toque o pulsación de tecla más lento de una visita, ignorando uno por cada 50 interacciones; pasar el cursor y hacer scroll no cuentan ([web.dev](https://web.dev/articles/inp)). Cada interacción tiene tres partes: retraso de entrada mientras termina otro trabajo, procesamiento en tus controladores de eventos y retraso de presentación hasta que se pinta el siguiente fotograma. Encuentra la interacción y el script antes de cambiar nada. La versión con atribución de [web-vitals](https://github.com/GoogleChrome/web-vitals) informa el elemento tocado, las tres partes, si la página aún estaba cargando y los long animation frames que se solaparon con la interacción. Desde Chrome 123, esos fotogramas nombran por su URL cada script que corrió más de 5 milisegundos, así distingues tu código del de un proveedor ([Chrome for Developers](https://developer.chrome.com/docs/web-platform/long-animation-frames)). Los scripts dentro de iframes de otro origen no aparecen por nombre. En los sitios de marketing, la interacción lenta suele ser una de estas: - **El botón Aceptar del banner de consentimiento.** Aceptar suele disparar todas las etiquetas de marketing a la vez. El equipo de Chrome ha trabajado con plataformas de consentimiento para que cedan el control justo después del clic y el navegador lo reconozca en el siguiente fotograma ([web.dev](https://web.dev/articles/cookie-notice-best-practices)); si la tuya no lo hace, pídeselo al proveedor. - **Etiquetas que se disparan durante la carga.** Un toque que cae mientras corren las etiquetas espera a que terminen. En Google Tag Manager, las etiquetas de imagen cuestan menos y las de HTML personalizado más, y las etiquetas no esenciales deben dispararse después de Window Loaded ([web.dev](https://web.dev/articles/tag-best-practices)). - **Menús, acordeones y filtros** que cambian estilos y luego leen el layout en el mismo controlador, lo que obliga al navegador a calcular el layout de inmediato. Para arreglar tus propias tareas largas, divídelas y cede el hilo principal justo después de la actualización visual. scheduler.yield() lo hace con prioridad en Chrome y Edge 129 y posteriores y en Firefox 142 y posteriores; Safari no lo admite en octubre de 2026, así que recurre a setTimeout ([web.dev](https://web.dev/articles/optimize-long-tasks)). Revisa también las páginas internas: en el Almanac, el 80% de las páginas de inicio móviles tenía buen INP, pero solo el 69% de las demás, donde se acumulan filtros, carruseles y widgets. ## Corrige el CLS reservando espacio, también después de la carga Lighthouse mide una sola carga de página. CrUX cuenta los desplazamientos de toda la visita, agrupados en ráfagas de hasta cinco segundos, y reporta la peor ráfaga ([web.dev](https://web.dev/articles/cls)). Por eso una página puede verse estable en el laboratorio y fallar en Search Console. Los desplazamientos dentro de los 500 milisegundos posteriores a un clic, un toque o una tecla se excluyen, pero los provocados por pasar el cursor no, ni tampoco el contenido que se carga de forma diferida mientras alguien hace scroll. Las correcciones: - Dale a cada imagen y video atributos width y height, o un aspect-ratio en CSS. En 2025, el 62% de las páginas móviles tenía al menos una imagen sin dimensiones. - Reserva un espacio con min-height o aspect-ratio para incrustaciones, formularios y otro contenido tardío, y conserva el espacio aunque no llegue nada. - Muestra los banners de cookies y de promociones como superposiciones en lugar de empujar la página hacia abajo. - Haz que la fuente de respaldo coincida con la fuente web usando size-adjust y las anulaciones de ascent y descent, o usa font-display: optional. - Anima con transform, no con top, left, width ni height. Después, haz que la navegación hacia atrás y hacia adelante no cueste nada. Una de cada cinco navegaciones en móvil es hacia atrás o hacia adelante, y una página restaurada desde la caché de ida y vuelta (bfcache) vuelve exactamente como se dejó, sin desplazarse otra vez ([web.dev](https://web.dev/articles/bfcache)). Elimina los controladores unload, agrega Permissions-Policy: unload=() para que terceros no puedan añadirlos, evita Cache-Control: no-store en páginas públicas y prueba en DevTools, en Application, Back/forward cache. ## Las transiciones de página cambian lo que se mide Si tu sitio cambia de página con JavaScript, como las aplicaciones de una sola página, el enrutador cliente de Astro, los enlaces de Next.js y las bibliotecas de transiciones, Chrome ha tratado durante mucho tiempo toda la visita como una sola carga de página: cada interacción y cada desplazamiento de layout posterior a la primera página cuenta contra la URL en la que aterrizó el visitante. Chrome 151 introdujo las APIs de soft navigation, que miden cada ruta por separado. En octubre de 2026, Chrome publica métricas experimentales de soft navigation en CrUX y apunta a volverlas estándar en mayo de 2027, pero la mayoría de las herramientas todavía no las muestran ([web.dev](https://web.dev/articles/vitals-spa-faq)). Esto afecta a nuestras propias cifras: en una muestra de 24 horas del 3 de octubre, 29 de las 45 vistas de dardo.studio fueron soft navigations. Hasta que tus herramientas informen las rutas por separado, prueba INP y CLS en las páginas a las que la gente llega después de aterrizar, no solo en la página de aterrizaje. ## Las páginas con 3D y mucho movimiento necesitan sus propias marcas Nuestra guía de [páginas web 3D](https://dardo.studio/es/blog/paginas-web-3d/) cubre los presupuestos de modelos y texturas. Cuatro lecciones de medir la escena 3D en tiempo real de nuestra página de inicio: - **El LCP no mide la escena.** Nuestro LCP es el titular, así que el LCP puede ser bueno mientras la escena sigue a oscuras. Agrega una marca de User Timing cuando aparezca el primer fotograma 3D y repórtala junto con tus vitals. - **Busca cascadas de importaciones.** Nuestra apertura cargaba sus módulos uno tras otro, y cada uno descubría el siguiente. Pedirlos juntos redujo el intervalo a oscuras antes de la escena de una mediana de 1.214 a 697 milisegundos, en cinco ejecuciones en frío intercaladas de cada compilación local de producción con 150 ms de latencia, 9 Mbps y una CPU cuatro veces más lenta. - **Prueba los preloads en ambos sentidos.** Las pistas modulepreload de baja prioridad para esos mismos módulos dejaron la escena lista unos 60 milisegundos antes, pero retrasaron el primer pintado unos 120, así que las quitamos. - **Vigila la primera interacción con una sección.** Con la CPU cuatro veces más lenta, el primer hover sobre nuestra sección de servicios produjo una tarea de 92 milisegundos, un costo de preparación que los hover siguientes no pagaron. Pasar el cursor no cuenta para el INP, pero un toque que caiga durante esa tarea espera a que termine. Construir escenas como esta es nuestro servicio de [sitios web 3D interactivos](https://dardo.studio/es/servicios/sitios-web-3d-interactivos/). ## Verifica en datos de campo unos 28 días después Las pruebas de laboratorio confirman una corrección el día en que se publica; los datos de campo de Google, una ventana móvil de 28 días, tardan semanas. 1. **Publica una corrección por versión cuando puedas y anota la fecha.** Dos correcciones en una misma versión no se pueden distinguir después. 2. **Lee primero tu propia medición.** Compara las visitas posteriores a la versión con las anteriores; un informe móvil de 28 días mezcla la versión vieja con la nueva. 3. **Lee CrUX cada semana, no cada día.** La API CrUX History se actualiza los lunes con datos hasta el sábado anterior, y cada punto semanal comparte tres semanas de visitas con el anterior. El primer punto construido solo con visitas posteriores a la versión llega unas cuatro semanas después de publicarla. 4. **Inicia la validación en Search Console** cuando todas las URL del grupo estén corregidas. Monitorea durante 28 días y falla si alguna URL aún muestra el problema. 5. **Revisa los márgenes.** Un grupo cercano a un umbral puede cambiar de estado por un vaivén de tráfico o un host de imágenes más lento sin ningún cambio de código, como señala la ayuda de Search Console. Conserva las mejoras revisando los Core Web Vitals cada mes frente a etiquetas, imágenes e incrustaciones nuevas; nuestros planes de [mantenimiento web](https://dardo.studio/es/servicios/mantenimiento-web/) incluyen ese informe mensual. Si el objetivo de fondo es el posicionamiento, combínalo con [SEO técnico](https://dardo.studio/es/servicios/seo/), ya que los Core Web Vitals son una señal entre muchas. Y si quieres una segunda opinión, [envíanos la URL y la plantilla que falla](https://dardo.studio/es/contacto/?service=website-speed-optimization): te diremos con qué métrica y con qué parte de ella empezar. ## Preguntas frecuentes **¿Cuánto tardan en verse las mejoras de Core Web Vitals en Search Console?** Unas cuatro semanas. Search Console y PageSpeed Insights leen los datos de campo de Chrome como una ventana móvil de 28 días, así que las visitas a una corrección publicada hoy se mezclan con visitas anteriores hasta que la ventana avanza. Las pruebas de laboratorio y tu propia medición de usuarios reales muestran el cambio en días. Cuando todas las URL de un grupo estén corregidas, inicia la validación en el informe de Core Web Vitals, que monitorea el grupo durante 28 días. **¿Por qué PageSpeed Insights no muestra datos de campo de mi sitio?** Los datos de campo de Chrome solo incluyen páginas y orígenes descubribles públicamente y visitados por suficientes usuarios elegibles de Chrome. Una página con pocas visitas recurre a datos a nivel de origen, y un sitio pequeño puede no tener ninguno; dardo.studio no tenía el 14 de octubre de 2026. En ese caso, mide LCP, INP y CLS en tus propias visitas con la biblioteca de código abierto web-vitals y usa pruebas de laboratorio para encontrar causas. **¿Qué hago si mi puntuación de Lighthouse es baja pero mis Core Web Vitals aprueban?** Los datos de campo deciden si apruebas; Lighthouse es una carga simulada en un celular de gama media con conexión lenta. Usa sus diagnósticos, como el elemento LCP y su desglose, para encontrar causas que también aparezcan en los datos de campo, y no persigas la puntuación en sí. También ocurre lo contrario: una página puede puntuar bien en Lighthouse y fallar INP o CLS en campo, porque Lighthouse no ve toques ni desplazamientos posteriores a la carga. **¿Qué Core Web Vital debo corregir primero?** El que sea deficiente para más visitas, empezando por los grupos móviles con más impresiones en Search Console. En el celular suele ser el LCP: en los datos de 2025 de HTTP Archive, el 62% de los sitios móviles tenía buen LCP, frente al 77% en INP y al 81% en CLS. Dentro del LCP, empieza por la subparte desproporcionada, normalmente el retraso de carga del recurso o el tiempo hasta el primer byte, antes de comprimir imágenes. **¿Puede un plugin o una CDN arreglar los Core Web Vitals automáticamente?** En parte. Una CDN que guarda el HTML en caché acorta el tiempo hasta el primer byte, y la optimización de imágenes acorta la descarga. Ninguna decide qué elemento se convierte en tu LCP, qué scripts corren cuando alguien toca la pantalla ni dónde se reserva espacio para una incrustación o un banner, y esas son las causas habituales de un LCP, INP y CLS deficientes. Viven en las plantillas y en la configuración de etiquetas, así que ahí se corrigen. **¿Los Core Web Vitals miden cada página de un sitio con transiciones de página?** Todavía no en la mayoría de las herramientas. Cuando JavaScript cambia de página sin una carga completa, Chrome ha contado cada interacción y cada desplazamiento de layout posterior contra la URL en la que aterrizó el visitante. Chrome 151 añadió APIs que miden cada soft navigation por separado, y en octubre de 2026 Chrome empezó a publicar métricas experimentales de soft navigation en CrUX, con la meta de volverlas estándar en mayo de 2027. Mientras tanto, prueba INP y CLS en las páginas a las que la gente llega después de aterrizar. ## Fuentes y lecturas Fuentes de esta página, con más detalles de sus publicaciones originales. - [web.dev: Web Vitals](https://web.dev/articles/vitals) · web.dev - [Search Console Help: Core Web Vitals report](https://support.google.com/webmasters/answer/9205520) · support.google.com - [Chrome for Developers: CrUX History API](https://developer.chrome.com/docs/crux/history-api) · developer.chrome.com - [Google for Developers: About PageSpeed Insights](https://developers.google.com/speed/docs/insights/v5/about) · developers.google.com - [web.dev: Optimize Largest Contentful Paint](https://web.dev/articles/optimize-lcp) · web.dev - [web.dev: Common misconceptions about how to optimize LCP](https://web.dev/blog/common-misconceptions-lcp) · web.dev - [web.dev: Interaction to Next Paint (INP)](https://web.dev/articles/inp) · web.dev - [Chrome for Developers: Long Animation Frames API](https://developer.chrome.com/docs/web-platform/long-animation-frames) · developer.chrome.com - [web.dev: Optimize Cumulative Layout Shift](https://web.dev/articles/optimize-cls) · web.dev - [web.dev: Back/forward cache](https://web.dev/articles/bfcache) · web.dev - [web.dev: Core Web Vitals and single-page apps FAQ](https://web.dev/articles/vitals-spa-faq) · web.dev - [HTTP Archive: Web Almanac 2025, Performance](https://almanac.httparchive.org/en/2025/performance) · almanac.httparchive.org [Nicolás Cerón](https://dardo.studio/es/nicolas-ceron/) Nicolás Cerón es el fundador de Dardo, un estudio de marca, diseño y desarrollo web en Bogotá, Colombia. ## Artículos relacionados - [**Páginas web 3D: cuándo valen la pena y cómo hacer que carguen rápido**Cuándo se justifica una página web 3D, cuándo sirven más un video o imágenes, y cómo logramos que los diez mundos 3D de Janus Observatory cargaran rápido.](https://dardo.studio/es/blog/paginas-web-3d/) - [**PostHog vs Google Analytics: cuál necesita tu sitio o producto SaaS y cuándo usar las dos**GA4 se conecta con Google Ads y Search Console; PostHog suma replay, feature flags y experimentos. Cuál necesitas, cuánto cuesta cada una y cómo usarlas juntas.](https://dardo.studio/es/blog/ga4-vs-posthog/) - [**Webflow o WordPress en 2026: ¿cuál es mejor? Costos reales, edición, SEO y velocidad**Cuánto cuesta en tres años un sitio bilingüe de 20 páginas con blog de 300 artículos en Webflow y en WordPress, y cómo se comparan en edición, SEO y velocidad.](https://dardo.studio/es/blog/webflow-o-wordpress/) - [**Core Web Vitals en Latinoamérica: cuántos sitios aprueban por país y por qué fallan en móvil (datos 2026)**En septiembre de 2026, un tercio de los sitios aprobó las Core Web Vitals en móvil en Colombia y Brasil, frente al 63 % en EE. UU. Datos por país y qué hacer.](https://dardo.studio/es/blog/core-web-vitals-latinoamerica/) ## Sigue explorando. - [Servicio · **Optimización de velocidad web y Core Web Vitals**](https://dardo.studio/es/servicios/optimizacion-de-velocidad-web/) - [Tu proyecto · **Inicia una conversación**](https://dardo.studio/es/contacto/)