← Cases Speed 16–22 Oct 2026 · PageBrick 1.8.0 and theme 2.2.0
From a PageSpeed report to the fix
pagebrick.org runs on PageBrick, so its PageSpeed report is the product’s own report. In under a week the mobile score went from 95 to 98 and the biggest finding disappeared, measured the same way on the same page. Two secondary numbers got worse, and they are in this case too.
- 98Mobile performance, up from 95 (PageSpeed Insights, 16 → 22 Oct 2026)
- 2.2 sLargest Contentful Paint on mobile, down from 2.9 s
- 410 → 0KiB the browser downloaded again on every visit (the cache finding, mobile)
- 176 → 59KiB of image savings still suggested on mobile
The problem
On 16 October 2026 the site scored 100 on desktop and 95 on mobile. The report listed three things: static files came with no cache lifetime (410 KiB downloaded again on every visit, on mobile), the hero picture was sent at 1400 × 1045 pixels and shown at 372 × 278 (165 KiB), and no picture had a srcset. Part of this was the theme and part was the core, so a fix in only one place would not have been enough.
The decision
Two stages, theme first. Stage 1, theme 2.2.0: every picture got smaller copies with a srcset; the first picture of the page is asked for first; the entrance animation that hid it for about a second now moves instead of fading; the two fonts are asked for together with the page; and the serif font was cut from 132 KB to 86 KB.
Stage 2, PageBrick 1.8.0: a switch in Settings writes browser-cache lines at the end of .htaccess (a year for files whose address changes with the file, a week for the rest), and every new photo keeps a 960-pixel copy.
The promise to existing sites shaped the details. The HTML a theme already prints must not change, so a srcset is something a theme asks for (img(sizes: …)), never something the core adds. And because an update never touches .htaccess, sites installed before get the cache with a button, which checks the site afterwards and takes the lines out by itself if the host answers with an error.
The proof
Before shipping, a fresh install was measured with Lighthouse: with the cache lines off, the report flagged 9 files (240 KiB); with them on, that audit passed. On a 375-pixel phone at double density the browser chose the 960-pixel copy: 8.6 KB instead of 19.7 KB for the test photo. The update from 1.7.1 to 1.8.0 was run in a real browser, 31 of 31 checks, including pressing the cache button on a site installed before and turning it off again to get the .htaccess back byte for byte. Then the live site was measured again with the same tool.
The result
On 22 October the mobile score was 98 (from 95) and Largest Contentful Paint 2.2 s (from 2.9 s). The cache finding is gone, and the image finding fell from 176 KiB to 59 KiB on mobile. Desktop stayed at 100.
Not everything improved. On mobile, First Contentful Paint went from 0.9 s to 1.1 s and Speed Index from 2.1 s to 3.3 s; on desktop, Largest Contentful Paint went from 0.4 s to 0.5 s and Speed Index from 0.7 s to 1.1 s. PageSpeed varies between runs, so the fair reading is: the points that matter here (largest paint, cache, image weight) moved the right way, a few secondary metrics moved the wrong way, and the next items on its list are 5 KiB of CSS and one animation that is not composited.
What stayed
A speed report is only proof if the same test runs before and after, on the same page, and the numbers that got worse are published too.