Speed Up Your Divi Site With A Caching Service To Help Boost Your Google Rankings

Speed Up Your Divi Site With A Caching Service To Help Boost Your Google Rankings

Since search engines such as Google have been taking page loading speed into account in their ranking algorithms since as early as 2010, making sure that your site loads quickly is not only essential to providing a good user experience for your site visitors, but it can also help or hurt your position on search engine result pages. Complex content creation solutions such as the Divi theme and its Divi Builder can pose a challenge to achieving high speed out-of-the-box since they require a fair bit of processing to render page content each time that a page is viewed. Divi has made strides toward improving performance, but much more can still be done by website administrators to implement performance optimizations that help reduce the time it takes to serve their site’s pages to visitors.

There are many different things that factor into page loading time, but the metric we will focus on today is referred to as “Time to First Byte” (TTFB) by Google PageSpeed Insights and other performance analysis tools. This is the time that it takes for the server to start responding to a request for a page on your site, and often the majority of this time on Divi-powered sites (in the absence of caching plugins or services) is taken up by loading WordPress, Divi, and plugins, and rendering content from shortcode form into HTML that can be sent back to the user. One of the best ways to reduce this time is by using a cache, which saves the HTML that is generated by Divi after it has been requested by a user, and uses that saved HTML to serve the same page to future users without needing to complete the full loading and rendering process each time. Not only does this increase the speed at which requests for your site’s pages are fulfilled, but it may also reduce the load on your web hosting server because it doesn’t need to run the WordPress and Divi code for each page request, freeing up memory and CPU cycles for requests that do require the server’s attention and allowing those requests to be processed more quickly.

Many different caching solutions exist, including cache plugins that get installed on your site and proxy caching services that run outside of WordPress and capture incoming web page requests before they even get to WordPress. Each solution will have its own way to set it up and configure it, so this article will focus on one solution which falls into the proxy caching category, and which we currently use ourselves here at WP Zone: CloudFlare. However, there are certainly other options out there and the principles I cover in this post should carry over to your service of choice.

CloudFlare: An Overview

CloudFlare is both a caching service and a global content delivery network (CDN), meaning that it can automatically store the content returned by your web server in response to user requests, and serve this content through a worldwide network of servers to help ensure that requests are answered as quickly as possible. Instead of pointing your domain name to your own web hosting server’s IP address, it is pointed to CloudFlare’s servers instead (with the help of CloudFlare’s nameservers). CloudFlare accepts incoming requests and forwards them to your web hosting server automatically when it doesn’t have the requested content in its cache, or if the cached content is too old or otherwise not useable. By default, only static content such as images and CSS stylesheets are cached, to avoid caching dynamic content which is supposed to change based on different variables such as whether the user is logged in to your site or has items in their cart, if your site is an ecommerce site. However, caching can be (cautiously) enabled for webpage content as well, and this usually provides the biggest speed boost for dynamically generated site content such as on pages powered by the Divi theme.

Getting Started

Getting CloudFlare set up in front of your site involves a few steps which I won’t cover in great detail here because they should be fairly easy to follow with the on-screen instructions provided by CloudFlare, and in the case of changing your domain’s nameservers, may vary depending on where your domain is registered.

  1. If you don’t have one already, create an account with CloudFlare.
  2. Add your site to CloudFlare using its domain name. In the process, you’ll be asked to choose a pricing plan for your site. CloudFlare does offer a free plan which has some limitations but is still quite powerful and should be able to do everything described in this article.
  3. Configure any DNS records that you have currently configured for the domain name and which CloudFlare didn’t import automatically. This is very important since the next step will involve changing your domain name’s nameservers to CloudFlare, so CloudFlare needs to have all DNS records configured before this change is made. Also, note that any DNS changes in future may need to be made manually in the CloudFlare dashboard since it may not automatically synchronize with the DNS service provided by your web host.
  4. Once CloudFlare provides the new nameservers for your domain, log in at the domain registration company you use for the domain name and change the nameservers to the values provided by CloudFlare. Make sure that any existing nameserver entries are removed.

Once you’ve completed the above steps, you’ll need to wait a while for your new nameservers to propagate across the domain name system, which can take anywhere from a few hours to a day or so. Requests to your site should then be processed through CloudFlare, and static resources such as images should be cached automatically.

Setting up Page Caching

As I’ve already mentioned, caching your Divi site’s pages themselves is tricky because we don’t want to break any dynamic functionality that may be built into your site, but page caching also offers some of the biggest benefits when the site is built with the Divi builder or another page builder that requires rendering to HTML on each page load. The approach I’ll suggest here is fairly conservative and risk-averse when it comes to the decision of whether or not to cache pages to achieve performance benefits vs. preserving dynamic functionality. I’ll start with the base configuration and then cover some additional configuration for you to consider if you are using certain ecommerce plugins.

