Tiempo de carga: por qué cuenta para su web

La velocidad no es una sensación, sino algo medible. Google evalúa tres indicadores que, juntos, describen cómo percibe una página un visitante real. Se distinguen en lo que miden y, por tanto, también en sus causas y en sus remedios.

Conviene distinguir dos tipos de medición: los datos de laboratorio se generan en una prueba simulada (por ejemplo, en PageSpeed Insights o Lighthouse) y sirven para localizar errores. Los datos de campo proceden de visitantes reales y muestran cómo se vive realmente la página. Pueden diferir; quien solo mira el resultado de laboratorio puede hacerse una idea equivocada. Mida en el móvil y varias veces, porque los valores fluctúan.

Una imagen se compone de píxeles. Cuantos más píxeles, más datos. Una foto sacada directamente de una cámara o de un móvil suele tener varios miles de píxeles de ancho, pero en pantalla normalmente solo hacen falta unos cientos o pocos miles.

Cinco pasos para las imágenes

1. Generar las medidas adecuadas. Una variante para cada tamaño de visualización, no el archivo original.
2. Elegir un formato moderno. WebP o AVIF suelen ser bastante más pequeños que JPEG con la misma calidad, con el formato clásico como alternativa para navegadores antiguos.
3. Sopesar la compresión. Una compresión ligera apenas se nota a simple vista, pero ahorra mucho. Compruebe en pantalla las imágenes importantes.
4. Carga diferida. Las imágenes situadas bajo la zona visible solo se cargan cuando el visitante se acerca al desplazarse. La primera imagen grande, en cambio, no: debe aparecer enseguida.
5. Indicar el tamaño. Ancho y alto en el código, para que el navegador reserve espacio y la página no salte.

Cómo mantener las imágenes de forma duradera, sin tener que pensarlo cada vez, se explica en la guía Optimizar las imágenes de la web. Las cuestiones de diseño se tratan en Lenguaje visual y fotos.

No todo se resuelve en el contenido de la página. También la forma en que un servidor entrega los archivos determina la rapidez con que arranca una página. Los puntos más importantes:

Tiempo de respuesta del servidor. Cuánto tarda el servidor en responder. En sistemas dinámicos (por ejemplo, WordPress), el servidor vuelve a calcular la página en cada acceso si no hay una caché de páginas activa. Las páginas generadas de forma estática están listas de antemano y se entregan casi al instante.

Compresión. Los archivos de texto (HTML, estilos, scripts) se pueden reducir mucho antes de la transmisión. Procedimientos como gzip o Brotli son estándar y deberían estar activados.

Indicaciones de caché. Con los datos adecuados, el servidor le dice al navegador durante cuánto tiempo puede conservar archivos como el logotipo, los estilos y las imágenes. En visitas repetidas ya no hace falta volver a cargarlos. Para las páginas que cambian a menudo se aplican plazos más cortos, para que los cambios lleguen.

Protocolos actuales. HTTP/2 y HTTP/3 agrupan muchas solicitudes de forma más eficiente que las versiones anteriores. La mayoría de los proveedores de alojamiento los ofrecen; conviene comprobarlo.

Ubicación y red de distribución. Un servidor cercano a los visitantes responde más rápido. Una red de distribución de contenidos (CDN) reparte los archivos en muchas ubicaciones. Para empresas regionales con visitantes en Alemania suele bastar un buen proveedor del país; con un público internacional compensa una CDN, que sin embargo debería valorarse desde el punto de vista de la protección de datos.

Tarifa de alojamiento. Las tarifas muy baratas comparten recursos con muchas otras páginas. Si el tiempo de respuesta es alto de forma permanente, un cambio puede ayudar, pero solo después de haber puesto en orden las imágenes y los scripts.

Así podría ser un proyecto de optimización para la web de una empresa. Es un patrón, no una serie de mediciones con resultados inventados.

1. Medición inicial: medir en el móvil las cinco páginas más importantes (inicio, dos servicios, contacto, una guía). Anotar los valores, la fecha y el dispositivo.
2. Lista de causas: anotar para cada página los tres mayores frenos (por ejemplo: imagen principal demasiado grande, script de chat, tres variantes de fuente).
3. Ordenar las palancas por esfuerzo y efecto: ajustar las imágenes (poco esfuerzo, gran efecto), quitar un script externo (poco esfuerzo, efecto medio), configurar la caché del servidor (esfuerzo medio, gran efecto en sistemas con base de datos), reducir las variantes de fuente (poco esfuerzo, efecto pequeño).
4. Aplicar en paquetes pequeños: volver a medir tras cada paquete. Así se puede atribuir cuánto aportó cada cosa.
5. Medición final y documentación: las mismas páginas, el mismo dispositivo, varias pasadas. Los resultados se le entregan a usted, con una indicación de lo que queda pendiente.
6. Repetición tras los cambios: tras cada ampliación importante (página nueva, plug-in nuevo, nueva colección de imágenes), comprobar brevemente las páginas principales.

