The Newest SiteGround Optimizer Settings (2021): Latest Version 5.8.1 With New Design, Cloudflare Full Page Caching, Extra Features

SiteGround Optimizer Settings

Want to configure the newest settings for SiteGround Optimizer?

Even though I don’t recommend SiteGround, their SiteGround Optimizer plugin has gotten better over the years. But I hope you’ll reconsider using them. Their TTFB is slow, support declined, CPU limits make you upgrade, and they’re admins of several Facebook Groups and removed hundreds (or even thousands) of negative posts about their brand. Super unethical company which is why I left them for Cloudways Vultr HF and you can see my migration results.

SiteGround No Value (Bad Review)

SiteGround Free (Bad Review)

I rewrote this tutorial to be updated for the latest version which includes a completely new design, Cloudflare’s full page caching, among other features. And since the older updates in 5.0 and 5.6, SiteGround Optimizer officially makes WP Rocket obsolete if you’re using SiteGround.

They added lots of features (heartbeat control, database cleanup, prefetch, preload, image optimization, etc). SiteGround Optimizer also uses server level caching which is faster than WP Rocket’s file-based caching. So yes, you can delete your old cache plugin and use SG Optimizer.

The only other plugin I recommend on top of SiteGround Optimizer is Kinsta’s Perfmatters plugin which takes care of a few things SG Optimizer lacks: removing unused CSS + JavaScript by unloading assets on specific content, bloat removal, hosting Google Analytics locally, etc).


1. Dashboard

The SiteGround Optimizer dashboard is an overview of your settings and notifies you of WordPress updates. You don’t need to achieve a perfect score (3/3, 6/6, 3/3) for everything. Mainly because combining CSS/JS files is not always recommended especially for larger sites. And minification should usually be done by your CDN (Cloudflare) instead of your cache plugin.

SiteGround Optimizer Dashboard


2. Caching Settings

Before configuring SiteGround Optimizer’s caching settings, login to your Site Tools account and go to Speed →  Caching (enable NGINX direct delivery, dynamic cache, and memcached).

SiteGround Memcached

SiteGround Optimizer Caching Settings

  • Dynamic Cache – On – enables dynamic cache which uses full-page caching by NGINX.
  • Memcached – On – enables memcached which speeds up database queries. Once it’s activated in Site Tools, this can be also activated in the SiteGround Optimizer settings.
  • Automatic Purge – purges cache when SiteGround Optimizer detects changes on your site. A full purge is done when you update WordPress plugins/core or delete a category, while a smart purge is done when a post is modified or after a comment is left. SiteGround recommends that you leave the “purge WordPress API cache too” setting Off  “unless you are actively using the REST API at the moment and you’re experiencing problems with it.”
  • Manual Dynamic Cache Purge – no need to do this since automatic purge should be on.
  • Exclude URLs From Caching – if you need to exclude certain URLs from cache, add them.
  • Exclude Post Types From Caching – same thing as the previous setting but for post types.
  • Browser-Specific CachingOff – SiteGround recommends only enabling this if you are having issues with plugins or things like generating the mobile version of your website.
  • Cloudflare Full Page Caching – On – enable for most websites, but usually not for WooCommerce or sites with lots of dynamic content. This caches everything instead of only static assets like CSS, JS, and images (can make a big difference). You need to activate Cloudflare in Site Tools, then add your Cloudflare email + Global API key to SG Optimizer. I also suggest using Cloudflare to minify CSS/JS/HTML and disabling this in SG Optimizer.
SiteGround Cloudflare Settings
Activate Cloudflare in Site Tools and use Cloudflare for minification (turn off in SiteGround Optimizer)
SiteGround Optimizer Authenticate With Cloudflare
Authenticate Cloudflare in SiteGround Optimizer and enable full page caching


3. Environment Settings

Environment settings are where you can force SSL, fix mixed content errors, control the WordPress Heartbeat API, prefetch third-party domains, and schedule database cleanups.

