How to Speed Up Your WordPress Website: 23 Proven Fixes

Most WordPress sites are slow not because WordPress itself is slow, but because of the decisions made on top of it. The hosting plan was chosen to save $5 a month. The theme downloaded because it looked pretty. The twelve plugins were installed over two years and never revisited.

The good news is that most of those decisions are reversible. And when you fix the right things in the right order, the improvement is dramatic.

This guide covers everything you need to know about how to speed up your WordPress website, from the fixes that take five minutes to the advanced techniques most guides never touch. Every statistic is sourced to its original study. Every recommendation is based on what actually moves the metrics that matter.

Here is the quick answer: The biggest wins come from fast hosting, a properly configured caching plugin, and optimized images. Fix those three things and you will eliminate most of the problem. Everything else in this guide builds on top of that foundation.

Before we get into the how, it helps to understand exactly what you are dealing with. And the numbers here are genuinely surprising.

What Speed Does to Your Conversion Rate

Portent ran a study on over 100 million page views across B2B and B2C websites and found that a site loading in one second has a conversion rate of 3.05%. The same site loading in five seconds drops to 1.08%. That is not a small difference. That is the gap between a business that works and one that is slowly bleeding customers without knowing why.

For B2B sites specifically, Portent found that a one-second load time produces conversion rates three times higher than a five-second load time, and five times higher than a ten-second load time.

And here is the number that should make any site owner pay attention: Google partnered with Deloitte on a study called Milliseconds Make Millions. They measured 37 brands across retail, travel, and luxury sectors. Improving mobile load time by just 0.1 seconds produced an 8.4% increase in retail conversions and a 9.2% increase in average order value. One tenth of a second. Not one second. One tenth.

What Speed Does to Your Bounce Rate

Google and SOASTA Research found the following from studying mobile web behavior:

• When load time goes from one second to three seconds, the probability of a visitor bouncing rises by 32%.
• From one second to five seconds, that probability rises by 90%.
• From one second to ten seconds, it rises by 123%.

Additionally, 53% of mobile users will leave a page that takes more than three seconds to load. That is more than half your mobile traffic, gone before they have seen your content.

What Speed Does to Your Search Rankings

Google made page speed a mobile ranking factor in July 2018. Since 2021, Core Web Vitals have been part of Google’s page experience signals. And Google completed the move to mobile-first indexing in July 2024, which means your mobile performance is now what primarily determines where you rank.

According to January 2026 Chrome User Experience Report (CrUX) data, only 55.7% of websites pass all three Core Web Vitals. That means nearly half the web is still failing on the metrics Google uses to evaluate page quality.

A lot of speed optimization advice focuses on the wrong numbers. Before touching any settings, you need to know what you are actually trying to improve.

The Core Web Vitals: What Google Actually Measures

In March 2024, Google officially retired First Input Delay (FID) and replaced it with Interaction to Next Paint (INP). Any article still referencing FID as a Core Web Vital is giving you outdated information. This is confirmed in Google’s official Web Vitals documentation, last updated October 2024.

The three active Core Web Vitals are:

According to January 2026 CrUX data:

• 68.3% of origins achieve good LCP
• 87.1% achieve good INP
• 80.9% achieve good CLS
• Only 55.7% pass all three at the same time

LCP is the hardest one to pass. The 2025 Web Almanac reports that only 62% of mobile pages reach a good LCP score. If your WordPress site has one Core Web Vitals problem worth prioritizing, this is almost always it.

The Fourth Metric Worth Watching: TTFB

Time to First Byte (TTFB) is not a Core Web Vital, but it affects all three of them. TTFB is how long your server takes to respond before the browser can render anything at all. Google’s target is under 0.8 seconds. If your TTFB is over 1.8 seconds, you have a hosting or caching problem, and no plugin is going to fix it.

Check your TTFB first. If it is high, that is your starting point.

You cannot improve what you have not measured. Here is the process to establish a baseline.

Step 1: Run Google PageSpeed Insights on three URLs: your homepage, a key landing page, and a typical blog post. These three pages behave differently and often have different bottlenecks.

