Want Faster Load Times? Optimize WordPress This Way

Contents

Why Speed Matters for WordPress Websites 1.1. Better User Experience 1.2. SEO and Search Rankings 1.3. Save on Advertising Costs Understanding WordPress Performance How to Check Your Current Speed 2.1. Free Speed Test Tools 1. Serve images in next-gen formats (Est savings of 78 KiB)2. Reduce unused CSS (Est savings of 82 KiB)3. Preload Largest Contentful Paint image 4. Serve static assets with an efficient cache policy 5. Eliminate render-blocking resources (Est savings of 0 ms)6. Properly size images (Est savings of 123 KiB) 7. Avoid an excessive DOM size (959 elements)8. Avoid large layout shifts (1 layout shift found)9. Largest Contentful Paint element – 890 ms 10. Avoid chaining critical requests (12 chains found)11. Minimize third-party usage 2.2. Key Metrics to Understand Common Reasons Why WordPress Sites Are Slow 3.1. Low-Quality Hosting 3.2. Too Many Plugins 3.3. Bloated Themes 3.4. Unoptimized Images 3.5. No Caching in Place Step-by-Step Guide to Speed Up WordPress 4.1. Use High-Quality Hosting 4.2. Install a Caching Plugin 4.3. Compress and Convert Images 4.4. Optimize Your Theme 4.5. Remove Unused Plugins 4.6. Reduce HTTP Requests 4.7. Clean Up the Database 4.8. Enable Lazy Loading 4.9. Use a CDN (Content Delivery Network)Advanced Tips for Speed Optimization 5.1. Disable Unused WordPress Features 5.2. Use the Latest PHP Version Detailed Analysis on How to Fix a Slow Website Check Source Code and Database Processing Enable WP_DEBUG to Check PHP Errors Use WP_Debug to Inspect Database Queries Identify Slow Plugins/Themes Using Code Profiler Check the Data Returned from the Server to the Browser Summary Solutions to Speed Up Your WordPress Website Use a high-quality nameserver Optimize TCP Connections and SSL/TLS Handshake Time Optimize Source Code Processing on the Server Object Caching Use Opcache for PHP Clean Up the Database and Check Foreign Key Indexes Use a Full Page Caching Plugin Regularly Optimize Your Database Size Optimize TTFB (Time To First Byte)Minification Technique Using Gzip/Brotli Using DNS-Prefetch and Prefetch for Third-Party Resources DNS-Prefetch and How to Use It Using Preload Using Speculative Loading Image Optimization on Websites Solving Render-Blocking Issues: Combine, Critical CSS, Defer, Async Handling Render-Blocking with CSS Handling Render-Blocking with JavaScript Conclusion

If you’re running a WordPress website, chances are you’ve encountered this frustrating issue: slow loading pages, users bouncing off your site quickly, and your SEO rankings dropping. All of that comes down to one thing — a slow website.

Website speed directly impacts user experience, search engine rankings, and even your advertising costs. Whether you’re running an online store, a personal blog, or a business site, a fast-loading website is essential.

So how can you improve your WordPress site’s speed without being a tech expert? In this article, I’ll walk you through clear, easy-to-follow steps to optimize your site performance. Let’s dive in!

Why Speed Matters for WordPress Websites

1.1. Better User Experience

Visitors hate waiting. If your website takes more than 3 seconds to load, most users will simply leave. A fast site keeps users engaged, encourages them to explore more pages, and improves conversion rates.

1.2. SEO and Search Rankings

Google has officially included page speed as a ranking factor. That means a faster site has a better chance of appearing on the first page of search results.

1.3. Save on Advertising Costs

A slow site leads to poor user experience, which lowers your ad quality score on platforms like Google Ads or Facebook Ads. That means you pay more per click. Optimizing your website speed helps reduce ad costs while improving results.

Understanding WordPress Performance

WordPress performance hinges on several factors:

Plugins: Too many plugins or poorly coded ones can slow down your site.
Themes: Heavy themes with complex code impact load times.
Server: Low-quality hosting or poor server configuration reduces performance.
Content: Large images, videos, or heavy scripts increase load time.
Traffic: High traffic can strain the server.

Understanding these elements helps pinpoint weaknesses and prioritize optimization. For instance, a plugin generating unnecessary HTTP requests can drag down speed, while a lightweight theme like Astra (Astra) can significantly improve performance.

How to Check Your Current Speed

2.1. Free Speed Test Tools

Before you optimize anything, test your site’s current performance. Here are some free tools:

Google PageSpeed Insights – https://pagespeed.web.dev/
GTmetrix – https://gtmetrix.com/
Pingdom Tools – https://tools.pingdom.com/

Google PageSpeed Insights test

These tools will show:

Load time
What’s slowing your site down (large images, bloated code, slow server, etc.)
Actionable suggestions for improvement

Google PageSpeed Insights Diagnostics

1. Serve images in next-gen formats (Est savings of 78 KiB)
- Meaning: Your website is using traditional image formats like JPEG or PNG.
- Solution: Convert your images to modern formats such as WebP or AVIF. These formats are more efficient and load faster.
2. Reduce unused CSS (Est savings of 82 KiB)
- Meaning: Your website is loading CSS code that isn’t actually used on the current page.
- Solution:
  - Remove or optimize unused CSS using plugins like Asset CleanUp or PurgeCSS.
  - Consider generating Critical CSS to load only essential styles first.
3. Preload Largest Contentful Paint image
- Meaning: The main image on your page (usually a hero/banner image) should be preloaded to display faster.
- Solution:
  - Add a <link rel="preload"> tag for the main image in the <head> section of your HTML.
