Notas de Jose Jordan

El service worker que casi me la lía

Fri, 02 Oct 2026 16:30:00 GMT

Hace poco añadí a esta web una ventana nueva, Notas, la que lista las entradas de este blog. Tenía su icono en el escritorio, su botón en el dock y su comando en la terminal. Los tests pasaban en local y en GitHub Actions. Lo publiqué, abrí la web en mi navegador, pulsé el icono… y no pasó nada.

Ni un error en pantalla. Simplemente, nada.

El síntoma

El icono estaba: lo veía en el escritorio. Pero al pulsarlo la ventana no se abría. En un navegador limpio, en cambio, funcionaba perfectamente.

Esa combinación ya es una pista: si el HTML nuevo está ahí pero el comportamiento nuevo no, lo más probable es que el navegador esté mezclando versiones. HTML de hoy con JavaScript de ayer.

Y eso es justo lo que pasaba. El index.html nuevo traía el icono, pero mi navegador seguía ejecutando un script.js antiguo que no sabía nada de ninguna ventana Notas. El código buscaba la ventana, no la encontraba y no hacía nada. Silencio total.

"Pero si mi service worker pide primero a la red…"

Esta web es una PWA y tiene un service worker precisamente para que funcione sin conexión. Cuando lo escribí elegí la estrategia network-first: para cada petición, primero se intenta la red y solo si falla se usa la copia guardada. La idea era evitar exactamente este problema: que cada despliegue se viera al momento y nunca se mezclaran versiones.

El código era más o menos este:

async function networkFirst(request) {
    const cache = await caches.open(CACHE);
    try {
        const response = await fetch(request);
        cache.put(request, response.clone());
        return response;
    } catch (error) {
        return cache.match(request);
    }
}

Parece impecable. El problema está en una palabra: fetch(request) no significa "ve al servidor". Significa "consigue este recurso", y el navegador tiene su propia caché HTTP a la que puede recurrir antes de salir a la red.

La caché heurística

Cuando una respuesta trae una cabecera Cache-Control clara, el navegador obedece. Pero cuando no dice nada sobre cuánto tiempo se puede guardar, el estándar HTTP permite que el navegador decida por su cuenta. Es lo que se llama caché heurística: si el fichero lleva una fecha de última modificación, el navegador puede considerarlo válido durante una fracción del tiempo que lleva sin cambiar, típicamente un 10 %.

Un script.js que no cambia en un mes puede darse por bueno durante unos tres días sin preguntar a nadie.

En mi fichero _headers, el que le dice a Cloudflare qué cabeceras enviar, había reglas para las imágenes y las fuentes, pero ninguna para los scripts. El service worker hacía fetch(request), el navegador consultaba su caché HTTP, veía una copia "todavía válida" según su heurística y la devolvía sin llegar a preguntar al servidor. El network-first nunca llegaba a la red.

Reproducirlo (y tropezar por el camino)

Antes de arreglar nada quería ver el fallo en una prueba. Monté un servidor local que servía script.js sin Cache-Control y con una fecha de modificación antigua, y le añadía al final una marca de versión: A en la primera visita y B después de "desplegar".

La primera prueba, con Playwright, decía que seguía cargando A incluso con el arreglo puesto. Al contar las peticiones que llegaban al servidor, vi que en la segunda visita ni siquiera se pedía script.js. Chromium lo estaba sacando de su caché en memoria porque mi prueba navegaba otra vez dentro de la misma pestaña, algo que no pasa cuando un visitante vuelve días después.

Cambié la prueba para abrir una pestaña nueva, como haría una visita real, y entonces sí:

con el service worker antiguo, la página seguía ejecutando la versión A y la petición no llegaba al servidor;
con el arreglo, el servidor recibía la petición y la página cargaba la versión B.

Moraleja dentro de la moraleja: cuando una prueba de caché te dé un resultado raro, cuenta las peticiones que llegan al servidor antes de fiarte de ella.

El arreglo

La corrección principal es una sola opción en el fetch del service worker:

const response = await fetch(request, { cache: 'no-cache' });

