Tu web optimizada
Una web rápida no depende de un solo truco, sino de decisiones en cada capa: lo que ve el usuario, la red, la API, el servidor, la base de datos y cómo se mide todo. Estos son 31 puntos, con una explicación breve por cada uno.
Frontend (7)
-
Agrega skeletons de carga
Mientras llegan los datos, muestra la forma del contenido en vez de un espacio vacío o un spinner. La página se siente más rápida y evita saltos de layout.
-
Sirve las imágenes en WebP o AVIF
Ambos formatos pesan bastante menos que JPEG o PNG con calidad similar. Menos bytes significa menor LCP y menos datos móviles.
-
Usa lazy loading en las imágenes fuera de pantalla
Con loading="lazy" el navegador descarga solo lo que el usuario está por ver. La carga inicial se concentra en lo visible.
-
Divide el JavaScript por página [code splitting]
Cada ruta carga solo el código que necesita. Un bundle único obliga a descargar y ejecutar lo que el usuario quizá nunca use.
-
Virtualiza las listas largas
Renderiza solo las filas visibles más un margen, no miles de nodos. Reduce memoria y mantiene fluido el scroll.
-
Cachea los archivos estáticos en el navegador
Con Cache-Control largo y nombres con hash, las visitas repetidas no vuelven a descargar CSS, JS ni imágenes.
-
Aloja tus fuentes y limita los grosores/pesos de fuente
Servirlas desde tu dominio evita una conexión extra a un tercero. Cada peso es un archivo más, así que usa solo los necesarios.
Network / Red (5)
-
Evita llamadas duplicadas a la API
Deduplica y cachea peticiones iguales (por ejemplo con una capa de caché de datos en el cliente). Menos tráfico y menos carga en el servidor.
-
Pon debouncing al buscador y al autocompletado
Espera una pausa al escribir antes de consultar. Pasas de una petición por tecla a una por intención.
-
Sirve los archivos estáticos desde una CDN
Los archivos se entregan desde un nodo cercano al usuario, lo que baja la latencia y alivia tu servidor de origen.
-
Activa la compresión Brotli o Gzip
Comprime HTML, CSS, JS y JSON en tránsito. Brotli suele ganar a Gzip en texto; ambos reducen mucho el tamaño transferido.
-
Lanza en paralelo las peticiones independientes
Si una petición no depende de otra, no las encadenes. Con Promise.all el tiempo total es el de la más lenta, no la suma.
API (3)
-
Pagina los resultados de la API
Devuelve los datos por páginas o con cursor, no colecciones completas. Respuestas pequeñas, consultas acotadas y memoria estable.
-
Pide solo las columnas que necesitas en las consultas
Evita SELECT *. Menos datos leídos, transferidos y serializados, y más posibilidades de usar un índice que cubra la consulta.
-
Pon timeout a las peticiones externas
Un servicio lento de terceros no debe colgar tu aplicación. Define un límite, reintenta con criterio y degrada con gracia.
Backend (5)
-
Manda las tareas lentas a una cola de trabajos
Correos, reportes o procesamiento de archivos se hacen en segundo plano. La respuesta al usuario es inmediata.
-
Arregla las consultas N+1
Una consulta para la lista más una por cada elemento escala mal. Resuélvelo con joins, carga anticipada (eager loading) o consultas por lote.
-
Transmite las respuestas de la IA en streaming
Muestra los tokens a medida que se generan. El usuario ve avance en segundos en lugar de esperar la respuesta completa.
-
Actualiza la interfaz sin esperar al servidor [optimistic UI]
Refleja el cambio de inmediato y confirma después. Si el servidor falla, revierte y avisa.
-
Usa un pool de conexiones
Reutiliza conexiones abiertas a la base de datos en vez de abrir una por petición. Evita el costo del handshake y protege a la base de saturarse.
Base de datos (4)
-
Cachea con Redis los datos más consultados
Los datos que se leen mucho y cambian poco se sirven desde memoria. Define cuándo expiran o se invalidan para no mostrar datos viejos.
-
Crea índices para las consultas más comunes
Un índice evita recorrer toda la tabla. Créalos según las consultas reales y revisa con EXPLAIN, porque cada índice encarece las escrituras.
-
Acerca el servidor a la base de datos [reduce latencia]
Si aplicación y base de datos están en regiones distintas, cada consulta paga ese viaje. Ubícalas en la misma región o zona.
-
Evita los joins innecesarios
Cada join suma costo. Une solo lo que necesitas y, cuando una lectura crítica lo justifique, considera desnormalizar o precalcular.
Medición y arquitectura (7)
-
Rastrea las peticiones lentas con OpenTelemetry
Trazas distribuidas muestran en qué servicio o consulta se va el tiempo. Sin medir, optimizas a ciegas.
-
Renderiza en el servidor [SSR] o estático
Enviar HTML ya armado mejora el primer render y el SEO. Si el contenido no cambia por usuario, genéralo estático.
-
Carga los scripts de terceros después de que cargue la página
Analítica, chats y píxeles con defer, async o tras la interacción. No deben competir con el contenido por el ancho de banda y el hilo principal.
-
Reparte el tráfico entre varias instancias [load balancing]
Un balanceador distribuye las peticiones y saca de rotación las instancias caídas. Más capacidad y mejor disponibilidad.
-
Monitorea la velocidad de usuarios reales [RUM]
Los datos de campo (Core Web Vitals de usuarios reales) muestran lo que las pruebas de laboratorio no ven: dispositivos, redes y regiones reales.
-
Prueba en celulares y redes lentas
Tu equipo de desarrollo no es el de tus usuarios. Prueba con CPU y red limitadas, y en dispositivos de gama media o baja.
-
Quita las dependencias que no estés usando
Cada paquete suma peso, superficie de ataque y mantenimiento. Audítalas y elimina lo que sobra.
Mide antes de optimizar: no todos los puntos aplican a todos los proyectos. Prioriza los que atacan el cuello de botella que muestran tus trazas y tus datos de usuarios reales.