sifg.net · Detrás de la web
Cómo hicimos más rápida sifg.net
Medimos antes de tocar nada, encontramos trabajo oculto en cada clic y lo arreglamos paso a paso. Te contamos cada mejora, cómo la descubrimos y cómo comprobamos que funcionaba.
Los resultados, de un vistazo
La misma web.
Menos espera.
Nuestra web es estática. Las páginas se generan ya terminadas antes de publicarlas, está desplegada en Cloudflare y está disponible en 8 idiomas: las traducciones se generan al compilar (es decir, al preparar la web para publicarla) a partir de las páginas en español.
Para hacerla más rápida partimos de tres ideas: medir antes de tocar nada; buscar «navegaciones ocultas», el trabajo que no ves pero que te cuesta tiempo; y adelantarse a lo que vas a abrir.
Lo hicimos en una sola sesión de trabajo. Cada mejora va contada igual: el problema, cómo lo descubrimos, el arreglo y cómo lo comprobamos. Al final están las cifras.
01 / Antes de empezar
Una red de seguridad y una lupa
Primero, poder volver atrás
Antes de cambiar nada creamos una copia de seguridad de la web, para poder volver atrás en cualquier momento, y guardamos una compilación de la versión anterior para compararla después con la nueva en las mismas condiciones.
Qué miramos
Revisamos la web publicada y su compilación con herramientas sencillas y tres preguntas:
Salieron cinco problemas. Ninguno era grave, pero todos se repetían en cada visita.
02 / Navegación oculta n.º 1
El rodeo invisible de cada clic
El problema
Una redirección es un desvío: pides una dirección y el servidor responde «ve a esta otra», lo que obliga a una segunda petición. Nuestros enlaces internos apuntaban a /productos/lumen, pero el servidor tenía la página en /productos/lumen/, con una barra al final.
Cómo lo descubrimos
Al revisar las cabeceras de la web real vimos que cada clic interno pasaba primero por una redirección de entre 90 y 140 milisegundos. Nadie lo notaba, pero se pagaba en todas las navegaciones: una navegación oculta de manual.
El arreglo
Cambiamos cómo se generan las páginas. Ahora cada una es un archivo (lumen.html) en vez de una carpeta con un index.html dentro, y el servidor la entrega en la misma dirección a la que enlazamos. Las direcciones antiguas con barra final siguen funcionando, así que no se rompen marcadores ni resultados de buscadores.
03 / Navegación oculta n.º 2
La página que llegaba dos veces
El problema
Si tu navegador estaba en otro idioma, la web cargaba primero la página en español y después saltaba a la traducida: dos cargas para ver una sola página. Además, el script que decidía el salto esperaba a que se descargaran estilos y fuentes.
Cómo lo descubrimos
En el mismo repaso: cada entrada empezaba descargando una página que el visitante no iba a leer.
El arreglo
Ahora decide el servidor. Una pequeña función en Cloudflare mira tu elección guardada o el idioma de tu navegador y te envía a la versión correcta antes de mandar un solo byte de la página en español. Solo se ejecuta en las páginas que lo necesitan, no con cada imagen. Siempre respeta una dirección que ya lleva idioma y no redirige a los buscadores.
El script del navegador queda como red de seguridad, ahora al principio del documento, para decidir antes de pedir estilos, fuentes o imágenes.
04 / Trabajo repetido n.º 1
Archivos que nunca cambian, pedidos una y otra vez
El problema
La caché es la memoria del navegador: guarda archivos ya descargados para no volver a pedirlos. Nosotros le decíamos «no guardes nada» para todo.
Incluso los archivos CSS (estilos) y JavaScript (código) cuyo nombre lleva un hash, una huella calculada a partir del contenido: si el contenido cambia, cambia el nombre, así que esos archivos nunca cambian. Aun así, el navegador volvía a pedirlos en cada página.
Cómo lo descubrimos
Estaba escrito en las cabeceras HTTP de todos los archivos.
El arreglo
Cada tipo de archivo tiene ahora la memoria que le corresponde:
05 / Trabajo repetido n.º 2
25 KB de código copiados en cada página
El problema
Unos 25 KB de JavaScript (el menú, el buscador y el cambio de tema claro/oscuro) iban dentro del HTML de cada página, en los 8 idiomas. Viajaba de nuevo con cada página en vez de vivir en un archivo que el navegador reutiliza.
Cómo lo descubrimos
Aquí medir nos corrigió a nosotros. Nuestra primera sospecha sobre el peso del HTML fue el índice del buscador. Al medirlo, vimos que solo ocupaba 4 KB: el resto era código.
El arreglo
Movimos ese JavaScript a un archivo aparte que el navegador guarda en caché entre páginas. Los textos que se traducen, como «Sugerencias» o «1 resultado», siguen dentro de la página para que el sistema de traducción los encuentre. Y salió un extra: un texto que nunca se traducía ahora sí se traduce.
06 / Trabajo repetido n.º 3
Una tipografía que venía de fuera
El problema
La tipografía Inter venía de Google Fonts: dos dominios externos y una hoja de estilos que retrasaba el primer pintado, el momento en que aparece algo en pantalla.
Cómo lo descubrimos
Lo vimos al listar los dominios a los que se conectaba cada página.
El arreglo
Ahora servimos Inter desde nuestro propio dominio, en su versión variable: un solo archivo que contiene todos los pesos, de la fina a la negrita. Y precargamos (pedimos cuanto antes) la parte que usan nuestros idiomas.
07 / Adelantarse
Preparar la página antes del clic
La idea
Quedaba la tercera idea: adelantarse. Prerenderizar es preparar una página entera (descargarla y dibujarla) en segundo plano, antes de que la abras. Si aciertas, al hacer clic ya está lista.
El arreglo
Usamos Speculation Rules, un estándar web: un bloque de reglas en JSON dentro de la página, sin librerías. Simplificado, es esto:
<script type="speculationrules">
{
"prerender": [{
"where": { "href_matches": "/*" },
"eagerness": "moderate"
}]
}
</script>Con "eagerness": "moderate", la página de destino se prepara cuando el ratón se queda un momento sobre un enlace interno, o cuando empiezas a tocarlo en el móvil. Excluimos los enlaces a archivos, como descargas o imágenes, y los que abren una pestaña nueva.
Antes comprobamos que la web no carga analítica, que podría contar visitas falsas por páginas preparadas que nadie abre.
Funciona en los navegadores basados en Chromium, el motor en el que se apoyan Chrome, Edge y otros. Safari y Firefox ignoran las reglas sin que se rompa nada.
08 / Medir para no arreglar
Lo que decidimos dejar como estaba
Pensábamos añadir medidas a las imágenes para que el contenido no se moviera al cargar. Ese movimiento se mide con el CLS (Cumulative Layout Shift, o desplazamiento acumulado del diseño): cuanto más cerca de 0, más quieta está la página.
Las mediciones dieron entre 0,003 y 0,01. Las imágenes ya van en contenedores de proporción fija que les reservan su hueco, así que lo dejamos como estaba. Medir también sirve para saber qué no hay que tocar.
09 / Bonus
Publicar también es más rápido
El problema
Cada despliegue (cada publicación de una versión nueva) tardaba unos 4 minutos.
Cómo lo descubrimos
Reprodujimos el problema clonando el proyecto desde cero: en cada despliegue se volvían a convertir 79 imágenes a AVIF y WebP, dos formatos modernos que ocupan menos.
Al clonar un proyecto, Git (la herramienta con la que guardamos el historial del código) pone a cada archivo como fecha de modificación el momento en que lo escribe. El script, al comparar fechas, creía que todas las imágenes estaban desactualizadas.
El arreglo
En el servidor de compilación solo se generan las imágenes que faltan.
10 / Método
Cómo comprobamos que funcionaba
Una mejora sin comprobar es solo una suposición. Nuestro método:
También descartamos lo que no era fiable. El «tiempo de bloqueo» de Lighthouse variaba de 0 a más de 1.000 ms entre pasadas idénticas, tanto en la versión antigua como en la nueva. Con ese ruido no lo usamos, ni damos una puntuación global.
11 / Las cifras
Los resultados
Dos términos antes de la tabla. El primer contenido visible es el momento en que aparece el primer texto o imagen. El elemento principal, o LCP (Largest Contentful Paint), es cuándo se pinta el elemento más grande de la pantalla, normalmente la imagen o el titular. Medidas de laboratorio, en móvil con 4G simulado.
| Medida | Antes | Después |
|---|---|---|
| Primer contenido visible, portada | 3,2 s | 2,0 s−38 % |
| Primer contenido visible, página de producto (Lumen) | 3,0 s | 2,1 s−30 % |
| Primer contenido visible, página de descarga | 3,1 s | 2,2 s−28 % |
| Elemento principal (LCP), página de producto | 3,0 s | 2,3 s−24 % |
| Elemento principal (LCP), página de descarga | 3,1 s | 2,4 s−22 % |
| Pasar de una página a otra (caché llena) | 770 ms | 518 ms−33 % |
| Peticiones al servidor en ese cambio de página | 7 | 3 |
| Dominios contactados para cargar una página | 3 | 1 |
| Tamaño del HTML de la portada | 92 KB | 68 KB |
| Paso de imágenes en cada despliegue | 1 min 25 s | 0,6 s |
Además, con el prerender activo, el cambio de página debería ser prácticamente instantáneo en Chrome y Edge, aunque no pudimos medirlo con una cifra.
12 / Siendo honestos
Lo que aún nos queda
La imagen principal de la portada sigue tardando en móviles con conexión lenta. El siguiente paso es servir imágenes más pequeñas en el móvil.
Entrar sin «www». Queremos que quien escribe el dominio sin «www» llegue sin pasar por redirecciones intermedias.
Medir con usuarios reales. Todas nuestras cifras son de laboratorio. Queremos medir también con visitas reales, con una herramienta que no use cookies.
La lección
Medir primero.
Arreglar lo que dicen los datos.
Lo que nos llevamos es un orden: medir primero, arreglar lo que los datos señalan (y no lo que creíamos), comprobar que la mejora es real y contar también lo que no ha funcionado o queda pendiente.
Una barra al final de una dirección costaba tiempo en cada clic, el peso no estaba en el buscador y las imágenes no necesitaban arreglo. Seguiremos midiendo.
Visitar sifg.net ← Volver a las noticias