Formato nuevo
Cómo comprobar la velocidad del sitio: mediciones, CWV y herramientas
Una página lenta pierde gente y señales de búsqueda. Comprobar velocidad no es una carrera al cien en PageSpeed — es averiguar qué bloquea (servidor, imágenes, JS) y en qué URLs duele.
Abajo: lab vs field, qué métricas importan, un set de herramientas magro y cómo leer recomendaciones. No reimprimimos una lista de precios de diez herramientas de 2018 — unas envejecieron, otras cambiaron de producto. Acelerar WordPress es un artículo aparte.
Por qué medir la velocidad
Los usuarios rara vez esperan eternamente: suben los rebotes y cae la conversión. Para SEO importan señales de page-experience — y bots y personas deben obtener contenido sin dolor.
No tomes el mito «los sitios líderes cargan en 0,38 s» de posts viejos como KPI. Mide tus plantillas en redes móviles y compara competidores por sustancia, no por el número mágico de otro.
Lab y field: dos capas de verdad
Lab (PageSpeed Insights / Lighthouse, WebPageTest): condiciones reproducibles, waterfall, tips de «qué quitar». Útil para regresiones tras un release.
Field (Chrome UX Report, informes de Search Console): cómo carga de verdad para tu audiencia. A veces el lab es verde y el field rojo — geografía, dispositivos y caché distintos.
Qué tratar como base
| Capa | Cuándo |
|---|---|
| Lab | Debugging, comparación antes/después del fix |
| Field | UX real y valoración de señales SEO |
| Ambas | Releases y debates de «ya vamos rápido» |
Qué métricas mirar
Core Web Vitals: LCP (contenido más grande), INP (responsividad), CLS (estabilidad del layout). Cerca — TTFB como señal de servidor/backend.
No arregles todo a la vez. Primero LCP en móvil en una URL clave, luego INP/CLS, luego cosmética de la nota.
Culpables habituales:
- hero pesado sin dimensiones
- JS/CSS bloqueantes
- TTFB / hosting lento
- widgets y tags de terceros
- fuentes sin font-display
Un set de herramientas magro
PageSpeed Insights — arranque rápido de lab más un resumen de field donde haya. WebPageTest — waterfall profundo y comparación por región. Google Search Console — page experience en todo el sitio.
También: DevTools Performance/Network en local, monitoreo de uptime (Pingdom y pares — como alerta, no como único medidor SEO). Checkers extra de «sitespeed» como segunda mirada, no como verdad.
Leer el informe — luego actuar
Fija URL, dispositivo (móvil), fecha y un screenshot o export. Lista las tres recomendaciones principales con estimación de esfuerzo. Ship → vuelve a medir en un día (el field tarda más en ponerse al día).
TTFB alto — hosting, caché, backend. LCP — imágenes, SSR/critical CSS, prioridad de carga. CLS — dimensiones de media y slots de ads.
Mini-ritual mensual:
- PSI en 3–5 URLs clave
- GSC: URLs con mala experiencia
- comparar con el mes pasado
- 1–2 fixes al sprint
Qué recordar
La velocidad se mide con métricas de percepción y de servidor — no con un montón de diez favoritos. Lab para debugging, field para la verdad del usuario.
Tras medir — encuentra el cuello de botella y arréglalo. Correr a 100 puntos sin mejor UX no es el trabajo.
FAQ
¿Hace falta 100 en PageSpeed?
No. Importa más LCP / INP / CLS en zona verde en móvil para URLs clave — y la UX real.
¿Lab y field son lo mismo?
No. Lab (Lighthouse) es una corrida controlada. Field (CrUX) son datos de usuarios reales. Mira ambos.
¿Basta con Webmaster?
Útil para disponibilidad y algo de diagnóstico — no sustituye PSI / CWV para cómo se siente la carga.
¿Velocidad equivale a rankings?
De forma indirecta, vía UX y crawl. Las posiciones del núcleo llevan meses planificados de trabajo — no «corrí PSI y entré en primera página».
¿Con qué URL empiezo?
Home, landings principales de ads u orgánico, página de producto o servicio, checkout.
¿Necesitas medir la velocidad sin culto al 100?
Miramos lab y field, LCP y TTFB — y cerramos un freno real, no una lista de diez tools.
Hablar del proyecto
