Velocidad web y SEO: cómo afecta la velocidad de página a su posicionamiento en Google

La conexión entre la velocidad y el posicionamiento en búsquedas

Google confirmó públicamente la velocidad de página como factor de posicionamiento desde 2010, pero la manera de medirla y ponderarla ha evolucionado de forma significativa en los últimos quince años. La introducción de los Core Web Vitals como señales de posicionamiento en 2021 fue el cambio más importante: pasó de una vaga preferencia por la velocidad a umbrales específicos y documentados públicamente que determinan si una página recibe o no un impulso en el posicionamiento.

La lógica de fondo es sencilla. El modelo de negocio de Google depende de que los usuarios confíen en sus resultados de búsqueda. Si Google envía de forma constante a los usuarios a sitios web lentos y frustrantes, esos usuarios quedan menos satisfechos con Google. Por lo tanto, las señales de velocidad son un indicador de la calidad de la experiencia de usuario, y la calidad de la experiencia de usuario es algo que Google tiene un fuerte incentivo comercial para optimizar en su algoritmo de posicionamiento.

Esto significa que la velocidad de página afecta su posicionamiento de dos maneras. Primero, de forma directa: las páginas que cumplen los umbrales de Core Web Vitals reciben una ventaja de señal de posicionamiento frente a páginas similares que no los cumplen. Segundo, de forma indirecta: las páginas lentas tienen mayores tasas de rebote, menor tiempo en el sitio y peores métricas de interacción, y todo ello envía señales de comportamiento negativas que afectan la manera en que Google evalúa la calidad de su contenido con el tiempo.

Los efectos indirectos suelen acumularse más rápido que los directos. Una página que carga en 5 segundos puede técnicamente aprobar los Core Web Vitals (si el contenido que carga primero es rápido) y aun así ahuyentar al 40 % de los visitantes antes de que interactúen con cualquier contenido. Esas señales de comportamiento se acumulan y afectan el peso que Google da a sus páginas en las decisiones competitivas de posicionamiento.

Los Core Web Vitals explicados

Los Core Web Vitals son las tres métricas de rendimiento específicas que Google usa como señales de posicionamiento. Cada una mide una dimensión distinta de la experiencia de página y tiene tres niveles: bueno, necesita mejorar y deficiente. Las páginas deben alcanzar el nivel "bueno" en las tres métricas para recibir el beneficio completo de posicionamiento de los Core Web Vitals: mejorar solo una métrica y dejar las otras en territorio "deficiente" no desbloquea la ventaja.

Largest Contentful Paint (LCP): rendimiento de carga

El LCP mide cuánto tarda el elemento visible más grande en el área de visualización del usuario en cargarse y renderizarse por completo. Normalmente es la imagen principal de una página de inicio, la foto principal del producto en una página de comercio electrónico o el bloque del encabezado principal en una publicación de blog. Los umbrales de Google: menos de 2.5 segundos es "bueno", de 2.5 a 4 segundos "necesita mejorar" y más de 4 segundos es "deficiente".

El LCP es la métrica que la mayoría de los sitios web de negocios incumple de forma más drástica. El LCP promedio en móviles de los sitios web de negocios está muy por encima de los 4 segundos, firmemente en territorio "deficiente". Las causas más comunes son las imágenes principales sin optimizar (subir una imagen de 3 a 5 MB tomada con una cámara cuando una versión WebP de 100 KB se vería idéntica), el JavaScript que bloquea el renderizado e impide que la página se muestre mientras cargan los scripts, los tiempos de respuesta lentos del servidor (TTFB) y la ausencia de indicaciones de precarga que le dirían al navegador que empiece a obtener la imagen del LCP antes.

Mejorar el LCP casi siempre requiere atender varios factores a la vez. Un servidor rápido con una imagen lenta y sin optimizar seguirá fallando. Una imagen optimizada en un servidor lento también fallará. La mejora del LCP suele ser el cambio de mayor impacto tanto para la experiencia de usuario como para el posicionamiento.

Interaction to Next Paint (INP): capacidad de respuesta