SiteGround Optimizer Environment Settings

  • HTTPS EnforceOn – to add SSL, activate a free Let’s Encrypt SSL in your SiteGround account, then turn on HTTPS Enforce in SiteGround Optimizer. Your website will automatically be configured for HTTPS, then your site will have the lock icon in browsers.
  • Fix Insecure ContentOff – if you see mixed content warnings in your browser when using SSL, it means you’re loading both HTTPS + HTTP. This can fix it, otherwise leave off.
  • WordPress Heartbeat Optimization – the WordPress Heartbeat API consumes CPU by showing you real-time plugin notifications, when other users are editing a post, etc. It’s not always a good idea to disable Heartbeat completely, but you can at least increase the interval to save resources and reduce CPU usage. I suggest 60s, 120s, 120s respectively.
  • DNS Pre-fetch For External Domains – open Chrome Dev Tools and use the sources tab to see third-party domains loading on your site. Prefetch establishes earlier connections to make them load slightly faster. Perfmatters and Flying Scripts can improve their load times more by delaying third-party JavaScript. Fonts + analytics should be hosted locally.
Find third-party domains in Chrome Dev Tools → Sources → Page
SiteGround Optimizer Prefetch External Domains
Prefetch those external domains in SiteGround Optimizer


4. Frontend Settings

Minification should ideally be done with Cloudflare, then should be turned off in SiteGround Optimizer. Combining files is only recommended for small websites with <10KB CSS/JS sizes.

SiteGround Optimizer Frontend CSS General Optimization Settings

SiteGround Optimizer Frontend JavaScript Optimization Settings

SiteGround Optimizer Frontend General Optimization Settings

  • Minify – Off – use Cloudflare to minify CSS/JavaScript/HTML which is faster than SG Optimizer. If you’re not using Cloudflare to minify files, these options should be enabled.
  • Exclude From Minification – if enabling minify in SiteGround Optimizer causes errors on your site, find problematic files in your source code, then exclude them from minification.
  • Combine FilesOff – only combine CSS on very small websites (and always test it). Otherwise, it can result in slower load times. WP Johnny recommends only combing if your total CSS/JS is 10kb or less which you can check in your GTmetrix Waterfall chart.
  • Exclude From Combination – no need to do anything here unless the combine setting is turned on and you need to exclude specific CSS, JavaScript, or HTML files from combining.
  • Preload Combined CSSOff – if you combined CSS, this preloads the file to load faster.
  • Defer Render-Blocking JavaScriptOn – defers JavaScript which can fix render-blocking resources in Lighthouse by delaying JS loading. Check your site for errors.
  • Exclude From Deferral Of Render-Blocking JS – the previous setting can sometimes break your website. If it does, find the problematic JavaScript files and add them here.
  • Web Fonts OptimizationOn – optimizes Google Fonts by adding preconnect to Also optimizes self-hosted fonts by preloading them. You should try to host fonts locally to avoid requests from (you can try the OMGF plugin).
  • Fonts Preloading – run your site through PageSpeed Insights and if Google recommends preloading key requests, they may suggest preloading certain fonts which you’ll add here.
  • Remove Query Strings From Static ResourcesOn – this is an old item in GTmetrix.
  • Disable EmojisOn – emojis aren’t good for your load times, so this will disable them.

CSS Size


5. Media Settings

SiteGround Optimizer’s media settings optimizes images through compression, WebP, lazy loading, and setting a maximum width which prevents users from uploading enormous images.

SiteGround Optimizer Media Settings

  • Image Compression – compression level should ideally be 85% since that’s what Lighthouse tests your website at and will result in the maximum savings. But, it will also result in the highest quality loss, so it really depends on your preference. Before saving, always backup the original images in case you’re not happy with the new image quality.
  • Use WebP Images – serve WebP images which fixes the next-gen formats item in PSI.
  • Lazy Load Media – lazy loads responsive images, thumbnails, widgets, and Gravatars.
  • Exclude CSS Classes From Lazy Load – you shouldn’t have to do anything here.
  • Exclude Media Types From Lazy Load – you shouldn’t have to do anything here.
  • Maximum Image Width – resizes images over 2560px if you’re uploading huge images.
SiteGround Image Compression Settings
85% compression level is what’s used in Lighthouse


6. Speed Test

The speed test runs your website through PageSpeed Insights.

If your Google Score is bad, check my guide on core web vitals. If your page load time sucks, check my WordPress speed guide. And if your TTFB is slow, that’s SiteGround for you. Give Cloudways Vultr High Frequency (who I use), Kinsta, or LiteSpeed servers on NameHero a try.

SiteGround Optimizer Speed Test

