¿Cuál es una buena velocidad de carga para un sitio web?

Según Google, un LCP de hasta 2,5 segundos, un INP de hasta 200 ms y un CLS de hasta 0,1 se consideran buenos, medidos en el percentil 75 de las visitas.

¿Qué es lo que más ralentiza un sitio web?

Casi siempre son imágenes demasiado grandes, archivos sin caché o sin compresión y exceso de JavaScript bloqueando la página. Mide antes de tocar nada para saber cuál pesa más en tu caso.

¿Necesito una CDN para un sitio pequeño?

Ayuda cuando tus visitantes están lejos del servidor, porque los archivos estáticos salen de un punto más cercano. Para un sitio con público local, la caché y las imágenes optimizadas suelen rendir más al principio.

¿Es buena idea usar lazy loading en todas las imágenes?

No. Usa loading="lazy" en las imágenes que quedan fuera de la primera pantalla, pero deja que la imagen principal de arriba cargue normalmente, o el LCP empeora.

Cómo hacer tu sitio web más rápido

Un sitio lento pierde visitantes antes de mostrar nada. El problema es que "lento" es vago: puede ser el servidor tardando en responder, una foto de 4 MB arriba de todo o un script que bloquea los clics. Cada causa tiene un arreglo distinto, y optimizar a ciegas suele gastar tiempo en lo que no pesa.

El camino que funciona es siempre el mismo: medir, encontrar el mayor cuello de botella, corregir un punto a la vez y volver a medir. Esta guía sigue ese orden y muestra el código de cada ajuste.

¿Cómo medir la velocidad de tu sitio?#

Google resume la experiencia de carga en tres métricas, llamadas Core Web Vitals:

Métrica	Qué mide	Bueno
LCP (Largest Contentful Paint)	Cuándo aparece el elemento visible más grande	hasta 2,5 s
INP (Interaction to Next Paint)	Cuánto tarda la página en responder a clics y toques	hasta 200 ms
CLS (Cumulative Layout Shift)	Cuánto "salta" el diseño durante la carga	hasta 0,1

Cada métrica se evalúa en el percentil 75 de las visitas, separando móvil y escritorio. La página solo aprueba si las tres están dentro de la meta.

Para medir, abre las DevTools de Chrome, ve a la pestaña Lighthouse y ejecuta un análisis en modo móvil. La pestaña Network muestra el tamaño y el tiempo de cada archivo, y ahí es donde encuentras al culpable. Lighthouse usa una prueba simulada; para datos de visitantes reales, usa el informe de Core Web Vitals de Search Console o PageSpeed Insights.

Anota los números antes de tocar nada. Sin ellos, no sabrás si hubo mejora.

¿Cómo optimizar las imágenes?#

Las imágenes suelen ser la mayor parte de los bytes de una página. Cuatro ajustes cubren casi todo:

Formato moderno. AVIF y WebP pesan menos que JPEG y PNG con la misma calidad visual. Ofrece los dos con un fallback.
Tamaños responsivos. No envíes una imagen de 2000 px a un móvil de 400 px de ancho.
Dimensiones declaradas. width y height reservan el espacio y evitan el CLS.
Lazy loading solo fuera de la primera pantalla.

html

<picture>
  <source type="image/avif"
    srcset="foto-480.avif 480w, foto-800.avif 800w, foto-1200.avif 1200w"
    sizes="(max-width: 600px) 400px, 800px">
  <source type="image/webp"
    srcset="foto-480.webp 480w, foto-800.webp 800w, foto-1200.webp 1200w"
    sizes="(max-width: 600px) 400px, 800px">
  <img src="foto-800.jpg" alt="Descripción de la foto" width="800" height="600" loading="lazy">
</picture>

El navegador usa la primera <source> cuyo formato soporta e ignora las demás. El <img> es el fallback.

¿Y la imagen principal de arriba?#

Casi siempre es el elemento del LCP, así que no le pongas loading="lazy": el navegador necesita saber dónde queda la imagen antes de decidir cargarla, y eso la retrasa. Pide prioridad alta:

html

<img src="hero-1200.webp" alt="Banner principal" width="1200" height="600" fetchpriority="high">

fetchpriority="high" es una pista, no una orden, pero hace que el navegador empiece a descargar la imagen antes. Si la imagen viene de un background-image en el CSS, el navegador la descubre tarde. En ese caso, usa <link rel="preload" as="image" href="hero.jpg" fetchpriority="high"> en el <head>.