4. Serve static assets with an efficient cache policy
- Meaning: Some static files (like images, JavaScript, or CSS) are not cached for long periods, which causes them to reload often.
- Solution:
  - Configure long-term browser caching (e.g., several months) via .htaccess or your server settings.
  - If you’re using a caching plugin like LiteSpeed Cache, enable long-term caching for static resources.
5. Eliminate render-blocking resources (Est savings of 0 ms)
- Meaning: Some CSS/JavaScript files are blocking the page from displaying immediately.
- Solution:
  - Defer or async non-critical JS files.
  - Use plugins like Async JavaScript or WP Rocket to handle render-blocking resources.
6. Properly size images (Est savings of 123 KiB)
- Meaning: Some images are being loaded in larger dimensions than necessary.
- Solution:
  - Resize images to match their display size.
  - Use responsive image plugins like ShortPixel Adaptive Images or Smush Pro.
7. Avoid an excessive DOM size (959 elements)
- Meaning: Your HTML contains almost 1,000 elements — that’s considered complex.
- Impact: It can slow down rendering in browsers.
- Solution:
  - Simplify your page structure.
  - Reduce unnecessary blocks generated by page builders like Elementor or WPBakery.
8. Avoid large layout shifts (1 layout shift found)
- Meaning: One element moved position during page load, causing visual instability.
- Solution:
  - Always define width and height for images and embeds.
  - Use CSS to create placeholder space before content loads.
9. Largest Contentful Paint element – 890 ms
- Meaning: The largest visible element (usually a large image or text block) loaded in 890 milliseconds.
- Note: This is excellent — anything under 2.5 seconds is considered good.
10. Avoid chaining critical requests (12 chains found)
- Meaning: Some key resources are loaded in a chain (one after another), which can slow down load time.
- Solution:
  - Optimize how critical CSS/JS is loaded.
  - Combine files where possible and preload essential ones.
11. Minimize third-party usage
- Meaning: Code from external services (e.g., Google Fonts, Facebook Pixel) didn’t block your page load.
- Note: Your site is doing well in this area — no action needed.

2.2. Key Metrics to Understand

Largest Contentful Paint (LCP): Time to load the largest visible content element on the page.
First Input Delay (FID): Time until the site responds to the user’s first interaction.
Cumulative Layout Shift (CLS): Measures layout stability during load (avoid elements jumping around).

Common Reasons Why WordPress Sites Are Slow

3.1. Low-Quality Hosting

Not all hosting is created equal. Cheap shared hosting often comes with overcrowded servers and poor performance.

3.2. Too Many Plugins

Installing too many plugins — especially heavy or outdated ones — will slow your site down.

3.3. Bloated Themes

Many “fancy” themes look great but come packed with features, JavaScript, and CSS that aren’t necessary, resulting in slower loads.

3.4. Unoptimized Images

Large image files are one of the most common causes of slow page loads.

3.5. No Caching in Place

Without caching, your site generates fresh pages from scratch every time someone visits — this takes time. Caching solves this by storing and serving static versions of your pages.

Step-by-Step Guide to Speed Up WordPress

4.1. Use High-Quality Hosting

If you’re using cheap shared hosting and your site is still slow, consider upgrading:

Go for VPS or Cloud Hosting
Choose WordPress-optimized providers like Cloudways, Kinsta, A2 Hosting, SiteGround

4.2. Install a Caching Plugin

This is one of the easiest and most effective ways to boost performance. Popular options include:

LiteSpeed Cache – ideal if your host uses LiteSpeed servers
WP Rocket – premium but user-friendly and powerful
W3 Total Cache – free, comprehensive, but more complex

Caching helps by:

Storing and serving static HTML pages
Minifying and combining CSS/JS
Integrating with CDNs for faster global delivery

4.3. Compress and Convert Images

Use image optimization plugins such as:

ShortPixel
Smush
Imagify

Also, convert images to modern formats like WebP, which are smaller in size without quality loss.

4.4. Optimize Your Theme

Choose themes that are lightweight and performance-focused like:

GeneratePress
Astra
Neve

Avoid themes packed with features you don’t need. If you already use one, disable unused components or switch to a better-optimized theme.

4.5. Remove Unused Plugins

Deactivate and delete plugins you no longer use
Avoid plugin duplication (e.g., don’t install multiple SEO plugins)

Where possible, use all-in-one plugins to reduce overhead.

4.6. Reduce HTTP Requests

Combine CSS/JavaScript files
Defer or delay loading non-essential scripts
Block unused third-party scripts (like unused fonts or tracking tools)

4.7. Clean Up the Database

Over time, your WordPress database accumulates junk — post revisions, spam comments, transients, etc.

Recommended plugins:

WP-Optimize
Advanced Database Cleaner

4.8. Enable Lazy Loading

Lazy loading means images and videos load only when the user scrolls to them — reducing initial page load time.

Many cache plugins offer lazy loading features — just enable them in the settings.

4.9. Use a CDN (Content Delivery Network)

A CDN stores and serves your site’s content from the server nearest to your visitor.

Benefits:

Faster loading times for visitors around the world
Reduced server load
Improved security (DDoS protection)

Popular CDNs:

Cloudflare – free and easy to set up
BunnyCDN – pay-as-you-go, fast, and affordable

Advanced Tips for Speed Optimization

5.1. Disable Unused WordPress Features

Disable Heartbeat API to reduce admin-ajax calls
Disable wp-cron.php and use real server cron jobs
Turn off emojis, embeds, XML-RPC

You can use plugins like Disable Everything, Perfmatters, or manually add code to functions.php.

5.2. Use the Latest PHP Version

Upgrading to PHP 8.x can boost performance by 10–30% compared to older versions. Check if your hosting supports this and update accordingly.

Detailed Analysis on How to Fix a Slow Website