Backlinko TTFB Test
SiteGround has a slow TTFB reported by Backlinko


Functionality SG Optimizer Still Lacks

There are still some things SG Optimizer lacks.

Asset Unloading – SiteGround Optimizer doesn’t have any settings to remove unused CSS/Javascript. Most times, this is done using asset unloading plugins like Perfmatters or Asset CleanUp. Both plugins let you disable unused assets (plugins, scripts, styles) on content where it doesn’t need to load. This reduces the overall size of your pages and results in better PSI scores.

Remove Unused Elementor CSS JavaScript

Bloat Removal – other than database cleanup, SiteGround Optimizer doesn’t do much bloat removal (limiting post revisions, increasing the autosave interval, disabling WooCommerce admin bloat), and other things can reduce bloat and CPU usage. I also use Perfmatters for this but you can try Widget Disable, Disable WooCommerce Bloat, or doing things manually like increasing your autosave interval. There’s usually lots of junk you should consider removing.


Hosting Google Analytics Locally – fixes the “leverage browser caching” error in GTmetrix PageSpeed for Google Analytics using either Perfmatters, Flying Analytics, or CAOS Analytics.

Delay JavaScript – there’s no option to delay JavaScript, so try using the Flying Scripts plugin.


Can I Delete My Old Cache Plugin?

Yes, you can.

There’s absolutely no reason to use WP Rocket anymore on SiteGround since SiteGround Optimizer has nearly every feature of WP Rocket, plus it uses faster server level caching.




Avoid Duplicate Functionality

If you keep WP Rocket or another cache plugin, disable page caching using the helper plugin since you only want to use 1 plugin for caching (and avoid duplicate functionality in general). If you activated Cloudflare in SiteGround, the default settings should work perfectly, but I would still configure page rules, enable hotlink protection, and test Brotli, Railgun, and Rocket Loader.

SG Optimizer should automatically disable duplicate functionality:



Did I Miss Anything?

I hope this was helpful, but I also hope you consider moving away from SiteGround. If not because their TTFB is slow, then because they’ve become a very unethical hosting company.

See Also: My Full WordPress Speed Optimization Guide


About Tom Dupuis

Tom Dupuis 2017Tom Dupuis writes WordPress speed and SEO tutorials out of his apartment in Denver, Colorado. In his spare time, he plays Rocket League and watches murder documentaries. Read his bio to learn 50 random and disturbing things about him.