Before you move forward, get a baseline speed score for your site with a speed test tool such as Google PageSpeed Insights or Pingdom Website Speed Test. Also, take note of the Time to First Byte (TTFB) metric’s value since this is where you should see the biggest improvement after page caching is implemented.

After implementing any of this configuration, be sure to test all functionality of your site! It is important to test multiple times because the first time you test, you may be testing with an empty cache, and the result may be different in subsequent requests when the cache for that page is populated. I would suggest a bare minimum of three iterations of each test.

Base Configuration

This configuration is one you might use for a basic site that is fairly static and doesn’t have any ecommerce functionality. It is also the starting point for sites that are more dynamic or ecommerce based.

  1. In the CloudFlare dashboard for your site, go to Caching > Cache Rules and create a new rule.
  2. Set a name for the rule; what you choose doesn’t matter from a functionality perspective.
  3. In the conditions section, choose “Cookie” as the Field, “does not contain” as the Operator, and “wordpress_logged_in_” as the value. This should disable caching for any requests when the user is logged in (and it may also disable caching for some requests where the user was logged in at some time in the past, but it should allow for caching for first-time visitors and search engine requests at the very least).
  4. In the conditions section. choose “URI Path” as the Field, “does not start with” as the Operator, and “/wp-admin/” as the value. This will exclude requests to the WordPress admin, including requests to /wp-admin/admin-ajax.php which is used by various plugins to implement ajax based functionality.
  5. If there are any pages that should not be cached, add an “And” rule for each page, choose “URI Path” as the Field, “does not equal” as the Operator, and enter the URL (not including the domain name; starting with “/”) as the Value. Repeat as many times as necessary. For example, if you have a contact page with a contact form on your site, you may want to exclude that page from caching just to be safe.
  6. Make sure that “Eligible for cache” is selected in the next section.
  7. Before deploying your rule, consider whether any of the following sections also apply to your site.

WooCommerce

If you have an ecommerce site powered by WooCommerce, it is probably a good idea to disable caching at any time where the user has one or more items in their cart. This should mitigate any caching issues on the cart or checkout page, or with cart count displays that you may have integrated in your site, etc.

In the rule you created previously, add a condition with “Cookie” as the Field, “does not contain” as the Operator, and “woocommerce_items_in_cart” as the value.

Simple Payment Module for Divi

Since our Simple Payment Module for Divi doesn’t have a separate cart or checkout page, it should work with the base configuration shown above. Out of an abundance of caution, I’d recommend that you also disable caching on the page(s) containing the payment module, as per the instructions in the Base Configuration section above.

Easy Digital Downloads

If you sell products on your site using Easy Digital Downloads, a slightly more complex process is required to make page caching work. This is because Easy Digital Downloads uses native PHP sessions by default, which typically trigger the web server to send response headers that disable caching (again, to avoid issues with dynamic content being cached). To prevent Easy Digital Downloads from starting a session when it is not needed, you can use the following code in a plugin that supports PHP snippets or in a custom plugin (just drop it into a PHP file in your wp-content/plugins directory):

/*
Plugin Name: Disable Unnecessary EDD PHP Sessions
Author: WP Zone
Author URL: https://wpzone.co/
*/

add_filter('edd_start_session', function($start) {
    if (!$start || $_REQUEST || isset($_COOKIE['PHPSESSID'])) {
        return $start;
    }
    foreach ($_COOKIE as $cookie => $value) {
        if (substr($cookie, 0, 20) == 'wordpress_logged_in_') {
            return $start;
        }
    }
    return false;
});

This code should prevent Easy Digital Downloads from starting a session in cases where there is no existing session, as long as the request did not contain any query variables or POST fields (which could indicate a request to add a product to the user’s cart), and the user is not logged in. This means that page caching should be enabled for first-time site visitors and search engine robots.

In addition to the code to disable PHP sessions, you’ll probably want to disable caching site-wide when there is one or more items in the user’s cart, to ensure that the checkout page and any cart count displays continue to work. In the CloudFlare rule you created previously, add a condition with “Cookie” as the Field, “does not contain” as the Operator, and “edd_items_in_cart” as the value.

Conclusion

If you haven’t already, deploy the caching rule you created using the instructions above. Let me re-emphasize: make sure you test your site thoroughly and repeatedly after doing this! With the plethora of WordPress plugins and configurations available, it is impossible to predict all possible problems that could result from implementing page caching, so testing is essential.

Test your site’s loading time again using the same tool you used previously. Run at least two tests and consider the result with the better score as the outcome, since the first test may result in a cache miss that needs a significantly longer time to send a response. If everything is working correctly and there were no performance optimizations in effect previously, you should see a substantial reduction in the Time to First Byte metric compared to your earlier test.

For more search engine optimization tips for your Divi site, check out my post on 5 Ways To Improve The Search Engine Performance Of Your Divi Site In 2023.

Jonathan Hall

Jonathan is the lead backend WordPress developer at WP Zone.