El INP reemplazó al First Input Delay (FID) como Core Web Vital en marzo de 2024. Mientras que el FID medía solo el retraso antes de poder procesar una primera interacción, el INP mide la capacidad de respuesta de la página ante todas las interacciones del usuario durante toda la visita. Cuando un usuario hace clic en un botón, toca un enlace o envía un formulario, el INP mide cuánto tarda el navegador en responder visualmente. Los umbrales de Google: menos de 200 milisegundos es "bueno", de 200 a 500 milisegundos "necesita mejorar" y más de 500 milisegundos es "deficiente".

Un INP deficiente se debe casi exclusivamente a problemas de JavaScript. Cuando un navegador ejecuta JavaScript pesado en su hilo principal, no puede responder al mismo tiempo a las interacciones del usuario: esas interacciones se ponen en cola y esperan a que termine el JavaScript. El tiempo que la interacción pasa esperando es lo que mide el INP. Los principales culpables son los paquetes de JavaScript grandes, los controladores de eventos costosos, el exceso de scripts de terceros (píxeles de seguimiento, widgets de chat, herramientas de pruebas A/B) y las tareas largas que acaparan el hilo principal.

El INP es el Core Web Vital más difícil de mejorar porque requiere cambios a nivel de código y no simples ajustes de configuración. Pero en muchos sitios web de negocios que han acumulado años de etiquetas de marketing y scripts de seguimiento, basta con auditar y eliminar los scripts redundantes para lograr mejoras drásticas en el INP sin ningún trabajo de desarrollo.

Cumulative Layout Shift (CLS): estabilidad visual

El CLS mide cuánto se desplaza el diseño de la página mientras carga. Usted ha experimentado el CLS cuando va a tocar un enlace y la página salta justo cuando su toque aterriza, enviándolo a un lugar no deseado. O cuando el texto que está leyendo se desplaza de repente hacia abajo porque se cargó una imagen por encima. Los umbrales de Google: menos de 0.1 es "bueno", de 0.1 a 0.25 "necesita mejorar" y más de 0.25 es "deficiente".

El CLS se calcula midiendo el tamaño y la distancia de los desplazamientos inesperados del diseño durante una visita a la página. Cada vez que el contenido se mueve de forma inesperada, se suma al puntaje de CLS. Las causas más comunes son las imágenes y los videos sin dimensiones de ancho y alto especificadas (el navegador no puede reservar espacio hasta que cargan), las fuentes web que hacen que el texto se reacomode cuando terminan de cargar (el "destello de texto sin estilo"), los anuncios o banners inyectados en la página después de que carga el contenido inicial y el contenido inyectado dinámicamente que empuja otros elementos hacia abajo.

Las mejoras del CLS suelen ser las victorias más rápidas en una auditoría de Core Web Vitals. Agregar dimensiones explícitas a imágenes y videos, implementar font-display: optional o font-display: swap para gestionar el comportamiento de carga de las fuentes y reservar espacio para el contenido dinámico reducen el CLS de forma sustancial con cantidades relativamente pequeñas de trabajo.

La indexación mobile-first y por qué lo cambia todo

Google completó su transición a la indexación mobile-first en 2023, lo que significa que ahora utiliza la versión móvil de su sitio web como versión principal para el rastreo, la indexación y el posicionamiento. Este cambio tiene una implicación directa y significativa para la velocidad de página: su rendimiento en móviles determina cómo Google evalúa su sitio, sin importar qué tan rápido cargue su versión de escritorio.

Esto es importante porque el rendimiento móvil es sistemáticamente peor que el de escritorio en la mayoría de los sitios web de negocios. Los dispositivos móviles tienen menos capacidad de procesamiento que las computadoras de escritorio, las redes móviles son más lentas y menos estables que las conexiones de banda ancha, y los navegadores móviles deben ejecutar el mismo JavaScript que los de escritorio en un hardware que suele ser de 2 a 5 veces más lento en esa tarea. Una página que aprueba Core Web Vitals en escritorio puede reprobar fácilmente las tres métricas en móvil.

La herramienta PageSpeed Insights de Google reporta por separado las puntuaciones móvil y de escritorio, y la puntuación móvil es la que importa para el posicionamiento. Muchos dueños de negocios se sorprenden cuando analizan su sitio por primera vez en PageSpeed Insights y ven un 30 o 40 en móvil junto a un 75 en escritorio, y más aún al enterarse de que la puntuación móvil, la más baja, es la que influye en su posicionamiento.

