Velocidad de página y Core Web Vitals
En las prácticas de búsqueda modernas, la velocidad de página consiste en hacer que las páginas parezcan rápidas: el contenido principal aparece enseguida, el diseño se mantiene estable y las interacciones responden sin retrasos. El nombre público de Google para las tres métricas de campo que reflejan esa sensación es : Largest Contentful Paint (), Interaction to Next Paint () y Cumulative Layout Shift ().
A lo largo de esta página, supongamos que Fernwood necesita que su página de precios, sus páginas comparativas y sus guías principales superen los umbrales de "bueno" en móviles, donde llegan la mayoría de los visitantes nuevos y muchos clics remitidos por asistentes de IA.
Esta técnica no pretende ser deliberadamente un manual completo de ingeniería. web.dev ya ofrece las guías prácticas detalladas. Lo que sigue es el marco para tomar decisiones: qué significan las métricas, cuánto importan, cómo priorizar con Silktide y a dónde dirigir a los equipos de ingeniería para aplicar correcciones.
Por qué funciona (y cuánto importa)
Hay dos públicos a los que les importa:
- Visitantes. Un LCP lento y un CLS con saltos provocan abandonos antes de que se vea la respuesta o la CTA. Es un problema de conversión incluso cuando el posicionamiento es bueno.
- Búsqueda. Google afirma que los Core Web Vitals son utilizados por los sistemas de posicionamiento como parte de la experiencia de página y recomienda tener buenas métricas para lograr buenos resultados en la Búsqueda (Comprender los Core Web Vitals y los resultados de búsqueda de Google; Comprender la experiencia de página). Google también afirma que la Búsqueda sigue intentando mostrar el contenido más relevante incluso cuando la experiencia de página es deficiente; por tanto, las métricas son una señal real, no una palanca mágica de posicionamiento. Trátalas como un requisito básico y un factor de desempate entre páginas similares, no como sustituto del contenido que responde primero o de la autoridad.
En concreto para AEO: una página rápida no hará que un asistente de IA te cite. Pero una página lenta, cuyo diseño cambia, sigue perdiendo a las personas que envían esas citas; y la renderización pesada del lado del cliente que perjudica la velocidad a menudo también perjudica el contenido legible sin JavaScript.
Las tres métricas importantes
Los umbrales siguientes son los objetivos de "bueno" de Google, evaluados para usuarios reales aproximadamente en el percentil 75 (datos de campo). Las herramientas de laboratorio sirven para diagnosticar; los datos de campo son lo que evalúa la Búsqueda.
| Métrica | Qué mide | Bueno |
|---|---|---|
| LCP | Cuándo aparece el contenido principal | ≤ 2,5 s |
| INP | Con qué rapidez responde la página a clics/toques | ≤ 200 ms |
| CLS | Cuánto salta el diseño mientras se carga | ≤ 0,1 |
Detalles y guías de depuración: Web Vitals de web.dev, Optimizar LCP, Optimizar INP, Optimizar CLS.
Cómo abordar el problema (orden de operaciones de Fernwood)
1. Elige las páginas importantes
No intentes abarcarlo todo. Empieza por:
- Páginas de destino con mucho tráfico y la página de inicio
- Páginas que generan ingresos (precios, registro, comparativas clave)
- Las guías principales y páginas de investigación que quieres que se citen
Un archivo de blog mediocre puede esperar. Una página de precios lenta no.
2. Separa el diagnóstico de laboratorio de la realidad de campo
- Laboratorio (pruebas de velocidad de Silktide, Lighthouse, WebPageTest): repetible, útil para encontrar causas en una URL y un perfil de dispositivo concretos.
- Campo (informe de experiencia de usuario de Chrome / informe de Core Web Vitals de Search Console, RUM como Analytics en Silktide, cuando esté disponible): lo que experimentaron los visitantes reales.
Pueden diferir sin que ninguno esté equivocado: hay distintos dispositivos, países y estados de caché. Corrige los problemas de laboratorio que se correspondan claramente con fallos de campo; no persigas la perfección de laboratorio en una URL que ya supera los umbrales de campo.
La pantalla Velocidad de Silktide combina diagnósticos de laboratorio con mediciones de visitantes reales cuando Analytics está conectado. La comprobación Web Vitals resume el rendimiento de laboratorio; Páginas de carga lenta y Cambios de diseño aíslan LCP y CLS.
3. Corrige las causas, no las puntuaciones
Cuando Silktide (o Lighthouse) señale una causa, corrige esa causa:
| Causa habitual | Métrica típica | Silktide / siguiente paso |
|---|---|---|
| Imagen principal enorme, servidor lento, CSS/JS que bloquea el renderizado | LCP | Páginas de carga lenta, Precargar imagen LCP, comprobaciones de optimización de imágenes |
| Imágenes/anuncios/contenido incrustado sin espacio reservado; fuentes tardías | CLS | Cambios de diseño, Tamaños de imagen explícitos |
| Tareas largas de JavaScript al hacer clic | INP / TBT | Reducir el tiempo de ejecución de JavaScript, Eliminar recursos que bloquean el renderizado |
| Exceso general de bytes | Todas | Revisar el peso en bytes, formatos de imagen modernos, caché |
Los equipos de ingeniería deberían utilizar las guías de web.dev enlazadas anteriormente para los detalles de implementación: los patrones específicos de cada framework cambian más rápido de lo que debería hacerlo esta página.
4. Vuelve a probar las mismas URL
Después de una corrección, vuelve a ejecutar las pruebas de laboratorio con el mismo perfil de dispositivo y espera a que los datos de campo se actualicen (las ventanas de CrUX abarcan varias semanas). Evalúa el éxito según el estado de campo de las URL importantes, no según una captura de pantalla de Lighthouse solo de la página de inicio en una presentación.
Límites honestos
- El contenido sigue ganando. Una página rápida y vacía pierde frente a una respuesta completa más lenta. Trabajar la velocidad de páginas débiles es solo pulirlas.
- Terceros. Los gestores de etiquetas, los widgets de chat y las herramientas de pruebas A/B suelen dominar INP y LCP. Reserva capital político para eliminarlos o aplazarlos; minimizar tu propio CSS no te salvará de una bomba síncrona de terceros.
- SPA / renderizado solo del lado del cliente. Si el sitio de marketing de Fernwood publica un contenedor vacío, quizá estés luchando tanto contra las métricas como contra la legibilidad para rastreadores de IA. Prioriza SSR/SSG para el contenido público (Contenido legible sin JavaScript).
- Teatro de la sobreoptimización. Reducir 20 ms el LCP de laboratorio en una URL con datos de campo ya en verde rara vez es el mejor uso del tiempo de un ingeniero mientras las páginas comparativas siguen sin bloques de evidencia.
Cómo ayuda Silktide
- Pantalla Velocidad: por dónde empezar en el producto
- Web Vitals: puntuación resumen de laboratorio y tiempos de los componentes
- Páginas de carga lenta (LCP) y Cambios de diseño (CLS)
- Comprobaciones de rendimiento complementarias (imágenes, JS, caché, redirecciones) enlazadas desde esos artículos
- Resumen de Experiencia de usuario: Experiencia de usuario
Relacionado
- Contenido legible sin JavaScript: a menudo la misma causa raíz que un LCP deficiente en tecnologías modernas
- / / /
- Web Vitals (web.dev)
- Core Web Vitals y la Búsqueda de Google
- Comprender la experiencia de página en los resultados de la Búsqueda de Google