Check Source Code and Database Processing

The Time to First Byte (TTFB) can be negatively impacted if there are issues during internal source code processing. When talking about code processing in WordPress, the root cause often stems from poorly optimized plugins or themes.

Enable WP_DEBUG to Check PHP Errors

Debugging in WordPress is the first essential step to identify and eliminate potential causes of slowness due to PHP errors.

Start by opening the wp-config.php file and locating the line:

define('WP_DEBUG', false);

Change it to:

define('WP_DEBUG', true);

And then add the following line to save debug logs in the wp-content/ directory:

define('WP_DEBUG_LOG', true);

At this point, you can monitor the wp-content/ folder to see if a debug.log file is generated. Review this file to identify any fatal errors, and check if they are related to specific plugins or themes. You can then try deactivating the problematic ones.

Also, using an incompatible PHP version can trigger warnings or issues. If you’re still on PHP 7, it’s highly recommended to upgrade to PHP 8.2 as per WordPress recommendations.

Use WP_Debug to Inspect Database Queries

Another critical step in troubleshooting a slow WordPress site is inspecting database queries using a plugin like Query Monitor.

Once installed, navigate to the slowest page on your website and click the Query Monitor tab in the admin toolbar to view detailed reports. It will show:

Total page load time
The number of database queries executed and their execution time
A list of action hooks triggered during page load

This information helps pinpoint slow queries or performance bottlenecks due to excessive hooks or unoptimized database interactions.

If you’re building your WordPress website entirely by yourself — writing your own theme and plugins — then you’ll have much more flexibility in optimization. However, most of us use pre-built themes and ready-made plugins, so we often can’t (or shouldn’t) make deep customizations based on the results from tools like Query Monitor.

That said, if your website shows database queries taking more than 2 seconds, it’s a clear sign that some part of your site is using inefficient queries or that your database is too large, causing slow responses.

When reviewing the Database Queries section in Query Monitor, you can identify which specific query is consuming the most time. From there, consider what feature is responsible for it — for example, a SELECT query fetching posts for display might be triggered by a post listing feature on the current page. You can then decide whether to remove that feature or check if the database size is the root cause of the slowness.

As a general rule, the total database query time on a single page should ideally not exceed 1 second.

Identify Slow Plugins/Themes Using Code Profiler

Recently, I discovered another useful plugin for identifying whether performance issues on a website are caused by the theme or a specific plugin — it’s called Code Profiler.

After installing this plugin, you can run a profiling session to collect performance data. When running the profiler, it’s best to execute it as a Authenticated user to get more accurate results, since doing so will bypass any caching applied to regular visitors. Also, make sure to run the profiling on the specific page where you’re experiencing slowness.

The results will be displayed as a graph comparing the processing time of your active theme and plugins. Usually, the theme will have the highest result, since it’s responsible for rendering content on the front end — and a more complex theme naturally takes more time to process. The same goes for plugins.

However, don’t rush to conclude that a plugin or theme is poorly optimized. Sometimes, the reason could simply be that your website contains a large amount of content, which makes the processing time higher compared to another site using the same plugin but with less data.

Still, these results give you a clear overview of which part of your website is consuming the most resources.

Check the Data Returned from the Server to the Browser

Once the server has finished gathering the necessary data, it sends it back to the browser to render and display the webpage. And this is where another layer of performance issues can begin.

Have you ever downloaded a large file from the internet? For example, downloading a 10MB file — it obviously takes time. Similarly, when you access a website, your browser is essentially downloading the content of that page to display it. If your page contains a large image (like the “fridge-sized” one I mentioned earlier), the browser will take significantly longer to load the page.

To check this aspect, you can use the Network tab in the DevTools of Chromium-based browsers like Google Chrome or Microsoft Edge. It’s best to test in Incognito mode to avoid cached data. Just follow the steps demonstrated in the video below.

After running the Network test, pay attention to the result summary at the bottom.

Here, you can see the total size of all resources being used on the website and how much has actually been downloaded. If your page has 20–30MB of transferred data, that’s a red flag. You can click the “Size” column to sort and identify which files are taking up the most space.

Next, focus on the DOMContentLoaded, and compare it with Load and Finish. Here’s what each metric means:

DOMContentLoaded: This is the time it takes for the browser to fully load the HTML structure and complete the DOM (Document Object Model) construction — excluding the loading time of CSS, JavaScript, images, etc. A high value indicates that the HTML structure is too heavy, usually influenced by the theme or page builders like Elementor. Also, any <script> tags that don’t have the defer or async attributes will contribute to this time.
Load: This is the time it takes for the browser to fully load all resources on the page — including HTML, CSS, JavaScript, iframes, etc. This is a good reference point for evaluating the real loading time of your website from a user’s perspective.
Finish: Let me warn you upfront — don’t rely on this number to evaluate your website’s speed. It represents the time from the first browser request until the last resource is received. So if your site uses AJAX to fetch more data after the page loads, or Lazy Load to defer loading images or content, the “Finish” time will continue to increase.

Summary

If Transferred Size is too large: You need to reduce the amount of resource-heavy content on the site — mainly large images and third-party JavaScript files.
If DOMContentLoaded is too high: Your page structure is likely too bloated. Consider simplifying or optimizing the layout. Avoid using too many containers in page builders like Elementor and remove unnecessary sections. You can also use HTML minification techniques to slim down the DOM structure.
If the Load Time is too high: Reduce the number of requests by minifying CSS/JS, enabling Lazy Load for images, and eliminating unused resources.

Solutions to Speed Up Your WordPress Website

The reason I took the time to explain things in such detail earlier was simply to clarify the root causes of why a WordPress website becomes slow. Once the underlying issues are clear, it becomes much easier to apply specific and effective solutions like the ones below.