Optimizar para la indexación mobile-first significa hacer pruebas en hardware móvil y condiciones de red representativos, no solo en un navegador de escritorio rápido con una buena conexión. El Chrome User Experience Report (CrUX) ofrece datos de campo, es decir, mediciones reales de rendimiento de usuarios reales, que Google utiliza realmente en sus evaluaciones de posicionamiento en lugar de las puntuaciones de laboratorio de PageSpeed Insights. Ambos son importantes, pero los datos de campo son los que entran en el algoritmo de posicionamiento.

Señales de experiencia del usuario que multiplican el impacto de la velocidad

Además de la señal directa de posicionamiento de Core Web Vitals, la velocidad de la página afecta a una serie de métricas de comportamiento del usuario que Google monitorea como indicadores implícitos de calidad. Estas señales de comportamiento no aparecen en un único factor de posicionamiento documentado, pero influyen en cómo Google pondera la calidad de sus páginas en los resultados competitivos con el tiempo.

La tasa de rebote desde los resultados de búsqueda (cuando un usuario hace clic en su resultado, pasa unos segundos en la página y regresa de inmediato a los resultados) es una de las señales de comportamiento más directas de las que dispone Google. Aunque Google nunca ha confirmado oficialmente el "pogo-sticking" como factor de posicionamiento, las investigaciones de la industria de búsqueda muestran de manera consistente una correlación entre tasas de rebote altas desde los resultados y posiciones más bajas. Una página lenta aleja a los visitantes antes de que interactúen, lo que produce exactamente este comportamiento a gran escala.

El tiempo de permanencia (cuánto tiempo se queda un usuario en su página antes de regresar a los resultados de búsqueda) se ve afectado de manera similar. Una página que tarda 5 segundos en cargar y luego funciona bien igualmente muestra un período inicial de 5 segundos en el que el usuario no ve nada y quizá ya presionó el botón de retroceso. Esos primeros segundos de la visita son los más importantes para la primera impresión y los más afectados directamente por la velocidad de la página.

La tasa de clics desde los resultados de búsqueda también se ve afectada de forma indirecta por la velocidad. Los datos de Search Console de Google muestran que los sitios con Core Web Vitals deficientes a veces exhiben un indicador de "Página lenta" o similar en los resultados, lo que puede reducir la tasa de clics incluso antes de que el usuario visite la página. Esto convierte la optimización de la velocidad en un factor de posicionamiento integral: afecta no solo su posición, sino también su capacidad de convertir esa posición en tráfico real.

Optimización de imágenes: la corrección de mayor impacto

La optimización de imágenes es la mejora de velocidad de mayor impacto disponible para la mayoría de los sitios web de negocios. Las imágenes suelen ser los archivos más pesados de cualquier página web, la causa más común de puntuaciones LCP deficientes y lo que con más frecuencia descuidan las empresas que no gestionan activamente el rendimiento técnico de su sitio.

El problema suele agravarse a lo largo de años de actualizaciones de contenido. Un sitio que se lanzó con imágenes razonablemente optimizadas va acumulando imágenes sin optimizar a medida que los miembros del equipo suben fotos de productos directamente desde las cámaras de sus teléfonos, imágenes de blog tomadas de bancos de fotos en resolución completa y capturas de pantalla mucho más grandes de lo necesario. Cada incorporación degrada el rendimiento poco a poco hasta que el efecto acumulado se vuelve grave.

Conversión de formato a WebP y AVIF

JPEG y PNG son los formatos en los que se sirven actualmente la mayoría de las imágenes en la web. WebP es un formato de imagen moderno desarrollado por Google que produce imágenes entre un 25 % y un 35 % más pequeñas que JPEG con una calidad visual equivalente, y entre un 25 % y un 70 % más pequeñas que PNG en imágenes con transparencia. AVIF es todavía más nuevo y produce imágenes entre un 30 % y un 50 % más pequeñas que WebP con calidad equivalente, aunque su compatibilidad con navegadores es algo más limitada.

