What Actually Happens When Someone Loads Your WordPress Page
Someone clicks a link to your site. A moment later, they’re reading your page.
In between, a surprising amount happens. And almost every performance problem you’ve ever read about lives at one specific point in that sequence.
That’s the useful part. Once you know the order things happen in, advice like “reduce TTFB” or “eliminate render-blocking CSS” stops being a list of unrelated warnings and becomes a map. You can tell which stage a problem belongs to, and why fixing the wrong stage doesn’t help.
So here’s the whole sequence, from the click to a page someone can actually use. Browsers do a lot of this work in parallel, so treat it as a simplified timeline rather than a perfectly linear one.
Step 1: Finding your server
Your visitor types a domain. Computers need an IP address.
The browser asks a DNS resolver where yoursite.com lives, and gets back an address. This can be very fast when the answer is already cached, but slower when a fresh lookup is needed.
Nothing has been downloaded yet. No HTML, no images. The browser is still looking up where to knock.
For repeat visitors, this step is often much faster because the answer may already be cached. When a fresh lookup is needed, it adds another small delay before the page can start loading.
Step 2: Opening the connection
Now the browser establishes a secure connection to the server. With HTTP/1.1 or HTTP/2, that typically involves TCP and TLS; HTTP/3 handles this differently using QUIC.
Either way, establishing the connection adds some network overhead before your content starts arriving. On a fast connection this is trivial. On mobile, where each round trip is slower, it adds up quickly.
This is also why every extra domain your page talks to has a cost. A Google Font, a chat widget, an analytics script, a video embed, each additional domain can require extra DNS and connection work.
Step 3: WordPress builds the page
The request reaches your server, and this is where WordPress does its work.
PHP starts up. WordPress loads core, your theme, and every active plugin. It queries the database, runs whatever hooks and filters your plugins have registered, and assembles the HTML.
This is the part almost nobody sees, and it’s where a lot of WordPress sites quietly lose valuable time. A slow query, a bloated options table, a plugin doing something expensive on every page load, it all lands here.
Problems at this stage often show up in TTFB (Time to First Byte), which measures the time from the start of the request until the first byte of the response arrives.
TTFB includes more than WordPress processing alone, but slow PHP, database work, or server response time can all contribute.
And here’s the important bit: page caching can skip most of this work. When a page is cached, a ready-made response can be served instead of generating the page from scratch. That can avoid much of the PHP and database work required to generate the page dynamically. That’s why caching is often one of the most effective TTFB improvements available to a WordPress site.
Step 4: The HTML arrives, and the browser starts reading
The first bytes land. The browser starts parsing the HTML from the top down, building the DOM as it goes.
While parsing, it finds references to other things: stylesheets, scripts, images, fonts. It starts requesting them.
The page may still be blank at this point. The browser has your content, but not yet all the instructions on how it should look.
Step 5: CSS can block rendering
This is the stage that surprises people.
The browser needs the relevant CSS before it can correctly render styled content. It needs enough styling information to know how the content should be displayed, otherwise your visitor could see a flash of unstyled content before the layout snaps into place.
So a stylesheet in your <head> is render-blocking by design. Rendering can be delayed while those styles are downloaded and processed.
The trouble is that WordPress sites can end up with large stylesheets containing rules for parts of the page nobody can see yet: the footer, the contact form, a slider halfway down. Your visitor stares at white while the browser downloads rules for a footer they haven’t scrolled to.
That’s exactly the problem CSS Critique solves: extract the styles that affect the visible area, inline them so they’re available immediately, and let the rest load in the background. Doing that by hand is painful, which is why FastPixel generates and injects it for each page automatically.
Scripts can also delay parsing or rendering, depending on how and where they’re loaded. Attributes like async and defercan change that behavior.
Step 6: The first paint
Once the browser has enough HTML and CSS to render something useful, it starts painting content to the screen.
Your visitor finally sees something. This moment is First Contentful Paint (FCP).
At this point, some content may already be visible while images, fonts, and scripts continue loading in the background.
Step 7: The main content loads, and LCP happens
The browser may already be downloading images in the background, and those images often represent some of the largest resources on the page.
The LCP element is often a hero image or featured image, but it can also be a large heading or text block. Largest Contentful Paint measures when the largest eligible content element visible in the viewport is rendered.
When an image is the LCP element, this is where image optimization really pays off, and where the usual PageSpeed warnings live: images that are larger than the space they occupy, images in outdated formats, images that could have been served from a nearby CDN edge instead of your origin server.
One trap worth naming: lazy loading an image that becomes your LCP element can make LCP worse. Lazy loading is for images below the fold. Applied to the image that is your LCP element, it tells the browser to wait before fetching the single most important thing on the page.
Step 8: Fonts settle in
Custom fonts are usually discovered after the browser processes the CSS that references them, unless they’re explicitly preloaded.
Depending on your settings, the text was either invisible while waiting, or displayed in a fallback font that now gets replaced.
That replacement can contribute to layout shifts: if the fallback and the real font have different proportions, everything around them moves when the swap happens. Same for images without width and height, ads, and anything injected above existing content.
Cumulative Layout Shift (CLS) measures this kind of unexpected visual movement. It’s the reason someone taps the wrong button because the page moved underneath their thumb.
Step 9: JavaScript runs
The page looks finished. It often isn’t.
JavaScript may still need to be downloaded, parsed, compiled, and executed, and much of that work happens on the main thread, the same single thread the browser uses to respond to taps and clicks. When a long JavaScript task keeps the main thread busy, the page can be slow to respond to user input.
This is why a page can look ready and still feel broken. The visitor taps a menu, nothing happens for 300ms, and they tap again.
That responsiveness is measured by INP (Interaction to Next Paint), and heavy JavaScript and third-party scripts are common causes of poor INP: analytics, tag managers, chat widgets, tracking pixels, embeds.
Reducing how much script the browser has to deal with is the only real fix here, and it’s part of what FastPixel’s CSS and JavaScript optimization does.
On a modern laptop, some of this may be difficult to notice. On a mid-range Android phone, with a CPU several times slower, it very much is, which helps explain why performance problems are often much more noticeable on mobile devices.
Where your performance metrics land on this timeline
Each metric measures a different stage, which is why one number rarely explains another:
- TTFB — everything leading up to the first byte arriving: network, connection, server, and backend processing.
- FCP — step 6. Influenced by how quickly the browser can start rendering useful content, including CSS and blocking resources.
- LCP — step 7. About when the largest visible content element finishes rendering, plus everything that had to happen before it.
- CLS — throughout the page lifecycle. Fonts, images without dimensions, and late-injected content can all cause unexpected shifts.
- INP — step 9 onward. Main-thread work, event handling, and rendering after user interactions.
A site can have excellent TTFB and terrible LCP. Another can paint quickly and still feel unusable because of scripts. They’re different stages, and they need different fixes.
What this means in practice
The next time a testing tool hands you a list of warnings, place each one on this timeline before you do anything. Most of them will cluster around one or two stages, and that’s where your time is best spent.
Broadly:
- Slow start? That’s steps 1–3. DNS, network latency, hosting, caching, and backend processing.
- Blank screen for too long? Steps 4–6. CSS and blocking scripts.
- Main content appears late? Step 7. Check the LCP element, image size, resource priority, and delivery.
- Page jumps around? Steps 7–8. Fonts and missing dimensions.
- Feels sluggish to interact with? Step 9. JavaScript and long main-thread tasks, including third-party scripts.
None of this requires you to become a browser engineer. It just helps to know that a page load is a sequence rather than a single event, and that “my site is slow” is really a question about which part is slow.
FAQ
Why is my page blank for a moment before anything appears? The browser has the HTML but is still waiting on render-blocking resources, usually CSS. Until it has enough styling information, it can’t render the content correctly. Critical CSS shortens that wait by inlining the styles needed for the visible area.
What’s the difference between TTFB and LCP? TTFB covers everything up to the first byte of the response arriving: DNS, connection, server and backend processing. LCP measures when the largest visible content element is rendered, which happens much later. A site can have a fast TTFB and a slow LCP, or the other way around.
Why does my site feel slow even though it looks fully loaded? Because looking finished and being responsive are different things. JavaScript may still be executing on the main thread, and while a long task is running the page can be slow to respond to taps and clicks. That’s what INP measures.
Why is my mobile score worse than my desktop score? PageSpeed Insights tests mobile and desktop under different simulated conditions. The mobile test represents a less powerful device and a slower network, so JavaScript, images, and other resources have less room for error. That’s why performance problems that barely register on desktop can become much more obvious in the mobile report.
Which stage should I fix first? Start with whichever one your testing tool points to most consistently. As a rule, backend and caching issues affect every other stage that follows. If TTFB is high, it’s worth addressing early because every later loading milestone has to wait for the initial response.
French 
English