Módulo 6 · 6.1

Español

Nederlands English Deutsch Français Español Italiano

¿Qué hace que un sitio sea lento, y cómo se mide?

Módulo 6: Velocidad · Tiempo de lectura: 9 minutos

Objetivo de la lección: Después de esta lección podrá medir dónde se pierde el tiempo y reconocer la diferencia entre la lentitud en el servidor y la lentitud en el navegador.

Conceptos clave: TTFB, Core Web Vitals (LCP, INP, CLS), datos de laboratorio, datos de campo, PageSpeed Insights, pestaña de red, compresión, scripts externos, límites del plan de alojamiento, 503

Primero medir, luego ajustar

"El sitio va lento" puede tener diez causas distintas. Quien, sin medir, instala a la vez un plugin de caché, un plugin de optimización de imágenes y contrata un plan más grande, no sabrá después qué ha ayudado, y además tendrá tres cosas más que mantener. Por eso, empiece siempre con tres preguntas (las mismas que figuran en la guía de su proveedor de alojamiento):

¿Va todo lento, o solo la administración? Una administración lenta con una parte pública rápida apunta a plugins que hacen mucho trabajo en el escritorio, o a bots que atacan la página de acceso.
¿Siempre, o en momentos concretos? Si solo ocurre en horas punta o cuando se ejecuta una tarea programada, su plan está llegando a sus límites.
¿Le pasa a todo el mundo, o solo a usted? Pruebe desde su teléfono con 4G o 5G, o pida a otra persona que lo compruebe. Si solo va lento para usted, el problema está en su conexión o en su VPN.

Dos mitades: servidor y navegador

El tiempo que espera un visitante consta de dos partes (lección 1.2):

El servidor genera el HTML: servidor web, PHP, plugins, base de datos. Esto se refleja en el TTFB (time to first byte), el tiempo hasta el primer byte de la respuesta. web.dev indica como regla general que la mayoría de los sitios deberían aspirar a un TTFB de 0,8 segundos o menos.
El navegador lee ese HTML y después descarga todo lo que contiene: hojas de estilo, scripts, tipos de letra, imágenes, vídeo, códigos de medición, widgets de chat. Solo cuando ha descargado suficiente de todo ello, el visitante empieza a ver algo.

Un TTFB alto se soluciona del lado del servidor: caché (lección 6.2), menos plugins o más ligeros, una versión más reciente de PHP, una base de datos limpia (lección 6.3) o más capacidad de cálculo. Un TTFB bajo con una página que, aun así, va lenta, apunta al lado del navegador: imágenes demasiado grandes, demasiados scripts, componentes externos.

Core Web Vitals

Google mide la experiencia de los visitantes con tres cifras, las Core Web Vitals:

Medición	Qué mide	Es bueno si
LCP (Largest Contentful Paint)	Con qué rapidez se muestra el elemento de contenido más grande (a menudo la foto principal o el encabezado)	2,5 segundos o menos
INP (Interaction to Next Paint)	Con qué rapidez reacciona la página cuando hace clic, toca o escribe	200 milisegundos o menos
CLS (Cumulative Layout Shift)	Cuánto se desplaza la página durante la carga	0,1 o menos

INP sustituyó en marzo de 2024 a la antigua métrica FID. Google utiliza estas cifras, entre otras cosas, para clasificar los resultados de búsqueda, pero el motivo principal para mejorarlas es sencillo: los visitantes abandonan una página lenta o que se desplaza de forma inesperada.

Datos de laboratorio y datos de campo

Existen dos tipos de mediciones, y ofrecen cifras distintas:

Datos de laboratorio: una prueba en un momento concreto, desde un único lugar, con un teléfono y una conexión simulados. Útil para comparar (antes y después de un cambio), pero no corresponde a un visitante real.
Datos de campo: mediciones de visitantes reales con Chrome, correspondientes a los últimos 28 días. Esto es lo que los visitantes experimentan de verdad. Los sitios pequeños suelen tener muy pocos visitantes como para generar datos de campo.

PageSpeed Insights (pagespeed.web.dev) muestra ambos: arriba los datos de campo (si los hay), debajo una prueba de laboratorio con una puntuación y recomendaciones concretas. No se fije solo en la puntuación de 0 a 100. Observe los componentes: ¿el LCP es malo porque el servidor es lento (TTFB) o porque la foto principal pesa 3 MB?

