In this guide, I’m going to take you through the best swift performance lite settings. The lite version of Swift Performance is very powerful and packs more than enough features for most WordPress users. However, if every last millisecond is important to you, there is always Swift Performance Pro, we use the Swift Performance Pro version but many of our clients run super fast sites with Swift Performance Lite.
You can follow this Swift Performance Lite settings guide from beginning to end or jump to a section using the section links below. I highly recommend reading the intro paragraphs featured just after the table of contents. Here I’ll help you avoid some common errors and show you where to get your free copy of Swift Performance Lite.
Table of Contents
These are quick links to each section of the guide. Each link corresponds to the sections found down along the left side of your Swift Performance settings page.
0.1. Installing Swift Performance Lite
0.2. Activating Swift Performance Lite
0.3. The Power of Staging Sites
0.4. Autoconfig Setup
1.0. General
1.1. General
1.2. Tweaks
1.3. Heartbeat
1.4. Cronjobs
1.5. Google Analytics
1.6. Whitelabel
2.0. Media
2.1. Images
2.2. Embeds
3.0. Optimization
3.1. General
3.2. Scripts
3.3. Styles
4.0. Caching
4.1. General
4.2. Tweaks
4.3. Exceptions
4.4. Warmup
4.5. Varnish
4.6. Appcache
5.0. CDN
5.1. General
5.2. Cloudflare
6.0. Export/Import
6.1. Export
6.2. Import
Rather than just tell you the best Swift Performance Lite settings to turn on, I’ll also explain the ones we don’t use and why. This guide aims to turn you into a Swift Performance Jedi ready to tune up your website to lightning fast speeds.
If you’re short on time and not interested in learning about each of the settings you can always just follow the headings throughout the guide. Each setting has its own heading and I have put quick instructions like “ON” or “OFF” in the heading itself so you can quickly setup your site.
Installing Swift Performance Lite
While I’m sure you already know how to install and activate a plugin, you might not be aware of a few important steps you should take before and during the installation of Swift Performance Lite.
Before you activate the plugin, make sure there are no other caching plugins active on your website. Have a look at your list of plugins and deactivate and delete any caching plugins you find. It’s never a good idea to have two plugins doing the same page speed optimizations. It can cause all sorts of issues and conflicts.
Typical caching plugins include WP Super Cache, LiteSpeed Cache, W3 Total Cache, WP Fastest Cache, and Hummingbird. Autoptimize is not a caching plugin so you won’t find caching conflicts, but you might find other conflicts. More on that later.
With that done, install and activate Swift Performance Lite. The developers have removed the free version from their website so you can only get it direct from WordPress via direct download or using the plugin search function as seen below.
Activating Swift Performance Lite
The moment you activate this plugin you will be greeted by a really useful setup wizard. This is one of the reasons I recommend this plugin to those who are starting out with optimization. The Autoconfig option makes setup a lot easier for beginners.
When the wizard begins you are presented with four options:
- Manual Configuration
- Import Settings
- Use Preset
- Autoconfig
Manual configuration lets you decide what options you want to implement.
Import settings is the option people use when they already have the perfect settings in place and want to use them again.
Use preset lets you apply a preset combination of settings.
Finally, we have autoconfig. This option detects and applies the best settings for your website. It usually does a very good job, but if you run into trouble you might need to choose manual the “manual configuration” option. You can then use this guide to apply the correct settings.
Autoconfig is the easiest way to get some important caching settings in place, so follow the autoconfig dialog boxes to get started. There are caching settings unique to your hosting environment and autoconfig will scan and then populate certain fields found in the advanced settings.
With the autoconfig setup done, follow each of the settings explained in this guide one-by-one because you will still need to do some fine-tuning manually. It’s also very useful to know what these settings actually do, especially when things go wrong.
The Power of Staging Sites
All optimization work should be done on a staging site rather than a live site. A staging site is an exact replica of your actual website. Use it to test out all the optimization work because if you cause any bugs when optimizing you don’t want it to impact your users.
If you like the load times and are sure there are no bugs on your staging site, you can push your staging site live. Pushing it live replaces your site with the new optimized version. It’s really easy and definitely the safest way to complete optimization work.
Good hosting providers will provide one-click staging; you click to create a staging site and click again to push it live. I highly recommend learning how to use a staging site, it’s pretty easy and once you start you’ll wonder how you ever made do without it.
The article linked above will help you find a host that supports one-click staging. And their support documentation will take you through the process. And their support staff are always available to help you through the process if you need additional help.
Autoconfig Setup
To use autoconfig just hit the button when you first activate Swift Performance Lite and follow the instructions. If you are using Cloudflare, you will hit a screen looking for your Cloudflare credentials. Add them now or hit the “Skip” button if you’re not sure. We’ll go through the Cloudflare setup later in this guide.
General
General
Having gone through the initial activation and setup, you will need to find your way to the Swift Performance Lite settings. You will start in “General” found in the “Settings” tab.
Before we touch a setting, let’s select the advanced view so we can access all the hidden extras. This is where we’ll find the real speed improvements.
When you open this panel you will uncover extra settings, some of which are only available to pro users and others you can change now.
Disable Cookies (ON)
If GDPR compliance is important to you then you should flick the switch and “Disable Cookies”. This stops cookies firing until a visitor has given explicit consent.
Remember, you will need to use something like cookiebot to give your visitors the opportunity to give cookie consent. Turning on this setting without a GDPR cookie plugin can cause issues with things like analytics. So get the cookie options in place before enabling this setting.
Hide Footprints (ON)
This premium feature is removes Swift Performance Pro comments from your HTML. If you aren’t concerned about seeing the comments in the HTML, which I am not, then enable this setting.
Use Compute API (ON)
This premium feature is very useful because it increases the speed of CPU heavy optimization work like minification, critical CSS generation and advanced JavaScript minification.
Prebuild Booster (OFF)
This setting can reduce CPU usage while speeding up the prebuild process. However, some users have found it to fill up their MySQL logs really fast. If you don’t know how to check your MySQL logs I would turn this setting off, just in case it causes problems.
Disable Admin Notices (OFF)
Swift Performance Lite gives you little notifications from time-to-time. The notices prompt you to clear your cache after adding a new plugin, updating a plugin or deactivate a plugin. Available to pro users only, there’s no real need to change this setting. The prompts are useful.
Debug Log
Debug Log is useful if you run into problems. If the image optimizer or caching functionality fails to work correctly, just turn on this setting, retrieve the error and share it with Swift Performance support.
Tweaks
Normalize Static Resources (ON)
This setting will resolve the “Remove Query Strings from Static Resources” warning found in GTmetrix. This warning was removed from Google PageSpeed Insights because removing query strings has become less relevant in recent years. This setting will not have a significant impact on your actual load time.
Just in case you’re wondering, query strings are extra bits of information attached to a JavaScript or CSS file URL. It’s all the stuff after a ? or & in a URL. Here’s an example of a JavaScript URL with a query string – https://ilovewww.loadlabz.com/wp-includes/js/wp-embed.min.js?ver=3.5.7
Prefetch DNS (ON)
Prefetch DNS is a useful feature that tells a browser to resolve external domain names ahead of time. This is useful for sites using third-party resources such as Google Fonts or Adsense.
DNS prefetch warms-up/resolves this connection for you ahead of time shaving valuable milliseconds off your page load. It’s basically a message from your website to your visitor’s browser saying “Hey browser, I’m planning to make a connection to this third-party URL soon, maybe you should look up the address now”.
Collect Domains From Scripts (ON)
This setting is very similar to the previous setting. The only difference is, you are now focusing on domains found in JaveScript. The setting tells Swift Performance Lite to scan all JavaScript looking for third-party URLs. If any are found, Swift Performance Lite will resolve these connections straight away.
Exclude DNS Prefetch (Unique to Your Site)
In some cases, you might want to exclude certain domains from DNS prefetch. If you use some third-party services that require you to pay for bandwidth anytime you access their resource, you might want to exclude it here so you only use bandwidth when the service is actually used.
Gravatar Cache (ON)
A Gravatar is that little image associated with your WordPress account. You see it when signed into your WordPress site up in the top right corner. You also see it when you comment on a blog post. These images are loaded from a third-party source which can cause load time delays.
Websites with very active comment sections should enable this setting and also look at using a CDN. WP-Rocket have an excellent article on Gravatar optimization.
Custom Htaccess (Optional field)
This field is used to add “force” HTTPS 301 redirects to your htaccess.php file. It is advised that you use this field instead of using an SSL plugin. Anything added to to this Swift Performance field will be placed at the top of your htaccess file.
Don’t worry if all the above makes no sense to you, just remember that you should use this field for HTTPS redirects should the situation ever arise.
Background Requests (Optional field)
Available in pro only, this field allows you to tell certain AJAX requests to run in the background. If you do decide to go for the pro version you should add /?action=post_view_count to this field.
Heartbeat
Before we get into the hearbeat settings let’s first talk about what heartbeat actually is. Heartbeat was first introduced to WordPress in the 3.6. release. As the name suggests, the heartbeat API allows WordPress to send a periodic pulse to your server.
This pulse communicates some important information and completes WordPress tasks such as autosaves, updating sales data for ecommerce plugins and locking posts when another author is in there editing.
While this functionality is useful, these requests can cause high CPU usage on your server. This is bad for performance because you need that CPU power for loads of other important functions on your site.
For this reason, it can be a good idea to limit the frequency of the pulse or disable it completely. Now that you know a little more about the Hearbeat API, let’s take a look at the settings.
Disable Heartbeat
Ticking any of the boxes in this section will disable heartbeat for that part of your website. It’s fine to turn off settings for all parts of your website apart from posts/pages. You’ll want heartbeat running on these.
Heartbeat Frequency
This setting allows you to reduce the pulse frequency of the hearbeat API. I recommend setting it to 140. This will limit CPU usage while still performing regular autosaves.
But the bottom line is, Heartbeat will mostly impact users on poor hosting with limited resources. If you host your website with a speed-focused provider like SiteGround or Cloudways, hearbeat will not be an issue. All Load Labz sites are hosted SiteGround or Cloudways and heartbeat has never been an issue.
Cronjobs
Cron jobs are commands or scripts scheduled to run at specific times. WordPress uses cron jobs via WP-Cron for some of its core features such as checking for updates and publishing scheduled posts. Plugins with scheduled tasks will also use cron jobs. For example, backup plugins working on a schedule will use WP-Cron.
Depending on the amount of traffic to your website, WP-Cron can impact your website’s performance. This is because WP-Cron does not run all the time, instead wp-cron.php fires on every page load. So, if your website receives a lot of traffic, running cron jobs on every page load can slow your site down.
Limit WP Cron (Set to 80)
Available to Pro users only, this setting allows you to limit cron jobs. 100 is unlimited and 0 means no cron jobs will run on your site. 80 is fine for most sites.
Enable Remote Cron (OFF)
Available to Pro users only, you will only use this setting if you:
- Turned off WP-Cron by setting the previous field to 0
- Are on a hosting package that disabled WP-Cron
- Have all site pages cached
You will be given the option to run cronjobs daily, twice daily or hourly. If the above conditions apply to you, then you should set it to run twice daily just be safe.
Google Analytics
***Important*** this feature will not work if you are using Google Tag Manager to run Google Analytics on your website. It will only work with the tracking code provided by Google Analytics. I use Google Tag Manager for all scripts so have never used this setting.
Bypass Google Analytics (ON)
This feature removes one request from your website – as you might have guessed, it removes a request to Google Analytics. Every website request adds to your load time so any setting that can reduce requests is always welcome.
For those who like to use Pingdom or GTmetrix to test their page speed, this setting will fix the “leverage browser caching” warning.
Turning this setting on will reveal the following fields:
Tracking ID (Add Your Own Tracking Code)
This is where you add your Google Analytics tracking ID. For example, UA-123456789-12. If you’re not sure where to find your tracking ID go to your Google Analytics account > “Admin” > in the middle column select “Tracking Information” > “Tracking Code”.
IP Source (Automatically Set)
Swift Performance will automatically detect the correct IP settings so you don’t need to change anything here.
Anonymize IP (ON)
If you take the privacy of your visitors seriously then you want to turn this on. It’s also important to anonymize IPs if you want a GDPR friendly website. GDPR stands for General Data Protection Regulation and is relevant to any website open to European visitors.
Delay Collect (OFF)
Enabling this setting will improve your load time slightly but will also mess up your Google Analytics bounce rate figures. I like to keep all my Google Analytics data nice and clean so I’m happy to take the slight hit in performance.
Exclude Users from Statistics (ON)
Available to pro users only, this option will filter out website visits from you and other admins. If your website receives a low amount of traffic this option can be very useful. Most website owners aren’t that interested in recording their own visits in Google Analytics.
Whitelabel (OFF)
This pro setting is for page speed professionals who want to hide the fact that they used Swift Performance to tune up a client website. If I so wished, I could change the plugin name to Load Labz so my clients see the Load Labz brand in their plugin menu. Nice idea, but not for me.
Media
This section is for pro users only and dedicated to optimizing your images. I recommend using Imagify to optimize images because it came out top of a recent head-to-head article we did. Imagify is the most powerful image optimization available by a long shot.
If you’d prefer to use a single plugin for all your page speed optimization, including image optimization, then you’ll need to sign up for Swift Performance Pro. For those of you who signed up, let’s take a look at the best settings.
Images
Optimize Images on Upload (ON)
This setting tells Swift Performance to optimize images as soon as they’re uploaded. This is a really useful setting because it means you won’t have to think about optimizing new uploads. It all gets done in the background leaving you free to work on content.
Resize Large Images (ON)
With this setting on you can set the maximum image width in pixels. If you have other people working on content who upload huge images, then this setting will let you set a max image size. The container size of your largest homepage image is usually the max size required.
Keep Original Images (ON)
If you turn this setting off Swift Performance will delete your original images and replace them with the optimized images. If you don’t like the quality of the optimized images you can’t roll back to the originals. For this reason, it’s always good to have the originals waiting as backups.
Serve WebP (ON)
WebP is a new incredibly light image format. Turning this setting on will tell Swift Performance to create a WebP copy of each image on your website. WebP images will be served up wherever possible.
I say wherever possible because not all browsers support this new file type. If a user accesses your website using a webp friendly browser they will be served a webp. If they use a browser that doesn’t support webp then Swift Performance will make sure the original file type is used.
Inline Small Images (ON)
If small images appear on-screen when your homepage first loads, then you might want to inline them. Your brand logo in the header area or any social icons used in your header might be good candidates.
When you turn this setting on, you turn your small images into a string of characters and numbers, basically code, and add them directly to your HTML.
Varvy has a great article on base64 encoding if you want to read up on it. Encoding images in this way can impact your SEO i.e. Google’s ability to index the images. The Varvy article covers this aspect also.
Why would you want to do this? Well, every image on your site must be requested and then loaded to your webpage. Every request will cost valuable load time.
When you add an image directly to your HTML you can speed things up by reducing requests. But, you also clog up your HTML with a lot of extra data so it’s only really useful for small images. Inlining large images would make your HTML too heavy so it’s best to leave the big ones as they are.
File Size Limit <bytes> (Unique to Your Site)
If you turned on the previous setting you will need to specify a limit to prevent larger images getting inlined too. As I mentioned, inlining larger images will clog up your HTML.
To find the limit to set here you want to check the file size of the images you want to inline. Let’s say you want to inline your website logo. You would go to your WordPress media menu and find the logo. Click on it and read the filesize from the menu.
Our logo is 4KB. I want to covert this into bytes ny asking Google “What is 4KB in bytes”. 4KB is 4000 bytes so I set my limit to 4500. I always add a few hundred extra bytes to give a little wiggle room.
Lazyload (ON)
When lazy loading is turned on, Swift Performance tells any images sitting offscreen to only load when my visitors scroll down to it. This is really useful if your pages have a lot of large images. I have seen this setting really improve the initial load time of a web page.
Critics of this setting will say lazy loading causes a web page to appear a little janky if someone scrolls quickly down the page on a slow network.
You’ve probably experienced it; you land on a webpage and scroll down, then the page jumps as an image appears. Then you scroll down again and the page jumps again as more images load.
That’s the worst-case scenario, why not turn the setting on and test out your pages to see how they feel?
Exclude Images (Up to you)
If you turned on lazyload then you might want to exclude some images. Any images that appear as part of your general design should be excluded.
You will also want to exclude any images that don’t play nice with the lazyload setting. If you test your website after turning on lazyload and notice missing images then you should exclude them here. This can happen on some rare occasions so excluding the image filenames should fix the issue.
Inline Lazy Load Images (OFF)
Enabling this option will reduce the amount of the requests made by your page. However, it can also make your HTML slower to load. There is a fine balance between the two so I usually turn this setting off. Feel free to try it out for yourself and test the results.
Embeds
YouTube Smart Embed (ON)
Available in Pro only, this setting lets you load a thumbnail placeholder instead of the full YouTube embed. I really like this setting, especially if on websites with multiple videos. Test any pages with an embedded video, enable this setting and test again. You should see a notable difference.
Lazy Load iFrames (ON)
This is the perfect setting if you have any videos sitting below-the-fold, below-fold-fold refers to anything sitting off screen. Activating this setting will only load your embedded videos when a visitor scrolls down to them. This is a good idea in almost all cases. Like anything, test your pages with the setting off and then again with it on.
iFrames are used for embedded YouTube and Vimeo videos, as well as things like Google Maps.
Exclude iFrames
If you have issues with some videos not loading correctly after enabling the previous setting, then you should add them to this field. You should also use this field to exclude all above-the-fold iframes.
Load iFrames on User Interaction (ON)
This setting adds an extra layer on top of the “Lazy Load iFrames” setting. The previous setting will tell iframes to only load when they appear on screen. This setting tells the iframe to load as soon as the user interacts with the page by clicking, tapping or scrolling.
I like this setting because the iframes do not load immediately but will be ready for an engaged user as soon as they get to them. It gives the iframe a head start compared to the previous setting.
Optimization
Correctly applying the following settings will have a huge impact on your page speed. It will solve Google PageSpeed Insight warnings like “Remove Render Blocking Resources”, “Minify JavaScript” and “Minify CSS” to name just a few.
***Warning*** Be careful with these settings because they may cause issues on your site. Professionals always apply settings on a staging site first and then test all pages to make sure everything still works correctly.
General
Enable Server Push (ON)
This is a pro feature that speeds up your site through the HTTP/2 protocol. Enabling server push tells your server to send all resources related to your webpage before the browser requests them.
So what does this mean and how does it work? Well put simply, every webpage is comprised of different resources. An example would be the .css files used for style. Without server push enabled a webpage’s HTML file is parsed and only when the .css file is found is it requested.
With this setting enabled, the .css file will be requested immediately and well before the browser has to do any parsing. This saves valuable load time and makes for a much more efficient user experience.
Optimize Prebuild Only (OFF)
This setting is not needed for most sites. It is best used on sites that take a very long time to load on first visit.
If you decide to use this setting, make sure to use it along with the “Prebuild Cache Automatically” option found in Settings > Caching > Warmup. This setting will improve load times when a user visits your site before any cache is built.
Optimize in Background (OFF)
Again, this option is not needed for most websites. However, if you are on shared hosting and/or have a very big website with lots of pages, then you might want to try out this setting. When using this setting you will want to disable the “Prebuild Cache Automatically” option found in Settings > Caching > Warmup.
Fix Invalid HTML (OFF)
This setting is used to fix up your HTML. Some themes and plugins still operate with bad HTML in place.
While this option might be useful in certain situations, it can cause issues with Yoast. I love Yoast and only use quality plugins so don’t have any need for this setting.
Minify HTML (ON)
When you minify HTML you remove white spaces, line breaks and unnecessary characters. By default, all this extra formatting is there to help humans understand the structure of a HTML document.
Computers do not need this type of structure so we can safely remove it. Doing so makes our HTML document lighter and quicker to load. What’s not to love?
Disable Emojis (ON)
Very few businesses use emojis in their content. Despite this, emoji support was added to WordPress core back in version 4.2 adding an additional request.
Because requests contribute to your overall load time many performance optimizers like to disable this feature – including me.
Limit Simultaneous Threads (OFF)
If your WordPress site is on a shared hosting package like GoDaddy, BlueHost, HostGator or any other cheap crappy hosting, then this setting can help limit CPU usage and prevent 508 errors on your site.
If you’re serious about page speed optimization then one of the first steps is moving your website to a good hosting provider. Have a look at our article created to help you choose the best host for your business size.
For those of you who are on very cheap and restrictive shared hosting, this option is best set to 1 or 2.
DOM Parser Max Buffer (Leave as it is)
Swift Performance will skip pages larger than the limit set here. Leave this as it is unless you are instructed to change it by a member of the Swift Performance support staff.
Scripts
This section is all about reducing and optimizing JavaScript on your WordPress site. Applying the correct settings often results in significantly faster load times.
***Warning*** Be careful with these settings because they may cause issues on your site. Professionals always apply settings on a staging site first and then test all pages to make sure everything still works correctly.
Merge Scripts (ON)
This setting will merge JavaScript files so a browser will call fewer files when building your web pages.
Doing so will have a positive impact on your load time because it reduces the amount of requests made by your webpage. Reducing page requests is always a good thing when it comes to page speed optimization.
Some people believe merging scripts is not required on sites using HTTP/2, which most WordPress sites do. However, I consistently get positive results by merging JavaScript files.
Async Execute (ON)
This setting tells all JavaScript to load asynchronously. While this sounds complicated it’s not really. It’s basically an instruction telling the browser to download JavaScript while building other parts of the page (asynchronously) and then to execute those scripts whenever the opportunity arises.
By default, a browser will stop all tasks associated with building your webpage to download the JavaScript and execute it. This is where we get the term render-blocking JavaScript. With async activated, your JavaScript will not be render-blocking.
Exclude 3rd Party Scripts (ON)
Sometimes async’ing third-party scripts can cause issues. I generally leave this setting on to save potential headaches.
Exclude Scripts (Add Those Listed Below)
Sometimes “async execute” can cause problems, as already mentioned. If you notice any issues you might want to exclude the offending scripts using this field.
There are some scripts known to cause problems, so you might want to add them here by default. Here are some of the worst offenders:
wp-includes/js/dist/, wp-includes/js/tinymce/, js/jquery/jquery.js, local-ga.js
Exclude Inline Scripts (Unique to Your Site)
This is another feature designed to help users fix any bugs caused by the “Merge Scripts” setting. Inline scripts are JavaScripts that sit directly in your HTML code rather than in a separate file.
It can be difficult for beginners to figure out what scripts are causing issues so you might want to contact Swift Performance Support for help.
Exclude Script Localizations (ON)
It’s best to leave this setting on as there is no real benefit to turning it off. Turning this off runs the risk of having separate JavaScript files for each of your web pages.
Minify JavaScript (ON)
JavaScript developers use a lot of unnecessary spaces, comments, and other characters to make their work easier to read when revisited. However, computers don’t need any of that to make sense of the code. Minification strips out all that stuff and makes the code lighter and the file sizes smaller. As you might have guessed, this means faster load times!
Minify with API (OFF)
On rare occasions, the above minification method can cause issues. If this happens you will want to try this feature to get your minification work done. Just be aware it’s available to pro users only.
Proxy 3rd Party Assets (OFF)
This setting can help with the “Leverage Browser Caching” error found in GTmetrix and the “Add Expires Headers” warning found in Pingdom Tools. However, it can also break scripts so leave this setting alone unless you know what you’re doing. It’s not going to make much of difference to your actual page speed anyway.
Separate Scripts (OFF)
This setting can be useful for sites using dynamic JavaScript. Dynamic JS can cause your cache to grow too big. Anyone using a clean fast theme and the lightest plugins should not have an issue.
Enabling this setting will create a separate merged JavaScript file for each and every page on your website. While this can be useful for websites with many different page types i.e. subscriptions, courses, forums and so on, it can also cause issues. It is best to leave this advanced setting alone unless you know what you’re doing.
Print Merged Scripts Inline (OFF)
This option can be useful in certain cases but for most users it’s best to leave it turned off. If you’re a moderately advanced user, feel free to test it out in a staging environment to see if it improves performance without causing any problems.
Lazy Load Scripts (Unique to Your Site)
This clever feature allows you to load below-the-fold JavaScript only when a user scrolls down to it. However, identifying what script to add here is not very easy for beginners so if you’re not sure just leave it alone.
If you’re feeling confident in your abilities, try adding third-party advertisement scripts like Adsense. Do not add your Google Tag Manager or Google Analytics scripts because doing so will cause issues.
Include Scripts (Unique to Your Site)
Sometimes JavaScript can contain references to other JavaScript. Rather than waiting for the browser to find it you can highlight it here for preloading. Leave this alone unless you know what you’re doing.
Styles
This section is all about reducing and optimizing the CSS on your WordPress site. CSS is what makes websites look the way they do. CSS controls the style of a webpage; its layout, color palette, and design. It also controls responsiveness across devices.
Applying the correct settings in this section of Swift Performance will result in significantly faster load times.
***Warning*** Be careful with these settings because they may cause issues on your site. Professionals always apply settings on a staging site first and then test all pages to make sure everything still works correctly.
Merge Styles (ON)
This setting merges your website’s different CSS files. This reduces the number of requests required to build a webpage to just one. Fewer requests almost always mean faster load times.
By default, all CSS files render-blocking. So, if five CSS files are required to build a webpage, the render process will be blocked five times. Combining them into one will help solve render-blocking issues often flagged by Google PageSpeed Insight’s as “Eliminate render-blocking resources”.
This setting is very powerful but can sometimes cause issues. If enabling this setting has a negative impact on the layout or styling of your web pages, then you will need to exclude those styles using the “exclude styles” field found lower down the settings page.
Generate Critical CSS (ON)
Critical CSS is all the styling used above-the-fold on your web pages. Above-the-fold refers to the top section of your webpage seen by users when they first land on your page.
Because this is the first thing users see, all styles used here are called critical and should be loaded before all other styles used lower down the page i.e. below-the-fold.
This setting attempts to identify critical CSS and extract it from the rest of your CSS. Swift Performance will tell the browser to load the critical CSS first resulting in a much faster load time for your users.
Extra Critical CSS (Unique to Your Site)
If you’re very familiar with the CSS used on your site and think some additional items need to be included in the critical CSS generated by Swift Performance, then you will want to add it here. This is really for advanced users.
Disable Full CSS (OFF)
While this setting can benefit simple sites using nice light themes, it can have a negative impact on other more complex websites.
If you know your way around DevTools and are confident testing your website, then try this setting out. For everyone else, I think it’s best to leave this setting off.
Compress Critical CSS (ON)
This a smart little setting that can save you some extra bytes, especially for those using heavy plugins or themes.
Remove Keyframes (ON)
Enabling this setting will remove CSS animations from your critical CSS generated earlier via the “Generate Critical CSS” option.
So long as you don’t have any above-the-fold CSS animations this setting is fine to use. Examples of above-the-fold CSS includes slideshows and animations that immediately appear on-screen when a user visits one of your web pages.
As always, make sure you test your website after implementing a change, and optimize on a staging site if possible.
Print Critical CSS Inline (ON)
This setting is on by default. Adding your critical CSS directly to your HTML file, otherwise known as inlining critical CSS, is best practice so you can leave this on.
Separate Styles (ON)
If you have a number of different page types i.e. product pages, listing pages, blog pages, forum pages, FAQs, courses, classes and so on, then this setting might benefit you. It’s best to test it and see if it improves things.
Not all page types use the same CSS because they will all have slightly different styling applied. Creating a separate CSS file for each page can help resolve the “Remove Unused CSS” warning displayed in Google’s PageSpeed Insights.
Minify CSS (ON, Basic)
When you minify CSS you remove all the preformatting used to make the CSS easy to understand for humans. Computers don’t need the additional spacing, indentations, and notes to make sense of the code. Minification cuts all that out making the CSS lighter and quicker to load.
Bypass CSS Import (ON)
This setting will add imported CSS files to the merged CSS file you created earlier. If that sounds complicated don’t worry, it’s a good thing and this setting is best left on because it can reduce the number of requests made.
And if you’ve been following this guide closely, you’ll know reducing the total request count for a webpage is a good thing for page speed.
Exclude 3rd Party CSS (OFF)
This setting is best left off for most websites. If you’re having issues with your styles you might want to try this switch to see if it fixes the problem. It will exclude third-party CSS from the merged CSS file you created via the “Merge Styles” option.
Third-party CSS can come from places like Google Fonts. Be careful using third-party CSS as there was a keylogger found to be created in CSS in 2018. Check out this article for more info. Obviously sources like Google are safe.
Exclude Styles (Unique to Your Website)
Use this field to add any styles that break after you apply the “merge styles” setting. You can use Google Chrome or Firefox DevTools to find the offending CSS files. I will write an article in the future showing you how to do this. I’ll share it on Twitter and Facebook so follow me to get it first.
Exclude Inline Styles (Unique to Your Website)
When you enable the “Merge Styles” option, Swift Performance will also add inline styles to the single merged CSS file. If this causes any issues you can add some of the inline style string here to exclude it. Themes built with speed in mind will not use inline styles.
Include Styles (Unique to Your Website)
This is a useful feature if your website uses JavaScript to load certain CSS. By adding this type of CSS here you are telling the browser about it ahead of time which helps with page speed.
Force Font Swap Display (ON)
This feature alone will make you want to go for the pro version of Swift Performance. When you enable this you stop third-party fonts such as Google Fonts render-blocking your webpage. This is an extremely powerful setting that all websites should implement.
If you’re after a free plugin that can get this done for then use Autoptimize, just be careful not to have any duplicate settings in place or you will encounter problems and conflicts.
Caching
General
Enable Caching (ON)
As you might have guessed, this setting enables caching. Swift Performance uses an extremely powerful caching system so make sure to leave this setting on.
Caching Mode (Disk Cache with Rewrites)
Of the three options, “disk cache with rewrites” offers the fastest way to serve a cache. If you used the autoconfig setup option outlined at the start of this guide, Swift Performance will detect the best option for your website automatically.
If your server does not support rewrites then choose “Memcached with PHP”. If your hosting setup does not use Memcached then choose “Disk Cache with PHP”.
It’s always a good idea to contact your hosting support if you aren’t sure. A good host will be more than happy to help you set this up correctly.
Early Loader (ON)
This option speeds up any cached items served with PHP. Even if you choose “Disk Cache with Rewrites” from the previous options, some items might still use PHP. For that reason, it’s always good to leave this setting on.
Cache Path (Tells You Where To Find Your Cache)
This option shows you the file path to your cache. If required, you can access it directly from your hosting account or via FTP.
Cache Expiry Mode (Action Based Mode)
Action based mode is the best option for almost all websites because it will clear the cache after you make a change. For example, the cache will refresh after you update a post, publish a new post, receive a new comment, or approve a new comment.
This action based method has obvious advantages over a time based method. Using a time based method could result in missing cache items and a bad user experience.
Some contact form plugins require you to use the time based method. One example is Gravity Forms. If the action based method is causing issues with your forms then you might want to try the time based method.
Clear Cache on Update Post by Page (Unique to Your Website)
Some web pages, like those using shortcode, will not be cached correctly. Add them in here to make sure they are. For example, if you are using WooCommerce shortcode to pull products into a certain page, then you will want to click the empty field and select the page using the shortcode. Continue adding all pages using shortcode in this way.
Clear Cache on Update Post by URL (Unique to Your Site)
This option is exactly the same as above except it gives you the option to manually add a page. This is useful if you can’t find the page from the dropdown list offered in the previous setting.
Cache Expiry Time (10 Hours)
You will only see this option if you choose “Time-Based Method” in the previous setting. It’s best to set this to 10 hours.
Garbage Collection Interval (30 Mins)
Again, you will only see this option if you chose the “Time Based Method” for your Cache Expiry Mode. This setting determines how often Swift Performance will check for cached pages that have expired.
Enable Caching for Logged In Users (OFF)
This setting is only useful for websites that require users to sign in to view content. For example, membership sites and sites offering courses would be good candidates.
Separate Mobile Device Cache (OFF)
If you have a separate site for mobile, you might want to try this setting out. Examples include websites built on AMP or those using a separate theme/plugin to serve a mobile version of their website.
Most modern websites are responsive. If your website adapts and changes to different devices then you won’t need to enable this setting.
Enable Browser Cache (ON)
This is a great little setting that sets rules in your .htaccess file telling your visitor’s browser to temporarily store important parts of your webpage. This improves the load time of your webpage for returning visitors so is best left on.
Enable GZIP (ON)
You want to enable GZIP but make sure it is not already enabled on your website via your host or another plugin. You don’t want to enable this setting twice. To test if your website already has GZIP or Brotli enabled use this tool. If your website is not using GZIP or Brotli, you can turn this setting on.
Cache 404 Pages (OFF)
You should only enable this feature if you have 404 pages that are regularly visited. Otherwise, this setting can cause performance issues. I’ve never had the need to use this setting.
Enable Dynamic Caching (OFF)
This is an advanced feature best left to developers and professional page speed optimizers. Even when done right the impact on your load time is often quite small.
Cachable AJAX Actions (Leave Empty)
Similar to the above setting, this setting should only be used by developers and experienced optimizers. For the developers out there, AJAX search might be a good candidate for this field.
AJAX Cache Expiry Time (Leave As Is)
This figure is the cache expiry time for AJAX in seconds. The current setting is fine for almost all users.
Tweaks
Avoid Mixed Content (OFF)
Available to pro users only, this setting helps you solve the “Mixed Content” warning which can arise after adding an SSL cert to your website. In some cases, not all content moves over to the new HTTPS protocol and a site with HTTP and HTTPS content is seen as unsecure by browsers.
This setting ensures all content correctly switches to HTTPS removing the warning from browsers. The unsecure warning seen in browsers is off putting to your visitors so it’s best to get it fixed.
Keep Original Headers (ON)
This is a useful feature for those of you using a security plugin or any other plugin that sends custom headers. If you’re not sure just enable this setting. Only pro users can access this setting.
Exceptions
This section offers many different ways to prevent pages, posts, URLs and so on from being cached. You need a little bit of advanced knowledge to use this section correctly. You basically want to exclude all pages and posts that are not front facing.
If you think all of your URLs are front facing, you might be surprised to see how many backend URLs show up when you crawl your site using a tool like Screaming Frog.
If you don’t exclude any pages, posts or URLs Swift Performance will try to cache everything. This isn’t a the best use of Swift’s resources and delay cache prebuild.
Other candidates are cart and checkout pages but Swift Performance does this automatically for most ecommerce plugins.
Exclude Post Types (Done Automatically If Using AutoConfig)
Here you can select which post types should not be cached. If you used the AutoConfig setup outlined at the start of this guide, Swift Performance will scan your website and exclude the most appropriate posts automatically.
Exclude Pages (Unique to Your Website)
Here you can choose pages to exclude. As I mentioned in the intro to this section, Swift Performance will automatically exclude cart and checkout pages. You might also want to exclude other ecommerce pages that might have unique content. Examples include, wishlists, private pages and pages with forms.
Exclude URLs (Add the Items Listed Below)
You can add a string here and Swift will exclude it from the cache. This is where you can add any backend pages found by Screaming Frog or a similar crawler. Use leading/trailing # for REGEX to exclude multiple URLs at once.
Some useful items to test here are:
sitemap
#/image\.+#
#autosave#
#json#
#/tag/(.*)/#
.xml
/amp/
Make sure to add one per line exactly as you see it above. And add them one at a time testing in between each item to make sure there are no issues on your website.
Exclude Cookies (OFF)
This is a useful setting if you want to exclude users with certain cookies from seeing cached pages. Most pages are fine without using this setting. Also, it’s available to pro users only.
Exclude Content Parts (Unique to Your Website)
Use this field to exclude all pages that feature specific content. It might be useful to exclude contact forms or email sign-up forms. This field is another good way to exclude multiple pages at once.
Exclude User Agents (Unique to Your Website)
An advanced feature that is useful if you want to prevent certain devices or browsers from seeing a cached version of your site. If you’re using this setting because your site looks wrong on mobile you might want to try the “Seperate Mobile Device Cache” found in the general settings.
Here’s a little further reading on user agents straight from Google, if you’re interested.
Exclude Crawlers (OFF)
While this can be useful in some cases, it’s best to let crawlers like Google see the cached version of your website. Page speed is a ranking factor and the cached version of your site is faster than the non-cached version. So, it makes sense to let Google crawl your super fast site.
Exclude Author Pages (ON)
Leave this on because author pages are low-priority and it is better to let Swift Performance focus on higher priority items.
Exclude Archive (OFF)
Archives are used for blog posts and are visited regularly on some websites. Caching can result in slightly outdated content in the archive page but Swift does rebuild the cache regularly so it should be fine for most websites.
Exclude REST URLs (ON)
This setting will exclude things like wp-json calls from the cache. There is no need to cache these so it’s best to exclude them. Like I mentioned before, you want to save your caching power for high priority items.
Exclude Feed (ON)
Just like above, it’s best to exclude the feed and save your caching power for high-priority items.
Warmup
Enable Remote Build Cache (OFF)
Available in pro only, this setting takes all the cache building off your own server and let’s the Swift Performance server do it instead. There’s no need to enable this for the majority of sites. The only time you would enable it is if Swift Performance is having trouble triggering the cache prebuild.
Prebuild Cache Automatically (ON)
Best to turn this setting on because it means people who visit your site directly after you clear the cache won’t have to wait for the cache to prebuild.
You will want to turn this setting off if you have 800+ pages and a budget shared hosting package like that provided by Bluehost, GoDaddy, HostGator and so on. If you’re thinking about improving your hosting you might find this article on WordPress hosting interesting.
Prebuild Speed (Moderate)
Set the level to “Moderate” in the field below.
Prebuild Author Pages (OFF)
In general, these pages are not visited very often so there is no need to prebuild them. The first person to visit the page will trigger the cache build. This first visitor will have to wait a little longer because they will be viewing the uncached page but every subsequent visitor will see the cached version.
Prebuild Archive (ON)
As mentioned in the “Exceptions” section, these pages can be visited often on sites with busy blogs. If your site has a busy blog, then you will want to enable this setting. Otherwise, you can safely turn it off.
Prebuild REST URLs (OFF)
If you have been following the settings throughout this guide you will remember we excluded REST URLs from the cache. As a result, there is no need to prebuild.
Prebuild Feed (OFF)
Turned off for the same reasons as above.
Varnish
Enable Auto Purge (OFF)
If you are using Varnish cache then you will want to enable this setting, otherwise it’s best to turn it off. To find out f your site is running Varnish, use this free tool.
Custom Host
Add the Varnish IP and port here if you have a DNS proxy like Cloudflare enabled.
CDN
General
Enable CDN (OFF)
Turn this setting on if you already use a content delivery network (CDN) such as KeyCDN or StackPath. Always leave out the http or https prefix when adding the URL.
CDN Hostname (Unique to Your Website)
Enter the CDN hostname in here. You will be able to find this information from your CDN. It usually looks something like this cdn.yourwebsite.com.
Enable CDN on SSL (ON)
If your website has https in its URL then enable this setting.
CDN Custom File Types (ON)
Available to pro users only, this setting uses your CDN for custom file types such as .PDFs. If you use .PDFs throughout your website, this is a useful feature to have.
Cloudflare
This section is for those of you already using Cloudflare. Use this section to set up Swift Performance Lite with your Cloudflare account.
Enable Auto Purge (ON)
When ON, this setting will clear the Cloudflare cache when the Swift Performance cache is cleared. You want to clear every cache at the same time to avoid conflicts or confusion when testing your website so turn this on.
Cloudflare Account Email (Enter Email)
Enter your Cloudflare account email here to connect it to Swift Performance. This is all part of the setup process.
Cloudflare API Key
Again, all part of the setup process. Sign into your Cloudflare account to find this. Here is a useful article from Cloudflare if you have any trouble locating it.
Cloudflare Host
Enter your domain name here. For example, I would add www.loadlabz.com (don’t add the http/https)
Export/Import
Export
Export Settings
Use this button to download your current settings for future use. Might not be a bad idea to store these settings on Google Drive or something similar just in case you ever need to revert back to them. You’ve put in a lot of work following this guide so best to keep your settings safe!
Import
Import Settings
Use this field to drag and drop your previously saved backup. Importing settings will overwrite the current settings.
Conclusion
I hope you got some value from this epic guide to the best Swift Performance Lite settings. A future article will look at the additional settings that only become visible in the pro version.
I am also working on a guide to the Swift Performance “Database Optimizer” tab. Follow me on Twitter or Facebook to hear about it first.
Thanks for visiting and taking the time to read this article.