How to improve WordPress Site Speed

In recent years, Google has made so many changes to its algorithms that its core tool for measuring website speed has become extremely important. Nowadays, every website needs to load quickly and meet several requirements to score over 90 points and pass the Core Web Vitals test.

In simple terms, a fast website is one that has the smallest possible size, and its code doesn’t delay the loading process. Ideally, when you enter the URL, the website should appear instantly. This isn’t just about providing a good user experience, but also about saving money. The faster your site is, the less space it theoretically occupies and the fewer server resources it consumes – making it cheaper.

You might think this doesn’t matter, but if you consider how many websites exist in the world, you can imagine how much could be saved if all images were compressed by, say, 50%. Of course, it’s never that perfect, but things are moving in the right direction.

Also, I wouldn’t assume that the biggest companies care about users or the energy needed to power the servers. They care about their interests, which include how fast they can display search results.

Checking and Improving WordPress Site Speed

How can you check your website’s speed? There are several tools, but I will focus on one: Google’s PageSpeed Insights, and I will explain how to interpret the data you receive after the test.

The “speed” test is based on a calculator that considers five elements: First Contentful Paint (FCP), Speed Index, Largest Contentful Paint (LCP), Total Blocking Time (TBT), and Cumulative Layout Shift (CLS). It may sound scary, but it’s really not.

A score of 90 points or above is considered good, and you should aim to achieve that. Contrary to what you might think, it’s not that difficult, but it does require some experience and programming knowledge.

1. First Contentful Paint (FCP)

Let’s start with First Contentful Paint (FCP). This metric focuses on the user and how they perceive the page’s loading. FCP measures how long it takes for the user to see your page fully, without any missing elements. Google’s maximum allowed FCP loading time is 1.8 seconds.

There are many reasons for slow FCP loading, and I’ll describe as many as I can to help you improve this metric.

• Eliminate render-blocking resources – These are URLs (and the CSS or JavaScript files they contain) that must be loaded for the page to display properly. The best practice is to use only critical resources in these URLs, while deferring the rest and removing anything unnecessary from the page. For example, if your homepage doesn’t use a carousel but still loads a JavaScript file for it, it’s a good idea to remove that script entirely or only load it where needed. If removal isn’t possible, you can try deferring the script.
• Minify CSS – Ensure CSS files are minified, as this can drastically reduce their size. Most dedicated WordPress servers or plugins have this functionality built-in, so implementing it shouldn’t be a problem.
• Remove unused CSS – Implement solutions that only load the CSS used on the specific page. This process can be complicated if your site wasn’t designed with this in mind.
• Remove unused JavaScript – Unused JavaScript always slows down the site for two main reasons. First, if it blocks rendering, the browser has to download, parse, compile, and evaluate the script, which takes time. Many people set such code to load asynchronously, which helps, but it’s still not ideal. The code competes with other resources for bandwidth, impacting performance, and still needs to be loaded eventually. On mobile devices, sending unused code over the network is undesirable, as users often have limited data.
• Preload required resources – You can instruct the browser to preload certain elements from your site in advance, speeding up page loading. Be careful not to preload too many elements, as this can have the opposite effect.
• Time to First Byte (TTFB) – This is the time it takes your server to send the first byte of data after receiving a request from the browser. It’s not a critical web metric, so if your score is slightly lower here, it’s okay as long as your other metrics are strong.
• Avoid multiple redirects – This should be obvious. Too many redirects slow down the site, so minimize them.
• Preload key requests – You can instruct the browser to preload specific JavaScript or CSS files. In simple terms, if you preload a JavaScript file that takes 200ms to load, you save that time.
• Avoid large network payloads – This is crucial as it directly advises against using large resources on the page. These could be huge JPEG files or oversized CSS files filled with unnecessary code. Downloading such a page is expensive, so Google is unlikely to show it high in search results since it could cost the user extra data charges.
• Use efficient caching policies for static resources – This is about proper cache configuration. The most important directive is max-age, which tells the server how long to keep a resource in cache. One important thing to remember is that with a long max-age directive, users may not see updates to files like CSS or JavaScript. To solve this, you can version your files so each change gives the file a unique name.
• Avoid excessive DOM size – This is important as it greatly affects how the site loads, especially on mobile devices. The DOM is, in simple terms, the structure of the HTML document. It’s important that this structure is optimized – no excessive nesting, no overly large DOM. Less experienced developers often create very “long” pages with JavaScript that uses general selectors. Instead of targeting a specific element, they may check all <li> elements on the page, which, combined with a large DOM, can severely slow down the browser.
• Minimize critical request depth – Limit network requests for interdependent resources. Check if some of these resources can be preloaded or loaded asynchronously if they are critical. If size reduction isn’t possible (because it’s an external library), consider writing something smaller tailored to your site instead of using the library.
• Ensure text remains visible during web font loading – Some fonts can be quite large, and while they load, no text may be visible on the page. Once loaded, the user sees what is called a “flash of invisible text.” This problem is easily fixed by using the font-display property where the font is declared, so the browser uses a system font until the custom one is ready. There are several options to choose from, so I recommend reading up on this.