Haga siempre la prueba varias veces (las cifras varían) y pruebe también una página normal, no solo la página de inicio.

Observar usted mismo con el navegador

Las herramientas de desarrollo de su navegador (F12) muestran lo que ocurre realmente:

Pestaña Red: actualice la página con la caché desactivada (marque la casilla "Deshabilitar caché"). Verá cada archivo que se carga, su tamaño y cuánto tardó. Ordene por tamaño: los archivos más grandes suelen ser imágenes. Ordene por dominio: ¿cuánto procede de terceros (tipos de letra, códigos de medición, vídeos)?
La primera solicitud (el propio HTML): haga clic en ella, pestaña Tiempos. "Waiting for server response" es el TTFB.
Cabeceras de esa primera solicitud: ¿hay compresión (content-encoding: br o gzip), y procedía la página de una caché (lección 6.2)?

Los culpables habituales

En la práctica, la lentitud en WordPress suele deberse a uno de estos motivos:

Ausencia de caché de página: cada página se genera de nuevo en cada visita (lección 6.2).
Demasiados plugins, o plugins pesados, sobre todo los que llaman a servicios externos en cada solicitud o ejecutan consultas pesadas (lección 5.3).
Imágenes grandes: una foto de 5 MB tomada con un teléfono en la página de inicio (lecciones 4.4 y 6.3).
Un tema pesado o un creador de páginas que carga muchos scripts y hojas de estilo en cada página (lección 5.1).
Componentes externos: tipos de letra, vídeos, widgets de chat, códigos de medición, botones de redes sociales de terceros. Cada uno supone una conexión a otro servidor que puede ser lento.
Una versión antigua de PHP (lección 8.4).
Una base de datos desordenada: miles de revisiones, spam, tablas de registro de plugins (lección 6.3).
Bots: rastreadores, rastreadores de IA e intentos de inicio de sesión que mantienen su plan ocupado (lección 7.3).
El plan llega a sus límites: capacidad de cálculo (CPU), procesos o memoria insuficientes para el tráfico.

Los límites de su plan

En el alojamiento compartido, cada plan recibe una parte fija del servidor: capacidad de cálculo, memoria, velocidad de disco y un número de procesos simultáneos. Si su sitio consume más, se ralentiza, o los visitantes reciben un mensaje de error 503 (Service Unavailable, en algunos proveedores de alojamiento "Resource Limit Is Reached"). En DirectAdmin con CloudLinux, esto se ve en Resource Usage (con "faults" si su sitio se ha ralentizado) y con X-Ray puede ver, por página, qué plugin o consulta consume el tiempo. Otros proveedores de alojamiento disponen de paneles similares, a veces solo bajo petición.

Un plan más grande ayuda si su sitio realmente necesita más recursos (una tienda online con mucho tráfico). No resuelve un sitio mal configurado: el problema volverá a aparecer más adelante. Busque primero la causa.

Resumen

Mida primero: todo o solo la administración, siempre o a veces, todo el mundo o solo usted.
El TTFB es el lado del servidor (aspire a 0,8 segundos o menos); el resto es lo que carga el navegador.
Core Web Vitals: LCP (2,5 s), INP (200 ms) y CLS (0,1); INP sustituyó a FID en 2024.
PageSpeed Insights muestra datos de campo y datos de laboratorio; la pestaña de red muestra lo que realmente se carga.
La mayor parte de la lentitud se debe a la falta de caché, plugins pesados, imágenes grandes y componentes externos; un plan más grande es solo el último paso.

Cuestionario

Ejercicio

Ejercicio A6.1: Mida su TTFB y la compresión. Introduzca la dirección de su sitio y, si lo desea, una página normal (por ejemplo, su página de contacto). El programa solicita cada página tres veces sin cookies y muestra el TTFB intermedio, el tamaño del HTML y si el servidor envía el HTML comprimido (content-encoding gzip o br). Compare el resultado con una prueba en PageSpeed Insights y anote lo que le llame la atención.

Para saber más

Estos artículos describen los pasos en los paneles de WebOké; en otros paneles funcionan de forma similar.

Cookies en WebOké

Ajustes de cookies

Necesarias

Marketing