100 on PageSpeed: what we changed to get there

The starting score was 58 out of 100 on mobile. That is not a bad score for a site with a 3D effect in the header, but it is one Google noticeably penalises in mobile search. We finished at 100 on desktop and 98 on mobile, with 100 for accessibility as well.

What follows is not a general checklist but the actual sequence — including the places where we got it wrong.

The starting point

The five changes that actually counted

1. Replace the library, do not optimise it

The header shows a particle cloud in 3D. A well-known graphics library was running for that — 458 KB after minification. The measurement showed that 51 KB of it was never executed at all.

The decisive question was how much of it we actually needed. It came to eleven building blocks: renderer, scene, camera, geometry, material and a few helper classes. All of them can be written directly against the browser's own graphics interface.

Result: 458 KB became 6 KB. The rendering is identical — we kept the same shaders.

2. Compression was only half switched on

The server configuration had compression set to "on" — but the line specifying which file types to compress was commented out. That is the default in many distributions. The result: only HTML was being compressed.

So the graphics library went over the wire uncompressed. After switching it on: 1,243 KB became 251 KB. We now also place pre-compressed versions alongside the files, so the server does not recompute on every request.

Effort: two lines of configuration. Effect: nearly a megabyte per first visit.

3. Remove the animation library entirely

A second library, 114 KB, handled fade-ins on scroll. The measurement additionally flagged it as the cause of forced layout reflows — it queried geometry while scrolling and forced the browser to recalculate the layout mid-motion.

Replaced by an IntersectionObserver that merely sets a class. CSS does the actual movement. 114 KB less, no more reflows, around 40 lines of our own code.

4. The favicon was 205 KB

A small thing with a surprising effect, because it loads very early. Replaced with a 6 KB SVG generated from the existing logo.

5. Querying geometry inside the animation frame

One script read the document's total height on every scroll event. The browser cannot answer that property from memory — it has to recalculate the layout of the whole page, mid-scroll.

The rule that follows, and holds everywhere: read in the event, write in the frame afterwards. Never the other way round. Since then the page height is measured once and remembered, instead of being queried sixty times a second.

The mistake that cost 24 points

What helped little

For completeness, the measures that appear in every guide and were barely measurable for us:

Image formats. Our home page has hardly any images — the logo is an SVG. Where images do appear, conversion is of course worthwhile; as a main lever it only works on image-heavy pages.

Shrinking fonts further. We self-host two font families and preload the ones needed in the visible area. Further optimisation would be possible but does not move the score.

Server location. Widely recommended, irrelevant in our case: time to first byte was already at 20 milliseconds. If you are already good there, a distribution network gains you nothing.

The approach, to follow yourself

1. Measure before changing anything. Mobile and desktop separately, note the values.
2. Find the largest transferred file. Almost always it is JavaScript. The question is not how to shrink it, but whether you need it.
3. Check compression. Not whether it is on, but for which file types.
4. Count render-blocking requests. Every stylesheet file in the head holds up the first paint.
5. Check for layout shifts without throttling. The one test we were missing.
6. Measure again after every change. Otherwise you will not know at the end what worked.

Help me turn my PageSpeed report into an ordered plan.
Be strict; praise nothing.

My measurements:
- Mobile: [score], desktop: [score]
- LCP, TBT, CLS per device: [values]
- Largest transferred files with size: [list]
- Render-blocking requests: [list]
- Messages from the report: [paste text]

About the site:
- How it is built: [CMS / static / site builder]
- Is JavaScript needed for the visible content? [yes/no]
- How is CSS delivered? [external / inlined / partly inlined]

Tasks:
1. Assign each message to a cause and say which metric it affects
   – LCP, TBT or CLS.
2. Sort the measures by effect per effort. For each, state how
   many points it realistically moves and why.
3. Name the measures from the report that will bring practically
   nothing given how my site is built – and justify that rather
   than simply omitting them.
4. For every large JavaScript file, ask first whether it is
   needed before suggesting minification.
5. Point it out if CSS is only partly inlined, and explain why
   that can be worse for CLS than not inlining at all.
6. Tell me what to re-measure after each change.

Do not invent measurements.

In closing

The score itself is not the goal — it is a measurement, not a business result. What counts is the experience behind it: a page readable after 1.4 seconds gets read by more people than one that takes six. For mobile visitors on a cellular connection, that difference is larger than any text optimisation.

Getting there, in our case, ran through one recurring question: do we need this? Five of six changes consisted of removing something, not adding something.

Common questions