Welcome to read my overview of the WordPress optimization when speeding up or setting up a traditional WordPress website. Before we dig into numbers and technologies I would like to give a brief introduction about the BestCloudTools project.
Mostly BestCloudTools is a content-sharing website to give you a clue about the best website building tools out there. On the other hand, it’s a hands-on project trying to combine the best practices and technologies when building a fast WordPress website. The main keywords on this project when optimizing WordPress are the A2 Hosting server platform, LiteSpeed caching technology, and Cloudflare content distribution network. The orchestration of those technologies and applying the best practices can be best represented as follows.
PageSpeed ScoreA (99%)
YSlow ScoreA (96%)
Fully Loaded Time2.0s
NB! The current score is based on the Legacy Report and is obsolete. Update Coming Soon
Let’s proceed and find out how those GTmetrix scores are achieved. Be aware that Fully Loaded Time indicated above is the average value for all pages and can differ from page to page. In this guide, we will take a closer look at BestCloudTool’s landing page. Below you can see the timing graphic generated by the site performance measurement tool. Be aware that every run of the measurement cycle can bring up slightly different results. Know that the frontpage’s Fully Loaded Time is 1.4s when the cache is hit.
Now we go through each page load timing and try to explain the best practices to apply when working on WordPress optimization.
Optimizing Time to First Byte for WordPress 156ms
Time to First Byte (TTFB) is the number of milliseconds spent to receive the first byte of the response once it has been requested. TTFB measures the duration from the user’s browser making an HTTP request to the first byte being returned by the server. This metric is one of the key indicators of web performance. As soon as the browser has started receiving content, it can start building up the page for the user. The time to first byte is made up of three components.
- The time needed to send the HTTP request.
- The time needed for the server to process the request.
- The time needed for the server to send back the first byte of the response to the client.
According to Google, your website’s TTFB should be 200 milliseconds or less. When your website TTFB is more than 500 milliseconds you should start improving your website. Usually, longer TTFB times are related to dynamic content or cheap shared hosting plans. If your webserver takes too long to even send the first byte of a page request, two problems can occur:
- Your website’s visitors will abandon your site and visit your competitor’s site instead.
- Your website’s SERP rank can suffer because Google takes TTFB into consideration.
Hence 156ms of TTFB is an excellent result. Mission accomplished!
What Causes Slower TTFB?
Four main causes of slow TTFB are:
- High web traffic.
- Network problems.
- Dynamic content generation.
- Sloppy database design.
Some ways to improve the TTFB include: optimizing application code, implementing caching, fine-tuning your web server configuration, or upgrading server hardware.
Although upgrading server hardware is the quickest and easiest solution to enhance the website performance, it’s strongly recommended to fix the other areas first. Know that WordPress itself is the biggest bottleneck in website performance!
How to Improve TTFB in WordPress Optimization?
There are many opportunities to improve TTFB for your website. Though it’s possible to improve low end shared hosting website, it’s strongly recommended to use at least a premium shared hosting plan. Ideally, VPS and dedicated hosting plans should be preferred, but unfortunately those plans are not affordable for everybody. When setting up a WordPress website, I strongly recommend using one of the A2 Hosting LiteSpeed WordPress Plans.
High Web Traffic
Due to high traffic, the origin server may reach very quickly to its capacity. Please be aware that there can be good traffic and bad traffic. Bad traffic is usually malicious bots crawling your site and causing unnecessary server load. At the same time, there can be good traffic like Google bots. Blocking malicious traffic is the best solution here. I even recommend blocking bots like SEMrush and Ahrefs via
NB! SEMrush and Ahrefs may not fully honor
robots.txt file content.
When your online business is directly dependent on either SEMrush or Ahrefs ranks, do not block these bots.
You can use Cloudflare to make sure that malicious bots do not crawl and slow down your website. When your origin server is still overloaded try to upgrade your hosting plan. Though you can freely choose your WordPress hosting solution, I still recommend choosing one of the premium options from A2 Hosting LiteSpeed WordPress Plans.
I do recommend using a reliable DNS and CDN service providers like Cloudflare. Cloudflare has many advanced techniques to speed up your website’s network traffic. Please take a closer look at All the Benefits You’ll Get When Using Cloudflare including fast DNS, Argo Smart Routing, and HTTP/3. Cloudflare has even offline mode feature to display a copy of your website when the origin server is unresponsive for some reason.
Dynamic Content Generation
Dynamic content (which is commonly used by WordPress) is one of the biggest causes of slower TTFB. Most pages on the web are dynamically served. Unlike static webpages that are sent to a web browser instantly upon request, dynamic web pages need to be assembled each time a user requests the webpage. This assembling process is what slows TTFB.
One of the biggest bottlenecks of dynamic content generation is the usage of many sloppily built plugins. BestCloudTool website uses only 12 plugins to expand the required functionality. Usually, WordPress plugins provide a great amount of extra functionality, but often only 10% of the functionality is used on the entire webpage. That means roughly 90% of the plugins code is unnecessary ballast in your server. After all, it’s still WordPress. Isn’t it? 🙂
You may think that well it doesn’t really matter when there is more code but WordPress uses only 10% of it. Right? No, it’s definitely more work for PHP on runtime. This 10% of code can have reference to classes that are sloppily built and may contain a lot of unnecessary code that needs to be parsed and processed by PHP. This for sure affects website performance and TTFB when the cache is not hit. Even WordPress itself contains a badly designed code in some places. Hence the rules to keep in mind in WordPress optimization:
- Keep plugins count as low as possible.
- Find a plugin that covers other plugins functionality and remove redundant ones.
- Measure website performance every time when adding a new plugin.
Significant improvements to TTFB occur by caching your dynamic pages. Caching your pages make the pages “pre-built,” with HTML ready to transfer when a browser requests the pages. There are mainly two options how to cache dynamic content:
- WordPress plugins – plugins such as LiteSpeed Cache Plugin or WP Rocket Plugin will help you cache your dynamic pages when optimizing WordPress. The plugins keeps track of when a “saved” dynamic page should be renewed so that the freshest copy possible is served. This is the most recommended option.
- WordPress hosting that caches automatically – WordPress hosting can give you caching capabilities that improve your site’s TTFB. Usually, Varnish or any other HTTP reverse proxy-based solution is used on the front side.
Not using WordPress CMS? Discover more LiteSpeed Caching Plugins.
Last but not least in WordPress dynamic content optimization, keep your WordPress version up to date. This may help to decrease TTFB for your website. Usually, the latest version contains code improvements and security fixes. Right, you should also not forget security!
Sloppy Database Design
By default, WordPress keeps all the post revisions in the database. I can say that it’s an unnecessary default behavior and revision numbers should be kept rather low. Otherwise, the posts table may grow big fast and may start causing performance problems. Fortunately, the LiteSpeed Cache Plugin contains all the necessary tools to control revision numbers. Besides, you can find many other tools to keep your database in good condition.
Today it’s suggested to get rid of the MyISAM and use the InnoDB database engine instead. This should not be a problem in 2020, but again some badly designed plugins may still create tables using MyISAM. Fortunately, the LiteSpeed Cache plugin has a built-in converter to transform all the tables for you.
Last but not least in WordPress database optimization, choose the WordPress plugins carefully. Complex plugins may run many unoptimized queries because of the complex business logic and database structure. Hence, you should think twice before installing any plugin. You need to ask a question from yourself. Does my website really needs that plugin? Maybe there are alternatives. For example, you don’t need the whole OptinMonster plugin when you simply need a subscription form in the website footer. Besides, sometimes it’s wise to hire a developer and implement only the feature you need. Yes, it’s a bit more expensive, but the entire website remains healthy and performs much better. Even the administration UI looks cleaner and simple to use.
DOM Interactive and DOM Loaded Time 0.7s
To load a page, the browser must parse the HTML to the DOM tree, which adds additional time to the page load. Before we dig into tips on how to decrease DOM Loaded Time lets go through the principle terms first.
What is the HTML DOM?
What is DOM Interactive and DOM Loaded Time?
What is Parser Blocking Resource?
When the browser loads HTML and comes across a
<script src="…"> tag and has to go through the whole process again. It’s a sequential process, and that’s parser blocking. When no
async attributes used, then all scripts are considered as parser blocking resources.
What Script Deferring Does?
defer attribute tells the browser not to wait for the script. Instead, the browser will continue to process the HTML and build DOM. The script loads in parallel and then runs when the DOM is fully built. In other words:
- Scripts with
deferattribute never block the page.
- Scripts with
deferattribute always executes when the DOM is loaded (but before the
How to Decrease DOM Interactive/Loaded Time in WordPress Optimization
<script src="..."> tag until that script has been downloaded, parsed, and executed. This also means that users can’t see the page content until it downloads and runs. The solution here is to use the
defer attribute for scripts, download them in parallel and execute before the
Fortunately, the LiteSpeed WordPress plugin has Load JS Deferred and Load Inline JS features for this purpose. Please find the configuration instructions on the LiteSpeed Cache Settings page to optimize your WordPress website.
Please make sure that the scripts that can’t be deferred for some reason are small as possible. More code means more downloading, parsing, and execution time.
Besides, optimization tools strongly recommend combining all the CSS/JS files into fewer files so that browser has to make fewer extra requests. Also, your website’s HTML DOM tree is slightly smaller after this optimization, and the parsing of HTML is faster. Why? Because your HTML contains less
<script> tags. Even the source code of HTML looks smaller and cleaner after this. LiteSpeed WordPress plugin has CSS Combine and JS Combine features for this purpose.
Make Fewer HTTP Requests is also a performance metric suggested by GTmetrix and Google PageSpeed Insights. Even when using HTTP/2 or HTTP/3 it’s still recommended to keep HTTP requests count as low as possible. Besides, fewer files to cache and a better overview of what exactly is happening on page load.
First Paint and Contentful Paint 0.8s
Before we dig into tips on how to decrease First Contentful Paint Time lets go through the principle terms first.
What is First Paint Time?
First paint time is the first point at which the browser does any sort of rendering on the page. Depending on the structure of the page, this first paint could just be displaying the background color or the majority of the page. From the user point of view, First Paint Time may not be that valuable.
What is First Contentful Paint Time?
When the browser paints any “consumable” content on the screen, First Contentful Paint Time is the point in time when it happened. This could be text, an image or canvas render. Because the focus is on content, this metric gives you an idea of when your user receives consumable information. This is much more useful for performance assessment that just the first rendering of anything. Be aware that First Contentful Paint Time may often be the same as First Paint Time.
How to Decrease the First Contentful Paint Time in WordPress Optimization
Minifying and combining CSS style resources is the fastest and easiest solution what you can use here. Again LiteSpeed Cache Plugin comes to the rescue. You can use CSS Minify, CSS Combine, Unique CSS File, and CSS HTTP/2 Push to optimize the loading of CSS styles.
Unfortunately, this is not enough when you want a fast WordPress website. Google developers suggest that you should prioritize visible content and that leads us to the Critical Rendering Path. When running the PageSpeed Insights tool, you likely get a suggestion to remove unused CSS/JS. Unused CSS/JS is a curse in environments such as WordPress, Joomla, or Drupal. Each theme and plugins add their own CSS/JS code that covers all the use cases all over the website.
The best what you can do here is choosing your WordPress theme and plugins wisely. Alternatively, you can hire a developer to extract the needed functionality out from the plugins that are used on your website and remove everything else. Of course, this comes with a trade-off of website speed vs website maintainability.
How to Optimize Image Loading
Use lazy loading to load all images on your website. On the LiteSpeed menu, navigate to Page Optimization > Media Setting > Lazy Load Images and turn this feature on for your website.
Last but not least, do not forget to convert your images to more optimized formats. Use the WebP format that is 30% smaller in size on average than other image formats. Fortunately, LiteSpeed Cache Plugin can help us here again. By default, you can optimize 1000 images per month for free and buy more quota when you have more images.
How to Optimize WordPress for the Critical Rendering Path? Advanced
Before we dig into tips on how to optimize Critical Rendering Path let’s go through the principle terms first.
What is Critical Rendering Path?
How to Decrease the Size of Loaded CSS Styles in WordPress Optimization
WordPress, including theme and plugins, may load unused CSS styles and this is inefficient in terms of website performance. To identify which CSS styles are unused on the webpage, please use the DevTools Coverage tab in Chrome. When you are lucky you can dequeue the entire CSS resource when none of the styles are in use on the page. Again this requires a developer and costs some money, but you get a much faster WordPress website. I was able to reduce CSS code from 265kB to 44kB in size. This means 83% less CSS code to download and apply by browser.
For example, you can extract used CSS style fragments from theme or plugins files to a separate CSS file or files and load them instead. As mentioned earlier, this comes with a trade-off. Though it makes your website loading faster, it has a bad impact on your website maintainability. Hence make sure you have a development process and version control in place when doing such WordPress optimization. Of course, you need a developer for this and make sure your developer has proper skills for that job 🙂
Last but not least, you can separate critical and non-critical CSS code into different files. It’s also strongly suggested to inline critical CSS and defer non-critical CSS style code. Here is an example of how to load a non-critical CSS file
<link rel="stylesheet" href="https://www.yourdomain.com/non-critical-styles.css" type="text/css" media="print" onload="this.media='all'; this.onload=null;" />
The website footer can be considered as Below the Fold content. Hence all the
<footer> related CSS code can be extracted to a non-critical CSS file and can be deferred.
Alternatively, you can try any critical CSS generation service where critical CSS is generated automatically for your website. Though the LiteSpeed WordPress plugin has Generate Critical CSS feature available, I haven’t had a chance to try it out yet. Please feel free to try it out for me and share your opinions in the comments 🙂
Why is Critical Path CSS Important?
Your website loads CSS styles to construct the render tree for your pages. You should mark any non-essential CSS (styles used Below the Fold or for different layout) as a non-critical resource, either by using print or other media queries in the link’s media attributes. Make sure that the amount of critical CSS and the time to deliver it is as small as possible. This is very crucial for responsive websites when customers using mobile devices when surfing over the slow networks.
Always choose and use a Mobile-First WordPress theme on your website. The same principle applies when choosing WordPress plugins that add any HTML to the frontend. Learn More
Why Should Critical Path CSS be Inlined?
For best performance, you may want to consider inlining the critical CSS directly into the HTML. This eliminates additional roundtrips in the critical path when the webpage loads. In the best case, your page may have only one roundtrip when only the HTML itself is a blocking resource.
How to Optimize Image Rendering for Above the Fold Content
Usually, each WordPress page has a featured image as one of the first elements in the article. To paint this image as quickly as possible you can add a preload link for that image into HTML. You may know that WordPress hints browsers about available image sizes through the
srcset image attribute. So which image we should preload then? Please keep in mind that network speed is not a problem for desktops using a broadband connection, but for mobile devices. Hence it’s reasonable to preload an image that is most suitable for mobile devices. For example, the BestCloudTools website preloads featured images with size 300×300 pixels.
Images that are visible inside the Above the Fold content, use the
data-no-lazy attribute to exclude them from lazy loading.
Onload 0.9s Coming Soon
Stay Tuned because There are More Stuff to Come!
Thanks for Reading and Good Luck on Your Journey! Need Some Help or Would Like to Ask Something about Current Content? Please Add a Comment 🙂