Convertir todas las imágenes a WebP (con alternativas JPEG/PNG para navegadores antiguos) es una de las victorias más rápidas en la optimización de imágenes. Herramientas como Squoosh, Cloudinary o los procesos de conversión en el servidor realizan la conversión de forma automática. En sitios de negocios que sirven cientos de imágenes, automatizar este proceso mediante una CDN con transformación de imágenes sobre la marcha suele ser más práctico que convertir los archivos manualmente.

Carga diferida de imágenes fuera de la vista inicial

De forma predeterminada, los navegadores comienzan a descargar todas las imágenes referenciadas en el HTML apenas empieza a cargar la página, incluidas las que están muy por debajo de la parte visible y que no se verán a menos que el usuario se desplace hacia abajo. La carga diferida (lazy loading) pospone la descarga de las imágenes fuera de la vista inicial hasta que están a punto de entrar en el área visible, lo que reduce de manera sustancial el peso de la carga inicial de la página.

Implementar la carga diferida es sencillo: agregue loading="lazy" a cualquier imagen que no sea visible en la parte superior de la página. La imagen LCP, la imagen principal de la primera pantalla, nunca debe cargarse de forma diferida. Esa imagen debería tener loading="eager" o ningún atributo loading (que por defecto es eager), y debería tener un <link rel="preload"> en el encabezado del documento para comenzar a descargarse antes de que el navegador termine de analizar la página.

Dimensiones explícitas para evitar el desplazamiento de diseño

Las imágenes sin atributos de ancho y alto especificados provocan desplazamientos de diseño (CLS) porque el navegador no sabe cuánto espacio reservarles hasta que terminan de descargarse. Cuando la imagen se descarga y se muestra, empuja hacia abajo el contenido que la rodea, lo que produce el comportamiento característico del CLS: el contenido salta mientras la página carga. Agregar atributos width y height explícitos a cada imagen le indica al navegador cuánto espacio reservar y elimina el desplazamiento de diseño causado por las imágenes.

Recursos que bloquean el renderizado y optimización de la ruta crítica

Los recursos que bloquean el renderizado son archivos CSS y JavaScript que el navegador debe descargar y procesar antes de poder mostrar cualquier contenido de la página. Cada recurso de este tipo en la ruta crítica suma directamente al tiempo de LCP: el navegador literalmente no puede mostrar la página mientras espera esos archivos.

Los recursos que bloquean el renderizado con más frecuencia son las hojas de estilo CSS cargadas en el <head> (todo el CSS bloquea el renderizado por defecto), los archivos JavaScript cargados en el <head> sin los atributos async o defer, y los archivos de fuentes web que deben cargarse antes de que se pueda mostrar el texto. Identificar cuáles recursos bloquean el renderizado y abordar cada uno de manera adecuada es un componente central de la optimización del LCP.

Inserción del CSS crítico

El enfoque más contundente para eliminar el CSS que bloquea el renderizado consiste en identificar el conjunto mínimo de reglas CSS necesarias para mostrar el contenido de la parte superior de la página (llamado "CSS crítico"), insertar esos estilos directamente en el <head> del HTML y diferir la carga del resto de la hoja de estilos. Así, el navegador puede comenzar a renderizar de inmediato sin esperar la descarga de ningún archivo CSS externo. Herramientas como Critical o Penthouse automatizan la extracción del CSS crítico.

Aplazamiento de JavaScript

El JavaScript que no necesita ejecutarse antes de que se muestre la página debe aplazarse. El atributo defer en las etiquetas script le indica al navegador que descargue el script en paralelo con el análisis del HTML, pero que no lo ejecute hasta que el HTML esté completamente analizado. El atributo async descarga y ejecuta el script en cuanto termina la descarga: es útil para scripts independientes, pero menos predecible que defer para scripts que necesitan que el DOM esté listo.

Los scripts de analítica, los píxeles de seguimiento, los widgets de chat y los scripts de automatización de marketing normalmente no necesitan ejecutarse antes de que se muestre el contenido de la página. Cargarlos de forma asíncrona o diferida, o solo después de que se haya renderizado el contenido principal, puede reducir de manera significativa el LCP sin perder ninguna función de seguimiento.