41 thoughts on “The Newest SiteGround Optimizer Settings (2021): Latest Version 5.8.1 With New Design, Cloudflare Full Page Caching, Extra Features

  1. Hello guys, hi Hristo,

    I am sorry but there is an issue on my end with this setup.

    Woocommerce + Cloudflare + SG Optimizer + WP-Rocket + RocketCDN (stackpath)

    All I did was switch lazy loading from WP-Rocket to SG Optimizer. Although SG Optimizer lazy load seems to indeed work better and be better recognized by lighthouse, this kills my TTBF big time.

    Found out it was due to the lazyloaded JS files being loaded by SG optimizer which were taking ages to load, not 100% sure why.

    Search console core web vitals confirmed this by going right back up when I made the switch.

    Switched back to lazy load on WP-Rocket and TTBF + loading are back to normal

    Doubt it is due to this multi CDN approach, but it seems rocketcdn (stackpath) loads pictures faster than cloudflare from what I have seen on my end…

    What has given me the best perf is to use:

    SG Optimizer as my dynamic/memcache
    CF and Stackpath as my CDNs
    WP-rocket for caching and additional small optimizations (which could be done by sg optimizer as well except lazy loading)…

  2. Does SG optimizer have setting anywhere which can take care of unused css and JS files . WP rocket recently included that option and it really helped in website speed.

    1. I don’t believe they do at the moment. WP Rocket incorporated removing unused CSS. The only other plugin I know that does this is RapidLoad by Frank (from Autoptimize), otherwise Asset CleanUp/Perfmatters for selective disabling.

  3. Great tutorial. I’ve been playing around with the settings including the settings you have detailed but for some reason the SG Optimizer makes zero difference to my page speed insights scores? I can’t fathom it and Siteground haven’t really shed any light.

    1. I have noticed the same. I’m with SG, but SG Optimizer doesn’t seem to make any difference to my page speed scores.

  4. Hey Tom, thanks for this. I know I’m getting on a bit but I’m getting mixed messages from this. I’m with SG. Are you actually recommending it or not? I have speed issues with my site and was on the verge of buying WP Rocket. Then I noticed all the functionality in SG/SG Optimizer and figured I didn’t really need it. Now I’m really confused. As you may have guessed, I’m a relative newbie to all this :-)

    1. Hey Dave,

      I generally don’t recommend SiteGround since their TTFB has gotten slower among other issues (reduced support, price hikes, CPU limits, etc). They’ve gotten worse since 2020 IMO and many other people’s opinions in Facebook Groups.

      If you decide to stay on SiteGround, you’re best off using their SG Optimizer plugin since yes, it has nearly all functionality of WP Rocket and uses server-side caching. Otherwise, I usually recommend Cloudways with WP Rocket which is what I use. CW just released DigitalOcean Premium servers yesterday, but regular DO or Vultr HF are all very fast.

      Saw your site’s TTFB was 253ms when I tested it. It’s not bad but worth giving another cloud host a shot, whether it’s Cloudways, RunCloud, or GridPane. All solid choices and much better/faster than SiteGrond IMO.

  5. Thanks Tom for this incredibly helpful article I refer to it all the time and notice the major update about no longer needing WP Rocket.

    I’ve been thinking about moving from Site Ground hosting for a while (I’m in no means a website/IT expert) and wondered what your opinion on the latest SG changes to MySQL would have any impact on server load times or if irrelevant to the Pingdom load times mentioned in this article? Cheers

    1. Hey Jimmi,

      I honestly haven’t tested it since SiteGround made the update to MySQL, GZIP, or other updates they’ve done since that Pingdom test.

      I saw Hristo’s response to your comment on the SiteGround blog. I agree, the test it “old” (less than a year) and may not be too relevant since all the updates in hosting accounts, web vitals, etc. I’m planning on running a new hosting test soon with the updated hosting plans and better metrics, but I doubt their TTFB has improved that much. Any test showing SiteGround is slow is wrong according to Hristo.

  6. To add, your test isn’t set right. There’s no way SiteGround will give you 2280ms responces from the cache. It was not configured properly and you were getting dynamic responses for sure which makes the whole chart completely wrong.

    1. “It was not configured properly”… how can it not be configured properly when nothing was configured? I signed up, installed WordPress with an Astra Starter Site, and added a couple plugins on all sites for benchmarking speeds. No SG Optimizer, Cloudflare, etc. I see this “not configured properly” response any time someone complains about SiteGrond’s slow TTFB. Is this wrong too?

      And honestly, you should start accepting at least the tiniest bit of responsibility (or at least being open to hearing people about) instead of calling anyone who disagrees with you, or puts out a test you don’t like, wrong. You have become close minded and constantly on the defense, Hristo. Anything to protect SiteGround’s reputation, huh?

  7. I am very pleased with what I’ve done with Siteground SG Optimizer. I greatly decreased resources to just 14 on an Elementor website. Site is very fast but in some speed tests the server response is very slow. I used OMGF from another one of your posts. And Optimole with Elementor. So one thing I noticed is that sometimes the server response time is crazy slow. Sometimes very fast or exceptible for a WP. Why such a fluctuation in speed. Is this what you were talking about with Siteground kind of not being consistent or slow. The sometimes slow sometimes fast is unexceptible. I talked with chat and they kind of said it’s out of scope (or we won’t help). Do you think this is a Siteground issue?

      1. Apparently SG released a bunch of speed performance enhancements today on all their plans – they claim will cut a bunch of time off of TTFB and other metrics. Curious how they do.

        1. Their taglines always have something like “up to 5x faster speeds” but those Hristo likes to overexaggerate. Think they just made dyanmic cache and memcached available on all plans. Take their claims with a grain of salt.

  8. For some reason, my hosted server was Siteground, used a cloudflare cache, bought a standalone Ip, and tested the network’s speed every 10 minutes after it was optimized. Half an hour is different, from A to B to C TO D. E. . . F, , , , , I’m going crazy. . . I don’t know what to say. Maybe we can’t use SG, even though it’s ten months away from being paid for . My site :

  9. Tom, thanks so much for this very informative article and your blog in general. You’ve helped me a lot. Although I never expect my site to go viral or anything, not that I would really want that anyway. But I would like it to be a good experience for visitors. To that end your advice has helped speed up things. I’m on SG but based on your comments I might move over to Cloudways before my billing cycle runs out. If I do, will the SG Optimizer still work or will I switch to something else?

  10. I dont have wprocket so I would like to ask you what other plugin would work good together with SG optimizer?

    I was using and testing with fast velocity, hummingbird andautoptimizer and got my yslow on 93. With sg optimizer only it got me on 84 on yslow.

    Any recommendation/help, would be much apreciated.

  11. Thanks for this useful article. Just to check – I’m using your recommended caching settings in SG Optimizer, and I use WP Rocket for other speed enhancements. Should I turn off caching in Sucuri? They give four options for caching – Enabled, Minimal caching, Site caching, Disabled

    1. Hey Tom,

      Yes only use 1 plugin for caching, probably not Sucuri. Either SG Optimizer or WP Rocket. Test both since you may get better results with one or the other.

  12. Hi Tom

    Thanks for this. Very clear and helpful.

    SiteGround seems to have added 2 new options under ‘Frontend Optimization’:
    1. Load Render-blocking JavaScript Files Asynchronously
    2. Combine CSS Files

    Would you suggest we activate them?

  13. Minify the HTML Output – should fix minify HTML items in GTmetrix (if enabled here, disable in other cache plugins + Cloudlare).

    I believe this is cloudflare and not Cloudlare? under topic 3 section

  14. Hi nice tutorial,

    I’ve some questions, which settings should I leave on in the WPRocket cache plugin?
    For instance, the mobile-friendly cache settings should I leave those on?
    And for the lazy load, should I enable it in the WPRocket plugin or the SG optimizer?

    Thanks in advance!

  15. to give fuller credit to what siteground does right, the image optimization is a nice feature of the sg optimizer. it also eliminates the need for smush. sg front-end optimizations also fixes blocking javascript.

    not sure how much the memcache, dynamic cache, and static cache helps compared to mysql optimizations and a regular cache. opcache is great.

    i also find that setting php to v7.2 or v7.3 would cause errors in sg optimizer. php v7.1 is the recommended setting to not have errors with the plugin.

  16. I don’t like the SiteGround/CloudFlare requirement to use www since it just adds another redirect for entering a url directly. I also found that using the default SiteGround setup for CloudFlare will actually double site load times, mostly because of something dealing with cookies and cache headers. CloudFlare can also increase TTFB. In all, it adds significant time to configure a website correctly with CloudFlare.

    I like some aspects of the SiteGround optimization tool. My goal was to reduce optimization plugins to one simple to configure optimization tool. What it does well is set up your .htaccess file quickly for https redirect, cache headers, gzip compression, and etags.

    However, the default front-end optimizations of SG Optimizer running on SiteGround’s GoGeek Share Hosting really aren’t as good as the default optimizations of Autoptimizer and Cache Enabler.

    I had been using Jetpack’s free CDN. It has some drawbacks, but it doesn’t harm performance like the SiteGround/CloudFlare free CDN.

    My main goal was to simplify configuration and maintenance of optimizations and caching by moving to SiteGround. However, the optimizations seemed to have failed to match performance.

    CloudFlare continues to fail in providing a free default configuration that actually increases rather decreases page load performance, and I believe it is on purpose as a marketing gimmick to give free users lower performance so they can offer to sell them an upgrade to make it faster. SiteGround’s participation in this marketing gimmick makes the “Go Geek” false advertising. Geeks prefer performance, not marketing gimmicks.

    The high regular pricing and steep space and CPU limitations are of concern with SiteGround, which makes it less attractive that other hosting plans. You can get almost good performance with the default configuration without CloudFlare. However, getting great performance is more difficult with SiteGround. The Free SSL and staging sites are great features too, but you can get those with hosting providers. Usually, what most providers are missing is the opcache, which can significantly improve Ajax performance, though you can always throw more hardware resources at that problem.

    I won’t name the other hosting provider so it doesn’t seem like I’m just trying to promote another hosting provider. I am just saying SiteGround really isn’t living up to the hype. They are close. They just aren’t there yet. It is still anybody’s game to provide all the key features since the one button optimizations just aren’t there yet.

Leave a Reply

Your email address will not be published.