Step 2: Write down your numbers. Record LCP, INP, CLS, TTFB, total page weight in MB, and total request count. You need these to know whether anything actually improved.

Step 3: Test mobile first. Since Google evaluates mobile performance separately and mobile CWV data drives mobile rankings, that is your primary benchmark. Not desktop.

Step 4: Re-test after each individual change. This is where most people go wrong. They apply five changes at once and have no idea which one did anything. Apply one change, test, record the result, then move to the next.

Tools Worth Using:

Most slow WordPress sites have the same underlying problems. Here is how each root cause maps to the metrics it damages.

Understanding this table tells you where to start. There is no point in fine-tuning JavaScript deferral when your TTFB is 2.5 seconds because of a slow server. Fix the server first.

These are the highest-impact changes relative to the effort they take. Most site owners can work through all eight of these in an afternoon.

1. Get Hosting That is Actually Built for Speed

Fixes: TTFB, LCP | Effort: Low | Impact: Very high

Hosting is the foundation. Everything else depends on it. Shared hosting puts your WordPress site on a server with hundreds or thousands of other sites. When those sites spike in traffic, your site gets slower too. There is nothing you can configure on your end to prevent that.

What to look for in performance-focused hosting:

• Server-level caching that does not depend on a plugin
• PHP 8.2 or newer, easy to switch
• NVMe SSD storage
• NGINX or LiteSpeed web server
• Verifiable TTFB under 200ms on cached pages

A practical test: If your TTFB is above 800ms on a cached page, your host is the bottleneck. No combination of plugins closes that gap. Upgrading your plan or moving hosts typically delivers more improvement than anything else on this list.

2. Install a Caching Plugin and Configure it Properly

Fixes: TTFB, LCP | Effort: Low | Impact: Very high

By default, WordPress generates every page dynamically. Every visitor triggers PHP execution and database queries. Caching stores a static copy of each generated page and serves it directly, turning a 400ms process into a 20ms one.

A caching plugin is non-negotiable for any WordPress site. But there is a catch: installing it is not the same as configuring it. Most plugins work at perhaps 60% of their potential out of the box. Work through the settings.

Comparison of the Main Options:

One important note: do not run two caching plugins at the same time. They conflict and will usually make things worse. Pick one, configure it fully, then evaluate whether you actually need anything else.

3. Fix Your Images

Fixes: LCP, page weight | Effort: Low | Impact: Very high

Images are typically the largest files on a WordPress page and the most common reason for a failing LCP score. An unoptimized hero image can add two to four seconds to LCP on its own.

Three things to fix:

Format: Convert images to WebP. It compresses significantly better than JPEG or PNG at the same visual quality. ShortPixel, Imagify, and Smush can convert and compress your existing images automatically.

Dimensions: If an image displays at 800px wide but the file is 3,000px wide, you are sending three times more data than needed. Resize before uploading, or use a plugin that handles responsive image sizing.

Compression: Even properly sized images benefit from compression. Aim to keep images under 100KB where possible, and under 200KB for large hero images.

One advanced fix that most guides skip: Preload your LCP image. This tells the browser to fetch it immediately rather than waiting to discover it while parsing the rest of the page. Add this to your <head>:

<link rel=”preload” as=”image” href=”your-hero.webp” fetchpriority=”high”>

WP Rocket can add this automatically. It is one of the most reliable single-line LCP improvements available.

4. Add a CDN

Fixes: LCP, TTFB for distant visitors | Effort: Low | Impact: High

A Content Delivery Network stores copies of your static files (images, CSS, JavaScript, fonts) in servers around the world. Each visitor gets them from the location nearest to them rather than from your origin server.

For a visitor in London loading a site hosted in a US data center, a CDN eliminates hundreds of milliseconds of trans-Atlantic latency per asset. Cloudflare has a strong free tier that works with any host. Many managed WordPress hosts bundle CDN functionality.

