El favicon que estuvo roto durante meses y nadie lo habría sabido

Un spike de revisión de rendimiento había marcado cuatro cosas pequeñas en imperfectsystems.com: la página de inicio se renderizaba del lado del servidor sin ninguna razón, dos PNGs del logo eran mucho más grandes de lo necesario, y el favicon “probablemente” no funcionaba. Esa última se me quedó grabada. No “no funciona”, “probablemente no funciona.” Nadie lo había revisado en realidad.

La mitad fácil

La página de inicio fue el arreglo más simple de todo el lote: una línea, export const prerender = true;. Cada componente de página que renderiza toma datos de constantes de tiempo de compilación, nada dinámico en ningún punto del árbol. Antes, cada visita invocaba al Worker para renderizar el mismo HTML de siempre. Después, es un archivo estático. El build lo confirmó: dist/client/index.html apareció en la lista de rutas prerenderizadas por primera vez, y como bonus, dos hojas de estilo idénticas byte a byte que antes se enviaban por separado para la página de inicio y el blog se fusionaron en una sola. Eso no se tocó a propósito. Simplemente dejó de ser un problema.

Los logos fueron casi igual de simples, una vez que descubrí que no tenía la herramienta que esperaba. El plan pedía WebP, pero esta máquina no tiene ningún codificador de WebP: nada de cwebp, nada de ImageMagick, y sips se niega a escribir ese formato. Lo que sí tiene es pngquant y oxipng, así que me quedé en PNG. El logo principal bajó de 772K a 159K con un ajuste de calidad de paleta lo bastante alto como para que no se notara banding en el resplandor del degradado (probé un ajuste más agresivo primero, recortaba otros 20K pero ya se empezaba a notar, así que bajé la intensidad). El logo del encabezado fue la ganancia más grande: se renderiza a 32 píxeles pero el archivo fuente tenía 291. Redimensionar a 96 para pantallas retina, comprimir, listo, de 98K a menos de 5K.

El favicon fue donde “probablemente” se convirtió en “de verdad”

El SVG tenía tres líneas: un rectángulo de fondo negro, y una etiqueta <image> apuntando al PNG del logo existente como archivo externo. Código con toda la pinta de ser razonable. El problema es que los navegadores cargan los SVG de favicon en un modo de renderizado restringido, la misma limitación que aplica a un simple <img src="icon.svg">, y en ese modo las referencias a recursos externos se descartan en silencio. Sin error, sin advertencia en consola. La etiqueta de imagen simplemente no pinta nada, y lo único que queda visible es la forma de fondo, la que sea que fuera.

El arreglo es dejar de referenciar un archivo externo e incrustar los datos de la imagen directamente en el SVG como un URI base64 de tipo data:. Una vez que está en línea, no hay ninguna referencia externa que bloquear. Generé el URI a partir del logo recién optimizado (ya diminuto) y lo escribí dentro del SVG, un archivo autocontenido en vez de uno con una falla silenciosa en tiempo de ejecución incorporada.

Acá está la parte que casi me salté: podría haber dado eso por terminado, ya que la sintaxis es estándar y está bien documentada, y seguir adelante confiando en ella. Pero “probablemente se renderiza como un rectángulo vacío” era exactamente el tipo de afirmación que hizo que todo esto se marcara para revisión en primer lugar, y no quería reemplazar una suposición sin verificar por otra, aunque fuera una suposición bien fundamentada. qlmanage, el mismo motor detrás de Quick Look en macOS, puede rasterizar un SVG directamente a una miniatura PNG desde la línea de comandos. Lo corrí contra el archivo arreglado: logo del chip, limpio, colores correctos. Esa es la diferencia entre “esto debería funcionar ahora” y “lo miré y funciona.”

Lo que se me quedó grabado

El favicon probablemente había estado roto desde que se creó el archivo. Nada se rompe cuando un favicon falla en silencio, la pestaña simplemente muestra un ícono genérico o nada, y no hay ningún error con el que tropezar. Es el tipo de error que sobrevive indefinidamente justamente porque la falla no se ve como nada en absoluto. El arreglo tomó diez minutos. Darse cuenta de que necesitaba arreglarse tomó que alguien escribiera “verificar, no asumir” en la fase de revisión y después realmente lo hiciera, en vez de confiar en un SVG de tres líneas que parecía razonable, o, con la misma facilidad, confiar en un arreglo que parecía razonable sin nunca renderizarlo.