A green score in a performance report is not a trophy. It is the visible result of an architectural decision: is the page assembled again on every single request, or does it already exist as a finished file that the server simply hands over? That one difference decides how much work sits between the click and the first thing a visitor actually sees. This article explains why statically delivered pages hold a structural advantage in the Core Web Vitals, what LCP, INP and CLS mean in everyday terms, and how to read measurements without letting one isolated number mislead you.
What a PageSpeed score of 100 really tells you
A performance score condenses several laboratory measurements into a single figure: a simulated device, a throttled connection, a defined starting point. That is exactly what makes it reproducible, and exactly why it only tells half the story. What it grades is how much work a page demands from the browser before anyone sees anything at all. The starting position is sobering. At the median, a page requested on a phone transfers around 2.4 megabytes (HTTP Archive Web Almanac), and more than 500 kilobytes (HTTP Archive Web Almanac) of that is JavaScript alone. At the same time, roughly 89 percent (Federal Statistical Office of Germany) of companies with internet access run a website of their own. Anyone who wants to be fast in that landscape has to settle one question first: where does the page actually come into being — in the browser, inside a server render path, or already at build time? A high score is not proof of a good website either, only an indication that the technical foundation is sound. A weak score, in turn, is rarely accidental: it signals that work has been pushed into the moment of the request somewhere along the line. Our overview of what delivery includes starts precisely there.
Lab and field answer different questions
The three Core Web Vitals in plain language
The Core Web Vitals bundle three questions. When does the visitor see the main content (LCP)? How quickly does the page answer an interaction (INP)? And does the layout stay calm while all of that happens (CLS)? Only around 48 percent (HTTP Archive Web Almanac) of websites requested on mobile devices reach a good rating across all three. The cause is rarely one single mistake. It is the sum of many small runtime decisions: an oversized title image, a font that arrives late, a script that occupies the main thread, a banner that pushes the text downwards. In practice the advice boils down to three moves: ship less, ship it earlier, and change less after the first paint. All three depend directly on how the page is produced. How a business website comes into existence in the first place is covered in our piece on building a website with AI — and the architecture chosen there is what later shows up in the numbers.
LCP: main content visible
Measures when the largest visible element inside the viewport has finished painting, usually an image or a headline. Server time, image weight and render-blocking resources feed straight into this value.
INP: response to input
Rates the delay between a click or keypress and the next visible reaction. Long JavaScript tasks occupy the main thread and push this value up noticeably on weaker devices.
CLS: a calm layout
Captures how much content still jumps around after the first paint. Images without dimensions, late-arriving fonts and injected banners are the usual culprits behind poor scores.
| Metric | Good | Needs work | Poor |
|---|---|---|---|
| LCP (largest content element) | up to 2.5 seconds | 2.5 to 4.0 seconds | over 4.0 seconds |
| INP (response to input) | up to 200 milliseconds | 200 to 500 milliseconds | over 500 milliseconds |
| CLS (layout shift) | up to 0.1 | 0.1 to 0.25 | over 0.25 |
Why rendering at request time costs time
On a page that is produced at request time, the real work only starts once the request arrives. The server boots an interpreter, loads a framework, opens a database connection, runs queries for content, navigation and settings, assembles templates, lets extensions apply their filters — and only then sends the first byte on its way. Each of these steps is short in isolation. Added up they become the time to first byte, and that pushes everything behind it further back: only when the HTML lands does the browser even learn which fonts, images and scripts it still needs to fetch. In practice the LCP suffers along with it. What makes this worse is that the chain runs again on every single request, even when the content has not changed in weeks. Caching layers soften the effect, but they add another moving part that has to be configured, monitored and purged whenever something is edited. The route from briefing to delivered page on our side is laid out in the step-by-step overview.
- The request reaches the web server and is passed on to the interpreter
- Framework, configuration and extensions are loaded and initialised
- Database queries for content, navigation, settings and translations are executed
- Templates are assembled while filters and extension points intervene
- The finished HTML is emitted, and only now does the transfer begin
- The browser discovers fonts, images and scripts and requests them one by one
Every millisecond a server spends assembling a page is a millisecond the browser no longer has for painting the content people came to see.
The structural edge of static delivery
Delivered statically means the HTML already exists before the first visitor shows up. The web server looks up a file and sends it out; nothing else happens per request. The entire runtime render path disappears, and the time to first byte comes down to network distance and file size. On top of that, such a file stays unchanged until it is rebuilt, and that is what makes caching genuinely effective: in the browser, in a reverse proxy, at distributed delivery points. A cache hit is the shortest possible route to the first byte because no application server is involved at all. For editorial work, very little changes: content is still maintained in an interface, with a build step in between that turns the configuration into finished pages. The difference lies in when the work happens, not in how the work feels day to day. What the result looks and feels like can be seen in our example websites.
No render path at runtime
No interpreter start, no database query, no template assembly per request. The server reads a prepared file and returns it unchanged to whoever asked for it.
Cache and CDN friendly
Unchanged files can be served with long lifetimes and held at distributed locations. Returning visitors often reload almost nothing, which shows up directly in the field data.
Fewer moving parts
Without runtime extensions, the classic sources of trouble disappear: slow queries, module conflicts and load spikes when many people arrive at the same moment.
| Aspect | Produced at request time | Delivered statically |
|---|---|---|
| Time to first byte | Depends on database, templates and extensions | File is read and sent straight away |
| Behaviour under load | Computing effort grows with every request | The same file serves every request |
| Caching strategy | Fragmented, often limited by personalisation | Long lifetimes and a high hit rate |
| Typical bottlenecks | Extensions, queries and session handling | Image weight and embedded third parties |
| Operational risk | Updates can quietly change delivery | Changes happen at build time, not in production |
Ballast: extensions, scripts and third parties
The second big lever is not the server, it is the document head. Around 94 percent (HTTP Archive Web Almanac) of the pages studied embed at least one third-party resource: font services, video embeds, mapping material, advertising and measurement snippets. Every one of them costs a name lookup, a connection handshake and transfer time — and many then execute code of their own that occupies the main thread and hits responsiveness directly. In classic CMS installations the extension stack piles on top: each additional module brings its own stylesheets and scripts, frequently loaded on every page, including the ones where the feature does not appear at all. A simple exercise helps here: count every connection to an outside server on a typical subpage and ask what measurable contribution each one makes. In our experience far fewer embeds survive that question than were originally in place. What that means when choosing a platform is set out on our page about the approach behind the product.
- Font files pulled from external services instead of hosted in your own directory
- Video embeds that fetch heavy scripts long before anyone presses play
- Mapping material loaded on every page rather than only on the contact page
- Several measurement and marketing tools running in parallel with overlapping purposes
- Extensions whose stylesheets load globally although they affect a single page
- Slider and animation libraries for effects that plain CSS could deliver as well
Third parties are a legal topic too
Reading the numbers properly
Measuring means comparing, and comparing needs stable conditions. A single test run swings noticeably with network quality, server load and cache state; the picture only becomes meaningful across several runs and several page types. Because roughly nine in ten (Bitkom) people in Germany use a smartphone, the mobile measurement is the benchmark, not the desktop view on a fast line. Field assessment adds one more rule: the 75th percentile counts, so three out of four page views should sit below the threshold, and the average is irrelevant. Finally, every measurement needs context — was the page tested with or without an accepted consent banner, with a cold or a warm cache? A plain log helps as well: date, page, device class, network profile and result in one table. That makes it possible to tell later whether a decline coincides with a specific change or whether the test conditions were simply different. Which building blocks we ship as standard is documented in the services overview.
- Measure on mobile, not only on a desktop with a fast connection
- Run each page at least three times and work with the middle result
- Look at the home page, a service page and a detail page separately
- Place lab results and field data side by side instead of playing them off
- Re-measure after every larger change and record the outcome with a date
- Document the cache state and the consent status of each test run
The 75th percentile sets the bar
Images, fonts and caching strategy
Once the architecture is settled, the remaining adjustments are craft. Images need explicit width and height attributes so the browser can reserve their space before the file has arrived; that single habit removes a large share of layout shifts. They also belong in modern formats and at the size they are actually displayed. Fonts belong on your own server, trimmed to the weights you really use, with display behaviour controlled through font-display and a preload hint for the cut needed above the fold. Delivery follows a simple split: versioned assets get long lifetimes, HTML stays short-lived and revalidates. Source order matters too: whatever the visible area needs should load early, everything else later or only on demand. Images below the fold can be deferred without any visitor noticing the difference. What is covered in which package is listed on our pricing page.
<!-- Self-host fonts and preload the cut used above the fold -->
<link rel="preload" href="/fonts/inter-var.woff2" as="font"
type="font/woff2" crossorigin>
<!-- Fixed dimensions reserve space and prevent layout shifts -->
<img src="/images/reception.avif" width="1280" height="720"
alt="Reception area of the practice"
fetchpriority="high" decoding="async">
<!-- Delivery: long lifetime for versioned assets, short for HTML -->
Cache-Control: public, max-age=31536000, immutable (CSS, JS, images)
Cache-Control: public, max-age=300, must-revalidate (HTML)How XICflow puts this into practice
XICflow keeps every website as a configuration in the database and builds static files from it that are then delivered per domain. There is no render path at request time, no extension stack and no module update that quietly shifts something in production. The delivery target is a Lighthouse result of 100 across all four categories, accessibility included — and that is more than cosmetics: around 95 percent (WebAIM Million) of the home pages examined show automatically detectable failures against the WCAG guidelines (W3C), while the European Accessibility Act (European Commission) has been binding for many providers since 28 June 2025. Images, legal texts and the consent dialogue come out of the same build and are delivered together with the page, so no external building block is inserted afterwards to lengthen the load path. What follows from that is spelled out in our article on accessible business websites; the path from input to finished file is described in the detailed workflow.
- Static delivery per domain, with no page assembly at request time
- Self-hosted fonts and images in modern formats with explicit dimensions
- Accessibility on a WCAG 2.2 AA basis from the very first page
- A consent banner included as standard, with no external service in the load path
- Multilingual setup with hreflang and translated slugs, no extra module required
- Contact form, blog and AI assistant without a heavy runtime stack behind them
A workable plan for the coming weeks
Performance projects rarely fail for lack of knowledge; they fail on sequence. Start with an inventory before tuning individual metrics: what is being loaded, by whom, and what for? A substantial share of page weight often disappears the moment resources nobody misses are removed. Only then does it pay to look at the delivery architecture and ask whether the page needs to be produced anew on every request at all. How consent can be handled cleanly and still stay lightweight is covered in our article on setting up cookie consent correctly. Worked examples of the whole interplay are available in the demo websites.
- List every resource a typical page loads and sort the list by origin
- Justify each external embed in writing or remove it without replacement
- Resize images to the dimensions they are shown at and convert them to a modern format
- Self-host fonts, reduce them to the weights in use and preload them deliberately
- Question whether the page has to be generated at request time in the first place
- Re-measure on mobile after the rebuild and watch the field data for four weeks
Speed is ultimately a question of architecture rather than fine-tuning. Assembling a page on every request means working against your own delivery indefinitely; shipping finished files moves that effort once into the build and typically leaves the measurements quiet afterwards. The decision reaches far beyond load time: it touches accessibility, data protection and international discoverability as well, as our piece on multilingual websites and hreflang describes. For many companies that is also the most practical order of operations: settle delivery first, then build out content and visibility. The number a testing tool reports at the end merely confirms a choice that was made much earlier.