My website scored 92 on PageSpeed. I audited it in public

I sell WordPress optimization. So the least I can do is practise what I preach: I ran my own website through PageSpeed Insights, wrote down everything that went wrong and fixed it. Here are the numbers before, what I changed, what I decided not to touch and the numbers after. No make-up.

The starting point

Report from 30 September 2026 on the udista.com home page, with Lighthouse 13.5:

A 92 on mobile is not bad. Most of the WordPress sites I audit score below 60. But 2.7 seconds before you see the first line of text on a phone with slow 4G is a lot for a home page that is, basically, text. And there were more interesting things than the score.

What I found

1. A 110 KB stylesheet blocking the first paint

PageSpeed estimated 1.5 seconds of savings on mobile from “render-blocking requests” alone. The browser paints nothing until it has downloaded and processed the stylesheet, and mine weighed 110 KB. Two stylesheets combined: the theme’s original one and an editorial layer I added later, with rules that override each other. The largest element on screen (the LCP) is the headline, a piece of text. If the CSS is slow, the headline is slow.

2. 93 KB of Google Analytics that goes unused

All the “unused JavaScript” PageSpeed flagged was a single file: the Google Analytics library. The browser downloads it as soon as you land, even though it measures nothing and sets no cookies until the visitor accepts them (the cookie plugin takes care of that). So there is no legal problem, but it is 93 KB downloaded for nothing if the visitor then rejects cookies.

3. A grey paragraph on a grey background

The introduction text of the products section had a contrast ratio of 4.29:1. WCAG 2.1 AA requires 4.5:1 for normal text. Close, but no. And of all people, me, who sells accessibility audits.

4. Three links that say the same thing and go to different places

The service cards ended with “See details →”. Three times, three destinations. Visually it makes sense, because each link sits under its own heading. But someone using a screen reader and jumping from link to link hears “See details, See details, See details” and cannot tell which is which.

5. My llms.txt was not responding in time

This is the new part. Lighthouse has added a category called Agentic browsing: it checks whether AI agents (the assistants that browse and do things on the user’s behalf) can understand and use your website. One of the tests is the llms.txt file, a plain-text summary of who you are, what you offer and where everything is, meant to be read by language models.

I already had an llms.txt. The problem was how it was served: WordPress generated it on every request, booting PHP, the database and every plugin to return 2 KB of text that never changes. On mobile it passed the test. On desktop, Lighthouse got tired of waiting: “Timed out fetching resource”. Result: 2/3.

What I did

1. Critical CSS inline, the rest deferred. The styles needed to paint the first screen go inside the HTML and the rest loads without blocking. LiteSpeed can do this with its QUIC.cloud service, but I did not want to depend on an external service for something that can be generated once and left in the theme. I generated it myself with penthouse, going through the main templates on mobile and desktop. If it ever causes trouble, deleting one file is enough for the site to load the CSS as before.
2. Contrast fixed. The paragraph grey goes from #64748b to #475569: from 4.29:1 to 6.9:1. The design barely changes to the naked eye.
3. Links with their own names. Each “See details” now carries hidden text for screen readers only: “See details: Optimization and rescue”. Visually, everything stays the same.
4. llms.txt as a static file. It is now a real file at the server root, which Apache serves without waking WordPress up, with a 24-hour cache. While I was at it, I added the AI development service, which was missing from the list.

What I did not touch (and why)

• “Improve image delivery: 4 KiB”. Four kilobytes. Fixing it costs more than it gives.
• “Optimize DOM size”. The home page is long because it has a lot to say. Cutting sections to gain one point would be optimizing for the tool and not for the reader.
• The 92 KiB of Google Analytics. They no longer block loading (I explain below why they did) and they measure nothing without consent. Delaying the download as well would save a few KB, but it does not change the score. Not worth it.
• Security headers (CSP, HSTS, COOP…). They show up as informational warnings and do not take points off. They are a separate project, with a post of their own.

That is the part no tool tells you: knowing which warnings matter and which are noise. A tool gives you a list. Judgement is deciding what to do with it.

The result

100 in all four categories, on mobile and on desktop. On mobile, the headline appears in 1.2 seconds instead of 2.7: less than half.

And it did not happen on the first try. After the first changes, mobile only went from 92 to 94, and on desktop the Speed Index got worse. I ran the same Lighthouse version PageSpeed uses and the culprit showed up: the cache plugin was stripping the async from the Google Analytics tag, so the browser waited to download 160 KB of JavaScript before painting anything. With one line in the theme that marks that script so the cache leaves it alone, the score went to 100.

What has really changed is what the score does not show: the CSS blocking the load has gone from 110 KB to zero, a screen reader user now knows where each link goes, and AI agents find my llms.txt on the first try.

What about your website?

If my website, which is custom-built and has no page builder, had five things to fix, yours probably has more. I will run a performance diagnosis and tell you what is worth touching and what is noise. And if you already know your website is slow, take a look at optimization and rescue.