One thing to be clear about: a CDN improves delivery of static assets, but it does not fix a slow TTFB for your main HTML document. That still comes from your origin server. CDN and fast hosting work together and neither replaces the other.

5. Switch to a Lightweight Theme

Fixes: LCP, TBT, page weight | Effort: Medium | Impact: High

A theme is not just a visual design. It determines how much CSS, JavaScript, and markup is loaded on every single page. Themes built to do everything often load 800KB to 1MB of assets most sites never use.

Speed-focused themes like GeneratePress, Kadence, Astra, or the default WordPress block themes load a fraction of that. Switching themes is more involved than installing a plugin, but for sites running heavy commercial themes it is often the biggest single improvement possible.

6. Audit Your Plugins and Remove the Ones You Do not Actually Use

Fixes: INP, server load | Effort: Low | Impact: High

Plugin count matters less than plugin quality and necessity. A well-coded plugin that does one thing adds almost no overhead. A poorly coded plugin that runs 30 database queries on every page load is a serious problem regardless of what else you do.

Simple audit process:

1. Go through your plugin list and deactivate anything you have not intentionally used in the past month.
2. Run a PageSpeed test before and after each deactivation.
3. Replace known heavy plugins with lighter alternatives where possible.

Common heavy plugins and lighter alternatives:

7. Update PHP to the Latest Stable Version

Fixes: Backend processing | Effort: Low | Impact: Medium-high

PHP is the language WordPress runs on, and each major release delivers real speed improvements. PHP 8.2 and 8.3 are noticeably faster than PHP 7.4 for WordPress workloads. The improvement is essentially free since it requires no code changes on a well-maintained site.

Check your PHP version in your hosting control panel. Update to the latest stable release. Do test on a staging environment first because a small number of older plugins have compatibility issues with PHP 8.x.

8. Enable GZIP or Brotli Compression

Fixes: Page weight, transfer time | Effort: Low | Impact: Medium

Compression reduces the size of text-based files (HTML, CSS, JavaScript) by 60 to 80% before they are sent to the browser. Brotli, the newer algorithm developed by Google, compresses 15 to 26% better than GZIP on average.

Most caching plugins enable GZIP automatically. Brotli is usually available as a setting at the host or CDN level. Confirm that compression is active by checking your response headers in WebPageTest. You are looking for Content-Encoding: gzip or Content-Encoding: br.

Once the foundation is solid, these target the specific bottlenecks that keep good sites from becoming great ones.

9. Clean Your Database and Keep It Clean

WordPress accumulates clutter over time. Post revisions, auto-drafts, spam comments, trashed posts, orphaned metadata, expired transients. On a small site this hardly matters. On a site with years of content and thousands of posts, it adds up and slows down database queries.

WP-Optimize and Advanced Database Cleaner handle this safely. Set up a monthly scheduled cleanup so the clutter does not build back up.

10. Limit Post Revisions

WordPress stores unlimited revisions for every post by default. On an active site with hundreds of articles being edited regularly, this can mean tens of thousands of database rows that serve no ongoing purpose.

Cap them by adding this to your wp-config.php file:

define(‘WP_POST_REVISIONS’, 5);

Five revisions per post is plenty for recovery purposes and keeps the database from inflating.

11. Throttle the WordPress Heartbeat API

The Heartbeat API sends a server request every 15 seconds while you are editing in the WordPress dashboard, supporting features like auto-save and post locking. On the default setting this generates constant server load during editing sessions, even for sites without heavy traffic.

Throttle it using WP Rocket’s built-in heartbeat control or the free Heartbeat Control plugin. Reducing the interval from 15 seconds to 60 seconds has no visible impact on the editing experience but meaningfully reduces server load.

12. Minify CSS, JavaScript, and HTML

Minification strips whitespace, comments, and line breaks from code files. The files work identically, they are just smaller. A minified CSS file is typically 20 to 30% smaller than the original.

Most caching plugins include minification options. Enable them, then test your site thoroughly across different pages and browsers before leaving it active. Aggressive JavaScript minification occasionally breaks functionality, and you want to catch that immediately.

13. Reduce the Number of HTTP Requests

