To speed up a WordPress site, measure first, then fix the slowest layer. Your PageSpeed Insights field data shows whether the server, the images or the scripts are holding pages back. Then apply the fixes below in order: hosting and PHP, caching and CDN, images and fonts, Elementor settings, plugins and scripts, and finally the database.
Instead of a random list of tips, this guide maps each symptom to the fix that addresses it, with the real settings in WordPress, Elementor and your hosting panel. Re-test after each change so you know what helped.
For the Core Web Vitals thresholds themselves, read our guide to why slow Core Web Vitals cost you customers.
Key takeaways
- Diagnose before you optimize: PageSpeed Insights field data shows whether the server, images or scripts are the bottleneck.
- WordPress.org recommends PHP 8.3 or greater, and PHP 8.1 no longer receives security fixes.
- The WordPress handbook names page caching as the quick fix with the biggest benefit for the least effort.
- Never lazy-load the hero image: give it priority and serve it as a correctly sized WebP or AVIF file.
- Elementor’s Performance tab has image, background and font settings worth enabling, but simpler layouts matter more than any setting.
How do you find out what is slowing down your WordPress site?
Run your key pages through PageSpeed Insights and read the field data at the top before you look at the score. Google explains that field data comes from real Chrome users over the previous 28 days, while the Lighthouse score underneath is a simulated test meant for debugging.
Test the templates that earn money, such as a service page, a product page and the contact page, not only the home page. Low-traffic pages fall back to domain-level data, or show none.
Match the symptom to the fix
| What you see | Likely cause | Start with |
|---|---|---|
| Slow Time to First Byte (TTFB) in field data | Underpowered hosting, old PHP, no page cache, distant server | Fixes 1 to 5 |
| Slow Largest Contentful Paint with a quick TTFB | Heavy hero image, late fonts, render-blocking CSS | Fixes 6 to 10 |
| Slow Interaction to Next Paint | Too much JavaScript from plugins, builders and third-party tags | Fixes 10 to 13 |
| Slow admin, cart or checkout while cached pages are fine | Heavy queries, bloated autoloaded options, no object cache | Fixes 14 and 15 |
Two free tools narrow it down. Tools > Site Health flags a missing page cache, a missing persistent object cache and oversized autoloaded options. The free Query Monitor plugin lists slow database queries and names the plugin or theme behind each one; it’s a developer tool, so run it on staging.
How to speed up a WordPress site: the 15 fixes in order
Work from the server outward. The table shows each fix, the metric it mainly improves and the typical effort.
| # | Fix | Mainly improves | Effort |
|---|---|---|---|
| 1 | Move to hosting that fits your traffic | TTFB | Medium |
| 2 | Run a current PHP version | TTFB | Low |
| 3 | Turn on full-page caching | TTFB and LCP | Low |
| 4 | Enable compression and browser caching | LCP | Low |
| 5 | Put a CDN in front of the site | TTFB and LCP | Low to medium |
| 6 | Resize images and serve WebP or AVIF | LCP | Medium |
| 7 | Prioritize the hero image | LCP | Low |
| 8 | Lazy-load everything below the fold | LCP | Low |
| 9 | Load fewer fonts, faster | LCP and CLS | Low |
| 10 | Trim page-builder bloat | LCP and INP | Medium to high |
| 11 | Remove or replace heavy plugins | TTFB and INP | Medium |
| 12 | Defer non-critical JavaScript | LCP and INP | Medium |
| 13 | Delay or drop third-party scripts | INP | Medium |
| 14 | Clean up the database | TTFB on uncached pages | Low |
| 15 | Add a persistent object cache | TTFB on uncached pages | Low to medium |
Fixes 1 to 5: How do you speed up the server side?
If TTFB is slow, fix the server first: no amount of image work makes up for a late first byte.
1. Move to hosting that fits your traffic
Crowded shared hosting is a common cause of slow response times. Managed WordPress hosting or a VPS gives your site dedicated resources and usually includes server-level caching. Location matters too: the WordPress handbook notes that the distance between server and visitor affects speed.
2. Run a current PHP version
WordPress.org recommends PHP 8.3 or greater. Check your version under Tools > Site Health > Info > Server, test the upgrade on staging, then switch it in your hosting panel (MultiPHP Manager in cPanel). PHP 8.1 stopped receiving security fixes at the end of 2025, and PHP 8.2 follows on December 31, 2026.
3. Turn on full-page caching
Without a page cache, WordPress runs PHP and database queries to build every page for every visitor. A cache stores the finished HTML and serves it directly. Use your host’s server cache if it offers one, or a single plugin such as WP Super Cache, W3 Total Cache, WP Rocket, or LiteSpeed Cache on LiteSpeed servers.
Never run two page caches at once, and exclude cart, checkout and account pages on WooCommerce stores. Site Health reports whether it detects a page cache and whether server response time is under its 600 ms threshold.
4. Enable compression and browser caching
Ask your host to confirm Brotli or Gzip compression for HTML, CSS and JavaScript, and long Cache-Control headers on static files. Most caching plugins and CDNs can set both. Returning visitors then load images, stylesheets and scripts from their own browser instead of your server.
5. Put a CDN in front of the site
A content delivery network serves copies of your images, CSS and JavaScript from locations near each visitor, and some also cache whole pages at the edge. Whether you use Cloudflare, Bunny.net or your host’s CDN, confirm it purges its cache when you publish changes.
Pakistan note
If most of your customers are in Pakistan but your server sits in the US or Europe, every uncached page request travels between continents. Pick a data center nearer your audience if your host offers one, put a CDN in front, and test on a local mobile connection. Selling mainly to the UK or the UAE? Host near those customers instead.
Fixes 6 to 9: How do you make images and fonts load faster?
Once the server is quick, images and fonts usually decide Largest Contentful Paint. The goal is to send the hero image first, at the right size, and everything else later.
6. Resize images and serve WebP or AVIF
Upload images at the size they display, not straight from a camera or design tool. A 4,000-pixel photo shown in an 800-pixel column wastes data on every phone. WordPress creates smaller copies on upload and serves them with responsive srcset markup, supports WebP, and since version 6.5 accepts AVIF when your server’s image library supports it.
To convert an existing library of JPEGs and PNGs, use an image optimization plugin or the WordPress Performance Team’s Modern Image Formats plugin. Check the output quality on a few images before converting everything.
7. Prioritize the hero image
The LCP element on most business pages is the hero image or main headline. Since WordPress 6.3, core adds fetchpriority="high" to the image it judges most likely to be the LCP element and avoids lazy-loading images near the top of the page.
Page builders and sliders can undo this. A hero set as a CSS background image is discovered late, and a slider may download several large images before showing one. Use a single, real image element for the hero wherever you can.
8. Lazy-load everything below the fold
WordPress adds native loading="lazy" to content images and iframes by default, so a separate lazy-loading plugin is often redundant. The gaps are background images, sliders and video embeds. For YouTube and map embeds, show a static preview that loads the real player only when clicked, a pattern known as a facade.
9. Load fewer fonts, faster
Each font family and weight is another file to download before text looks right. Stick to two families and only the weights you use, serve WOFF2 files, and set font-display to swap (text appears at once in a fallback font) or optional (fastest, though the web font may not show on slow connections).
Self-hosting fonts removes a connection to Google’s servers, but web.dev notes it isn’t automatically faster in practice. It pays off most when you serve files through a CDN, or when privacy rules make third-party font requests a problem.
How do you speed up WordPress with Elementor?
Turn on Elementor’s built-in performance settings, then simplify the layouts themselves. Settings help, but a page built from deeply nested sections and a dozen add-on widgets will stay heavy whatever you toggle.
10. Trim page-builder bloat
| Setting | Where | What it does | Recommendation |
|---|---|---|---|
| Optimized Image Loading | Performance tab | Adds fetchpriority=”high” to the LCP image and lazy-loads images below the fold | Enable |
| Lazy Load Background Images | Performance tab | Lazy-loads every background image except the first | Enable, then check hero sections |
| Optimized Gutenberg Loading | Performance tab | Dequeues unused block editor scripts and styles | Enable if pages are built only in Elementor |
| Load Google Fonts Locally | Performance tab | Serves Google Fonts from your server; disabled by default since Elementor 3.32.1 | Enable when you have a CDN |
| Google Fonts Load | Advanced tab | Sets how fonts display while loading: Swap, Optional and others | Swap or Optional |
| Element Caching | Features tab (experimental), then each widget’s Advanced tab | Stores rendered widget HTML to reduce server work | Only for static widgets without dynamic tags |
Beyond settings, rebuild old section-and-column layouts with Flexbox containers, which Elementor says use one wrapper element instead of two. Also drop add-on packs you keep for one or two widgets: Elementor loads assets only for widgets on the page, but some add-ons load theirs everywhere.
If a theme or builder setup is past saving, a lean rebuild by our web development team can cost less than months of tuning. Choosing a builder for a new site? Our comparison of Elementor and the block editor covers the trade-offs.
Fixes 11 to 13: How do you stop plugins and scripts slowing WordPress?
What each plugin loads matters more than how many you have. One heavy slider or social feed can cost more than ten small utility plugins, so measure before you delete.
11. Remove or replace heavy plugins
The WordPress handbook calls deleting unnecessary plugins the first and easiest performance step. On staging, deactivate plugins one at a time and re-test, or check Query Monitor for the slowest queries, and replace all-in-one plugins you use for one feature. Our list of essential WordPress plugins for business sites shows what most sites actually need.
12. Defer non-critical JavaScript
Scripts in the page head block rendering until they download and run. WordPress 6.3 added defer and async loading strategies for developers, and most caching plugins can defer JavaScript or delay it until the visitor interacts. Afterwards, test menus, sliders, forms and cookie banners, which delayed scripts often break.
13. Delay or drop third-party scripts
Chat widgets, heatmaps, ad pixels, review badges and embedded feeds run other companies’ code and often drag down Interaction to Next Paint. List every tag in your theme, plugins and Google Tag Manager, remove duplicates and tools nobody checks, and load the rest after the page is interactive or after consent. A chat widget rarely needs to load before someone clicks it.
Fixes 14 and 15: How do you speed up the WordPress database?
Database work matters most on pages that can’t be cached: the admin area, WooCommerce carts and checkouts, site search and member areas. Clear out clutter first, then add an object cache.
14. Clean up the database
- Autoloaded options: WordPress loads these on every request. The WordPress handbook suggests keeping them under 800 KB, and since WordPress 6.6 Site Health raises a critical issue above that. Large entries often belong to plugins you removed long ago.
- Post revisions: cap them with
define( 'WP_POST_REVISIONS', 5 );in wp-config.php, then delete old revisions with a cleanup plugin. - Expired transients, spam and trash: clear them with a cleanup plugin or WP-CLI, for example
wp transient delete --expired.
Back up the database before any cleanup, since a plugin that deletes the wrong option can break the site. Recurring cleanups belong in your WordPress maintenance checklist rather than being a one-off job.
15. Add a persistent object cache
A persistent object cache such as Redis or Memcached keeps the results of repeated database queries in memory, so WordPress doesn’t fetch the same options on every request. The handbook says this shortens TTFB and protects the database during traffic spikes. Your host must provide the cache server; you then install the matching object cache plugin.
How TechZone can help
TechZone builds and speeds up WordPress and Elementor sites for businesses in Pakistan, the UK, the UAE, the USA, Canada and Australia. We start from your field data and a staging copy, find the metric that fails, fix the biggest bottleneck first and show you before-and-after measurements. If tuning won’t be enough, we’ll tell you plainly. Our WordPress maintenance plans cover this work every month. Explore our WordPress design and development services, or book a free 30-minute consultation to walk through your PageSpeed Insights report together.
Frequently asked questions
Which caching plugin is best for WordPress?
The best WordPress caching plugin depends on your server. On LiteSpeed servers, LiteSpeed Cache uses the server’s own cache. Managed WordPress hosts often include server caching, so an extra plugin may conflict with it. Elsewhere, WP Super Cache and W3 Total Cache are free options and WP Rocket is a paid one. Whichever you choose, run only one page cache at a time.
Why is my WordPress site slow only when I’m logged in?
A WordPress site is often slow only for logged-in users because page caches skip logged-in sessions, so every admin page is built fresh with PHP and database queries. Heavy plugins, a bloated autoloaded options table and the admin toolbar add to the load. A persistent object cache and a database cleanup usually help most with a slow logged-in experience.
Can a speed optimization plugin break my WordPress site?
Yes, a speed optimization plugin can break a WordPress site. Settings that delay JavaScript, combine files or remove unused CSS often stop menus, sliders, forms or cookie banners from working. Enable one setting at a time on a staging copy, test your key pages and forms after each change, clear every cache, and keep a recent backup before touching the live site.
Does a lightweight theme make WordPress faster?
A lightweight theme usually makes WordPress faster, because it loads less CSS, JavaScript and markup on every page. The WordPress handbook says a fast, lightweight theme performs much more efficiently than a heavy, graphics-laden one. Before switching, check what your current theme loads in PageSpeed Insights, since a theme change also means rebuilding layouts and retesting the whole site.
How much does WordPress speed optimization cost?
WordPress speed optimization costs depend on whether the problem is configuration or structure. Configuration fixes, such as caching, PHP upgrades, image settings and a CDN, are usually the smaller job. Structural problems, such as a heavy theme, nested page-builder layouts or plugins the site depends on, can take far longer. Ask for a written scope that lists the fixes and includes before-and-after measurements.