Let’s take another look at the diagram I created at the beginning of the article, and we’ll go step by step to resolve the bottlenecks in that flow. By doing so, your website will become blazing fast — maybe even out of control fast.

Use a high-quality nameserver

A good nameserver can resolve DNS queries quickly and reliably. One of the best choices today is Cloudflare’s nameserver. You don’t have to enable the proxy feature if you don’t want to, but their DNS service alone is known for its speed and reliability.

Cloudflare is not only a DNS provider but also one of the leading Web Application Firewall (WAF) services, offering excellent performance and protection for your website. Using their nameserver can significantly improve your site’s speed and stability.

Cloudflare nameservers offer consistently fast resolution speeds across all regions

Optimize TCP Connections and SSL/TLS Handshake Time

Nowadays, most websites are required to use the HTTPS protocol to encrypt data transmitted over the connection for security purposes. Whether you like it or not, not using HTTPS will result in a “Not Secure” warning in the browser’s address bar — which is quite embarrassing.

Of course, the SSL/TLS Handshake process doesn’t take up too much time in the overall connection setup, but if you’re into optimization, you might want to try switching to an SSL certificate that uses ECC (Elliptic Curve Cryptography) encryption instead of the commonly used RSA.

Most importantly, your website should be using HTTP/3 to improve performance by leveraging the UDP protocol instead of TCP. This helps reduce the number of TCP connections overall and allows more resources to be loaded simultaneously over a single secure HTTPS connection.

To check whether your website server supports HTTP/3, you can use the tool http3check.net. If it’s not enabled, you can either contact your hosting provider or reconfigure the web server on your server.

Note: The bot protection feature on Cloudflare may block access to the checking tool.

Optimize Source Code Processing on the Server

The server-side processing includes logic execution within the source code and database queries. This process often takes up the largest chunk of time during a full website connection cycle, so it’s crucial to pay close attention here.

In WordPress, the first step is to consider disabling unnecessary or unused plugins. Only keep those that are absolutely essential for your website to minimize action hook executions and database queries each time a page is loaded.

By enabling WP_DEBUG, as previously mentioned, you’ll be able to identify if your website has any warnings or fatal errors. Make an effort to clean those up. (Sometimes I even solve the issue by… disabling the plugin throwing the warnings if there are too many! )

Object Caching

If your website makes too many database queries or has a large database, it’s recommended to use Object Cache to reduce the frequency of database queries. This is especially useful for news websites, blogs with many posts, or WooCommerce stores with many products.

Object Cache temporarily stores data objects in memory and reuses them when needed to avoid reprocessing or repeated database queries. In WordPress, these objects include post data, settings stored in the wp_options table, etc. Keep in mind, post objects also cover custom post types, including WooCommerce products, since they are stored in wp_posts and wp_postmeta.

To enable Object Cache:

Ask your hosting provider if they support Redis or Memcached.
- If Redis is supported: Install the Redis Object Cache plugin.
- If Memcached is supported: Install the Memcached Object Cache plugin.
If you’re using a VPS or a dedicated server, install it yourself or ask a server expert, as the setup method depends on your current software stack.

If your WordPress site only has a few static pages, Object Cache won’t offer significant benefits. For sites with real-time data updates, avoid using Object Cache, as it would need to constantly refresh data in memory—leading to inefficiency or even performance issues.

Also, if you’re using a VPS or server with limited RAM, it’s not recommended to use Object Cache, because both Redis and Memcached use RAM to store cache data.

Use Opcache for PHP

It may sound redundant to mention that WordPress is written in PHP, but optimizing PHP can significantly improve WordPress performance. Just reiterating for clarity—some may forget this when diving into WordPress optimization.

Note: This article refers to both Opcode and Opcache. Opcode refers to machine-level instructions in computer science, while Opcache is a caching mechanism that stores these opcodes.

PHP is an interpreted language, meaning it executes code via an interpreter without compiling to machine code beforehand. This interpreter reads and executes the code immediately.

PHP uses the Zend Engine, and the execution process follows these steps:

PHP’s interpreter starts reading the code.
Zend Engine parses the syntax, checks for errors, and generates an Abstract Syntax Tree (AST).
Zend Engine compiles the AST into Opcode.
Zend Engine executes the Opcode and sends the response.

When Opcache is enabled:

The first execution goes through all four steps.
But from the second execution onward, PHP skips steps 2 and 3. Instead, it loads the stored Opcode from memory and jumps straight to execution—making the process significantly faster.

Comparison between the processing cycle of the interpreted language PHP and another compiled language like Java. source:*support.engineyard.com*

How Opcache memory intervenes in the PHP execution process

I believe you don’t need to know a thing about computer science (I don’t either) to understand that using Opcache helps speed up the PHP execution process.

To enable Opcache on Web Hosting, you can ask your hosting provider’s technical support to check, or access the Select PHP Version feature in cPanel/DirectAdmin and see if the opcache extension is enabled—then simply check it to activate.

If you’re using a VPS or a dedicated server, check whether Opcache is already installed with PHP, and refer to the appropriate documentation to enable it based on the software stack you’re using. You can verify its status by running the following command:

php -i | grep "opcache.enable"

Clean Up the Database and Check Foreign Key Indexes

When a user accesses a page (especially one that doesn’t use Page Cache), the queries defined in your code will be executed to fetch data from the database and display it. Here’s an example of how data is queried for a post with the ID of 123:

SELECT * FROM wp_posts WHERE ID = 123;
SELECT * FROM wp_postmeta WHERE post_id = 123;

