Last updated: October 2026.
To improve page load speed, fix the three things Google actually measures: get Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds and Cumulative Layout Shift under 0.1. This guide is the practical version for WordPress sites, with the 12 fixes that move those numbers and the order to do them in.
Key takeaways
- Google’s published thresholds are LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less, judged at the 75th percentile of real page loads on both mobile and desktop (web.dev, Web Vitals).
- Interaction to Next Paint replaced First Input Delay as a Core Web Vital on 12 March 2024, so any checklist still optimising for FID is optimising a retired metric (web.dev, Chrome team, 12 March 2024).
- Time to First Byte is not a Core Web Vital, but web.dev’s rough guide is 0.8 seconds or less, with anything over 1.8 seconds counted as poor (web.dev, Time to First Byte).
- Speed is a tiebreaker rather than a rescue. Google states Search always seeks to show the most relevant content even when page experience is sub-par, but a great page experience can decide a close contest (Google Search Central, Understanding page experience, updated 22 September 2026).
- Test with both: PageSpeed Insights for a single URL and the Core Web Vitals report in Search Console for the site, because lab and field data disagree and the field data is the one Google uses (Search Console Help, Core Web Vitals report).
Definition: page load speed is how quickly a page becomes usable, not how quickly the spinner stops. It is measured in stages: server response (TTFB), the moment the biggest element is painted (LCP), how long the page takes to respond to a tap (INP) and how much the layout moves while loading (CLS). Optimising the wrong stage is why so many speed projects deliver a better score and no better experience.
What is a good page load time?
There is no single number, because “loaded” means different things depending on who is asking. A visitor wants the hero image and the headline. A search engine wants the rendered content. A form wants the submit button to work. Google scores those separately, which is why a site can feel fast and still fail Core Web Vitals, or pass the score and feel slow.
| Metric | What it times | Good | Needs work | Poor |
|---|---|---|---|---|
| LCP Largest Contentful Paint | How long until the biggest element in view is drawn | 2.5 seconds or less | 2.5 to 4.0 seconds | Over 4.0 seconds |
| INP Interaction to Next Paint | The delay between a tap and the screen responding | 200 milliseconds or less | 200 to 500 milliseconds | Over 500 milliseconds |
| CLS Cumulative Layout Shift | How much the layout moves while loading | 0.1 or less | 0.1 to 0.25 | Over 0.25 |
| TTFB Time to First Byte | How long the server takes to start answering | 0.8 seconds or less | 0.8 to 1.8 seconds | Over 1.8 seconds |
All three Core Web Vitals thresholds come from web.dev’s published guidance, which also states the measurement rule that catches people out: the numbers are judged at the 75th percentile of page loads, so three quarters of your visits have to hit the target (web.dev, Web Vitals). A good average with a bad tail still fails. The TTFB row is web.dev’s own rough guide and TTFB is deliberately not one of the three Core Web Vitals (web.dev, Time to First Byte).
Send us your PageSpeed Insights link and we’ll tell you the 3 fixes that matter most. Not an audit document. The three changes with the biggest effect on your enquiries, ranked, with what each one is likely to buy you.
How do you test page load speed?
Three tools, each answering a different question. Run all three before you change anything, because fixing without a before reading means you cannot prove the fix worked.
PageSpeed Insights gives you a lab score for one URL plus, where there is enough traffic, the field data Google has already collected for it. Paste the URL, read the Core Web Vitals block at the top first, then the opportunities list (PageSpeed Insights). Treat the score as a summary, not a goal: a 100 on a lab test on a fast connection tells you very little about a mid-range Android on 4G.
The Core Web Vitals report in Search Console is the one that matters. It groups your URLs by status, using real visits, and it is the same data Google’s ranking systems see (Search Console Help, Core Web Vitals report). You need the property verified and enough traffic for it to populate. If the report is empty, you are flying on lab data alone.
A waterfall view shows the order and the overlap of every request, which is the only way to see a blocking script sitting in front of your hero image. Chrome DevTools has one built in, with device emulation and network throttling, so you can watch a page load as a mid-range phone on a slow connection rather than as your laptop on fibre (Chrome DevTools, Simulate mobile devices). GTmetrix and WebPageTest are the equivalent third-party tools; both are useful, and both add a login before you see the graph.
Why do lab scores differ from field data?
Lab data is one synthetic visit from one location on one device profile. Field data is every real visit over 28 days, on every phone, network and browser your audience actually uses. Google ranks on field data, so when the two disagree, the field number is the truth and the lab number is a debugging aid.
There are three usual reasons for the gap. Your test machine has a fast CPU and a good connection, so a heavy page passes. Your audience is geographically close to the server while your test runs from somewhere else, or the reverse. And third-party scripts that behave differently per visitor, such as chat widgets, personalisation or ad tags, are often not loaded in a lab run at all, which means the lab score never sees the thing slowing your real visitors down.
| Symptom on a phone | Most likely cause | Fix to try first |
|---|---|---|
| Blank screen for a second or more | Slow server or an uncached WordPress page | Page caching, then object caching |
| Text appears, picture fills in late | Hero image is oversized or lazy loaded | Compress, resize, serve WebP or AVIF, stop lazy loading the hero |
| Buttons feel dead for half a second | Long JavaScript tasks blocking the main thread | Defer non-critical scripts, remove unused plugins |
| Content jumps as the page settles | Images, fonts or ads without reserved space | Set width and height, reserve space for embeds |
| Fast on your desktop, slow on mobile data | Too much weight, not enough compression | Brotli, a CDN, fewer fonts |
| Fine logged out, slow logged in | Caching disabled for logged in users | Exclude only the account pages, cache the rest |
What are the 12 ways to improve page load speed?
This is the list we work through on a WordPress site, in roughly the order of payoff per hour of work. Skip nothing on the way to the interesting ones: hosting and caching sit at the top because everything else is built on them.
1. Move to fast hosting with Australian servers
If your TTFB is over 0.8 seconds, nothing further down this list will save you. Shared hosting on a busy server, or a data centre in the United States serving Melbourne visitors, adds latency to every single request. A server in Sydney or Melbourne costs a few dollars a month more than the cheapest plan and removes a few hundred milliseconds from every page before you have changed a line of code.
2. Update PHP, WordPress core, themes and plugins
Each PHP release brings real performance work, and an old branch is a security risk as well as a slow one. Check the version in Tools then Site Health, and ask your host which versions they support before you change it, because a theme that breaks on a new PHP version is a worse outcome than a slow page. Update plugins one at a time on a staging copy and test the site after each, so a culprit is identifiable.
3. Turn on page caching and object caching
Page caching stores the finished HTML so the next visitor does not make WordPress build it again. Object caching stores database query results so a page with twenty queries makes two. On WordPress these are plugin or host level settings, and a properly cached page typically drops TTFB from several hundred milliseconds to a few dozen. This is the single highest value change on most sites, and the one most often left off.
4. Resize and compress images, and serve WebP or AVIF
Images are usually the largest thing on the page. Upload them at the size they will display, not straight from a camera, and let the CMS serve a smaller file to smaller screens with srcset and sizes (web.dev, Serve responsive images). WebP and AVIF are both widely supported now and both cut file size substantially against a JPEG of the same visual quality. Do not reach for JPEG 2000, which older versions of this article recommended: browser support never arrived.
5. Lazy load below the fold, not the hero
Lazy loading defers images until they are nearly in view, which is now the browser default and a genuine win for a long page. The mistake is applying it to the image that is already at the top, because you have then told the browser to wait before loading the very element that decides your LCP. Add fetchpriority="high" to the hero image and leave the rest lazy.
6. Remove plugins you do not need
Every active plugin is code loaded on requests, and many add their own CSS and JavaScript to every page whether or not that page uses the feature. Twenty plugins is not automatically a problem; twenty plugins where eight do the same job is. Deactivate one at a time and re-measure, because a plugin that costs nothing visible on a desktop can be the cause of a half second delay on a phone.
7. Choose a lightweight theme, or trim your page builder
Page builders ship a framework whether or not a page uses it. If you are on one, audit what loads and disable modules you never use, and avoid stacking a second builder on top. If you are choosing a theme now, weight matters more than the demo screenshots. Our own comparison of custom websites against templates covers the trade-off, and WordPress compared with a custom build explains when a custom stack wins on speed.
8. Minify and defer CSS and JavaScript
Minification strips whitespace and comments, which is a small but free win. Deferring matters more: a script without defer or async stops the browser parsing HTML until it has downloaded and run. Test one file group at a time, because a deferred script that another script depends on will break the page rather than speed it up. DigiFix runs free CSS, JavaScript and HTML minifiers you can use before you touch the live site.
9. Control third party scripts, pixels and embeds
Chat widgets, heatmaps, ad pixels, review widgets and social embeds are the most common cause of a site that scores well in a lab and feels slow in the field, because the lab never loads them. Inventory them, ask which ones earn their place, and load the rest only on the pages that need them. For a video embed, use a click to load pattern so the YouTube player is not fetched until someone presses play.
10. Optimise your web fonts
Each weight and style of a web font is a separate download, and a font that swaps in late drags text around the page. Load the weights you actually use, subset to the characters you need, self host rather than calling a third party, and set font-display: swap so text is readable before the font arrives.
11. Use a CDN and Brotli compression
A CDN serves your files from a location near the visitor, which matters most for a business whose customers are spread across Australia or overseas. Brotli compresses text files better than gzip and every current browser supports it, so ask for it rather than settling for gzip (web.dev, Reduce network payloads with text compression). Most managed hosts and CDNs enable it with one setting.
12. Clean up your database
Post revisions, expired transients, spam comments and orphaned metadata accumulate for years and slow the queries that build your pages. Object caching hides much of this, which is why it comes first, but a database with tens of thousands of stale rows eventually shows. Back up before you touch it, then remove revisions beyond the last few and clear expired transients. Do not run a cleanup plugin on a live site without a backup you have tested.
Want this done for you and kept done? A DigiFix WordPress care plan covers caching, image delivery, plugin updates, database hygiene and a monthly speed reading, so the site does not drift back to where it started.
How do you fix each Core Web Vital?
The three vitals fail for different reasons, so treat them separately. Fixing LCP will not fix INP, and a page that scores well on both can still jump around.
Fixing LCP: get the biggest element painted sooner
Identify what the LCP element actually is before changing anything, because it is often a heading rather than an image. If it is an image, compress and correctly size it, serve WebP or AVIF, add fetchpriority="high" and remove lazy loading from it. If it is text, the delay is usually a font file or a render blocking stylesheet, so preload the font and cut the critical CSS. Underneath all of it, TTFB sets the floor: an LCP of 2.5 seconds is not possible on a server that takes 2 seconds to answer.
Fixing INP: keep the main thread free
INP measures the gap between a tap and the next frame the browser paints, which is dominated by long JavaScript tasks. Break up long tasks, defer third-party scripts, and remove anything that runs on every page but is only needed on one (web.dev, guidance on long tasks). A chat widget that boots on load and then watches every click is a common culprit, and so is a slider plugin initialising images nobody has scrolled to. Test on a throttled phone, because INP problems are invisible on a fast desktop.
Fixing CLS: reserve space for everything
Every image needs width and height attributes so the browser can reserve its box before the file arrives. Embeds, iframes and ads need a fixed aspect ratio container. Banners inserted above content shift everything below them, which is why cookie notices and promo bars belong in reserved space rather than pushed in afterwards. Fonts need font-display: swap plus a fallback stack with similar metrics.
Definition: Cumulative Layout Shift scores how much visible content moved and how far, without any user input causing it. A 0.1 score is a small nudge. Above 0.25 usually means someone tapped a button that moved out from under their thumb, which is the version that loses enquiries. Time to First Byte is the time from the request reaching the server to the first byte of the response arriving back, and it is the one number that tells you whether to blame the host.
What does a speed fix look like in practice?
Here is a measured example rather than a case study claim. On 24 October 2026 we loaded one DigiFix page in Chrome at an iPhone viewport with a 4G throttle, a 4 times CPU slowdown and the cache disabled, and recorded the browser’s own performance entries. The page returned its first byte in about 240 milliseconds, painted its largest element at about 800 milliseconds and produced a Cumulative Layout Shift of 0.144.
Read that honestly: the server is fast and the page paints quickly, but the shift score is above Google’s 0.1 threshold, and it was reproducible across three runs. The shift came from the theme’s header section collapsing from 738 pixels to 638 pixels as the page settled, which moves everything below it. That is a theme fix, not a hosting fix, and it would be invisible on a desktop where the header has more room. A second page measured the same day produced 0.19 for the same reason.
| Page measured | TTFB | LCP | CLS | Verdict |
|---|---|---|---|---|
| Homepage | 0.25s | 0.67s | 0.005 | Passes all three |
| Service page | 0.25s | 0.64s | 0.031 | Passes all three |
| Article with sidebar | 0.25s | 0.80s | 0.144 | Fails CLS, header collapse |
Those three readings are the median of three runs each, ours, taken on 24 October 2026 in Chrome at a 390 pixel viewport with a 4G throttle, 4 times CPU slowdown and the cache disabled. They are lab numbers, not field data, so treat them as a starting diagnosis rather than a result. The point of the table is the pattern: the same theme passes on a short page and fails on a long one, which is why a single homepage score never tells you whether the site is healthy.
What we would do, in order. Week one: capture before readings so the fix can be proven, identify the shifting element in DevTools, and reserve its correct height. Week two: apply the reserved space, retest three times, and check the Search Console field data over the following 28 days, because that is when the change shows up in the report Google uses. If field data does not move, the cause was something else and the reading was noise.
What waiting costs. Layout shift is the cheapest speed problem to fix and the one visitors notice most, because they feel it as a mis-tap rather than as a delay. It does not show up in an enquiry report at all: the person who tapped the wrong button and left is not a row in your analytics.
When are speed fixes not enough?
There is a point where the theme or the plugin stack is the bottleneck and no amount of caching fixes it. The signs are consistent: TTFB is fine, images are compressed, caching is on, and LCP still will not come under 2.5 seconds because the page has to download and execute a framework before it can show anything. That is an architecture problem.
That decision has its own guide: whether to rebuild for speed or fix what you have answers the should I rebuild question, and this article answers how do I fix it. Read that one before you commission a rebuild, and read the bigger picture on website speed if you want the strategy rather than the checklist. Two related problems are worth checking at the same time: signs you have outgrown WordPress and plugins compared with custom features. Neither is a reason to rebuild on its own.
When your theme is the bottleneck, a rebuild is the cheaper answer. DigiFix builds WordPress and custom sites with the framework weight chosen up front, so speed is a design decision rather than a repair bill later.
What else affects WordPress page speed?
Two things that are not speed fixes but show up as them. A site with malware or a compromised plugin spends its time serving injected content, and the first symptom is often a page that suddenly takes four seconds. The security risks for small business WordPress sites guide covers what to check. The second is mobile behaviour: a page can load fast and still be unusable on a phone if the menu, form or tables do not adapt, which is what the mobile optimisation checklist and our guide to what responsive web design is cover.
What are the most common questions about page speed?
What is a good page load time in seconds?
Aim for a Largest Contentful Paint of 2.5 seconds or less, because that is the threshold Google publishes for the metric that measures when the main content appears. Under one second is excellent and over four seconds is poor by the same standard. Judged at the 75th percentile of real visits, so the slowest quarter of your traffic counts as well, which is usually mobile users on a weak connection.
Does page speed affect SEO rankings?
Yes, but as a tiebreaker rather than a trump card. Google’s own page experience guidance says Search always seeks the most relevant content, even if the page experience is sub-par, and that a great page experience can contribute to success where several pages are equally helpful. So speed rarely lifts a thin page and regularly decides a close contest between two good ones. It also affects conversion directly, which matters more to most businesses than the ranking.
Why is my WordPress site slow when the score is high?
Because the lab test does not load what your real visitors load. Third-party chat, analytics, heatmap and advertising scripts are frequently excluded from a lab run, and logged out lab visits skip the plugins that only fire for known users. Compare the lab score against the field data in Search Console. When they disagree, the field number is the one to trust, and the gap itself tells you the problem is in a script.
What replaced FID as a Core Web Vital?
Interaction to Next Paint replaced First Input Delay on 12 March 2024, and FID was deprecated in the same change. The practical difference is that FID only measured the delay before the very first interaction, while INP samples interactions across the whole visit and reports a high percentile. That makes INP stricter and harder to game, and it means a page that passed FID comfortably can still fail INP.
How long does it take to improve page speed?
The big wins are usually a day or two: caching, image compression and removing the worst plugins. Field data then needs up to 28 days to reflect the change in Search Console, so patience is part of the process. Structural problems, such as a page builder loading a framework before any content appears, take longer because the fix is a rebuild of the templates that carry the traffic.
Is a speed plugin worth installing on WordPress?
Usually yes, but one, not three. A single caching plugin that handles page cache, minification and lazy loading will do most of the work, and stacking several that each try to minify and defer the same files is a reliable way to break a site. Configure it slowly, clear the cache after each change and check a real page after every step. If your host already provides server level caching, use that and keep the plugin for the parts the host does not cover.
Does image compression really make a difference?
On most sites it is the largest single saving available, because images are the biggest part of the page weight and they are usually uploaded at camera resolution. A hero image at 4000 pixels wide displayed at 800 pixels wastes most of its bytes on detail nobody sees. Resize to the display size, compress, serve WebP or AVIF, and add srcset so phones get a smaller file again. That combination regularly halves the page weight.
DigiFix is a Melbourne digital agency working on digital marketing, web development and SEO for Australian businesses. Start with the web development services page, see recent client work in the portfolio, read about DigiFix and the team, and find more guides like this in the DigiFix blog.
Talk to the team that fixes these every week. Bring your URL and we will show you the three changes worth doing first, in plain English, with no obligation.