¿Cómo comprimir HTML, CSS y JavaScript?#

El texto se comprime muy bien. El navegador envía Accept-Encoding: br, gzip y el servidor responde con Content-Encoding: br (Brotli) o gzip, junto con Vary: Accept-Encoding para que las cachés guarden cada versión por separado. Activa la compresión para HTML, CSS, JS, JSON y SVG.

No vuelvas a comprimir imágenes, audio ni video: JPEG, WebP, PNG y MP4 ya están comprimidos, y comprimirlos otra vez solo gasta CPU y a veces hasta agranda el archivo.

Después de comprimir, envía menos código:

Quita las bibliotecas que usas para una sola función.
Usa defer en los scripts que no necesitan ejecutarse antes de que la página aparezca: <script src="app.js" defer></script>.
Divide el JavaScript por página, para que cada una descargue solo lo que usa.

¿Cómo configurar la caché del navegador?#

Quien ya visitó el sitio no debería descargarlo todo de nuevo. El encabezado Cache-Control dice por cuánto tiempo el navegador puede reutilizar un archivo. La estrategia más segura tiene dos reglas.

Los archivos con hash en el nombre (como app.3f9a1c.js), que nunca cambian en la misma dirección, se quedan un año en caché:

http

Cache-Control: max-age=31536000, immutable

El HTML, que referencia esos archivos, debe revalidarse siempre:

http

Cache-Control: no-cache

Ojo: no-cache no significa "no guardes". Significa "guarda, pero pregunta al servidor antes de reutilizar". Para prohibir cualquier almacenamiento, el valor es no-store. Cuando cambias un archivo, cambia el hash, cambia la dirección y la caché antigua simplemente deja de usarse. Mira la explicación completa en Qué es Cache-Control.

¿Cuándo ayuda una CDN?#

Una CDN guarda copias de tus archivos estáticos en varios puntos del mundo y sirve a cada visitante desde el más cercano. Eso reduce la latencia y alivia tu servidor. La ganancia es mayor cuando el público está repartido o lejos de la región del servidor, y menor cuando todos están cerca. Detalles en Qué es una CDN.

Una CDN suele respetar el Cache-Control que definiste, así que los dos ajustes se suman: la caché decide qué se puede reutilizar y la CDN decide desde dónde.

Si el contenido no cambia en cada petición, un sitio estático es el caso más simple: no hay código ejecutándose en el servidor por cada visita, solo archivos listos para cachear.

¿Cómo saber si funcionó?#

Recarga la página con las DevTools abiertas en la pestaña Network. En la segunda carga, los archivos con hash deben aparecer como "(memory cache)" o "(disk cache)".
Revisa los encabezados de un archivo: Cache-Control y Content-Encoding deben estar presentes.
Ejecuta Lighthouse de nuevo y compara LCP, INP y CLS con los números que anotaste.
Sigue el efecto en visitantes reales con Search Console, que tarda días en reflejar los cambios.

Errores comunes#

Poner loading="lazy" en la imagen del LCP.
Olvidar width y height, lo que genera CLS.
Dar un max-age largo a archivos sin hash: los visitantes dejan de ver la versión nueva.
Optimizar lo que no pesa: confírmalo antes en la pestaña Network.
Probar solo en tu computadora rápida y con tu buena conexión.

Cómo hacerlo en Square Cloud#

En Square Cloud, tú haces el deploy del sitio y controlas los archivos y el código. Los sitios estáticos tienen un runtime propio, y toda aplicación web recibe un subdominio *.squareweb.app con HTTPS y certificado TLS automático.

La red incluye una CDN global basada en Cloudflare, HTTP/3 y tráfico ilimitado, sin cobro por ancho de banda ni por petición (política de uso justo). Eso cubre la parte de entrega, y la CDN respeta el Cache-Control que envía tu aplicación. La optimización de imágenes, los encabezados de caché y el JavaScript siguen siendo ajustes tuyos, como se describe arriba.

Para medir el resultado, todos los planes tienen analytics web sin cookies, con visitas, rutas, países y status codes. Los planes Pro y Enterprise agregan latencia p50/p95/p99 y logs HTTP. El plan Hobby parte de R$12,49 al mes.

Mira cómo publicar tu sitio en Hosting de sitios web.

Cómo hacer tu sitio web más rápido (caché, CDN, imágenes)