In this case, MySQL will search for post data in the database where the column ID equals 123. This is how Indexing works in MySQL — its goal is to retrieve exactly the data you need (by scanning only the ID column) instead of scanning the entire wp_posts and wp_postmeta tables to find the row where ID = 123.

However, in some cases, I’ve noticed that many websites lose their INDEXES attribute on columns like ID, even though the data still exists. When that happens, the website still functions, but performance significantly drops.

So if your website is experiencing unusual slowness related to the database, you should check whether the tables in use are missing necessary INDEXES. You can do this by creating a file, for example named check_indexes.php, in your WordPress root directory and inserting a code snippet to inspect database indexes.

<?php
// Ensure the file is only run through the browser
if (php_sapi_name() !== 'cli') {
    // Load WordPress environment
    require_once('wp-load.php');

    global $wpdb;

    // Get the list of all tables in the current database
    $tables = $wpdb->get_results("SHOW TABLES", ARRAY_N);

    echo "<h1>Check Indexes in Database Tables</h1>";

    foreach ($tables as $table) {
        $table_name = $table[0];
        echo "<h2>Table: $table_name</h2>";

        // Get index information for the current table
        $indexes = $wpdb->get_results("SHOW INDEXES FROM $table_name", ARRAY_A);

        if (!empty($indexes)) {
            echo "<table border='1' cellpadding='5' cellspacing='0'>";
            echo "<tr><th>Index Name</th><th>Column</th><th>Index Type</th></tr>";

            foreach ($indexes as $index) {
                echo "<tr>";
                echo "<td>{$index['Key_name']}</td>";
                echo "<td>{$index['Column_name']}</td>";
                echo "<td>" . ($index['Non_unique'] == 0 ? 'Unique' : 'Non-Unique') . "</td>";
                echo "</tr>";
            }

            echo "</table>";
        } else {
            echo "<p>This table has no indexes.</p>";
        }

        echo "<hr>";
    }
} else {
    echo "This file should not be run from the command line.";
}
?>

Note: Delete this file immediately after using it to avoid unwanted data exposure.

Then access this file in your browser via the URL:
https://your-domain.tld/check_indexes.php
to see the inspection results.

If the database tables have indexes, the structure will be displayed as shown in the image below. However, if you see the table names but no indexes are shown, it means the indexes have been lost, which can cause your website to slow down.

To restore the INDEXES, you can use the following command to recreate the index for a column. For example, applying it to the meta_id column in the wp_postmeta table:

ALTER TABLE wp_postmeta
ADD PRIMARY KEY (meta_id);

Make sure to replace wp_ with the correct database table prefix you’re using.

You can refer to the indexed columns used in WordPress core tables [here]

Use a Full Page Caching Plugin

Full Page Caching is widely used in WordPress. It works by saving the entire content of a page as an .html file and storing it on your hosting server. This cached version is then served to users on subsequent visits. If you’ve heard of plugins like WP Rocket, LiteSpeed Cache, or WP Fastest Cache, they all use this technique to significantly improve website performance.

Here’s how it works:
On the first visit to a page (e.g., a blog post), the plugin will generate and store the full HTML content of that page as a cache file on the server. On subsequent visits, instead of processing PHP code and making MySQL queries, the server simply serves the pre-generated HTML file directly to the browser. This drastically reduces server processing load and improves page load speed for the user because the browser receives a fully rendered HTML file instantly—without waiting for backend processing.

Additionally, this technique significantly reduces Time to First Byte (TTFB) in the browser, which is a key metric for site speed and performance.

If you’re looking for a free plugin that provides all the essential features, WP Fastest Cache or LiteSpeed Cache are great choices. After activating the plugin, simply enable the Cache System option to get started. They also offer other useful features that can be enabled as needed. Some of these features will be mentioned in other sections of this article.

Set up Full Page Caching in WP Fastest Cache plugin

Regularly Optimize Your Database Size

Over time, your website’s database can gradually grow in size. Sometimes, this is caused by certain plugins that store excessive or unnecessary data without your knowledge, leading to unusually large database sizes.

To check your database size, you can either use the phpMyAdmin tool provided in your hosting control panel, or install a plugin like Advanced Database Cleaner. This plugin not only helps you monitor your database size, but also allows you to remove unnecessary data that accumulates over time, such as old revisions, trashed posts, spam comments, and transient options.

Optimize TTFB (Time To First Byte)

The TTFB (Time To First Byte) of a website depends on two factors: the processing speed of the source code on the server and the content returned to the browser. In Solution 3, if you’ve optimized everything correctly, the TTFB should have already improved. In this section, I’ll cover techniques you can apply to optimize the content sent to the browser, helping it render the page as quickly as possible.

Minification Technique

Minification is a common term used to describe the process of removing unnecessary characters, such as whitespaces and line breaks, from code to make it faster to read and reduce the file size.

In WordPress, we apply minification to CSS files, JavaScript files, and the HTML structure of the page. This is often referred to as Minify CSS, Minify JavaScript, and Minify HTML.

Currently, caching plugins like WP Fastest Cache, LiteSpeed Cache, and WP Rocket all support minification features, so you can simply enable them. Unfortunately, minification for JavaScript is only available in the premium version of WP Fastest Cache — but that’s okay, it’s not essential.

In my opinion, the Minify feature is quite useful in many cases, and I recommend using it — except in situations where it doesn’t help resolve render-blocking issues, which I’ll discuss below.

Using Gzip/Brotli

Gzip is a compression technology that reduces the size of HTML, CSS, JavaScript, and HTML files before sending them to the browser. This helps speed up delivery by decreasing the size of these resources, allowing the server to save bandwidth and the browser to render content faster.

There are several compression technologies available, such as Gzip, Brotli, Zstandard (Zstd), and LZ4. Among them, Gzip is still the most widely used. However, Brotli is now considered a better option due to its higher compression ratio and better compatibility with websites — especially for HTML, CSS, and JavaScript files.