2. Speed Index

The Speed Index shows how quickly content appears on the page you’re trying to visit. What’s interesting is how Lighthouse measures this: it records a video and then evaluates the visual progression between frames. The result is based on this process, handled by the Speedline Node.js module. The score is then compared to real-world data from the HTTP archive. To improve this score, you should focus on the three elements we discussed above:

• Minimize main thread work
• Shorten JavaScript execution time
• Ensure text is visible during font loading

3. Largest Contentful Paint (LCP)

Largest Contentful Paint (LCP) is a crucial metric (weighted at 25%) that measures perceived load speed. A good LCP score usually indicates that users feel the site is useful and functioning well.

Here’s a quote from Google’s documentation: “LCP reports the render time of the largest image or text block visible within the viewport relative to when the user first navigated to the page.”

A good LCP time is under 2.5 seconds, which may seem simple, but in reality, it can be challenging. A poorly designed and coded site can result in a very poor score. Some elements considered in LCP include <img> tags, <video> elements, background images loaded via url(), elements with opacity 0, or those that cover the entire screen and are mistakenly identified as background images. That’s why it’s so important to communicate with developers or specialists in page speed optimization early on during the design phase.

4. Total Blocking Time (TBT)

Total Blocking Time (TBT) is the total time during which the website is less responsive, starting from when the first content appears on the screen (FCP) until the page is fully interactive (TTI).

Here’s how it works: when the browser loads the page, it sometimes encounters “long tasks.” These are processes that take longer than 50 milliseconds. During such a task, the browser can’t interrupt it, so if a user tries to interact, the browser will only respond after the task finishes. If there are multiple long tasks, the user may feel the site is slow or unresponsive. TBT is the sum of all delays caused by these long tasks, showing how “blocked” the site feels during loading.

5. Cumulative Layout Shift (CLS)

Unexpected layout shifts on a website can be annoying for users. For instance, when reading text, if it suddenly moves, users can lose track of what they were reading or accidentally click the wrong link or button. In some cases, such shifts can cause serious issues, like confirming a large order by mistake.

These problems usually occur when a site loads asynchronously (elements appear at different times) or when new content is dynamically added above already visible elements. Causes include images and videos without specified dimensions, fonts that load larger or smaller than the initial placeholder, or ads and third-party widgets that dynamically resize.

How to Speed Up a WordPress Site – Tools

To speed up your WordPress site, you need to take a comprehensive approach and address all potentially problematic elements. As mentioned above, large CSS or JavaScript files, or oversized images, can affect WordPress site speed. Sometimes the JavaScript code is written poorly, and by the time the site becomes functional, the user could have made a coffee and eaten a cookie :).

Let’s start with CSS and JavaScript files. There are many plugins that can help you solve this problem. For those who aren’t programmers, a good choice would be a plugin like WP Rocket. It includes most of the essential features that will help you fix various issues.

You can, for example, set JavaScript code to load after the first user interaction (scrolling or moving the cursor), which can greatly improve your speed scores. This method will really help you get a better score in Google PageSpeed.

Another crucial element is image size. The larger your site, the more expensive it is to load, so make sure your images are as small as possible and use “lazy loading” so that they load with a delay.

Once you’ve optimized your files and code, remember that choosing the right server is also essential. We use dedicated solutions and often choose Kinsta.com, which offers great options for every need. It’s not the cheapest option, but it’s worth it. First of all, they have an excellent caching system that ensures your site performs well. Kinsta also keeps you on the latest PHP version and regularly informs users about plugin vulnerabilities. If a plugin turns out to be vulnerable to attacks, Kinsta immediately sends a notification asking for an update or temporary deactivation. Additionally, their plans include a CDN, which helps your site load even faster.

There are still many other things you can do to improve WordPress site speed, and here are a few more tips:

• Use lazy loading for user comments
• Limit or disable post revisions
• Remove Google Fonts loading
• Disable or adjust the Heartbeat API
• Disable emojis and dashicons

Conclusion

As you can see, speeding up a WordPress site is not a simple task and often depends on many factors. The truth is, if a site is well-designed and developed, working on its speed should go smoothly. Unfortunately, that’s not always the case, and that’s when a developer should step in to professionally optimize it. Poorly used plugins can cause significant problems or prevent users from navigating your site or, even worse, making purchases. In such cases, you not only lose reputation but also money.