Rendimiento del servidor e implementación de una CDN

El Time to First Byte (TTFB) es el tiempo que transcurre entre que un navegador solicita una página y recibe el primer byte de la respuesta del servidor. Un TTFB alto, normalmente cualquier valor superior a 600 ms, hace casi imposible lograr una buena puntuación de LCP sin importar cuán optimizado esté el contenido de la página, porque el tiempo de LCP se mide desde el momento en que comienza la navegación, no desde que el servidor empieza a responder.

El TTFB depende de tres factores: el tiempo de procesamiento del servidor (cuánto tarda su servidor en generar y enviar la respuesta), la latencia de red (la distancia física entre el usuario y el servidor) y cualquier cola que se forme cuando el servidor recibe más solicitudes de las que puede procesar rápidamente. Cada uno tiene soluciones distintas.

Infraestructura de alojamiento

Muchas pequeñas empresas están en planes de alojamiento compartido que eran adecuados cuando su sitio se lanzó, pero que se han convertido en el principal cuello de botella de rendimiento a medida que el sitio ha crecido. El alojamiento compartido coloca varios sitios web en un solo servidor y, cuando cualquiera de ellos tiene picos de tráfico, todos se ven afectados. El alojamiento VPS (Virtual Private Server, servidor privado virtual) o dedicado ofrece un rendimiento constante sin importar lo que hagan los sitios vecinos.

Para los sitios dinámicos (WordPress, por ejemplo), el almacenamiento en caché de páginas en el servidor es esencial. Sin caché, cada solicitud de página obliga al servidor a consultar la base de datos, ejecutar PHP y armar el HTML desde cero. Con caché, la primera solicitud realiza ese trabajo y las siguientes reciben al instante el HTML ya armado, lo que reduce el tiempo de respuesta del servidor de cientos de milisegundos a menos de 50 ms.

Redes de distribución de contenido (CDN)

Una CDN distribuye los recursos estáticos de su sitio (imágenes, CSS, JavaScript, fuentes) en servidores ubicados en múltiples regiones geográficas. Cuando un usuario solicita su sitio, la CDN sirve esos recursos desde el servidor físicamente más cercano al usuario, lo que reduce la latencia de red. Para un negocio de Florida que atiende principalmente a usuarios de Florida, una CDN quizá no cambie el rendimiento de forma drástica. Para un negocio con tráfico nacional o internacional, implementar una CDN puede reducir entre un 50 % y un 80 % el TTFB de los recursos estáticos.

Las CDN también ofrecen almacenamiento en caché automático para los recursos estáticos con tiempos de vigencia prolongados, de modo que los visitantes recurrentes y los usuarios de la misma zona geográfica reciben los recursos desde la caché y no desde su servidor de origen. Servicios como Cloudflare (que además ofrece protección contra DDoS y funciones de seguridad) hacen que implementar una CDN sea accesible para las pequeñas empresas sin una inversión técnica significativa.

Scripts de terceros: el asesino oculto del rendimiento

Los scripts de terceros (Google Analytics, Facebook Pixel, Google Tag Manager, HotJar, widgets de chat, herramientas de pruebas A/B, seguimiento de CRM, widgets de solicitud de reseñas, sistemas de chat en vivo) se cargan desde servidores externos que su sitio no controla, ejecutan JavaScript que consume tiempo del hilo principal y a menudo cargan recursos adicionales propios. La mayoría de los sitios web de negocios han acumulado entre 10 y 25 scripts de terceros a lo largo de varios años de incorporar herramientas de marketing, y el impacto acumulado en el rendimiento es considerable.

El problema se agrava porque cada script suma de forma independiente al tiempo de ejecución de JavaScript en el hilo principal. Un solo script de marketing puede añadir 20 ms de bloqueo del hilo principal. Cinco scripts añaden 100 ms. Diez añaden 200 ms, punto en el cual las puntuaciones de INP empiezan a mostrar calificaciones de "necesita mejorar" o "deficiente". Y la mayoría de estos scripts además descargan recursos adicionales (imágenes, más scripts, llamadas a API) que suman más carga y latencia.

Gestión de etiquetas y consolidación de scripts

