I ran PageSpeed Insights on the site recently, mostly out of curiosity. I had built the site to be simple: static HTML, a small CSS payload, minimal JavaScript. I wanted to see whether the report agreed with that or had something to say about it.

What came back

The report flagged a few things. Render-blocking CSS, inefficient cache lifetimes, document request latency. At first glance it reads like a list of failures, but I found most of it less alarming on closer inspection.

The render-blocking CSS finding was the one I looked at first, partly because 440ms of potential savings sounds significant. Two stylesheets load in the document head and block rendering until they are parsed. But PageSpeed runs its tests with a cold cache, simulating a first visit with nothing cached. A returning reader already has both files in the browser cache and nothing is blocking anything. The problem only applies to a visitor who has never loaded the site before.

Looking at the finding made me think more carefully about the architecture. The site runs on GitLab Pages behind Cloudflare. Static assets get cached at the CDN edge, so a returning reader loads CSS from a nearby node without a round trip to the origin. For that reader the render-blocking finding is not a real issue. The cold start for a first visit is a known cost of this setup, not something I feel a strong need to engineer around. Inlining the CSS or lazy-loading it would both trade that one-time cost for different ongoing problems: inlining means every HTML response carries the full stylesheet payload with no separate caching; lazy loading risks a flash of unstyled content. Neither felt worth it. Extending the cache TTL means the cold start happens less often and matters less when it does.

The cache TTL finding connects to this. Static assets currently expire after one hour, which means someone coming back the next day will redownload CSS and JavaScript that has not changed. Extending that expiry is a straightforward config change and would make the render-blocking finding less meaningful for the small fraction of visitors it actually affects.

The finding I found most interesting

The HTML document itself took 673ms to load in the test. Cloudflare proxies the site and caches static assets at the CDN edge, but it does not cache HTML pages by default. So every request for a page travels all the way back to the origin server on the VPS. The CSS arrives quickly from a nearby Cloudflare node, but the page that references it makes a full round trip each time.

This was not something I had thought carefully about before. The fix is a configuration change at Cloudflare to enable HTML caching at the edge, and I think it would have more impact on actual load times than anything in the CSS path. I also checked the redirect chain while I was here: HTTP to HTTPS in a single hop. Nothing to tidy.

Still to do

I have not made either of the two changes yet, the HTML caching and the longer cache TTL. Writing this up now partly as a record of where things stand, so I have a clear before state when I eventually make both changes and rerun the test.

Keeping an eye on it

The numbers are already reasonable. But I think running the report occasionally and actually reading it is a useful habit, if only because it is easy to assume a site is fast without ever checking. Not every finding will matter. Most of this one did not. But I would rather find the HTML caching gap now than later, when it is harder to reason about.