Hay un consejo de velocidad web que aparece en todas las guías y que, aplicado como se aplica casi siempre, hace tu sitio más lento.
Se llama carga diferida, lazy loading, y consiste en decirle al navegador que no descargue una imagen hasta que el visitante baje hasta ella. Para las veinte fotos del final del artículo es una idea excelente. Para la primera, la grande, la que se ve nada más entrar, es un disparo en el pie.
Una de cada seis páginas de internet se lo está haciendo a esa primera imagen.
El error que comete una de cada seis webs
La imagen grande de arriba suele ser tu LCP: el elemento más grande que aparece en pantalla, y el que Google cronometra para decidir si tu sitio carga rápido. En móvil, el 76% de los elementos LCP son imágenes; en escritorio, el 85.3% (HTTP Archive, Web Almanac 2025).
Ponerle carga diferida a esa imagen es decirle al navegador que espere antes de descargar justo lo que se está midiendo. La documentación de Google no se anda con rodeos: «Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay» (web.dev). Nunca la difieras, porque siempre añadirá retraso innecesario.
Y aun así, el 10.4% de las páginas móviles lo hace con el atributo nativo, y entre el 16% y el 17% si se cuentan también los scripts a medida.
No es porque nadie lo sepa. Es porque el plugin de optimización trae una casilla que dice «activar carga diferida en todas las imágenes», y esa casilla incluye la única que no debía.
Arreglarlo toma dos minutos y está explicado más abajo. Pero antes conviene aclarar dos cosas, porque cambian por completo en qué vale la pena gastar la tarde.
Velocidad y Google: la verdad incómoda
Lo que Google dice exactamente
Casi todo lo que se escribe sobre este tema empieza igual: Google penaliza a los sitios lentos. La documentación de Google es bastante más templada que eso.
Dice tres cosas, y conviene leerlas seguidas. Primera: «There is no single signal», no existe una señal única de experiencia de página. Segunda: «Core Web Vitals are used by our ranking systems», sí se usan. Y tercera, la que nadie cita: «Google Search always seeks to show the most relevant content, even if the page experience is sub-par» (Google Search Central). La Búsqueda siempre intentará mostrar el contenido más relevante, aunque la experiencia de página sea mediocre.
La misma página añade que tener buenos resultados en el informe de Core Web Vitals «doesn’t guarantee that your pages will rank at the top».
Traducido a lo que significa para ti: la velocidad es un desempate entre páginas que ya compiten. No sube un artículo malo a la primera página ni hunde uno bueno a la tercera. Si tu contenido no responde a la búsqueda, ninguna optimización técnica lo va a arreglar.
Lo cual deja una pregunta razonable: entonces, ¿para qué molestarse?
Dónde sí está el dinero
Por esto.
Deloitte y la agencia 55 midieron durante 30 días, por encargo de Google, el comportamiento de más de 30 millones de sesiones en 37 marcas europeas y estadounidenses. Les bajaron el tiempo de carga móvil y observaron qué pasaba con el negocio.
Una mejora de una décima de segundo produjo estos cambios (web.dev, Milliseconds make millions):
- Comercio minorista: +9.1% en conversión de ficha de producto a carrito, y +9.2% en gasto medio por pedido.
- Lujo: +40.1% en el paso de ficha de producto a carrito.
- Viajes: +10% en reservas.
- Generación de contactos: +21.6% en llegadas al formulario.
Una décima de segundo. Menos de lo que tarda un parpadeo.
Dos matices honestos: el estudio es de finales de 2019 y mide una comparación controlada, no una ley de la física. La magnitud varía muchísimo entre sectores, como se ve en el salto entre el retail normal y el de lujo. Pero la dirección se ha repetido en tantas mediciones distintas que ya no está en discusión.
Y en México hay un dato que cierra el argumento desde el otro lado. Entre las razones por las que un comprador abandona una compra online, la tercera más citada es «problemas con la página web y la navegación», con un 57%, detrás de la falta de información (75%) y los problemas con el pago (71%) (AMVO, Estudio de Venta Online 2026). En un mercado que movió 941 mil millones de pesos y creció 19.2% en un año.
Ahí está el dinero. No en el ranking.
Tu puntuación de PageSpeed no es tu velocidad
Laboratorio y campo miden cosas distintas
Cuando pasas tu web por PageSpeed Insights te devuelve un número del 0 al 100 dentro de un círculo de color. Ese número es Lighthouse: una sola carga simulada, en un teléfono de gama media simulado, con una conexión ralentizada a propósito, lanzada desde un centro de datos de Google.
Es un diagnóstico. Es útil. No es lo que Google usa para evaluar tu sitio.
Encima de ese círculo, si tu web tiene tráfico suficiente, hay otro bloque que casi nadie mira: los datos de usuarios reales. Eso es el informe CrUX, y funciona distinto. Recoge visitas reales de Chrome de los últimos 28 días, y el valor que reporta es el percentil 75: aproximadamente, la experiencia del cuarto más lento de tus visitantes (web.dev).
Puedes sacar 95 en el laboratorio y suspender en el campo. Y al revés.
La razón es simple cuando se ve: el laboratorio prueba una carga, sin caché, desde un sitio fijo. El campo incluye a tu visitante con un teléfono de hace cinco años, con cuarenta pestañas abiertas, conectado al wifi del café.
La regla que yo usaría: la puntuación te dice qué arreglar; el dato de campo te dice si lo arreglaste. Y como el campo es una media móvil de 28 días, «lo optimicé ayer y Search Console sigue en rojo» no es un error, es el funcionamiento normal.
Las tres métricas, en español
Son tres, y se evalúan por separado en móvil y en escritorio.
LCP (Largest Contentful Paint): cuánto tarda en aparecer el elemento visible más grande. Bueno, 2.5 segundos o menos. Malo, más de 4.
INP (Interaction to Next Paint): cuánto tarda la pantalla en reaccionar cuando el visitante toca algo. Bueno, 200 milisegundos o menos.
CLS (Cumulative Layout Shift): cuánto se mueven las cosas de sitio mientras la página carga. Bueno, 0.1 o menos. Es la métrica del botón que se desplaza justo cuando ibas a pulsarlo.
Y ahora las cifras que reordenan las prioridades de cualquiera. En 2025, el 48% de los sitios aprobaba los tres Core Web Vitals en móvil y el 56% en escritorio. Desglosado por métrica, en móvil: CLS aprueba el 81%, INP el 77% y LCP solo el 62%.
Es decir: si tu web falla, lo más probable es que falle en LCP. Y si falla en LCP, lo más probable es que el culpable sea una imagen.
Dónde está realmente el peso de tu web
La página mediana pesa hoy 2,559 KB en móvil y 2,862 KB en escritorio, y carga 72 recursos.
Repartido por tipo de recurso, en móvil: las imágenes son 911 KB, el JavaScript 632 KB, las fuentes 122 KB, el CSS 77 KB y el HTML 22 KB.
Dos lecturas de esos números.
La primera es que tu web engorda sola. La mediana móvil creció un 8.4% en un solo año, de 2.4 a 2.6 MB, y un 202.8% desde 2015. Nadie decidió eso: se acumuló, una imagen y un script a la vez. Más del 90% de las páginas carga al menos un recurso de terceros, y las categorías que más aparecen son publicidad, analítica y CDN.
La segunda es más incómoda para el género de artículos al que este pertenece: minificar el CSS, que es el consejo más repetido de todos, apenas hace nada. Estás exprimiendo 77 KB mientras 911 KB de imágenes siguen intactos. Hazlo si quieres, tarda veinte minutos y no molesta. Pero no lo hagas primero, y sobre todo no creas que ya arreglaste algo.
La imagen principal decide tu nota
Para tres de cada cuatro sitios en móvil, «mejorar el LCP» significa literalmente «arreglar una imagen».
Vale la pena ver cómo se reparte ese tiempo. Google divide el LCP en cuatro fases y publica cómo debería verse el reparto ideal: el 40% en el TTFB (lo que tarda tu servidor en mandar el primer byte), menos del 10% en el retraso hasta empezar a descargar el recurso, otro 40% en descargarlo y menos del 10% en pintarlo.
Léelo otra vez: cuatro de cada diez décimas de tu LCP se van antes de que exista un solo píxel, esperando a tu servidor. De eso va la sección del hosting. El otro 40% es la imagen, y de eso va esta.
Los cuatro arreglos, en orden
Uno. Quítale la carga diferida. Busca la imagen grande de arriba y elimina el loading="lazy". Si lo puso un plugin, casi todos tienen un campo para excluir imágenes o para saltarse las primeras. Cinco minutos, y es la mayor ganancia de las cuatro.
Dos. Dile al navegador que tiene prisa. Añade fetchpriority="high" a esa imagen. Un atributo. Google avisa de algo importante: úsalo en una imagen, dos como mucho. Si todo es prioritario, nada lo es.
Tres. Ponle ancho y alto. Los atributos width y height hacen que el navegador reserve el hueco antes de tener la imagen. No cuesta nada y es la cura del CLS.
Cuatro. Súbela del tamaño correcto y en el formato correcto. Esto merece su propio apartado, porque es donde circula el dato equivocado.
Qué formato usar y de qué tamaño
Así están hoy las imágenes LCP reales de internet: 57% en JPG, 26% en PNG y solo el 11% en WebP. Ocho de cada diez sitios sirven su imagen más importante en un formato de los noventa.
Ahora, cuánto ahorra cambiarlo de verdad. La documentación oficial de Google dice que WebP con pérdida es entre un 25% y un 34% más ligero que un JPEG de calidad equivalente, y que WebP sin pérdida es un 26% más ligero que un PNG (Google).
Ese es el número. La cifra del 50 al 80% que circula en muchas guías en español mezcla dos cosas distintas: convertir el formato y, a la vez, redimensionar y recomprimir la imagen. Convertir, por sí solo, te da un tercio. La otra mitad del ahorro viene de dejar de subir una foto de 4000 píxeles de ancho para mostrarla a 800.
De ahí sale la regla que más ahorra de todo el artículo: ninguna imagen debe subirse más ancha que el tamaño máximo al que se va a ver, multiplicado por dos. Si tu columna de contenido mide 800 píxeles, tu techo son 1600. Esa sola costumbre hace más que cualquier plugin.
Sobre AVIF: comprime mejor que WebP, pero tarda más en generarse y todavía da algún problema de compatibilidad con herramientas viejas. En 2026, WebP es la opción segura por defecto; AVIF, si tu flujo de trabajo ya lo maneja sin fricción.
El hosting es la palanca más grande y la menos tocada
Si el 40% de tu LCP es el tiempo que tarda tu servidor en contestar, hay un límite que ninguna optimización dentro del navegador puede cruzar.
Los números son brutales. Porcentaje de sitios con buen TTFB en móvil, por tipo de alojamiento: Cloudflare Pages 88%, Vercel 85%, Netlify 83%, Fastly 78%, AWS Amplify 67%, DigitalOcean 54% y hosting compartido, 29% (WebVitals.tools, benchmark de abril de 2026).
Veintinueve contra ochenta y ocho. Cincuenta y nueve puntos entre el plan de 40 pesos al mes y las plataformas construidas para esto.
El matiz honesto: esas plataformas de borde no son un reemplazo directo de un WordPress con WooCommerce; están pensadas para otra arquitectura. Pero la brecha dice algo que conviene oír si estás en el plan más barato de un hosting genérico: ese es tu techo, y no hay plugin que lo levante.
Lo que sí puedes hacer sin mudarte: comprobar que tu hosting ofrezca caché a nivel de servidor (LiteSpeed o Nginx FastCGI), que corra una versión reciente de PHP, y poner un CDN delante. El plan gratuito de Cloudflare cubre buena parte de eso en una tarde.
Y ya que hablamos de plataformas, las tasas de aprobación por gestor de contenidos en escritorio: Wix 82%, Webflow 79%, Shopify 78%, Squarespace 70%, Drupal 64%, WordPress 50% y Magento 40%.
WordPress al 50% no es un defecto de WordPress. Es lo que le pasa a una plataforma que cualquiera puede instalar en el hosting más barato con quince plugins encima, mientras Wix y Shopify controlan el servidor, el tema y lo que se puede instalar. Pero significa algo práctico: en WordPress el rendimiento por defecto es cara o cruz, y el trabajo es tuyo.
WordPress: qué sí y qué no
Un plugin de caché, no tres
El error más común que se ve en sitios pequeños: tres plugins de optimización instalados a la vez, cada uno minificando el mismo CSS, cada uno con su propia carga diferida, estorbándose entre ellos. El resultado habitual es un sitio más lento que sin ninguno, y un problema imposible de diagnosticar.
Uno de caché. Uno de imágenes, o ninguno si redimensionas antes de subir. Se acabó.
Con nombres, ya que la versión publicada no da ninguno: WP Rocket es de pago y el que menos hay que tocar. LiteSpeed Cache es gratuito y excelente, pero solo si tu hosting corre LiteSpeed, así que compruébalo antes. W3 Total Cache y WP Super Cache son gratuitos y piden más configuración.
El orden para activarlos: primero caché de página, y mides. Después minificación, y mides. Al final carga diferida, y compruebas que tu imagen principal siga fuera. Ese último paso es de lo que iba el principio de este artículo.
La función que ya tienes activada y no sabías
Desde la versión 6.8, WordPress incorpora carga especulativa en el núcleo, activada por defecto en la parte pública del sitio.
Lo que hace: cuando el visitante empieza a pulsar un enlace, el navegador ya va adelantando la carga de esa página. Viene en modo prefetch y nivel conservador, así que no se dispara por pasar el ratón por encima. Excluye automáticamente las URLs con parámetros, que son las que suelen hacer cosas, y se desactiva para usuarios con sesión iniciada (Make WordPress Core).
Lo que gana, medido por el propio equipo de WordPress sobre los sitios que usaban el plugin: una mejora de alrededor de 1.9 puntos en la mediana de aprobación de LCP.
Dos puntos no son una revolución, y ese es justo el motivo de mencionarlo. Es lo que da un ajuste bien hecho a nivel de plataforma. La imagen te da más, y te la puedes arreglar tú esta tarde.
Tu página de inicio es la más lenta del sitio
Este dato es contraintuitivo y está medido: en móvil, el 45% de las páginas de inicio aprueba Core Web Vitals frente al 56% de las páginas interiores. En escritorio, 47% contra 61%.
La razón se entiende sola en cuanto se ve. La página de inicio es donde va el carrusel. Y el vídeo de fondo. Y la tira de logotipos de clientes. Y la ventana del boletín. Y los tres testimonios con foto.
Todo lo que alguien pidió alguna vez que estuviera «arriba del todo» vive ahí.
Y es la página a la que mandas la publicidad.
Si vas a optimizar una sola página primero, es esa. Y la mejora con más retorno casi nunca es comprimir algo: es borrarlo.
El orden de trabajo, de más a menos rentable
Todo lo anterior, puesto en el orden en que conviene hacerlo:
- Quitar la carga diferida de la imagen principal. 5 minutos. Ganancia grande en LCP.
- Redimensionar y convertir esa imagen. 15 minutos. Ganancia grande en LCP.
- Añadir
fetchpriority="high",widthyheight. 10 minutos. Ganancia en LCP y CLS. - Activar caché de página. 30 minutos. Ganancia en TTFB y en LCP.
- Poner un CDN delante. 1 hora. Depende de dónde estén tus visitantes.
- Quitar scripts de terceros que nadie mira. 1 hora. Ganancia en INP y en peso.
- Borrar elementos de la página de inicio. 1 hora. Ganancia en todo.
- Minificar CSS y JavaScript. 20 minutos. Ganancia pequeña.
- Cambiar de hosting. Un día. Ganancia grande, si venías de compartido.
Los tres primeros suman media hora y cubren la mayor parte de lo que una web pequeña puede ganar. El octavo está en la lista sobre todo para que puedas tacharlo y dejar de pensar en él.
Cómo mantenerla rápida sin obsesionarse
Una vez al mes, diez minutos: pasa por PageSpeed Insights tu página de inicio y tu artículo más visitado, y mira el bloque de usuarios reales, no el círculo de colores.
Antes de subir cualquier imagen, redimensiónala. Esa costumbre sola evita casi todas las recaídas.
Cada vez que instales un plugin, mide antes y después. La mayoría de los sitios que se ponen lentos no se rompieron: alguien instaló algo un martes.
Y revisa la imagen principal después de cada actualización del tema o del plugin de optimización, porque es cuando la carga diferida vuelve sola.
Por último, y va en serio: no persigas el 100. Un sitio que aprueba las tres métricas de campo con un 78 de laboratorio es más rápido, para personas de verdad, que uno con 100 y datos de campo en rojo.
Preguntas frecuentes
¿Cuánto debería tardar mi web en cargar? La cifra que importa no es el tiempo total sino el LCP, y el umbral es 2.5 segundos o menos en el percentil 75 de tus visitantes reales. Es decir: al menos tres de cada cuatro visitas deben ver el contenido principal antes de esos 2.5 segundos.
¿De verdad Google me penaliza por ser lento? No en el sentido en que suele contarse. Google confirma que los Core Web Vitals los usan sus sistemas de posicionamiento, pero también que no hay una señal única y que la Búsqueda mostrará el contenido más relevante aunque la experiencia de página sea mediocre. Funciona como desempate entre páginas que ya compiten, no como castigo.
¿Qué puntuación de PageSpeed debería tener? Ninguna en concreto. Esa puntuación es una simulación de laboratorio y sirve para saber qué arreglar. Lo que conviene mirar es el bloque de datos de usuarios reales, que es lo que Google usa y lo que refleja lo que vive tu visitante.
¿WebP o AVIF? WebP para casi todo el mundo en 2026: está soportado en todas partes, y según Google ahorra entre un 25% y un 34% frente a JPEG con la misma calidad. AVIF comprime más, pero tarda más en generarse y da algún problema con herramientas antiguas. Si tu plugin o tu CDN lo genera solo y sin fricción, úsalo.
¿Cuántos plugins de optimización necesito? Uno de caché. Y uno de imágenes si no piensas redimensionarlas a mano. Tres plugins haciendo lo mismo es la causa más frecuente de sitios lentos e imposibles de diagnosticar.
¿Merece la pena pagar un hosting más caro? Si estás en compartido, probablemente sea el cambio con más retorno de toda la lista: solo el 29% de los sitios en hosting compartido tiene un buen TTFB, y el TTFB es alrededor del 40% de tu LCP. Antes de mudarte, prueba lo barato: caché de página, un CDN gratuito y una versión reciente de PHP.
Optimicé ayer y Search Console sigue igual, ¿qué pasa? Nada. Los datos de campo son una media móvil de 28 días, así que una mejora de hoy tarda semanas en verse completa. Para comprobar de inmediato si el cambio funcionó, usa la pestaña de laboratorio o mide con la extensión Web Vitals en tu propio navegador.
Fuentes y metodología
Los datos de este artículo se consultaron en septiembre de 2026.
HTTP Archive — Web Almanac 2025, capítulos de Rendimiento y Peso de página. Tasas de aprobación de Core Web Vitals globales y por métrica, tipo y formato del elemento LCP, porcentaje de páginas que difieren su imagen LCP, peso mediano por tipo de recurso, número de peticiones y crecimiento interanual. Los pesos por tipo de recurso son medianas independientes, así que no suman el peso mediano de la página.
Google Search Central — Page experience. Postura oficial de Google sobre los Core Web Vitals como señal de posicionamiento.
web.dev — Optimize LCP y Web Vitals. Umbrales de las tres métricas, percentil de evaluación, reparto por fases del LCP y recomendaciones sobre carga diferida y fetchpriority.
web.dev — Milliseconds make millions. Estudio de Deloitte y la agencia 55 por encargo de Google sobre 37 marcas y más de 30 millones de sesiones, 30 días a finales de 2019.
Google — WebP. Ahorro medido de WebP frente a JPEG y PNG con índice de calidad SSIM equivalente.
WebVitals.tools. Tasas de buen TTFB por tipo de alojamiento (benchmark de abril de 2026) y de aprobación de Core Web Vitals por gestor de contenidos, sobre datos del informe CrUX de HTTP Archive de noviembre de 2025.
Make WordPress Core. Funcionamiento y configuración por defecto de la carga especulativa incorporada en WordPress 6.8, y mejora medida en la aprobación de LCP.
AMVO — Estudio de Venta Online 2026. Tamaño del comercio electrónico en México y motivos declarados de abandono de compra.
Sobre los tiempos del orden de trabajo: son estimaciones para alguien que no ha hecho antes cada tarea y trabaja sobre un WordPress corriente. Sirven para ordenar la lista, no como presupuesto.
¿Cuál es tu LCP ahora mismo? Pasa tu página de inicio por PageSpeed Insights, mira el bloque de usuarios reales y déjanos el número en los comentarios. Si pasa de 2.5 segundos, decimos por dónde empezarías.