Every file the browser loads (images, stylesheets, scripts, fonts, third-party embeds) is a separate HTTP request. Each request has its own connection overhead. Fewer requests means faster initial load.

Practical places to reduce requests on a typical WordPress site:

• Remove Google Fonts you are not using, or limit to one or two weights
• Eliminate third-party scripts for tools you are no longer actively using
• Remove social sharing plugins that load scripts on every page
• Disable tracking pixels for services that are no longer relevant

14. Host Your Google Fonts Locally

When WordPress loads Google Fonts from fonts.googleapis.com, the browser has to establish an external DNS connection, open a TLS connection, and download the font file from Google’s servers. This typically adds 200 to 400 milliseconds on some connections and also raises GDPR considerations for European visitors.

Hosting fonts on your own server eliminates that round trip entirely. The OMGF (Optimize My Google Fonts) plugin automates this. Some themes also include a local-fonts option in their settings panel.

15. Enable Browser Caching for Return Visitors

Browser caching tells visitors’ browsers to store certain files locally so that on their next visit, those files load from their device instead of from your server. This is most impactful for return visitors and can cut load times significantly for repeat traffic.

Set cache expiry headers through your caching plugin or directly in .htaccess. A one-year expiry for static assets (images, fonts, CSS files that do not change often) is standard practice.

16. Paginate Comments and Control Your Archive Page Size

Two default WordPress settings that quietly slow down busy sites:

Comments: A post with 200 or more comments (especially when avatars are enabled) loads noticeably slower. Go to Settings, then Discussion, and enable “Break comments into pages” with a limit of 20 to 30 comments per page.

Archive pages: The more posts WordPress loads on a category or tag page, the more images and markup it generates. Keep the number at a reasonable level for your layout (usually 10 to 12 posts) under Settings, then Reading.

17. Disable WordPress Emojis

WordPress loads an emoji detection script on every page. If your site does not rely on custom emojis, this is an unnecessary request. You can disable it through most caching plugins or by adding this to your theme’s functions.php:

remove_action(‘wp_head’, ‘print_emoji_detection_script’, 7);

remove_action(‘wp_print_styles’, ‘print_emoji_styles’);

These require more technical confidence. Always test on a staging environment before applying to a live site.

18. Generate Critical CSS and Load the Rest Asynchronously

When a browser encounters a CSS file linked in the <head> of a page, it stops rendering until it has downloaded and parsed that entire file. This is called render-blocking, and it is one of the primary causes of slow LCP.

Critical CSS is the small subset of CSS rules needed to render the visible part of the page before scrolling. Inlining that CSS directly in the <head> and loading the rest of the stylesheet asynchronously lets the page render immediately without waiting for the full file.

WP Rocket and FlyingPress automate critical CSS generation. You will need to regenerate it whenever your theme or layout changes significantly.

19. Defer and Delay JavaScript

JavaScript without a defer or async attribute blocks the browser from rendering the page until that script has fully downloaded and run. This is a primary driver of high Total Blocking Time and poor INP scores.

Three levels of JavaScript optimization you can apply progressively:

Add defer to scripts that do not need to run before the page is visible.

Add async to independent scripts like analytics that do not depend on other scripts.

Delay JS until user interaction for third-party scripts (chat widgets, heavy embeds) that are rarely needed on initial load. WP Rocket and Perfmatters both offer a “delay JavaScript” feature that does this automatically.

20. Use Resource Hints: Preload, Preconnect, DNS-Prefetch

Resource hints tell the browser to start working on resources it will need before it discovers them in the HTML, shaving off meaningful time on the critical path.

Preload your LCP image and key fonts. Preconnect to critical third-party origins your site relies on. DNS-prefetch for origins used but not immediately critical.

<link rel=”preconnect” href=”https://fonts.gstatic.com” crossorigin>

<link rel=”dns-prefetch” href=”https://www.google-analytics.com”>

These are relatively low-risk and often reduce LCP by 100 to 300 milliseconds.

21. Set Up Object Caching with Redis or Memcached

