WORDPRESS PERFORMANCE / CORE WEB VITALS
Why Is My WordPress Website Slow? A Practical Core Web Vitals Checklist
A slow WordPress site is rarely fixed by adding one more optimisation plugin. The real bottleneck can sit in hosting, images, fonts, JavaScript, third-party tracking, database work, theme code, layout shifts or a plugin that runs expensive work on every page.
THE SHORT ANSWER
WordPress is not automatically slow — but it makes it easy to accumulate things that are.
A fast site needs a healthy chain from server response to rendered content and usable interactions. Google’s current Core Web Vitals targets classify good field performance at LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less at the 75th percentile. Those metrics are useful because they point to loading, responsiveness and visual stability rather than rewarding one synthetic score.
If a WordPress site takes five seconds to feel ready, the useful question is not “which cache plugin should I install?” It is “what is the browser waiting for?”
A page can be slow because the server takes too long to respond, the hero image is several megabytes, fonts block rendering, a page builder outputs heavy markup, third-party scripts compete for the main thread or an interactive widget runs too much JavaScript after the page appears.
Those causes need different fixes. Caching can hide some server work, but it cannot make an oversized image smaller. Compressing images will not fix a chat widget that blocks interactions. Removing one plugin will not help if the hosting environment is saturated before WordPress even starts rendering the page.
The practical approach is to measure representative pages, identify the slowest stage of the experience and improve the architecture in the order that gives users the biggest benefit.
01 / READ THE RIGHT METRIC
Core Web Vitals tell you which part of the experience is weak — not exactly which plugin to delete
Treat the metrics as symptoms. The diagnosis comes from the page, network and browser work behind them.
LCP — main content appears late
A poor LCP often points to slow server response, a large hero image, render-blocking CSS or fonts, or a main element that is only discovered late in the loading process.
LoadingINP — interactions feel delayed
A poor INP usually means the browser is busy when the user clicks, taps or types. Heavy JavaScript, complex widgets and third-party scripts are common contributors.
ResponsivenessCLS — the page moves unexpectedly
Layout shifts often come from images without reserved dimensions, late font swaps, banners inserted above content or interface elements that change size after load.
Visual stabilityField data — what real users experience
Lab tools are excellent for diagnosis, but Core Web Vitals are evaluated from real-user field data where enough data exists. Look at both rather than optimising one screenshot of a test run.
Real-world experience02 / DIAGNOSE IN THE RIGHT ORDER
Start at the server, then follow the page through the browser
This order prevents you from polishing front-end details while the page is still waiting seconds for the first response.
Check server response and caching
Measure whether the HTML arrives quickly. Hosting limits, uncached PHP work, slow database queries or remote API calls can delay everything that follows.
Find the LCP element
Identify the largest visible element above the fold. If it is an image, check dimensions, format, compression, loading priority and whether the browser can discover it immediately.
Inspect CSS, fonts and render blocking
Look for large stylesheets, unnecessary font families and resources that must load before meaningful content can be painted.
Measure JavaScript and third parties
Analytics, chat, maps, booking tools, ads and plugin scripts can all occupy the main thread. Remove what does not justify its cost and delay what can wait.
Test on mobile and slower conditions
A desktop office connection can hide problems. Check the pages and devices your real customers are likely to use.
03 / HOSTING + WORDPRESS BACK END
If the server is slow, every front-end optimisation starts late
The browser cannot render HTML it has not received yet.
Use hosting appropriate for the workload
A brochure site, high-traffic publication and busy WooCommerce store place very different demands on PHP workers, memory, database and storage.
Use full-page caching where the page can be cached
Cached public pages can bypass repeated WordPress work. Logged-in, cart and personalised pages need more careful rules.
Keep PHP and WordPress current
Supported versions bring performance, compatibility and security improvements. Updates should still be tested before production changes.
Remove expensive background work
Backups, imports, search indexing, scheduled jobs and API syncs can compete with customer requests if they are badly timed or repeatedly fail.
Investigate database-heavy plugins
Large option tables, repeated queries and unbounded logs can slow WordPress even when the front-end page itself looks simple.
Use object caching when the workload benefits
Persistent object caching can reduce repeated database work for suitable sites, but it is not a substitute for fixing inefficient queries or bloated data.
04 / IMAGES, FONTS + MEDIA
The fastest image is the one sized for the space it actually occupies
Media is often the largest part of the page, especially on visual WordPress sites.
Resize before delivery
Do not send a 3000-pixel photograph to a card that displays at 600 pixels. Responsive image markup should let the browser choose an appropriate file.
Match file to display sizeCompress with modern formats
WebP or AVIF can reduce image weight significantly, but quality still matters. The right format is the one that preserves the visual result at a sensible size.
Reduce bytes, not quality blindlyPrioritise the hero, lazy-load what follows
The primary above-the-fold image usually needs early discovery. Images far below the fold can wait until the user approaches them.
Load in visual priorityKeep fonts disciplined
Every family, weight and style adds another file or request. Use the weights the design actually needs and avoid loading large font sets for one decorative sentence.
Fewer font resources05 / JAVASCRIPT + THIRD-PARTY COST
Every widget asks the browser for time — decide which ones deserve it
A page can paint quickly and still feel slow if the browser is too busy to respond to the customer.
WordPress plugins often load JavaScript across the whole site even when their feature appears on only one page. Page builders, sliders, animation libraries, cookie tools, chat systems, booking widgets, maps and marketing tags can all add work after the initial HTML arrives.
The first fix is not always minification. If a script serves no meaningful purpose, removing it is stronger than compressing it. If it is useful only after interaction, load it later. If a plugin adds a large dependency for one small feature, consider a lighter implementation.
Third-party scripts deserve special attention because their performance is partly outside your control. Keep the tools that produce measurable business value and be willing to remove tools that create more delay than benefit.
- Load scripts only on the pages that use them where practical
- Delay non-essential marketing and interface scripts
- Avoid duplicate analytics or tag implementations
- Replace heavy widgets when a simpler interaction does the job
- Retest after each major removal so you know what actually changed
06 / PLUGINS + THEME WEIGHT
Plugin count is a weak metric; plugin behaviour is what matters
Ten focused plugins can be lighter than one extension that runs complex work on every request.
Check what loads site-wide
A plugin used on one landing page should not automatically send large CSS and JavaScript bundles to every blog post, service page and checkout step.
Scope assets to where they are neededAvoid overlapping optimisation layers
Two cache plugins, several image optimisers or multiple security layers can conflict and make troubleshooting harder without improving the result.
One clear owner per jobTreat the theme as application code
A theme can add queries, scripts, fonts and layout systems before plugins even start. Performance work needs to consider the complete stack rather than blaming plugins alone.
Measure the whole front endRemove abandoned functionality
Old sliders, shortcodes, tracking tools and unused integrations can survive redesigns for years. If the business no longer uses the feature, the code should not keep taxing every visit.
Delete what the business no longer needs07 / CACHING IS A TOOL, NOT A CURE
Caching can make repeated work cheaper, but it cannot make unnecessary work valuable
A cache is powerful when the content can be reused. It is not a reason to keep a bloated page architecture.
FIX THE SOURCE FIRSTUse caching to reduce repeated server and delivery cost after you have removed obvious waste from the page.
Page caching, browser caching and a CDN can all help, but a cached page can still send oversized media, too much JavaScript and unstable layout to the browser. Performance has to be healthy on both sides of the request.
08 / PERTH BUSINESS CONTEXT
Your customers may be on fast Perth fibre, mobile data in a car park or a phone sharing a busy network — the website has to cope with more than your office connection
Performance decisions should reflect the devices, locations and journeys behind the business.
A tradie website may receive most enquiries from phones. A Fremantle hospitality site may depend on mobile menus, bookings and maps. A Cannington retailer may serve image-heavy product pages. An Osborne Park B2B site may have fewer visits but larger documents, product systems or tracking integrations.
The optimisation priorities therefore change with the page. We test the templates that carry real commercial intent — home, service, product, checkout, landing and enquiry pages — rather than assuming one homepage score represents the entire site.
Perth CBDSubiacoFremantleJoondalupOsborne ParkWannerooMidlandCanningtonRockingham
09 / PRACTICAL SPEED CHECKLIST
If your WordPress site feels slow, check these in this order before rebuilding anything
The goal is to isolate the bottleneck with the least disruption to the live site.
Test several real page types
Measure the homepage, a key service page, a blog post and ecommerce pages where relevant. One template can hide a problem another template exposes.
Compare field and lab data
Use real-user Core Web Vitals where available, then use lab traces to understand the resource, task or layout event causing the issue.
Check server response
If HTML delivery is slow before the browser starts rendering, investigate hosting, caching, PHP, database and remote dependencies first.
Optimise the actual LCP element
Do not compress every image blindly. Start with the image or content block that defines the main loading experience.
Audit JavaScript and third parties
Look for long tasks, unused bundles and services that block interaction without adding enough commercial value.
Reserve space for media and UI
Set image dimensions and stable component sizes so content does not jump while assets, fonts or banners load.
10 / TURN THE AUDIT INTO A FIX PLAN
Prioritise performance work by user impact, not by the number of warnings in a report
A useful optimisation plan starts with the pages and problems that affect the most valuable customer journeys.
Fix the largest shared bottleneck
If hosting or a global script affects every page, solve that before polishing one isolated image.
Improve the highest-value templates
Service, product, checkout and enquiry pages deserve priority because performance there can affect both search visibility and conversion.
Retest after each meaningful change
Performance fixes can interact. Measure again so you know which change helped and whether a new regression appeared elsewhere.
Watch field data over time
Real-user metrics do not update instantly. Monitor trends after deployment rather than expecting field reports to change the moment the cache is cleared.
Keep the site lean as it evolves
New plugins, campaigns, tracking tools and media can slowly rebuild the same problem. Performance is easier to maintain when every new feature has an owner and a purpose.
WORDPRESS SPEED + CORE WEB VITALS FAQS
Questions businesses usually ask when a WordPress site feels slow
The right answer depends on where the delay starts, so these answers focus on diagnosis before adding another layer of optimisation.
06 QUESTIONS
Clear answers to the decisions that usually affect cost, scope and ownership.
ANSWER
WordPress itself may not be the main cause. Slow hosting, uncached requests, heavy themes, oversized images, database-heavy plugins, third-party scripts and too much JavaScript can all create delay. Measure the page first so the fix targets the real bottleneck.
ANSWER
Google’s current good thresholds are LCP at 2.5 seconds or less, INP at 200 milliseconds or less and CLS at 0.1 or less, assessed at the 75th percentile of page loads. A site should aim to meet all three for most users, not just produce one high lab score.
ANSWER
It can help when repeated server work is a major part of the delay. It will not fix oversized images, heavy third-party JavaScript, unstable layout or a slow external service. Caching is one layer in the system, not a universal cure.
ANSWER
There is no useful universal number. One poorly built plugin can be more expensive than several focused plugins. What matters is what each plugin does on every request, which assets it loads and whether several tools are overlapping the same job.
ANSWER
Performance is part of page experience and slow pages can also hurt users before rankings become the issue. Core Web Vitals are not a substitute for relevance, content and authority, but improving a genuinely slow site can strengthen both usability and the technical quality of the page.
ANSWER
Often, yes. Hosting, caching, media, fonts, scripts, plugin behaviour and database issues can be improved without changing the visual design. A redesign becomes relevant when the theme or page architecture itself is a major source of weight or when the site needs broader UX changes at the same time.
TIRED OF GUESSING WHY THE SITE IS SLOW?
Show us the pages that matter to your customers — we will trace the delay from server response to real interaction and prioritise the fixes that change the experience.
Share your WordPress URL, the pages that feel slow, any recent changes and the customer actions that matter most. We can audit the stack, identify the bottlenecks and scope the performance work around evidence rather than plugin promises.