no-cache no quiere decir "no guardes nada", aunque el nombre confunda. Quiere decir "puedes usar tu copia, pero pregunta antes al servidor si sigue valiendo". Si no ha cambiado, el servidor responde 304 Not Modified, una respuesta minúscula, y se usa la copia. Si ha cambiado, llega la versión nueva. El coste es casi nulo y desaparece la mezcla de versiones.

Para cubrir también las visitas que todavía no pasan por el service worker, añadí la misma instrucción a _headers para los ficheros que cambian en cada despliegue:

/script.js
  Cache-Control: no-cache
/styles.css
  Cache-Control: no-cache

Y subí la versión del service worker para que los navegadores que ya tenían el antiguo instalasen el nuevo.

Que no vuelva a pasar

Añadí un test que comprueba dos cosas: que el service worker hace sus peticiones con cache: 'no-cache' y que _headers incluye esa cabecera para los scripts y las hojas de estilo. Es un test sencillo, casi de texto, pero me avisará si un día alguien (probablemente yo) "limpia" esas líneas sin saber por qué están ahí.

Lo que me llevo

fetch() dentro de un service worker no garantiza ir a la red. Si quieres red de verdad, dilo con cache: 'no-cache' o cache: 'reload'.
Si no le dices al navegador cuánto puede cachear, lo decidirá él. Pon Cache-Control explícito a todo lo que cambie con cada despliegue.
"HTML nuevo, comportamiento viejo" casi siempre significa versiones mezcladas. Es lo primero que hay que mirar.
Los tests en un navegador limpio no ven este tipo de fallos. Hay que simular al visitante que vuelve.

Lo mejor de tener un blog es que este fallo, en vez de quedarse en un commit, se ha convertido en una nota. Si te ha pasado algo parecido, escríbeme con mail desde la terminal: me encantará leerlo.

The service worker that almost got me

Fri, 02 Oct 2026 16:30:00 GMT

I recently added a new window to this site, Notes, the one that lists the posts on this blog. It had its icon on the desktop, its button in the dock and its command in the terminal. The tests passed locally and on GitHub Actions. I deployed it, opened the site in my browser, clicked the icon… and nothing happened.

No error on screen. Just nothing.

The symptom

The icon was there: I could see it on the desktop. But clicking it did not open the window. In a clean browser, on the other hand, it worked perfectly.

That combination is already a clue: if the new HTML is there but the new behaviour is not, the browser is most likely mixing versions. Today's HTML with yesterday's JavaScript.

And that is exactly what was happening. The new index.html had the icon, but my browser was still running an old script.js that knew nothing about a Notes window. The code looked for the window, did not find it, and did nothing. Total silence.

"But my service worker goes to the network first…"

This site is a PWA and has a service worker precisely so that it works offline. When I wrote it I chose a network-first strategy: for every request, try the network first and use the saved copy only if that fails. The whole point was to avoid this very problem: every deploy should show up immediately and versions should never mix.

The code looked roughly like this:

async function networkFirst(request) {
    const cache = await caches.open(CACHE);
    try {
        const response = await fetch(request);
        cache.put(request, response.clone());
        return response;
    } catch (error) {
        return cache.match(request);
    }
}

It looks flawless. The problem is in one word: fetch(request) does not mean "go to the server". It means "get me this resource", and the browser has its own HTTP cache that it can use before going out to the network.

Heuristic caching

When a response carries a clear Cache-Control header, the browser obeys it. But when the response says nothing about how long it may be kept, the HTTP standard lets the browser decide for itself. This is called heuristic caching: if the file has a last-modified date, the browser may treat it as fresh for a fraction of the time since it last changed, typically 10%.

A script.js that has not changed for a month can be considered good for about three days without asking anyone.

My _headers file, which tells Cloudflare which headers to send, had rules for images and fonts, but none for the scripts. The service worker called fetch(request), the browser checked its HTTP cache, saw a copy that was "still fresh" according to its heuristic and returned it without ever asking the server. Network-first never reached the network.

Reproducing it (and tripping on the way)

Before fixing anything I wanted to see the bug in a test. I set up a local server that served script.js without Cache-Control and with an old modification date, and appended a version marker to it: A on the first visit and B after "deploying".

The first Playwright test said it was still loading A, even with the fix in place. When I counted the requests reaching the server, I saw that on the second visit script.js was not even requested. Chromium was taking it from its in-memory cache because my test navigated again inside the same tab, something that does not happen when a visitor comes back days later.

