Updated 9 October 2026
Your WordPress website is slow. Your first thought is to install a speed plugin. Your second is to change hosting. Your third is to replace the whole website.
Before doing any of those, find out what your visitors are actually waiting for.
A slow site does not automatically mean the existing website needs to be scrapped. The delay could come from the server, an oversized hero image or code that keeps a phone’s browser busy. Those problems need different fixes. WordPress performance overview.
Measure first, fix the largest identified problem and check the result. Avoid changing ten settings at once or replacing the design before you have established that it is necessary.
The goal is not a beautiful number in a speed test. It is a website people can comfortably use. A green score is not much consolation if your contact form stopped working during the “optimization.”
1. Measure important pages, not just the homepage
Open Google PageSpeed Insights and test your homepage, main service page and contact page. For an online store, add a product page and a category page. These are my suggested starting points, not a universal test suite.
Check mobile and desktop separately. PageSpeed combines a controlled Lighthouse test with real-user data where available. They do not measure precisely the same circumstances. Google’s explanation.
Three important metrics are:
| Metric | What does it describe? | Good result |
|---|---|---|
| LCP | When does the largest content element in the viewport appear, such as a main image or text block? | 2.5 seconds or less |
| INP | How quickly does the page show a visual response to a click, tap or keypress? | 200 milliseconds or less |
| CLS | How much does the layout shift unexpectedly? | 0.1 or less |
These are Google’s good Core Web Vitals thresholds. Real-user assessment uses each metric’s 75th percentile, with mobile and desktop evaluated separately. At least three-quarters of measured experiences should meet the relevant threshold. Metric definitions.
Save your baseline. I recommend running three comparable tests per page and using the median result rather than picking the most flattering run. Record the date and test settings as well.
PageSpeed’s real-user view covers the previous 28 days. Check whether it describes the individual URL or the whole origin. Low-traffic pages may have no real-user data available. How PageSpeed handles data.
2. Back up the site and bring its software up to date
Before changing plugins, the theme or server settings, back up both the database and the files. Check how you would restore them. A WordPress content export is not a substitute for a complete site backup. WordPress backup guidance.
Test substantial changes on a staging copy. For a store, first ensure staging cannot send real customer emails or take live payments. Do not overwrite new production orders with an older staging database.
Update WordPress, the theme and active plugins, checking compatibility and functionality at each stage. As of 9 October 2026, the latest WordPress release is 7.1.3, published on 6 October with security and bug fixes. Do not postpone security updates until the performance project is complete. Official release announcement.
Updating is part of maintaining a website. It is not evidence that the particular cause of slowness has been fixed.
3. Enable page caching without duplicating the same job
For an ordinary content page, you can serve previously generated HTML instead of making WordPress rebuild the page for each visitor. This is page caching. WordPress caching guidance.
First ask your hosting provider whether it already supplies this. Choose a plugin only after understanding what is currently running.
WP Super Cache is a free option for serving static HTML copies. LiteSpeed Cache is worth considering on LiteSpeed hosting; its page-caching functionality requires an appropriate server component or QUIC.cloud. Installing the plugin on arbitrary hosting does not provide that functionality by itself. WP Rocket is a paid alternative combining caching with other optimization features. WP Super Cache · LiteSpeed requirements · WP Rocket.
My recommendation is to give one solution control of each job. Enabling two full-page caching plugins is not a sensible starting point. That does not mean different caching layers cannot work together: page caching, browser caching and persistent object caching do different things. Types of caching.
Ask your host or developer to verify that the public page is actually being served from cache. After making changes, also confirm that editing content removes the outdated copy when it should. WooCommerce requires additional exclusions, covered below.
4. Reduce image size and load the main image at the right time
Start with the large image in the first screen. Is a phone downloading the same file as a wide desktop display? Is a small product card accidentally using the original photograph?
Compare the displayed image size with the file being downloaded, allowing for screen pixel density. srcset and sizes help the browser choose an appropriately sized version. Your theme or page builder needs to output them correctly. How responsive images work.
For photographs, try WebP or AVIF and compare file size and visible quality. WordPress has supported AVIF since version 6.5 when the hosting environment supports processing it. Format support does not mean your old JPEGs have automatically been converted. Check what visitors actually receive. WordPress AVIF support.
The most important exception: do not lazy-load the LCP image with loading="lazy". That image should arrive early. Reserve lazy loading for images below the initial viewport. Where needed, fetchpriority="high" can raise the main image’s priority, but it should not be added indiscriminately to every image. Google’s LCP guidance.
WordPress can already set loading attributes itself. Inspect the existing HTML before adding another optimization, particularly with custom themes and page builders. WordPress image-loading behavior.
Give images and videos dimensions or an aspect ratio so the browser can reserve space. This helps avoid text jumping down when an image arrives. Reducing layout shifts.
Do not bulk-delete original images until you have checked the new versions, thumbnails, product views and backup.
5. Assess plugin impact, not just plugin count
“You have too many plugins” is not a diagnosis. Find out which plugin is doing unnecessary work and where that work happens.
List your installed extensions and the purpose of each. My first candidates for investigation would be overlapping features, site-wide widgets and functionality that is no longer used.
For example, does a blog article need the booking system’s code? Are you using every module from that page-builder add-on pack? Has the same analytics integration been added through both the theme and a plugin?
Query Monitor helps developers inspect database queries, PHP errors, enqueued scripts and outgoing server-side HTTP requests. It is a diagnostic tool, not a switch that makes a website faster automatically.
Test changes individually on staging. Do not remove security, accessibility or payment functionality simply because the test produces a smaller number without it.
Apply the same reasoning to the theme: start with one expensive template or component. Replacing the entire design is more defensible when you have demonstrated a widespread problem that cannot be fixed economically in smaller pieces.
6. Reduce JavaScript and third-party overhead
A page may look ready while its menu or buttons still fail to respond promptly. JavaScript processing can keep the browser’s main thread busy. This affects INP, not just the initial load. Google’s INP guidance.
Review chat widgets, maps, video players, social feeds and marketing scripts. They can add downloads and processing work. Loading third-party JavaScript.
My first question would be whether visitors need each feature immediately. A contact section could initially show an address and a button to open the map. A video player could load after someone chooses its preview rather than at the start of every visit.
A plugin’s “Delay JavaScript” feature may help, but postponing everything until the first click is not a safe blanket strategy. Immediately test the mobile menu, forms, consent manager and payment integration. Exclude essential scripts from the delay where necessary. WP Rocket’s feature documentation.
Likewise, do not automatically combine all JavaScript files. With HTTP/2, combining is not inherently beneficial, and minifying code does not remove the work it performs. Minification versus combining.
7. Simplify font loading and prevent layout shifts
Check how many typefaces and styles the page actually loads. Are all of them in use?
I would start by retaining necessary styles, using WOFF2 for web fonts and preloading only critical font files. Preloading every font can compete with other important resources. Google’s font recommendations.
font-display: swap lets text appear in a fallback font before the web font arrives. However, switching to a font with different dimensions can move the layout. Check headings and button widths as well as whether text appears promptly. Fonts and layout stability.
For an Estonian version, specifically test õ, ä, ö and ü. Reducing a font’s character set should not leave parts of the text in a different typeface or break people’s names.
8. Investigate hosting and PHP; add a CDN for a reason
When the delay occurs before HTML arrives, image compression alone cannot solve it. Investigate server response, WordPress processing and hosting resources. Do not automatically blame the hosting provider after seeing one slow response. WordPress server and performance guidance.
Ask your host whether page caching and PHP OPcache are functioning and whether any resources become saturated under load. Measure requests that cannot be served from full-page cache as well. WordPress server environment guidance.
PHP status on 9 October 2026: the general WordPress requirements page recommends PHP 8.3 or later; its hosting handbook recommends 8.4 or later for production. PHP 8.4 and 8.5 are actively supported. PHP 8.2 security support ends on 31 December 2026. WordPress requirements · Hosting recommendation · PHP support schedule.
In practice, test a PHP 8.4 or 8.5 branch compatible with your theme and plugins, using an up-to-date patched release. Changing PHP versions is not a promise of a particular percentage improvement.
A content delivery network, or CDN, can deliver files from locations closer to visitors. It is especially worth measuring when your audience spans multiple countries. How CDN caching works.
An important detail: Cloudflare does not cache HTML by default. Connecting a CDN therefore does not prove that WordPress no longer has to build the page at the origin. HTML caching needs an appropriate configuration, including exclusions for personalized content. Cloudflare’s default behavior.
9. Check the database and WooCommerce’s specific requirements
If public pages are fast but the dashboard or purchase journey is slow, measure those separately. Do not try to diagnose them from a homepage speed score alone.
WordPress Site Health may flag autoloaded options: settings that WordPress loads automatically. When their total size is substantial, investigate which theme or plugin produces the data. Do not delete unfamiliar database rows simply to make the database look cleaner. WordPress’s Site Health check.
Persistent object caching can allow data to be reused across requests. Redis, for example, needs a functioning server service and a WordPress connection; installing a plugin alone is insufficient. Its usefulness depends on the workload. WordPress object caching.
For WooCommerce, verify full-page cache exclusions: the cart, checkout and account must preserve customer-specific content. Use the store’s actual URLs, including translated versions, and verify the exclusions in every HTML caching layer, including the CDN. WooCommerce caching guidance.
Test with two genuinely separate browser sessions, such as different browsers or separate profiles. One customer’s cart must never appear for another customer. Two private windows in the same browser may not provide independent sessions, so do not build the test around that assumption. Chrome’s explanation of an Incognito session.
For a store with many orders, also review HPOS, which stores order data in dedicated database tables. Migrating an existing store requires extension compatibility checks and data synchronization. It is not a universal speed switch or a replacement for testing payments and order processing. WooCommerce’s HPOS guide.
10. Measure again and test real user journeys
After each meaningful change, test the same pages with comparable device, network and cache conditions. Distinguish a first visit from a repeat visit, and a cached response from a newly generated page.
Keep a simple change log: what changed, which page you tested, which metric improved and whether the features still work. This tells you which change helped and which one to roll back.
An ordinary page-load test does not exercise every user action. Try the menu, search, filters and form submission on a phone. Investigating INP requires testing interactions, not just navigation. Diagnosing slow interactions.
For a store, check product variations, quantity changes, coupons, delivery choices and a test payment on staging. Check behavior after both accepting and declining optional consent choices. The improved page must also work for someone who is not using your browser and is not logged in as an administrator.
Real-user data covering a 28-day period changes gradually, not immediately after clearing a cache. Understanding the reporting window.
Where should you start when you cannot tackle everything?
Use the test results to make decisions rather than treating them as a report to file away.
| Observed problem | What should you investigate first? |
|---|---|
| A long wait before the page begins appearing | Page caching, PHP processing and server response |
| Text appears, but the large hero image arrives late | Image size, discovery and loading priority |
| Menus or buttons respond slowly | JavaScript, third-party widgets and the specific interaction |
| Content moves around while loading | Image dimensions, fonts and late-inserted content |
| Public pages are fast, but the dashboard or checkout is slow | Database work, outgoing requests and dynamic processing |
This is a diagnostic starting order assembled from the guidance above, not a diagnosis of your website. Start with one important template, improve it and then apply the successful fix to other pages using the same implementation.
Frequently asked questions
Can you speed up WordPress for free?
Yes, some improvements do not require buying a tool. PageSpeed Insights and WP Super Cache are freely available. Checking existing caching, correcting an oversized image and removing unnecessary functionality do not inherently require another subscription. Development work or better hosting may still cost money. PageSpeed Insights · WP Super Cache.
Do you need a PageSpeed score of 100?
No. Google uses Core Web Vitals in its ranking systems, but good results do not guarantee a top search position. Google advises against chasing perfect scores solely for SEO. Prefer a functioning website that feels fast to the people using it. Google’s page experience guidance.
Should you change the theme or rebuild the whole website?
Not before diagnosing the problem. Compare the cost of improving the existing implementation with what a new theme or website would actually solve. A larger rebuild may make sense when problems are widespread or essential dependencies are no longer maintained. One late-loading image is not sufficient justification by itself.
A faster website starts with the right diagnosis
The most useful first step is not another plugin or another website. It is a clear answer to one question: what is the visitor waiting for?
Once you know that, you can choose changes that improve an important page while preserving what already works.
Is your WordPress website slow, but you are not sure where to start? Send me the website address and describe where you notice the delay: the homepage, mobile browsing, the dashboard or checkout. We can discuss improving the existing website without automatically starting with a complete rebuild.
Sources checked on 9 October 2026. Recommendations draw on official documentation from WordPress, Google, PHP, WooCommerce and the named tools. This is a general guide, not an audit of a particular website or a guarantee of a specific speed improvement.
Need help with a slow WordPress website?
I can measure the starting point, identify what slows your site down and implement agreed fixes. The service includes comparable before-and-after measurements and checks of the forms or shopping steps affected by the work.
