The Website Changed. The Story Didn't.

On 24 October 2026 littlebluepilot.com was rebuilt on a different framework and stayed where it was. Every address it had still works, and apart from what the owner chose to change that day, its 57 public pages kept their titles, descriptions, share cards and structured data. The lyrics on all eleven song pages are the same as they were, byte for byte. The site also took on a new look the same day (warm paper by day, and night where the story is night), which is the part a visitor can see. This entry is about the part they cannot.

What it was moving from

The old site was already static. It was a Next.js 16 application with React 19, exported to plain files at build time: no server, no database, no accounts. On Lighthouse’s desktop profile it scored 95 to 99, and 100 for accessibility.

The project’s records say what the move had to keep and how it would be checked. They do not record a single reason for making it, and this entry does not supply one. What can be shown is what the new architecture does differently, and what changed as a result.

The engineering case is straightforward. The old site carried a framework made for applications, on a site that is mostly reading. A static export of a Next.js site still sends React and the framework’s router to every page, with a serialised copy of the page’s component tree written into the page as inline scripts, so that navigation and the interactive components can work in the browser. On this site most of that arrived with little to do: a storybook chapter, a song’s words and a flight note are pages to read. The parts that genuinely respond to a child are specific. The menu, the share button and the theme song’s player are on every page; the rest are pages built to be played with, such as Ask Little Blue, the Hangar, the Sky Map, the Playroom’s games, the Workshop’s editors and the colouring page.

Astro’s model fits that shape, and four outcomes of the move are documented:

• Static delivery. Every page is rendered to HTML when the site is built.
• Less script in the browser. Script is sent only for the islands that need it. The site’s security policy allows only scripts it has seen at build time, each by its own fingerprint, so it has to list every inline script on every page: the old export needed 231, the rebuild needs 10.
• Offline for the whole site. One service worker now keeps the core pages of the site, where the old one kept a single page.
• A build that checks more. The rebuild fails on things that would otherwise only go wrong on the live host, described below.

That is a judgement about this site, a site for reading with a few things to play, and not a verdict on either framework. A site that was mostly application would have pulled the other way.

Parity first, taste second

The rule for the move was parity before anything else. The old site was exported fresh on the day of the move, and a script recorded, for every route, its title, meta tags, canonical, icons, structured data, heading, links, files and the pictures it asked the browser to load first. Every page of the rebuild was then compared with that record.

To make the comparison mean something, the stylesheets were first copied across unchanged. A port that changes the look at the same time as the code can only be checked by taste; a port that keeps the look can be checked route by route. Only once the comparison passed did the redesign begin, and it changed styles with the addresses, the words and the markup held still.

The comparison has 61 rows. 58 pass, and every difference among them is written down with its reason; one page is new (the page a reader sees offline), and two rows are artefacts of the old framework that were not carried across. None fails. One address did move, on the owner’s decision during the move: the first record’s page now lives at its own name, and its old address answers with a permanent redirect. The build refuses to produce a page at the old address, so there can never be two copies of it for a search engine to choose between. Across the 59 built pages, all 11,981 internal links and every anchor they point at resolve.

Where the words live

Astro has content collections, a structured way to keep text in files with a schema the build checks. The obvious move was to put everything into them. The rebuild did not, on purpose.

The songs already had one place that reads and checks them: it holds every lyric against the chapters, every picture against the files on disk, and every note against the phrase it annotates. Parsing the same files a second time, through a collection, would have made two sources of truth for one set of words. The flight notes stayed in their pages for a related reason: Ask Little Blue checks its answers against the notes’ own text, and that check reads it from the pages.

The lesson generalises less than it sounds. Collections are a good default for new writing. Moving text that already has a validator into a second system is a cost, not a tidy-up.

One thing on every page

Astro can send a small router to every page, so that moving between pages does not reload the document. The rebuild uses it for one reason the old site already had: the theme song keeps playing while a child moves around the site. Without script, or in a browser without the view-transitions feature, links are ordinary page loads.

It has a cost, and the audit after launch measured it. On Lighthouse’s slowed phone profile the homepage spends about one and a half seconds in style and layout, and one long task of about 450 ms is the router’s, almost all of it style and layout rather than script. The likely causes are broad selectors that make the browser re-check the whole page on any change, a large homepage and a blurred header. The router stays, because the music is part of the site; the next step is a performance trace, not a guess.

Offline, for the whole site

The old site kept one page offline: Ask Little Blue, with a small service worker of its own that held 55 files, about 3.7 MB. The rebuild has one worker for the whole site. After a first visit, the homepage, the music, both records’ pages and every song’s page, the storybook and Ask Little Blue open with no connection, and other pages are kept as a reader opens them, up to the last 80 pages and 400 of their files. Sound and film are never kept.