I changed the test to open a new tab, like a real visit, and then it was clear:

with the old service worker, the page kept running version A and the request never reached the server;
with the fix, the server got the request and the page loaded version B.

A lesson inside the lesson: when a cache test gives you a strange result, count the requests that reach the server before trusting it.

The fix

The main fix is a single option on the service worker's fetch:

const response = await fetch(request, { cache: 'no-cache' });

Despite its confusing name, no-cache does not mean "do not store anything". It means "you may use your copy, but ask the server first whether it is still valid". If nothing changed, the server answers 304 Not Modified, a tiny response, and the copy is used. If it changed, the new version arrives. The cost is almost zero and mixed versions are gone.

To also cover visits that do not go through the service worker yet, I added the same instruction to _headers for the files that change on every deploy:

/script.js
  Cache-Control: no-cache
/styles.css
  Cache-Control: no-cache

And I bumped the service worker version so that browsers with the old one installed would pick up the new one.

Making sure it does not happen again

I added a test that checks two things: that the service worker makes its requests with cache: 'no-cache' and that _headers includes that header for the scripts and stylesheets. It is a simple, almost textual test, but it will warn me if someone (probably me) ever "cleans up" those lines without knowing why they are there.

What I take away

fetch() inside a service worker does not guarantee going to the network. If you really want the network, say so with cache: 'no-cache' or cache: 'reload'.
If you do not tell the browser how long it may cache something, it will decide for you. Set an explicit Cache-Control on everything that changes with each deploy.
"New HTML, old behaviour" almost always means mixed versions. It is the first thing to check.
Tests in a clean browser do not catch this kind of bug. You have to simulate the returning visitor.

The best thing about having a blog is that this bug, instead of staying buried in a commit, became a note. If something similar has happened to you, write to me with mail from the terminal: I would love to read it.

Cómo está hecha esta web

Fri, 02 Oct 2026 08:00:00 GMT

Quería que mi portfolio fuera algo más que una página con mi CV: un sitio que se pudiera usar. Por eso josejordan.dev es un pequeño escritorio con su barra de menú, sus iconos, un dock y una terminal desde la que puedes ver mi experiencia, mis proyectos o escribirme.

Sin dependencias y sin build

Todo es HTML, CSS y JavaScript "a pelo". No hay framework, ni node_modules, ni proceso de compilación: los ficheros del repositorio son exactamente los que se publican. La única fuente es JetBrains Mono, alojada en la propia web.

Esto tiene ventajas muy prácticas:

La web carga rápido y no depende de que una librería siga mantenida dentro de cinco años.
Cualquier cambio se entiende leyendo un solo fichero.
Se puede alojar en cualquier sitio que sirva ficheros estáticos.

Un gestor de ventanas en unas pocas funciones

Cada ventana (la terminal, Proyectos, Contacto, el Buscaminas y estas Notas) es un elemento HTML con una cabecera y unos botones. Un pequeño gestor en script.js se encarga de:

Arrastrarlas con Pointer Events, para que funcione igual con ratón y con el dedo.
Traer al frente la que pulsas.
Minimizarlas al dock, cerrarlas y maximizarlas.

En el móvil las ventanas pasan a ocupar la pantalla, porque arrastrar ventanas en 6 pulgadas no tiene sentido.

La terminal

La terminal tiene más de veinte comandos: about, projects, experience, cv, mail, theme, neofetch… y alguno escondido. Tiene historial con las flechas, autocompletado con Tab y sugerencias cuando te equivocas al escribir.

Todo el contenido vive en content.js, separado de la lógica, y toda la salida se construye con nodos del DOM, nunca con innerHTML, así que lo que escribas en la terminal no puede inyectar HTML.

Dos idiomas sin duplicar código

La versión en español está en / y la inglesa en /en/. Un script mínimo detecta el idioma del navegador (o el que elegiste) y te lleva a tu versión, sin redirigir nunca a Google ni a las vistas previas de las redes sociales, para que cada versión se indexe en su dirección.

Seguridad: una CSP estricta

La web se sirve con una Content Security Policy que solo permite scripts y estilos de la propia web. Nada de