Object caching stores the results of database queries in server memory so WordPress does not have to re-run them on every page load. For standard blog-style sites with full-page caching, this is a nice-to-have. For these scenarios it is essential:

• WooCommerce stores (logged-in users bypass page cache entirely)
• Membership sites with personalized content
• Sites with more than 50,000 posts where query complexity grows

Redis and Memcached are the two standard backends. Enabling them requires your host to support it. The Redis Object Cache plugin connects WordPress to a Redis instance once your host has it configured.

22. Remove Unused CSS and JavaScript

Modern WordPress setups using page builders or feature-heavy themes often load CSS and JavaScript on every page that most pages never use. This inflates page weight and increases Total Blocking Time unnecessarily.

You can identify unused code using Chrome DevTools: open the Coverage tab while a page is loading and it will show you what percentage of each file is actually used. Perfmatters and Asset CleanUp let you disable specific scripts and styles on pages where they are not needed.

23. Identify Slow Queries and Plugins with Query Monitor

Query Monitor is a free developer plugin that shows you every database query run on each page load, which plugin or theme function triggered it, and how long it took. It also flags PHP errors and unusually slow queries.

This turns performance troubleshooting from guesswork into a targeted process. If one plugin is responsible for 60% of your database queries, Query Monitor shows you which one. That is information you cannot get from PageSpeed Insights or GTmetrix alone.

WooCommerce creates performance challenges that standard page caching cannot fully solve. Cart pages, checkout, account pages, and product pages are dynamic and user-specific. They cannot be served from a full-page cache.

Object Caching Becomes Critical

Logged-in shoppers bypass page cache. Object caching with Redis or Memcached keeps their experience fast by storing database query results in memory instead of re-running them on each request.

Exclude Dynamic Pages from Caching Rules

Cart, checkout, and account pages must be excluded. Serving a cached checkout page to a different user is a bug, not just a performance issue. Your caching plugin should handle this automatically for WooCommerce, but confirm it in the settings.

Disable Cart Fragments on Non-WooCommerce Pages

The cart fragments feature fires an AJAX request on every page load across your entire site to update the cart total dynamically. On pages with no cart widget, this is wasted overhead. Perfmatters can disable it on non-WooCommerce pages.

Product Images Need Extra Attention

WooCommerce archive pages load many product images at once. Make sure they are all in WebP format, correctly dimensioned for your product grid, and lazy-loaded.

Run Scheduled Database Maintenance

WooCommerce generates significant session data, order meta, and product revisions. Stale sessions and expired transients pile up faster on stores than on standard sites. Monthly cleanup with WP-Optimize keeps queries fast.

Rather than applying every fix at once and hoping something helps, here is a practical framework for diagnosing what is actually wrong.

• Start with TTFB: If your TTFB is above 800ms on a cached page, your server is the bottleneck. Spend your time here before anything else. No front-end optimization closes a 1.5-second server gap.
• Find the biggest resource: Open Chrome DevTools, go to the Network tab, sort by file size, and look at what is at the top. For most WordPress sites it is an image. Fix your largest resources before your smallest ones.
• Check for render-blocking: PageSpeed Insights will flag “Eliminate render-blocking resources” if anything is blocking the page from rendering. Address blocking CSS through critical CSS generation and blocking JavaScript through deferral.
• Check Total Blocking Time: High TBT in your PageSpeed Insights lab score predicts poor INP. Identify what is causing long tasks using Chrome’s Performance panel. Heavy third-party scripts and large plugin-loaded JavaScript files are the usual suspects.
• Check return visitor performance: Once the above is solid, confirm that browser caching is configured so repeat visitors are loading from local storage rather than re-downloading everything.

Working through these in order stops you from optimizing the wrong thing. A lot of sites spend hours on CSS minification while a 5MB hero image or a 2-second TTFB is still sitting there untouched.

Some of the slowest WordPress sites out there have been optimized. Here is what typically went wrong.