A new worker also has to retire the old one, which was still installed in families’ browsers. The old worker’s address now serves a replacement whose only job is to clear its own copy, unregister itself and reload the page, so the next load is served by the new site. It stays in place for as long as a reader might come back with the old one.

The privacy page states how much the offline copy downloads, and the build fails if the real figure drifts more than a quarter of a megabyte from what the page says. The figure itself is the main limitation of the design so far: the first visit fetches about 7 MB in the background, more than a phone should spend without being asked. Making that first download smaller, without giving up the pictures or the pages that work offline, is the open question in the site’s offline work. How the worker is built is written up in Building offline-first experiences for families.

Note added 30 October 2026: on 28 October the site stopped downloading its offline copy on a first visit. The worker is now registered only when a reader chooses “Save for offline” in the site’s reading preferences; what it keeps, and the rules above, are unchanged. Measured on 30 October, a visit saves nothing until that button is pressed, and the copy it then keeps is 132 files, about 6.2 MB. A browser that received the worker before 28 October keeps it until it is cleared from the same preferences. The change is described in Offline, only when asked.

Accessibility, held rather than redone

The old site’s twenty browser audits came across and were adapted where they named the old framework’s mechanisms. None was weakened to let the rebuild pass. Four checks turned out to be wrong already: they described behaviour the old code had stopped having, and the old export failed them too. Those were corrected to check what the code does, which is its own small lesson about tests that nobody has watched fail.

Contrast was measured from rendered pixels on every restyled page, at phone and desktop widths, with no text under 4.5:1. Every target on the restyled pages is at least 44 pixels on a phone, every interactive part was checked by keyboard, and each page was read with reduced motion, without JavaScript, and at widths from 320 to 1440 pixels. The audit of 25 October then ran axe over every page at two widths, 120 page loads, and found no real failures. It also found three places where a control is smaller than the 24 pixels the accessibility guidelines ask for, which the earlier checks had missed.

What the measurements say

Both builds were measured on the same machine, one after the other, on 24 October: Lighthouse 13.5 with its slowed phone profile, three runs of each page, median shown.

Page, phone profile	Rebuild	Old site	Largest paint, rebuild / old
Home	84	79	4.1 s / 4.7 s
Music	80	79	4.6 s / 4.7 s
A song page	81	81	4.3 s / 4.5 s
Storybook	80	73	4.9 s / 5.6 s
Ask Little Blue	88	79	3.0 s / 4.7 s
Workshop	81	77	4.6 s / 5.1 s

The rebuild was equal or better on all six pages, and its largest paint was earlier on all six. On the desktop profile the rebuild scored 98 to 100 and the old site 95 to 99. One number went the other way: Ask Little Blue’s blocking time rose, from 97 to 294 ms. Single runs on that machine swung by 10 to 20 points, which is why the table shows medians, and none of this is field data from real phones.

The live site was measured again on 25 October, five runs each. The homepage scored a median of 87 on the phone profile with its largest paint at 2.3 seconds, and 100 on the desktop. A flight note scored 79. The picture at the top of every note, the largest thing on a phone’s first screen, was being loaded lazily, so the browser waited 432 ms before asking for it. Loaded eagerly and at high priority, it now waits 22 ms. The note’s largest paint on the phone profile is still about 4.2 seconds, and the next step is a smaller cut of that picture: a phone fetches 93 KB where about 60 would do. The pictures further down each note are now given their source only as the reader nears them, with a plain copy for browsers without script, and measured in one sitting they no longer cost anything at load.

What the move taught

• Check a port against a record, not against memory. The route-by-route comparison found more than any reading of the code would have.
• Keep the look still while the code moves. Separating the port from the redesign is what made the port checkable.
• Let the build refuse what the host would refuse. The security policy forbids inline event handlers, and Svelte, rendering a picture whose attributes are passed through, writes one into the markup. A browser would have blocked it only on the real host, so the build now fails on any inline handler.

The limits that remain

• The offline copy’s first-visit download, about 7 MB.
• Style and layout time on phones, which needs a performance trace.
• Real devices, Firefox and Safari’s engine: the checks so far ran in one browser engine on one machine.

Note added 30 October 2026: the first of these limits no longer applies. The site downloads its offline copy only when a reader asks for it (see the note under “Offline, for the whole site”).

For a child, nothing that mattered moved. The chapters, the songs and their words are where they were, at the addresses they had. What changed is underneath: less script, one offline worker instead of two, and a build that checks more of its own promises before anything goes live.