That said, Brotli has a drawback: it compresses files more slowly at higher compression levels compared to Gzip. But this isn’t a concern for websites, as they typically use lower compression levels that are fast enough for web file compression.

To check whether your website is using Brotli, you can use the tool at tools.keycdn.com/brotli-test. If you’re using a web hosting service and Brotli isn’t enabled, it’s a good idea to contact your provider and ask about enabling it.

Using DNS-Prefetch and Prefetch for Third-Party Resources

Nowadays, most websites establish some kind of connection to external domains — for example, loading Google Fonts, Google Analytics, and other third-party resources. These external assets can affect your website’s performance.

To optimize performance in such cases, you can use browser-supported features like dns-prefetch and prefetch.

DNS-Prefetch and How to Use It

As mentioned earlier, the first step for a browser to establish a connection is resolving the domain name via DNS, which is done through a Nameserver. If your website includes links to external domains, the browser must perform this DNS resolution for each one — which takes time.

DNS-Prefetch allows you to instruct the browser to resolve a third-party domain in advance, before any actual requests are made to it. Once resolved, subsequent requests to that domain can skip the DNS lookup step and connect directly, speeding up loading.

To use DNS-Prefetch, you simply declare the domain in your HTML using the <link> tag like this: <link rel=”dns-prefetch” href=”DOMAIN” />

<link rel="dns-prefetch" href="//fonts.googleapis.com">

⚠️ Important Note: DNS-Prefetch treats subdomains and root domains separately. This means if you prefetch a subdomain, only that specific subdomain will be resolved — not the main domain, and vice versa.