• Running two caching plugins: This is more common than it should be. Two caching plugins do not double the performance improvement. They conflict with each other and often produce a site that is slower than having neither.
• Applying changes directly to a live site: Minification and JavaScript deferral can break things. Critical CSS generation can miss styles. Test on staging first. Always have a backup before making performance changes in production.
• Optimizing for a 100/100 lab score instead of real-user data: PageSpeed Insights lab scores are useful diagnostic tools, but Google uses Chrome User Experience Report (CrUX) field data for ranking. A site with a lab score of 74 but excellent real-user Core Web Vitals can outrank a site with a lab score of 96 and poor field data. Check your field data in Google Search Console.
• Treating desktop performance as the primary benchmark: Since Google completed its move to mobile-first indexing in July 2024, your mobile performance is what primarily drives rankings. Always treat mobile as your main measurement target.
• Assuming a CDN fixes everything: A CDN speeds up delivery of static assets globally. It does not fix a slow TTFB for your main HTML response. Both matter and they address different parts of the problem.

There is a clear order of operations here, and ignoring it is the most common reason speed optimization efforts produce disappointing results.

Fix the foundation (hosting and TTFB) first. Add caching. Optimize your images. Add a CDN. Audit your plugins. Update PHP. Then move into the intermediate fixes (database, revisions, minification, fonts). Then the advanced techniques (critical CSS, JavaScript deferral, object caching) once the simpler problems are solved.

Measure after every step. Some changes deliver 400ms improvements. Others deliver 20ms. The only way to know is to measure. And the fastest sites are not the ones with the most optimization plugins installed. They are the ones that started with fast infrastructure, kept their setup lean, and paid attention to the metrics that actually matter.

1. What are the best ways to speed up my website?

The best ways to speed up your website are to use a fast hosting setup, enable page caching, compress and properly size images, remove unnecessary plugins, use a lightweight theme, and deliver assets through a CDN. You should also minify CSS and JavaScript, optimize your database, and keep WordPress, plugins, and PHP updated for better performance.

2. What changes can I implement to speed up a very slow site?

To speed up a very slow site, start by checking hosting performance, then enable caching, optimize large images, remove heavy plugins, and clean up unused themes or scripts. You should also reduce third-party requests, optimize your database, delay non-critical JavaScript, and test your site with tools like PageSpeed Insights or GTmetrix to identify the biggest bottlenecks.

3. How to optimize or speed up your WordPress website in a few minutes?

To speed up your WordPress website in a few minutes, install a caching plugin, compress existing images, remove unused plugins, update WordPress and PHP, and enable a CDN if available. You can also switch to a lightweight theme and optimize your database. These quick fixes often improve load time without requiring a full rebuild or advanced development work.

4. What is the best WordPress website speed optimization plugin?

The best WordPress website speed optimization plugin depends on your setup, but popular options include WP Rocket, LiteSpeed Cache, W3 Total Cache, and FlyingPress. A good speed plugin should handle page caching, file minification, lazy loading, and database cleanup so you can improve load times without manually configuring multiple performance tools.

5. What is the best free WordPress speed optimization plugin?

If you need a free WordPress speed optimization plugin, LiteSpeed Cache, WP Super Cache, and W3 Total Cache are among the strongest options. The best choice depends on your hosting environment, but in general, a free plugin should provide caching, basic optimization, and performance controls that reduce page load time without requiring paid add-ons.

6. What website speed-up extension can improve WordPress performance?

A website speed-up extension for WordPress usually refers to a caching or optimization plugin that improves load time by reducing server work and shrinking front-end assets. Tools like WP Rocket, LiteSpeed Cache, Perfmatters, and Autoptimize can help by caching pages, delaying non-critical scripts, optimizing CSS and JavaScript, and improving how quickly content loads for visitors.

7. Is there a one-click WordPress speed optimization solution?

Yes, some WordPress performance plugins offer near one-click speed optimization by enabling caching, file optimization, image lazy loading, and basic cleanup from a single dashboard. Tools like WP Rocket and LiteSpeed Cache are often used for this because they can deliver noticeable speed improvements quickly without requiring advanced technical setup.