Google Tag Manager es a la vez una fuente de problemas de rendimiento y una solución para ellos. Las configuraciones de Tag Manager mal administradas activan decenas de etiquetas en cada página, entre ellas muchas redundantes (varias configuraciones de analítica que rastrean los mismos eventos), obsoletas (píxeles de seguimiento de plataformas publicitarias que ya no se usan) o innecesarias (scripts de pruebas A/B que terminaron hace meses). Una auditoría de Tag Manager que elimine las etiquetas innecesarias suele ser la mejora de INP más rápida disponible.

Cargar el propio Tag Manager de forma asíncrona (lo cual hace por defecto) no es suficiente. Las etiquetas que se activan a través de Tag Manager igualmente se ejecutan en el hilo principal. La solución es reducir la cantidad de etiquetas que se activan y asegurarse de que las que sí lo hacen sean ligeras y, cuando sea posible, trasladen su trabajo fuera del hilo principal.

Estrategia de caché para visitantes recurrentes

La caché del navegador controla durante cuánto tiempo el navegador almacena los recursos descargados antes de volver a solicitarlos al servidor. Sin los encabezados de caché adecuados, los navegadores vuelven a descargar su CSS, JavaScript, imágenes y fuentes en cada carga de página, incluso para visitantes recurrentes que ya han visitado la misma página varias veces. Con una caché bien configurada, los visitantes recurrentes cargan las páginas casi al instante porque la mayoría de los recursos se sirven desde la caché local del navegador.

La estrategia de caché estándar diferencia los recursos según la frecuencia con la que cambian. Las páginas HTML deben tener tiempos de caché cortos (o ninguno) porque su contenido cambia con frecuencia. Los archivos CSS y JavaScript con versiones (con un hash en el nombre del archivo, como main.a3f7b2c.css) pueden tener tiempos de caché muy largos, de hasta un año, porque cuando el contenido cambia, cambia el nombre del archivo y se fuerza una descarga nueva. Las imágenes y las fuentes rara vez cambian y también pueden almacenarse en caché durante períodos prolongados.

Implementar los encabezados de caché requiere configuración del servidor (ya sea mediante .htaccess en alojamientos basados en Apache, nginx.conf en Nginx o mediante la configuración de la CDN). Muchos plugins de caché para WordPress se encargan de esto automáticamente. En los sitios desarrollados a la medida o generados de forma estática, los encabezados de caché normalmente se configuran en los ajustes de la plataforma de alojamiento.

Herramientas para medir y diagnosticar problemas de velocidad

Tres herramientas ofrecen los datos más útiles para optimizar la velocidad. Entender qué mide cada una y qué significan sus resultados es esencial para diagnosticar problemas específicos en lugar de adivinar las correcciones.

Google PageSpeed Insights

PageSpeed Insights (pagespeed.web.dev) ofrece tanto datos de laboratorio (una prueba controlada ejecutada en los servidores de Google) como datos de campo (mediciones reales de rendimiento de usuarios de Chrome mediante el Chrome User Experience Report). La puntuación de laboratorio sirve para diagnosticar problemas específicos, pero los datos de campo son los que Google utiliza en su algoritmo de posicionamiento. Un sitio puede tener una puntuación de laboratorio de 40 y datos de campo "buenos" en todas las métricas de Core Web Vitals, porque los usuarios reales con conexiones rápidas experimentan el sitio de forma distinta a la conexión móvil lenta emulada en las pruebas de laboratorio.

PageSpeed Insights ofrece "oportunidades" y "diagnósticos" específicos que identifican los problemas exactos que afectan a cada métrica. La sección de oportunidades estima cuánto tiempo se ahorraría al implementar cada corrección, lo que la convierte en una herramienta práctica de priorización. Comience por las oportunidades con mayor ahorro de tiempo para el LCP y luego aborde por separado los problemas de CLS e INP.

Google Lighthouse

Lighthouse está integrado en Chrome DevTools (F12 → pestaña Lighthouse) y puede ejecutarse directamente en su navegador en cualquier página, incluidas las páginas protegidas por autenticación a las que PageSpeed Insights no puede acceder. Lighthouse ofrece las mismas métricas de rendimiento que PageSpeed Insights, además de auditorías de accesibilidad, SEO y mejores prácticas. Ejecutar Lighthouse en modo "móvil" con "limitación simulada" se aproxima a lo que experimentan los usuarios móviles con conexiones 4G.