Also, it’s recommended to use protocol-relative URLs (//domain.com) instead of absolute ones (https://domain.com). This ensures that the browser uses the appropriate protocol (HTTP or HTTPS) based on the user’s current connection, avoiding unnecessary overhead.

Warning: You should only declare dns-prefetch for third-party websites that your site is actually connecting to. Avoid copying and pasting a generic list from the internet, as doing so can unnecessarily burden the user’s browser with excessive DNS resolutions — which may negatively impact performance instead of improving it.

The question is:
“I’m not even sure which third-party domains my website is connecting to — how can I use dns-prefetch properly?”

The answer:
You can easily find out by copying the code snippet below and pasting it into the Console tab in your browser’s DevTools, then press Enter:

(function() {
  const thirdPartyDomains = new Set();
  const currentDomain = window.location.hostname;

  // Collect all resources using the Performance API
  performance.getEntriesByType('resource').forEach((resource) => {
    const resourceURL = new URL(resource.name);
    const resourceDomain = resourceURL.hostname;
    
    // Only store domains that are not the current domain
    if (resourceDomain !== currentDomain) {
      thirdPartyDomains.add(resourceDomain);
    }
  });

  // Generate <link> tags for each third-party domain
  let links = "";
  thirdPartyDomains.forEach((domain) => {
    links += `<link rel="dns-prefetch" href="//${domain}">\n`;
  });

  console.log(links);
})();

Then, insert the returned results into the <head></head> section of your current theme.
You can quickly do this by using a plugin like Insert Headers and Footers (or Insert Scripts to Header and Footer) to easily add the code to the <head> area without editing theme files directly.

Additionally, it’s worth mentioning that the DNS resolution results in the browser are stored in the browser’s cache, and the duration of this caching is determined by the TTL (Time to Live) value of the DNS record. This also answers your question if you have previously changed DNS settings and saw the TTL but were unsure what it meant.

Using Preload

If dns-prefetch performs DNS resolution in advance for third-party domains, then preload is an operation that preloads important resources to be ready for the page’s content rendering process. This helps ensure that truly critical resources load first, avoiding delays that could disrupt the smooth user experience.

The most practical use case for the preload feature is to preload fonts from Google Fonts and preload large images appearing above the fold to improve the LCP (Largest Contentful Paint) score in PageSpeed.

Currently, the types of files supported for preload include fonts, .css, .js, images, videos, audio, iframes, and .html files.

You can perform preload by inserting the following code snippet into the <head></head> section of your website or through a plugin like Insert Scripts in Footer and Header with the structure below:

<link rel="preload" as="image" href="//domain.ltd/banner.jpg" crossorigin="anonymous" />

In this, replace as="image" with the type of file you want to preload (such as audio, document, style, script, font) and link to the resource that needs to be preloaded.

You should avoid overusing preload and only preload the resources that definitely need to be prioritized before the browser renders the page. If you preload too many unused resources, it will not optimize your website but may actually slow it down.

If you’re not sure what to preload on your site, you can get a list of resources to preload based on the content visible to users before they scroll (Above the Fold). Then add images, fonts, Google Fonts, backgrounds into <link> tags for you to copy and insert into your website. Use the code below and paste it into the Console tool in DevTools to get started:

(function() {
  const preloadedResources = new Set();

  // Get the viewport height to determine Above-the-Fold
  const viewportHeight = window.innerHeight;

  // Get all image elements and elements with background images in the viewport
  const elementsAboveFold = Array.from(document.querySelectorAll('img, [style*="background"], [style*="src"]')).filter(el => {
    const rect = el.getBoundingClientRect();
    return rect.top >= 0 && rect.top < viewportHeight;
  });

  // Find image resources and background-image resources
  elementsAboveFold.forEach(element => {
    let src;

    // Find image resource from img tag
    if (element.tagName === 'IMG' && element.src) {
      src = element.src;
    }

    // Find resource from background-image
    const bgImage = window.getComputedStyle(element).getPropertyValue('background-image');
    if (bgImage && bgImage !== 'none') {
      src = bgImage.slice(4, -1).replace(/"/g, "");  // Extract URL from background-image
    }

    if (src) {
      // Convert URL to protocol-relative form //domain.ltd instead of https://domain.ltd
      src = src.replace(/^https?:/, '');
      preloadedResources.add(src);
    }
  });

  // Find Google Fonts links (only take actual CSS files)
  const googleFontsLinks = Array.from(document.querySelectorAll('link[href*="fonts.googleapis.com/css"]'));
  googleFontsLinks.forEach(link => {
    let href = link.href.replace(/^https?:/, ''); // Convert to protocol-relative form //domain.ltd
    preloadedResources.add(href);
  });

  // Output <link rel="preload"> tags to console
  let preloadLinks = '';
  preloadedResources.forEach(resource => {
    let asType = 'image'; // Default is image
    if (resource.endsWith('.woff2') || resource.endsWith('.woff')) {
      asType = 'font';
    } else if (resource.includes('fonts.googleapis.com/css')) {
      asType = 'style'; // Google Fonts uses 'style'
    }
    preloadLinks += `<link rel="preload" href="${resource}" as="${asType}" crossorigin="anonymous">\n`;
  });

  console.log(preloadLinks);
})();

Remember to carefully review and remove anything that doesn’t need to be preloaded, for example, images from blog posts.

Using Speculative Loading

Recently, WordPress has released a plugin developed by the official WordPress Performance Team that uses the <link rel="prefetch" /> and <link rel="prerender" /> attributes to preload a page that is likely to be needed next, saving time.

Image Optimization on Websites

At this point, I’ve mentioned image optimization on websites three times already—and for good reason. It’s one of the main culprits behind unusually high page sizes that browsers have to load. Sure, an uncompressed CSS or JavaScript file can be hefty, but it still pales in comparison to a single 4K image—which is basically the elephant in the room.

When using images on your site, you should always compress them to keep their file sizes as low as possible without significantly affecting display quality. Realistically, website images don’t need ultra-high resolutions like 4K or 8K. In most cases, resizing them—especially their width—to under 2000px is more than enough. After all, the maximum content width for most websites rarely exceeds 1600px. The blog you’re reading right now? Its content width is just 799px.

Another key factor is the image format. Instead of the traditional JPEG/PNG/GIF formats, you should consider using the WebP format (.webp)—originally developed by On2 Technologies and later acquired and enhanced by Google. WebP supports both lossless compression (like FLAC for audio) and lossy compression (like MP3 for audio), and it’s very versatile. It even supports animated images (like GIFs) and transparency.

That may all sound a bit technical, but don’t worry—WordPress plugins make this process a breeze. Many plugins can automatically resize, compress, convert to WebP, and display images on your site without you lifting a finger. If you’re looking for a free option, Smush Image Optimization is a solid choice. And if you’re willing to pay, the Pro version of Smush unlocks even more powerful features.

Personally, I use Smush on nearly every WordPress site I manage because it just works. Here are some reasons why I think it’s worth it:

Excellent compression compared to other plugins.
Automatic processing of images when uploaded—no need to optimize manually.
Background optimization of existing media (Pro version).
Option to retain original images, so you can restore them if needed.
Seamless .webp generation and delivery on the front-end.

You might be thinking: “How much space can you really save by compressing an image? Maybe 30–40% tops?” Nope. I’ve seen reductions of 75–80%, especially with screenshots. It’s seriously impressive.

Solving Render-Blocking Issues: Combine, Critical CSS, Defer, Async

Earlier in the section about preload, I briefly mentioned the concept of Above the Fold. Originally, this term came from newspaper design, referring to the area of content visible when a newspaper is folded in half.

Today, in the context of websites, it still refers to the initial visible area of a webpage—the content users see immediately without scrolling. This area typically includes branding elements and key information you want visitors to see right away.

Now, there’s no fixed pixel height for what counts as “above the fold” because it varies based on the viewport size of the user’s device. Even tools like Google PageSpeed Insights only estimate the “above the fold” area by simulating how the page loads on a standard device under standard conditions.

With that in mind, it’s safe to assume that the above the fold content is critically important and should load quickly and clearly for users upon page load.

So, why are we talking about Above the Fold here? Because it plays a central role in speed optimization—particularly when dealing with render-blocking resources like CSS and JavaScript. If we understand how these resources affect rendering, and how they relate to above-the-fold content, we can optimize load times significantly.

By default, CSS files are render-blocking. That means as the browser parses the page from top to bottom, it will pause rendering whenever it encounters a <link> tag that points to a stylesheet. It has to download and parse that CSS file before continuing. If your site loads several separate CSS files, this behavior can seriously delay rendering and impact perceived load time.

JavaScript behaves in a similar way—but it’s a bit easier to handle. You can use the defer or async attributes on <script> tags to prevent JavaScript from blocking the rendering process.

The big challenge in WordPress is that most themes and plugins load their own separate CSS and JS files. This makes controlling render-blocking behavior harder because you’re dealing with assets from multiple sources.

Handling Render-Blocking with CSS

To address the render-blocking issue caused by CSS, we can apply one or a combination of the following techniques. The core idea is to prioritize the loading of critical CSS—only the styles required to render the above the fold content—while deferring the rest to load asynchronously or later in the HTML document.

However, implementing Critical CSS in WordPress can be quite tricky, especially if you’re hoping to rely on plugins to automate the process. Each plugin tends to include its own CSS files, themes also have their own stylesheets, and if you’re using Elementor, the chances of conflicts or visual glitches with Critical CSS are pretty high—unless you’re doing everything manually. I’ll probably write a dedicated guide on that in the future when I have time.

So, what’s a more practical solution? One that’s easier for most users is to use the Combine CSS technique. This involves merging multiple CSS files into a single or fewer files to reduce the number of HTTP requests. Fewer requests generally mean faster load times.

But… this approach introduces a new issue.

By combining all CSS files, you end up with one large file. That can take longer to download—especially on slower networks—and worse, with modern web standards like HTTP/2 and HTTP/3, it’s often unnecessary. These protocols support multiplexing, meaning the browser can download multiple smaller files in parallel much more efficiently than before.

So if Critical CSS is hard to implement, and Combine CSS is no longer optimal… what’s the solution?

That’s where I had a bit of an aha! moment.

What if we load CSS asynchronously, defer its execution, and only render it after the DOM is ready? This could reduce render-blocking significantly. Of course, doing this introduces the risk of a flash of unstyled content (FOUC)—where the site briefly appears unstyled for 1–2 seconds before the CSS loads in. Still, this trade-off might be worth it if it means shaving seconds off your page load time.

In many cases, this deferred loading strategy can outperform both Critical CSS and Combine CSS approaches when properly implemented.

CSS does not support defer like JavaScript by default, so it requires some tricks to adjust. In the case below, we will use a plugin to handle this.

To solve the poor user experience issue when applying defer loading, we just need to preload a few important .css files before the browser starts rendering — I already mentioned preload above.

Here is a detailed guide on how to set CSS to load with defer and preload important .css files first, using the support of the following plugins: CSS JS Manager, Async JavaScript, Defer Render Blocking CSS supports WooCommerce, and Insert Scripts in Header and Footer.

Note: You should disable the combine and minify CSS features in caching plugins such as WP Rocket, LiteSpeed Cache, WP Fastest Cache, etc., if they are enabled, when using the defer CSS method.

First, we need to identify which .css files are being loaded on the page by visiting the homepage and running the following JavaScript snippet in the Console tab of the DevTools.

(function() {
  const cssFiles = [];
  const linkElements = document.querySelectorAll('link[rel="stylesheet"]');

  linkElements.forEach(link => {
    let href = link.getAttribute('href');
    if (href) {
      // Convert links to the format //domain.tld
      href = href.replace(/^https?:/, '');
      cssFiles.push(href);
    }
  });

  console.log(cssFiles.join('\n'));
})();

You will receive a list of .css files loaded on the page, including both internal website files and third-party files, arranged in order with the files loaded first appearing at the top.

Now that you have the list of CSS files to handle, your task is to classify them based on your experience as follows:

List 1: Third-party CSS files that are necessary for the main display of the page (e.g., Google Fonts), for the purpose of preloading.
List 2: Internal CSS files of the website that you consider essential for the main display of the page, for the purpose of preloading.
List 3: Remaining CSS files that you think should be loaded last, for the purpose of deferred loading.

After you have these lists, prepare preload tags using the syntax below, repeating for each CSS link in List 1 and List 2:

<link rel="preload" href="//domain.tld/CSS-FILE" as="style" crossorigin="anonymous">
<link rel="preload" href="//domain.tld/CSS-FILE" as="style" crossorigin="anonymous">
<link rel="preload" href="//domain.tld/CSS-FILE" as="style" crossorigin="anonymous">

After preparing the code, install the Insert Scripts to Header and Footer plugin (if you don’t have it yet), then go to Settings → Insert Scripts to Header and Footer and paste the code into the Scripts in Header section. That’s it.

Next, you will need to install the plugins CSS JS Manager, Async JavaScript, and Defer Render Blocking CSS supports WooCommerce on your website. Then, access CSS JS Manager from the admin dashboard.

Then click the Add New Resources button.

Then copy the CSS file links from list 3 into this section, select the Method as Defer, and save. If there are any CSS files you consider unnecessary, choose Remove this under Selection Logic.

Repeat this process until complete.

Essentially, this plugin uses a technique to defer loading CSS files by first using preload to have the browser load the file early. Once the file is preloaded, it changes the attribute from rel="preload" to rel="stylesheet" so the browser recognizes it as a CSS file and applies it to the page rendering.

Handling Render-Blocking with JavaScript

Unlike CSS, JavaScript execution can be easily changed so it doesn’t block rendering on the browser by simply adding the defer or async attribute to the JavaScript loading elements. However, in WordPress, to do this effectively, you will still need to use a plugin. Here, we will use the CSS JS Manager, Async JavaScript, Defer Render Blocking CSS supports WooCommerce plugin that we have already installed.

First, you also need to identify which .js files your website is using by running the following code snippet in the Console of the browser’s DevTools.

(function() {
  // Get all entries from the Performance API
  const resources = performance.getEntriesByType('resource');
  const jsFiles = [];

  // Filter the entries that are JavaScript from the resource list
  resources.forEach(resource => {
    if (resource.initiatorType === 'script') {
      let jsFile = resource.name;
      // Convert links to the format //domain.tld
      jsFile = jsFile.replace(/^https?:/, '');
      jsFiles.push(jsFile);
    }
  });

  // Print out the list of JavaScript files in the actual order they were loaded
  console.log(jsFiles.join('\n'));
})();

It will generate a list of .js files loaded on the website in the order they were previously loaded. The purpose is to easily identify the first 2-3 files to set as async, while the remaining files will be set to defer. Usually, we set the jQuery library to load asynchronously to ensure it loads earlier than the files loaded with defer.

After you have the list of files to apply defer and async, go back to the CSS JS Manager in the WordPress admin dashboard, click the Add New Resources button, enter the .js file link, select the file type as JS, and choose the corresponding Async or Defer option.

Conclusion

The above is what I need to write about optimizing the speed of a WordPress website. The article is quite long, so if you have any questions, please leave a comment below.