Diga adiós a la lentitud. Descubra cómo mejorar la velocidad de su sitio web con las Core Web Vitals (INP, LCP, CLS) en plataformas como WordPress, Shopify y React/Next.js.
Conclusiones clave:
1. ¿Cómo puedo aumentar la velocidad de mi sitio web?
Mejorar la velocidad de su sitio web es fundamental para su rendimiento. Antes de desarrollar cualquier estrategia, es importante empezar con un diagnóstico adecuado mediante herramientas como Google PageSpeed Insights o GTmetrix. Estas herramientas le ayudan a identificar los problemas exactos que ralentizan su sitio. La mayoría son habituales: imágenes demasiado pesadas, problemas de caché del navegador, archivos CSS grandes, plugins sin usar y herramientas de terceros. Puede abordar los problemas de mayor impacto comprimiendo las imágenes a WebP o AVIF, usando una CDN y minificando archivos como CSS, JavaScript y HTML. Elimine los plugins y herramientas que ya no utilice. Y, sobre todo, corrija los problemas de Core Web Vitals, como los elementos que cargan lentamente y los cambios de diseño. Tras corregirlos, la velocidad de su sitio puede mejorar entre un 70 y un 90 %. Si su sitio sigue siendo lento, una agencia profesional o unos consultores SEO pueden ayudarle a ir más allá.
2. ¿Qué velocidad debería tener realmente mi sitio web?
Lo ideal es que su sitio web cargue en 2 o 3 segundos. Esto ofrece una mejor experiencia de usuario y reduce la tasa de rebote. Pero más importantes que el tiempo total de carga son las métricas definidas en las Core Web Vitals de Google. Debe centrarse en un Largest Contentful Paint (LCP) inferior a 2,5 segundos, un First Input Delay (FID) inferior a 100 ms y un Cumulative Layout Shift (CLS) cercano a 0. Estas métricas influyen directamente en la experiencia de usuario y en el posicionamiento en buscadores.
3. ¿Mejorar la velocidad del sitio web puede aumentar realmente los clientes potenciales o las ventas?
Sí. La velocidad influye directamente en el comportamiento de los usuarios. Un sitio web más rápido mantiene a los usuarios interesados, genera confianza y mejora las conversiones.
Céntrese en áreas clave como una carga más rápida de las landing pages, un mejor rendimiento en móviles y la reducción de los retrasos en formularios y procesos de pago. Incluso pequeñas mejoras pueden generar un crecimiento notable de las conversiones.
La velocidad de un sitio web no es solo una característica más. Influye directamente en sus ventas y sus ingresos.
Según Akamai Technologies, las conversiones caen un 7 % por cada segundo de retraso. Por otro lado, reducir el tiempo de carga de 5 a 2 segundos puede aumentar las conversiones hasta un 74 %.
Los datos de Google muestran que el 53 % de los usuarios móviles abandona una página si tarda más de 3 segundos en cargar.
Un sitio web lento no solo frustra a los visitantes. Le hace perder activamente posiciones, ingresos y clientes potenciales.
En esta guía, explicamos técnicas, herramientas y soluciones prácticas para mejorar la velocidad de su sitio. Y, lo que es más importante, también encontrará tácticas avanzadas de las que la mayoría de las guías no hablan.
El resultado es una mejor experiencia de usuario, un mejor posicionamiento SEO, más conversiones y menores tasas de rebote.
Por qué la velocidad web importa más que nunca en 2026
La mayoría de los artículos esconden el verdadero impacto en el negocio en una nota al pie. Empecemos por ahí, porque si no siente la urgencia, no se lo tomará en serio.
Puede cambiar de estrategia. Puede posicionarse en la primera página. Pero si su sitio web es lento, los visitantes se irán antes incluso de ver lo que ofrece.
Amazon descubrió que cada 100 milisegundos de retraso le costaban un 1 % de sus ventas. Para un negocio de comercio electrónico que factura $10M al año, eso supone $100,000 perdidos por cada 100 ms. No es una pequeña fuga; es una sangría silenciosa de ingresos.
Si quiere entender sus propias cifras:
Tome su número de visitantes mensuales. Multiplíquelo por su tasa de conversión y su valor medio de pedido. Después, aplique una caída del 7 % por cada segundo adicional que tarde su sitio en cargar.
¿Esa cifra final? Son los ingresos que está dejando escapar ahora mismo.
¿Qué significa realmente «rápido» en 2026?
Casi siempre se oye que su sitio web debe ser rápido, pero ¿cuánto? Nadie lo explica con claridad. Aquí lo desglosamos con las Core Web Vitals, que definen referencias de rendimiento medibles. Estas métricas influyen directamente en sus señales de posicionamiento. En marzo de 2024, Google sustituyó el antiguo First Input Delay (FID) por Interaction to Next Paint (INP). Esta nueva métrica mide la interactividad de forma mucho más estricta, y muchas guías todavía no se han puesto al día.
LCP. Carga
< 2.5s
Largest Contentful Paint. ¿Cuánto tarda en aparecer el contenido principal?
Bueno: <2,5 s. Mejorable: 2,5-4 s. Deficiente: >4 s
INP. Interactividad
<200 ms
Interaction to Next Paint. Mide todas las interacciones del usuario, no solo la primera.
Sustituyó a FID en 2024. Bueno: < 200 ms. Deficiente: >500 ms
CLS. Estabilidad
<0.1
Cumulative Layout Shift. Mide la estabilidad visual, es decir, cuánto se mueve la página mientras carga. Bueno: <0,1. Deficiente: >0,25
Por qué INP importa más de lo que se cree
FID solo medía el retraso antes de que el navegador empezara a procesar la primera interacción. INP mide la duración completa de cada interacción a lo largo de toda la sesión, incluidos clics, toques y entradas de teclado. Una página cuyos botones respondan con lentitud suspenderá INP aunque su FID fuera perfecto. Esto afecta de forma desproporcionada a las aplicaciones de una sola página, los paneles de control y cualquier sitio con JavaScript complejo en el lado del cliente.
TTFB. Respuesta del servidor
< 0.8s
Time to First Byte. La rapidez con la que responde su servidor cuando un usuario solicita la página.
Bueno: <0,8 s. Mejorable: 0,8–1,8 s. Deficiente: >1,8 s
FCP. Primer renderizado
< 1.8s
First Contentful Paint. El momento en que aparece en pantalla el primer contenido visible (texto o imagen).
Bueno: <1,8 s. Mejorable: 1,8–3 s. Deficiente: >3 s
TBT. Tiempo de bloqueo
< 200ms
Total Blocking Time. Mide cuánto tiempo está bloqueado el navegador sin poder responder a las acciones del usuario.
Bueno: <200 ms. Mejorable: 200–600 ms. Deficiente: >600 ms
Speed Index. Carga visual
< 3.4s
Muestra con qué rapidez se muestra visualmente el contenido de la página durante la carga.
Bueno: <3,4 s. Mejorable: 3,4–5,8 s. Deficiente: >5,8 s
Diagnostique antes de corregir: realice estas 5 pruebas
Cuando busca cómo mejorar la velocidad web, siempre obtiene la misma respuesta: simplemente optimice las imágenes y use una CDN. Sin duda, son consejos inútiles, porque no indican dónde está el cuello de botella. Antes de tocar un solo archivo, realice estos pasos de diagnóstico y anote sus puntuaciones de referencia. Son los puntos de partida que demostrarán su mejora.
| Herramienta | Tipo de datos | Lo que solo esta herramienta le muestra |
|---|---|---|
| Google PageSpeed Insights | Campo + laboratorio | Datos de usuarios reales del conjunto de datos CrUX: rendimiento real en dispositivos reales, no solo simulaciones de laboratorio. También muestra el estado de las Core Web Vitals. |
| GTmetrix | Laboratorio (sintético) | Gráficos de cascada, tiempos detallados de las solicitudes y puntuaciones de Lighthouse. Ideal para depurar recursos concretos. |
| WebPageTest | Laboratorio (varias ubicaciones) | Prueba el rendimiento desde distintas ubicaciones geográficas y velocidades de conexión. Útil para analizar la experiencia de una audiencia global. |
| Chrome DevTools – Red | Laboratorio | El análisis de cascada más detallado disponible. Muestra cada recurso, el tamaño de los archivos, el orden de carga y las solicitudes bloqueantes. |
| Google Search Console – CWV | Campo (media de 28 días) | Muestra qué páginas no superan las Core Web Vitals según datos de usuarios reales. Refleja directamente el posible impacto en el posicionamiento en Google. |
La diferencia que nadie explica
PageSpeed Insights es una herramienta gratuita de Google que analiza el rendimiento, la velocidad y la experiencia de usuario de su sitio web.
Ofrece dos tipos de datos:
Datos de campo (de usuarios reales de Chrome a través del conjunto de datos CrUX)
Datos de laboratorio (de una prueba simulada de Lighthouse)
Si no coinciden, fíese de los datos de campo, porque reflejan la experiencia real de los usuarios y lo que Google tiene realmente en cuenta para el posicionamiento.
Los datos de laboratorio sirven principalmente para depurar e identificar problemas.
Si su puntuación es baja, empiece por revisar sus Core Web Vitals en los datos de campo y luego utilice los datos de laboratorio para corregir los problemas.
Su tabla de referencia
Antes de hacer cualquier cambio, registre estas siete cifras. Anótelas. Las usará para medir cada mejora:
- Puntuación LCP (en segundos) de PageSpeed Insights
- Puntuación INP (en milisegundos) de PageSpeed Insights
- Puntuación CLS de PageSpeed Insights
- TTFB (Time to First Byte) de WebPageTest
- Peso total de la página en KB/MB de GTmetrix
- Número total de solicitudes HTTP de GTmetrix
- Estado de las Core Web Vitals en Google Search Console (aprobado / no aprobado)
Descubra cómo se puede optimizar la velocidad de un sitio web
Antes de corregir nada, necesita entender qué está ralentizando realmente su sitio. La mayoría de las empresas pasan directamente a la «optimización» sin diagnosticar el verdadero problema, y ahí es donde las cosas se tuercen.
Veamos los problemas más comunes y lo que puede hacer, de forma realista, para solucionarlos:
1. Capa base: alojamiento, servidor e infraestructura
El alojamiento es la base de la velocidad de su sitio web. Su rendimiento depende en gran medida de él. Incluso un sitio bien optimizado parecerá lento si el servidor es débil.
Esta suele ser la mayor oportunidad desaprovechada, porque cambiar de alojamiento parece difícil. Pero, en realidad, puede mejorar su velocidad al instante sin necesidad de programar.
Elegir el alojamiento adecuado
- Alojamiento compartido: solo para sitios pequeños con poco tráfico (< 1000 visitantes/mes). No es adecuado si su sitio genera clientes potenciales o ventas.
- VPS (servidor privado virtual): una buena opción intermedia. Más velocidad y más control que el alojamiento compartido.
- Alojamiento en la nube gestionado: proveedores como Kinsta, WP Engine y Cloudways se encargan del rendimiento por usted. Ideal para sitios web de empresa.
- Alojamiento edge: plataformas como Vercel, Netlify y Cloudflare Pages cargan su sitio desde servidores cercanos a los usuarios. Así su sitio es extremadamente rápido en todo el mundo.
Métrica de velocidad clave: TTFB (Time to First Byte)
Bueno: menos de 800 ms
Excelente: menos de 200 ms
Si su sitio web parece lento, este suele ser el motivo
3 causas habituales de lentitud
Sin caché: su sitio vuelve a cargarlo todo cada vez. El almacenamiento en caché puede hacerlo mucho más rápido.
Ubicación del servidor lenta: si su servidor está lejos de sus usuarios, su sitio carga más despacio.
Base de datos o backend pesados: demasiado procesamiento en el servidor lo ralentiza todo.
Una solución sencilla que la mayoría pasa por alto
Active HTTP/3 y QUIC
En 2026, HTTP/3 ya cuenta con amplio soporte en todos los principales navegadores y CDN. HTTP/3 utiliza el protocolo de transporte QUIC en lugar de TCP. Mejora la velocidad, sobre todo en redes móviles. Muchos proveedores de alojamiento y Cloudflare ya lo admiten.
Lo que obtiene tras corregir esta capa
Menor tiempo de carga del sitio
Mejor experiencia de usuario
Más conversiones
Menor tasa de rebote
2. Optimización de imágenes: la mayor mejora de velocidad
La mayor parte del peso de sus páginas proviene de las imágenes. En muchos casos, suponen entre el 50 y el 80 % del tamaño total de la página. Por eso, si su sitio es lento, es lo primero que debe corregir. Lo bueno es que no necesita conocimientos profundos de SEO técnico para mejorarlo.
Use formatos de imagen modernos
Los formatos antiguos como JPEG y PNG son pesados. Cámbiese a:
WebP: menor tamaño con la misma calidad. Funciona en casi todos los navegadores.
AVIF: aún más pequeño que WebP. Lo mejor para la máxima compresión.
SVG: úselo para logotipos e iconos. Muy ligero y escalable.
La implementación HTML correcta utiliza el elemento <picture> para servir el mejor formato que admita el navegador:
Sirva el tamaño de imagen adecuado (srcset y sizes)
No cargue una única imagen grande para todos los dispositivos. Use srcset y sizes para que el navegador elija el tamaño de imagen correcto. Esta es la implementación correcta:
Si falta el atributo sizes, el navegador puede cargar una imagen más grande de lo necesario. Esto ralentiza su sitio.
Use la carga diferida con cuidado
La carga diferida permite cargar las imágenes solo cuando se necesitan. Use loading=”lazy” para las imágenes situadas por debajo de la parte visible de la pantalla.
Pero evite un error común:
Nunca aplique carga diferida a su imagen LCP
La imagen LCP (normalmente su imagen principal, la foto de producto en la parte visible o la imagen destacada del artículo) es lo que Google mide. Si le aplica carga diferida, el navegador retrasa deliberadamente su carga, lo que empeora directamente su puntuación LCP y su posicionamiento por Core Web Vitals. Aplique loading=”lazy” solo a las imágenes situadas por debajo de la parte visible. Para su imagen LCP, use en su lugar fetchpriority=”high” para indicar al navegador que la cargue con máxima prioridad.
Herramientas recomendadas según el caso de uso
- Squoosh (squoosh.app): gratuito y basado en el navegador. Ideal para convertir y comprimir imágenes individuales. Admite AVIF, WebP y todos los formatos modernos con vista previa visual de la calidad.
- ImageOptim: aplicación para Mac de compresión sin pérdida por lotes. Adecuada para una optimización puntual por lotes.
- Cloudinary / Imgix: transformación de imágenes basada en CDN. Sirve automáticamente el formato, el tamaño y la calidad adecuados según el dispositivo y el navegador que realizan la solicitud. Ideal para sitios con grandes bibliotecas de imágenes o contenido generado por usuarios.
- ShortPixel / Imagify: plugins de WordPress que comprimen y convierten automáticamente las imágenes al subirlas. Una solución de «configurar y olvidar» para sitios WordPress.
Lo que esto soluciona:
Carga más rápida, mejores Core Web Vitals, mejor SEO y menor tasa de rebote.
3. JavaScript y CSS que bloquean el renderizado
Cuando su página carga, el navegador lee el HTML de arriba abajo. Si encuentra archivos <Script> o <link rel=” stylesheet”>, lo detiene todo para descargarlos y procesarlos. Este retraso se denomina bloqueo del renderizado y es una de las principales causas de tiempos de carga lentos y malas puntuaciones LCP.
Por qué es importante
Antes de mostrar nada en pantalla, el navegador necesita:
- Convertir el HTML en DOM
- Convertir el CSS en CSSOM
- Combinar ambos en un árbol de renderizado
JavaScript puede modificar ambos, por lo que el navegador detiene el renderizado hasta que se procesan los scripts. Cuanto más bloqueo, más tarda en aparecer el primer contenido visible.
Una solución sencilla que cualquiera puede aplicar
Defer vs. async vs. module: la guía definitiva
<script src=”…”>— Por defecto. Bloquea por completo el análisis del HTML. La descarga y la ejecución se producen de forma síncrona. No lo use nunca para scripts no críticos.
<script defer src=”…”>— Se descarga en paralelo al análisis del HTML, pero solo se ejecuta cuando este termina, en el orden del documento. Úselo para scripts que dependen del DOM o entre sí (analítica, la mayoría de los plugins).
<script async src=”…”>— Se descarga en paralelo y se ejecuta en cuanto está listo, interrumpiendo el análisis del HTML. El orden de ejecución no está garantizado. Úselo para scripts totalmente independientes (anuncios, widgets sociales) en los que el orden no importe.
<script type=”module”>— Diferido por defecto, admite importaciones de módulos ES y siempre se ejecuta en modo estricto. Úselo para JavaScript moderno que utilice la sintaxis import/export
Regla práctica
Mueva todas las etiquetas <script> justo antes de </body>, o añada defer a los scripts del <head>. Nunca coloque scripts bloqueantes en el <head> sin defer o async: es la corrección del bloqueo del renderizado con mayor impacto que existe.
Reduzca el tamaño de los archivos
Minifique su CSS y JavaScript. Así se eliminan los espacios sobrantes y se reduce el tamaño de los archivos hasta en un 40 % sin cambiar su funcionalidad.
Carga inteligente en 2026
En lugar de un único archivo grande, divida su código por páginas o funcionalidades. Los navegadores modernos pueden cargar más rápido varios archivos pequeños.
Elimine el CSS no utilizado
La mayoría de los sitios web cargan más CSS del necesario. Elimine los estilos no utilizados para reducir el tamaño de los archivos y acelerar el renderizado.
El truco de la cobertura de Chrome DevTools
Abra Chrome DevTools, vaya a More tools – Coverage (o pulse Ctrl+Shift+P) y busque «coverage». Después, haga clic en el botón de grabar y cargue su página. La pestaña Coverage muestra exactamente qué porcentaje de cada archivo CSS y JS se utiliza realmente. Cualquier archivo CSS con más de un 70 % sin usar es un objetivo prioritario para depurarlo. Utilice PurgeCSS, UnCSS o la purga integrada de Tailwind para eliminar automáticamente los estilos no utilizados.
4. Estrategia de caché: navegador, servidor y CDN
La caché no es un único ajuste. Tiene tres capas, y cada una resuelve un problema distinto. Si las trata igual, su sitio puede mostrar contenido desactualizado o seguir siendo lento.
- 1. Caché del navegador: almacena archivos en el dispositivo del usuario mediante Cache-Control y Expires. Ideal para visitantes recurrentes. No influye en los usuarios que llegan por primera vez.
- 2. Caché del servidor: almacena datos procesados con herramientas como Redis o Memcached. Reduce el TTFB y acelera sitios dinámicos como WordPress.
- 3. Caché de CDN: almacena su sitio en servidores de todo el mundo. Entrega el contenido desde la ubicación más cercana y mejora el tiempo de carga a nivel global.
Conceptos básicos de Cache-Control
Estos encabezados controlan qué se almacena en caché y durante cuánto tiempo:
Invalidación de caché mediante hash del contenido
Los archivos como main.js se renombran como main.a3f9c2d.js. Cuando cambia el contenido, cambia el nombre del archivo. Esto permite un almacenamiento en caché prolongado sin mostrar contenido desactualizado.
Opciones de CDN
- Cloudflare: un buen punto de partida. El plan gratuito cubre la mayoría de las necesidades.
- BunnyCDN: rentable para sitios con mucho tráfico y mucho contenido multimedia.
- Fastly / Akamai Technologies: configuración avanzada para sitios web a gran escala.
Por qué es importante
Una caché bien configurada mejora la velocidad, reduce la carga del servidor y aumenta las conversiones.
Si su caché está mal configurada, incluso un servidor rápido parecerá lento.
5. El impuesto oculto: los scripts de terceros
En un sitio web, los scripts de terceros como la analítica, el chat en vivo, los widgets sociales, las redes publicitarias y las herramientas de pruebas A/B añaden carga adicional a su tienda online. Y usted no controla ni su código, ni su servidor, ni sus tiempos.
Cada script de terceros añade al menos una búsqueda DNS y una conexión, lo que significa que, cuantas más solicitudes de conexión, más retrasos se producen. Esto afecta directamente a la velocidad y a la experiencia de usuario.
Cómo comprobarlo
Abra Chrome DevTools y vaya a la pestaña Network.
Ordene por dominios y busque las solicitudes de terceros
O ejecute Lighthouse y revise
«Reduce el impacto del código de terceros».
Céntrese en:
Tiempo del hilo principal
Tamaño de transferencia
Número de solicitudes
¿Por qué es importante?
Siempre que vaya a añadir un script, hágase esta pregunta: ¿cuánto cuesta? Aquí mostramos lo que ocurre tras integrar la herramienta.
Un solo widget de chat puede bloquear el hilo principal entre 300 y 800 ms.
Las herramientas de analítica pueden añadir entre 200 y 400 KB de JavaScript
Una herramienta de pruebas puede retrasar su LCP entre 300 y 600 ms
En definitiva, compare el coste: si el valor para el negocio no lo justifica, simplemente elimínelo.
Corrija los elementos de carga lenta con una técnica inteligente: use fachadas para los elementos incrustados pesados
Es una optimización inteligente que a menudo se pasa por alto, incluso en 2026. Una fachada es un marcador de posición ligero que retrasa la carga de los elementos incrustados pesados hasta que el usuario interactúa con ellos.
En lugar de cargar de inmediato elementos como YouTube, mapas o widgets de chat, muestra una vista previa sencilla (como una imagen o miniatura). El contenido real solo se carga cuando el usuario hace clic.
Esto reduce el tiempo de carga inicial de la página y mejora el rendimiento sin eliminar funcionalidades.
Resultado: ninguna carga adicional hasta que sea necesaria.
Mejoras técnicas rápidas
Aloje las fuentes en su propio servidor para eliminar retrasos adicionales de DNS y conexión
Use font-display: swap para mantener el texto visible
Precargue las fuentes importantes con <link rel=”preload”>
Para los scripts de terceros importantes, use:
<link rel=”preconnect”>
Para los menos importantes, use:
<link rel=”dns-prefetch”>
6. Optimización de INP: que su sitio se perciba rápido al usarlo
INP (Interaction to Next Paint) es ahora una de las métricas de velocidad más importantes, desde que esta importante señal de posicionamiento de Google sustituyó a FID en marzo de 2024.
Mide la rapidez con la que su página responde visualmente después de que el usuario interactúa con ella, ya sea al hacer clic, escribir o interactuar con algún elemento.
Un sitio puede cargar rápido y, aun así, parecer lento si las interacciones se retrasan. Por eso INP importa más que la simple velocidad de carga.
Las principales causas de un INP deficiente
Tareas largas que bloquean el hilo principal: cualquier tarea de JavaScript que dure más de 50 ms es una «tarea larga». Impide que el navegador procese las acciones del usuario hasta que termina
Controladores de eventos pesados: si un clic en un botón ejecuta cálculos pesados, actualiza muchos elementos de la página y hace una llamada a una API, todo a la vez, bloquea el navegador.
Layout thrashing: cuando lee y modifica continuamente el tamaño de los elementos dentro de un bucle (por ejemplo, comprobar un ancho y volver a establecerlo), el navegador tiene que recalcular el diseño cada vez. Esto ralentiza su sitio web.
Demasiado JavaScript de terceros ejecutándose en cada interacción: los eventos de analítica y los píxeles de seguimiento publicitario que se activan al hacer clic añaden cientos de milisegundos al tiempo de respuesta.
Cómo solucionarlo
- Divida las tareas largas en partes más pequeñas con setTimeout o scheduler.postTask()
- Reduzca el JavaScript pesado en los eventos de clic
- Evite las actualizaciones repetidas del DOM dentro de bucles
- Limite los scripts de terceros en las interacciones
- En sitios con React, use startTransition() de React 18 para conseguir actualizaciones más fluidas
Estabilidad visual (CLS): evite que su página dé saltos
CLS (Cumulative Layout Shift) mide cuánto se mueve su página mientras carga.
Si el texto se desplaza de repente o un botón se mueve justo cuando hace clic, eso es CLS. Una página estable resulta fluida. Una página que da saltos pierde usuarios.
Causas habituales de CLS y cómo solucionarlas
Imágenes y vídeos sin dimensiones: el navegador no sabe cuánto espacio reservar.
Solución: añada width y height en cada etiqueta <img>.
Anuncios o iframes sin espacio reservado: se cargan más tarde y desplazan el contenido hacia abajo.
Solución: establezca una altura fija o mínima para los contenedores de anuncios.
Contenido añadido tras la carga de la página: ventanas emergentes, banners o avisos de cookies desplazan el contenido.
Solución: reserve espacio o colóquelos en la parte inferior.
Problemas de carga de fuentes (FOUT): el texto cambia de estilo tras la carga y desplaza el diseño.
Solución: use font-display: optional o ajuste correctamente los tamaños de fuente.
Animaciones CSS incorrectas: usar top, left o margin provoca cambios de diseño.
Solución: use transform y opacity.
Secciones de carga tardía: tarjetas o contenidos que cargan con un tamaño mayor del previsto.
Solución: mantenga el marcador de posición (skeleton) del mismo tamaño que el contenido final.
Una solución moderna y sencilla para las imágenes
Use aspect-ratio en CSS para reservar el espacio antes de que cargue la imagen.
Así se evitan por completo los cambios de diseño causados por las imágenes.
Guía rápida de font-display
font-display: swap → texto rápido, pequeño cambio de diseño
font-display: optional → sin cambios de diseño, pero puede que la fuente no cargue
font-display: block → texto invisible, evite usarlo
Listas de verificación de velocidad por plataforma
Lista de verificación de velocidad para WordPress (2026)
WordPress impulsa el 43 % de los sitios web, pero las configuraciones predeterminadas suelen ser lentas. Céntrese primero en estos puntos:
- Use alojamiento WordPress gestionado para un mejor rendimiento: Kinsta, WP Engine o Cloudways
- Instale un plugin de caché y active todas las capas de caché.
- Elija un tema ligero para reducir la carga de CSS y JavaScript.
- Elimine los plugins que no use para reducir la carga del servidor y de scripts.
- Aloje las fuentes en su propio servidor para evitar solicitudes externas.
- Limpie su base de datos con regularidad para que las consultas sigan siendo rápidas.
- Optimice y comprima las imágenes antes o durante la subida.
Lista de verificación para Shopify y comercio electrónico
Los problemas de velocidad suelen deberse a las aplicaciones y las imágenes:
- Audite todas las aplicaciones instaladas para reducir el JavaScript innecesario.
- Elija un tema optimizado para el rendimiento.
- Redimensione y comprima las imágenes de producto a tamaños aptos para la web.
- Active la carga diferida para las imágenes de productos y colecciones.
- Elimine o difiera los scripts de terceros no críticos.
Consejos de velocidad para React / Next.js
- Use importaciones dinámicas para cargar el código solo cuando sea necesario.
- Elija el método de renderizado adecuado para cada página.
- Use startTransition para mantener la interfaz fluida.
- Precargue los enlaces para mejorar la velocidad de navegación.
Técnicas avanzadas que realmente hacen que su sitio se perciba rápido
Estas técnicas van más allá de la optimización básica. Mejoran tanto la velocidad real como la rapidez que perciben los usuarios.
1. Speculation Rules API (carga instantánea de páginas)
Esta función permite al navegador cargar las páginas antes de que el usuario haga clic.
Cuando el usuario hace clic, la página aparece al instante porque ya está lista en segundo plano.
Para los desarrolladores, esto se hace con la Speculation Rules API y ajustes de prerender. Empiece con el modo moderate para no desperdiciar recursos.
Por qué importa: los usuarios no perciben ningún retraso al navegar.
2. Priority Hints (mejore el LCP rápidamente)
No todos los recursos son igual de importantes.
Con fetchpriority, le indica al navegador qué debe cargar primero.
Asigne prioridad alta a su imagen principal (elemento LCP)
Asigne prioridad baja a scripts como los de analítica
Por qué importa: una carga más rápida del contenido clave mejora el LCP y la experiencia de usuario.
3. Edge computing (reduzca el retraso del servidor)
En lugar de cargar su sitio desde un único servidor lejano, el edge computing lo entrega desde una ubicación cercana.
Herramientas como Cloudflare y Vercel procesan las solicitudes más cerca del usuario.
Por qué importa: menor TTFB y tiempos de respuesta más rápidos en todo el mundo.
4. View Transitions API (haga que la velocidad se perciba mayor)
La velocidad no es solo cuestión de cifras. También es cuestión de percepción.
Con la View Transitions API, los cambios de página resultan fluidos en lugar de bruscos.
Aunque el tiempo de carga sea algo mayor, los usuarios sienten que el sitio es más rápido.
Por qué importa: mejor experiencia de usuario y mayor interacción.
Su plan de acción de 30 días
Semana 1
Diagnóstico y corrección de imágenes
- Realizar un diagnóstico completo (PSI, GTmetrix, WebPageTest)
- Registrar la tabla de referencia
- Convertir todas las imágenes a WebP/AVIF
- Añadir width/height a todas las etiquetas img
- Añadir fetchpriority="high" a la imagen LCP
- Quitar la carga diferida de las imágenes de la parte visible
Semana 2
Caché y alojamiento
- Activar la caché de página completa en el servidor
- Configurar los encabezados Cache-Control para los recursos estáticos
- Activar una CDN (el plan gratuito de Cloudflare, si no hay otra opción)
- Alojar las fuentes en el propio servidor y eliminar el enlace a Google Fonts
- Valorar mejorar el alojamiento si el TTFB > 600 ms
Semana 3
Scripts y terceros
- Añadir defer/async a todos los scripts no críticos
- Auditar los scripts de terceros y eliminar los que no se usan
- Añadir preconnect para los terceros restantes
- Implementar una fachada para los vídeos incrustados de YouTube
- Auditar el CSS no utilizado con la pestaña Coverage
Semana 4
Avanzado y supervisión
- Investigar y corregir los problemas de INP
- Revisar el CLS y corregir los elementos que provocan cambios de diseño
- Añadir Speculation Rules a las páginas con más tráfico
- Configurar Lighthouse CI en su pipeline
- Configurar las alertas de CWV en Search Console
- Volver a medir y documentar las mejoras
¡Conclusión final!
La velocidad de un sitio web no es un proyecto con fecha de finalización. Es una práctica continua. Cada nueva funcionalidad, plugin o imagen es una posible regresión. Los equipos que mantienen sitios rápidos son los que tratan el rendimiento como una disciplina continua —con monitorización, presupuestos y el hábito de una revisión trimestral—, no como un sprint puntual. El trabajo que haga este mes se irá degradando sin mantenimiento. Construya sistemas, no solo soluciones.
