PageSpeed 100/100 on a Live Site: What We Did and Why It Works

In the Google PageSpeed Insights test dated July 17, 2026, this site’s homepage measured 100/100 for performance, accessibility, best practices and SEO on both mobile and desktop. LCP measured 1.0 s on mobile and 0.3 s on desktop. You can review the results in the report from that test.

Update note: The homepage was redesigned after this measurement. The results and interface descriptions below refer to the tested version; assessing today’s performance requires a new measurement.

This post describes the architectural choices used in the measured version. The gain a similar approach can deliver on another site depends on that site’s baseline measurements and technical conditions.

Why Should You Care?

Speed is not a matter of technical pride; it is a matter of money:

• Ad budget: If a visitor you paid for per click leaves because the page takes 4 seconds to open, that budget is wasted.
• Google ranking: Core Web Vitals are among the signals used by Google’s ranking systems. Good scores alone do not secure high rankings; Google’s guidance recommends considering several aspects of page experience together.
• Trust: A site that opens instantly on mobile says “these people know what they are doing” within the first second. A slow agency site is an advertisement against its own service.

The Five Decisions Behind the Result

1. Generate HTML at publish time, not at visit time

The tested version was compiled statically with Astro, with each page’s HTML prepared at publish time. Serving a page therefore did not require a database query or template rendering. Pages were delivered through Cloudflare’s distribution network.

2. Draw the hero with code, not an image

The animated panel on the tested homepage was drawn with HTML and CSS. This avoided downloading a separate large image for the panel. Images were prepared as WebP, with those below the first screen using lazy loading. The screenshots on today’s homepage are different from that earlier panel.

3. Fix the layout up front

Image widths and heights were defined in the HTML. This let the browser reserve space before each file loaded, reducing layout shifts caused by image loading. Other dynamic content also needs to be considered when evaluating CLS results.

4. Treat JavaScript as the exception

The tested page had no heavy framework bundle or collection of third-party widgets. Limiting scripts to the required interactions reduced the load on the browser’s main thread. The effect of each added script was evaluated through measurement.

5. Cache aggressively, keep HTML fresh

The measured version served static assets (CSS, JS and icons) with long-lived cache headers, while HTML was refreshed on each deploy. The amount downloaded again depended on the browser’s cache state and which files had changed.

“Why Is Our Site Slow?”

The four causes we see most often on client sites:

1. Setups that generate HTML from scratch on every page view, with no caching
2. Unsized 3–5 MB images
3. Third-party scripts accumulated over time — analytics, chat, heatmaps
4. Unused CSS and JS shipped by theme and plugin sprawl

These issues do not always require rebuilding a site; the appropriate intervention depends on the existing infrastructure. We start with measurements, prioritize issues by their impact and evaluate changes through before-and-after reports. Stating the test date and conditions makes it possible to compare different versions accurately.

If you want to see where your site stands today, take a look at our site speed optimization service or write to us; let’s run the first measurement together.