La vista "Treemap" del informe de Lighthouse muestra un desglose visual de cuáles archivos JavaScript son los más grandes, lo que ayuda a identificar paquetes sobredimensionados y código sin usar. La pestaña "Coverage" de Chrome DevTools funciona junto con Lighthouse para mostrar exactamente qué líneas de CSS y JavaScript se usan realmente en cada página frente a cuánto se carga innecesariamente.

WebPageTest

WebPageTest (webpagetest.org) ofrece las pruebas de rendimiento más detalladas y configurables disponibles de forma gratuita. A diferencia de PageSpeed Insights, WebPageTest permite probar desde ubicaciones geográficas específicas (útil para probar desde Florida si su negocio atiende a una audiencia de Florida), con velocidades de conexión específicas (simulando redes móviles más lentas) y en navegadores específicos. También ofrece un gráfico de cascada que muestra cada recurso que descarga el navegador, en qué orden y cuánto tarda cada uno, lo que lo convierte en la herramienta más potente para diagnosticar qué causa específicamente un LCP lento o un TTFB alto.

La vista "Film Strip" de WebPageTest muestra cuadro por cuadro cómo carga la página, lo que facilita ver exactamente cuándo aparece el contenido por primera vez y si ocurren desplazamientos de diseño. La función "Filmstrip Comparison" permite probar la misma página antes y después de una optimización para confirmar visualmente la mejora.

Correcciones comunes y lo que realmente logran

Las recomendaciones de optimización de velocidad suelen parecer abstractas si no se entiende qué hace específicamente cada corrección y qué métrica mejora. A continuación, un mapa práctico de las correcciones más comunes y su impacto principal en cada métrica.

Convertir imágenes a WebP/AVIF (mejora el LCP)

Los archivos de imagen más pequeños se descargan más rápido, lo que reduce el tiempo antes de que el elemento LCP sea visible. En la mayoría de los sitios web de negocios, convertir a WebP únicamente la imagen principal y las imágenes de la parte superior de la página reduce el LCP entre 0,5 y 1,5 segundos, a menudo la diferencia entre "deficiente" y "bueno".

Agregar preload para la imagen LCP (mejora el LCP)

Una etiqueta <link rel="preload" as="image"> en el encabezado del documento le indica al navegador que empiece a descargar la imagen LCP en cuanto comienza a analizar el HTML, incluso antes de encontrar la etiqueta <img> en el cuerpo. Esto puede reducir el LCP entre 0,3 y 0,8 segundos en las páginas donde la imagen LCP se descubre tarde en el HTML.

Agregar dimensiones a las imágenes (mejora el CLS)

Agregar atributos width y height explícitos a todas las imágenes evita los desplazamientos de diseño causados por imágenes que empujan el contenido al cargar. Este único cambio a menudo lleva el CLS de "deficiente" a "bueno" en sitios con muchas imágenes sin dimensiones.

Eliminar scripts de terceros sin usar (mejora el INP)

Auditar Tag Manager y eliminar las etiquetas de seguimiento de plataformas publicitarias, herramientas o pruebas A/B que ya no están en uso reduce la ejecución de JavaScript en el hilo principal. Cada script eliminado reduce la probabilidad de tareas largas que bloquean la respuesta a la interacción.

Implementar caché en el servidor (mejora el TTFB y el LCP)

En WordPress y otros sitios dinámicos, activar el almacenamiento en caché de páginas en el servidor reduce el TTFB de 200–800 ms a menos de 50 ms. Como el TTFB se mide desde el inicio de la navegación, reducirlo disminuye directamente el tiempo de LCP en la misma cantidad.

Aplazar el JavaScript no crítico (mejora el LCP y el INP)

Agregar defer o async a los scripts que no necesitan ejecutarse antes de que el contenido de la página sea visible los saca de la ruta crítica (lo que mejora el LCP) y reduce la presión sobre el hilo principal durante la visita (lo que mejora el INP).