De 1,7 MB a menos de 300 KB: la optimización de este mismo sitio

La versión anterior de este sitio pesaba 1.698 KB. Lo medí, no lo estimé. Y era el sitio de alguien que ofrece "optimización de rendimiento" como servicio, lo cual lo hacía peor.

Este es el detalle de qué encontré y qué hice, con los números de cada paso.

Qué pesaba

El 99% del peso del sitio eran cuatro imágenes. Una sola —un PNG decorativo usado como fondo de una tarjeta— pesaba más de un megabyte.

1. Las imágenes: −96%

Tres problemas al mismo tiempo:

• Formato equivocado. PNG es para gráficos con transparencia, no para fotos. Para una foto, PNG puede pesar diez veces más que WebP con la misma calidad visible.
• Tamaño equivocado. La imagen tenía muchos más píxeles de los que se mostraban en pantalla. El navegador la descargaba entera para después achicarla.
• Sin compresión. Guardada al 100% de calidad, cuando entre 72 y 80 es indistinguible a simple vista.

La solución fue redimensionar al tamaño real de uso, convertir a WebP con calidad 72 y dejar un JPEG como respaldo para navegadores viejos. De 1.681 KB a 69 KB.

2. Una librería de iconos entera para usar tres

El sitio cargaba boxicons.min.css desde un CDN externo. Esa hoja de estilos define miles de iconos. Se usaban tres.

Además de peso, tenía dos costos peores: bloqueaba el renderizado (el navegador no dibujaba nada hasta terminar de descargarla) y dependía de un servidor de terceros que si está lento, tu web está lenta.

La solución fue reemplazarlos por SVG escritos directamente en el HTML. Cero peticiones externas, cero bloqueo, y unos pocos cientos de bytes.

3. Las fuentes bloqueaban la primera pintura

El sitio cargaba tres familias tipográficas con doce variantes de peso desde Google Fonts, de forma bloqueante.

Dos cambios simples: pedir solo los pesos que realmente se usan (de doce a siete), y cargar la hoja de forma no bloqueante, de manera que la página se dibuje con una fuente del sistema y cambie cuando la tipografía llegue.

4. Cosas que no pesan pero rompen

Aprovechando la reconstrucción, dos correcciones que no son de peso pero afectaban la experiencia:

• cursor: none global. El sitio ocultaba el puntero del sistema y dibujaba uno propio con JavaScript. Si el JS fallaba o tardaba, el usuario se quedaba sin puntero visible. Ahora solo se activa cuando el JS confirmó que corre y hay un mouse real.
• Contraste por debajo del mínimo. El color de los textos secundarios daba 3,0:1 sobre el fondo, cuando el mínimo accesible es 4,5:1. Y ese color se usaba justo en el subtítulo principal. Ahora está en 6,0:1.

Qué te llevás de esto

Si tenés una web lenta, arrancá por las imágenes. En la enorme mayoría de los casos son el 90% del problema y es lo más barato de arreglar: no requiere rehacer nada, solo procesarlas bien.

Después mirá qué está cargando tu sitio desde servidores de terceros. Cada uno es una dependencia que puede fallar o demorar.

Y medí antes de tocar. Sin el número de antes, no podés demostrar la mejora.