El orden evita el error más frecuente: pasar meses puliendo detalles mientras una sola imagen demasiado grande determina el resultado.

1. Abra PageSpeed Insights, introduzca la dirección de su página de inicio y elija la vista móvil. Anote LCP, INP y CLS.
2. Mire la lista de recomendaciones y busque las tres que más tiempo deberían ahorrar. Normalmente las imágenes están en los primeros puestos.
3. Abra su página en el móvil con la red móvil. ¿Cuánto tarda en poder leer?
4. Compruebe en el código fuente (clic derecho, mostrar código fuente de la página) si se cargan scripts de servidores externos. Busque las direcciones de proveedores externos.
5. Pruebe una página con muchas imágenes, por ejemplo sus referencias. ¿Con qué rapidez aparecen las primeras imágenes y con cuál la última?
6. Toque un punto del menú mientras la página aún se está cargando. ¿Responde enseguida?

Si desea ayuda con la evaluación, una medición con lista de medidas se ofrece por separado y se describe en el presupuesto (los proyectos comienzan desde 2.500 €). Muy relacionado está el aspecto técnico de la optimización para buscadores, véase SEO técnico.

Con el tiempo las páginas se vuelven más pesadas: una imagen aquí, un script allá. Un presupuesto de rendimiento fija límites para que no ocurra de forma gradual. Consiste en pocas reglas claras que conoce todo el que publica contenidos.

• Las imágenes solo se suben en tamaños preparados; para cada foto rige un límite máximo de tamaño de archivo.
• Los scripts o plug-ins nuevos necesitan una justificación y se miden antes en una página de pruebas.
• Los vídeos no se reproducen automáticamente y solo se cargan tras un clic.
• En cada página se usa como máximo un elemento principal grande.
• Para las páginas principales rigen valores objetivo (por ejemplo, las zonas verdes de los Core Web Vitals), que se revisan cada trimestre.
• Los incumplimientos no se reprenden, sino que se corrigen: quien encuentra una imagen demasiado grande la sustituye y lo comunica.

El presupuesto no protege de todos los errores, pero hace visible el tema. El equipo comprende que cada añadido desencadena un cálculo de tiempo.

Un cambio es una decisión mayor que optimizar una imagen. Compensa en estos casos:

1. El tiempo de respuesta del servidor es alto de forma permanente, incluso con una página aligerada y con la caché activa.
2. La tarifa limita tanto los recursos que las horas punta provocan mensajes de error.
3. El proveedor no ofrece una versión actual de PHP, ni HTTP/2, ni la posibilidad de configurar la caché.
4. La ubicación está lejos de su público objetivo y la entrega mediante una red no es una opción.
5. No se cumplen los requisitos de seguridad o de protección de datos, por ejemplo, falta un contrato de encargo de tratamiento.

Antes del cambio, compruebe la duración del contrato, la ayuda con la migración y cómo se trasladan el dominio y las direcciones de correo electrónico. Haga planificar la migración para que no haya interrupciones. El mantenimiento posterior se describe en Mantenimiento web.

TTFB (Time to First Byte)

Tiempo hasta que el servidor entrega el primer byte de la respuesta. Muestra la rapidez con que reacciona el servidor.

Bloqueo de renderizado

Archivos que el navegador debe cargar antes de poder mostrar la página.

Lazy loading

Carga diferida de las imágenes solo cuando hacen falta.

Caché

Memoria intermedia: los archivos ya cargados se reutilizan.

Minificación

Eliminación de caracteres superfluos de los archivos de código para reducir su tamaño.

CDN

Content Delivery Network: una red de servidores que entrega los archivos cerca del visitante.

Hilo principal

La parte del navegador que ejecuta el código y construye la página. Si está saturada, la página reacciona con retraso.

Datos de campo y de laboratorio

Valores medidos en visitantes reales frente a valores medidos en una prueba artificial.