The Ideal Swift Performance Lite Settings (2022) With Cloudflare + CDN Instructions

Swift performance settings

Some people swear by Swift Performance, others stay away because of scam reports.

I wrote this tutorial on configuring the Swift Performance Lite settings since I try to do this for every cache plugin, but I chose not to use it myself. Too many negative reviews and I’m sure WP Johnny gets excellent results with it, I would just rather support Gijo Varghese from FlyingPress.

They have a good amount of documentation and let Swift Performance Lite users unlock many Pro features for free. You can do this by registering for Swift in the Dashboard settings, adding your license key, and downloading the Swift Performance Extra plugin. I would definitely watch Johnny’s Swift YouTube video since many of these settings are based on his recommendations.

These settings should only be used as a starting point. Make sure you avoid duplicate functionality if you use Cloudflare for things like image optimization and minification, Perfmatters for asset unloading or anything else, or WP-Optimize for database cleanups.

 

1. Wizard

Once you install Swift Performance, it opens a setup wizard. Run the Autoconfig option and Swift will configure a few settings based on your server configuration, plugins, settings, etc.

Swift performance setup wizard

Enable auto purge if using Cloudflare, create an API token, and enter it here.

Swift performance cloudflare token

Swift Performance will tweak a few settings based on your configuration.

Swift performance autoconfig

 

2. Dashboard

The dashboard shows stats like how many known pages Swift detected vs. how many are actually cached. The Warmup table shows your cached pages, their prebuilt priority, and the date each page was last cached. You can manually add URLs if Swift didn’t detect certain pages.

Swift performance dashboard

Register with Swift, add your license key, and you’ll get more features on the Lite version.

Swift performance pro features

Once your key is added, you’re prompted to install the Swift Performance Extra plugin.

Swift performance extra

 

3. Settings

The advanced view expands the Swift Performance settings with more things to configure.

Swift performance advanced view

 

3.1. General

General

  • Hide Footprints: ON – leave off if you want to see Swift in the source code.
  • Use Compute API: ON – speeds up CPU intensive processes, provides viewport critical CSS, and better JS minify. You will need to register with Swift (or use Swift Pro) to see this.
  • Clear Cache Role: select which users are allowed to clear Swift’s cache.
  • Disable Admin Notices: pro feature to disable Swift admin notifications.
  • Disable Toolbar: OFF – lets you remove Swift from the WP toolbar menu.
  • Page Specific Rules: ON – adds a metabox to change settings on specific pages.
  • Collect Anonymized DataOFF – I always prefer this off, but it’s up to you.
  • Debug Log: used for debugging if you’re running into issues while configuring it.

Tweaks

  • Custom Htaccess: mainly used to add redirects.
  • Background Requests: add rules to make AJAX requests run in the background so the browser doesn’t have to wait for a response (see documentation which has an example).

Heartbeat

  • Disable Heartbeat: you can usually disable Heartbeat everywhere except for posts/pages since you probably want autosaves and Heartbeat features when you’re in the post editor.
  • Heartbeat Frequency: 240 is a good number and uses less resources than 15-60 seconds.

Cronjobs

  • Limit WP Cron: limiting WP-Cron saves resources. You can set it to something like 50 which is used in the documentation. 100% means unlimited while 0% means disabled.
  • Enable Remote CronOFF – unless you want to disable WP-Cron and use Swift’s API to set up a remote cron service, you can leave it off. Fully disabling WP-Cron isn’t recommended.

Google Analytics

 

3.2. Media

General

  • Smart Lazyload: ON – if you use Swift for lazy loading images, turning this on excludes above the fold images/iframes from lazy load which can improve LCP in core web vitals.

Images

  • Optimize Images On Upload: ON – Swift will optimize images when you upload them. If you’re using another plugin or CDN to optimize images, leave those settings OFF in Swift.
  • Image Source: MEDIA LIBRARY – Swift will store data about your images in the media library which is defaulted if using WPML, or you can set it to the WP-CONTENT directory.
  • Image Optimizer: I do lossless compression at 85% since Lighthouse tests images at 85%.
  • Resize Large Images: 1920 – prevents people from uploading huge images over 1920px.
  • Keep Original Images: ON – should always be on in case you want to revert your images.
  • Generate WebP: ON – turn this on if you want Swift to generate WebP versions on images.
  • Serve WebP: <PICTURE> ELEMENTS – replaces <img> tag with <picture> tag which is recommended in the documentation and is also more compatible when using Cloudflare.
  • Serve WebP Background Images: ON – background images will also be served in WebP.
  • Exclude Images: if you don’t want certain images served as WebP, add the images here.
  • Lazyload Images: ON – remember to only use 1 plugin/service for lazy loading. Swift has quite a few settings and you may want to test it out, but this is obviously your own choice.
  • Exclude Images URL/Classname: the Smart Lazyload setting already excludes above the fold images automatically, so there shouldn’t be any reason to exclude images manually.
  • Respect Lazyload Standards: ON – images won’t be lazy loaded if they have the skip-lazy class or data-skip-lazy attribute. This should also be left on in all the other Swift settings.
  • Preload Sensitivity: 50 – number of pixels before the viewport lazy loaded images will start preloading. You can try increasing this if you want a smoother scrolling experience.
  • Load Images On User Interaction: ON – only load images on mousemove, keypress, touchstart, or scroll. Since images are already lazy loaded, it probably won’t help much.
  • Inline Lazy Load Images: ON – inline placeholders but it’s not supported by all browsers.
  • Lazyload Placeholder: placeholders can reduce layout shifts (choose the one you want).
  • Lazyload Background ImagesOFF – background images are large, so while there may be a big improvement for “defer offscreen images,” it may also take some time for them to load. If you enable it, make sure above the fold images are being excluded and preloaded.
  • Fix Missing Dimensions: ON – adds width/height attributes to images without specified dimensions to prevent layout shifts (fixes the “explicit width/height” PSI recommendation.
  • Force Responsive ImagesOFF – only on if your theme doesn’t load responsive images.
  • Gravatar Cache: ON – no reason not to use this. Although if your blog has lots of comments, you should look into local avatars or delaying them if they load externally.
  • Inline Small ImagesOFF – small sites can turn it on if you have small images/icons on the top of your pages and you’re not using FontAwesome (recommended by WP Johnny).

Embeds

  • Youtube Smart Embed: ON – only loads thumbnail until play button is clicked.
  • Lazy Load Iframes: ON – similar to previous settings only for other iframes too.
  • Load Iframes On User Interaction: ON – self-explanatory, I would turn this on.

 

3.3. Optimization

General

  • Enable Server Push: TEST – test your results with and without enabling this. Server push can give you better results by loading resources ahead of time but separates scripts/styles.
  • Optimize Prebuild Only: ON – Swift says this should be on or first-time visitors have to wait until Swift’s optimization process is complete, but Johnny recommends turning it off.
  • Optimize in Background: if the previous setting doesn’t work, this will be used as fallback and makes Swift start the optimization/caching in the background using an AJAX request.
  • Prebuild Booster: on for slow shared servers, off for more powerful servers.
  • Disable Emojis: ON – if you really need emojis, use Unicode emojis instead.
  • Limit Simultaneous ThreadsOFF – when the optimize prebuilt only setting is off, this reduces CPU usage when you have many simultaneous, but Johnny says it should be off.
  • Merge Assets for Logged in UsersOFF – faster for logged-in users but causes problems.
  • Prefetch DNS: ON – automatically adds the prefetch resources hint for third-party domains, just remember that CDN URLs and Google Fonts should use preconnect instead.
  • Collect Domains From Scripts: ON – scans JavaScript for third-party domains to prefetch.
  • Exclude DNS Prefetch: exclude fonts.gstatic.com and your CDN URL so they’re not prefetched, then make sure each of these use the preconnect resource hint instead.
  • Normalize Static Resources: removes “cache buster” from static file URLs which can prevent scripts/styles from being cached. This is only useful if you merge scripts/styles.

 

Scripts
Merging/minifying JavaScript is notorious for causing errors, but I would test these and check your load times. If you see errors, find the problematic files and add them to ‘Exclude Scripts.’

  • Merge ScriptsOFF – merging scripts/styles usually gives you worse results. But since turning it off also removes the option to minify scripts (and same thing with styles), you can use your CDN to minify HTML, CSS, and JS. Cloudflare and Bunny Optimizer do this.
  • Disable jQuery Migrate: TEST – turn on if this doesn’t break your site, leave off otherwise.
  • Preload Scripts: you can add JavaScript files containing elements that load above the fold so they’re preloaded, just make sure you test how each preload impacts its load time.
  • Preprocess Scripts: run plugin/theme scripts on the server by adding URLs or filenames.
  • Preprocess Inline Scripts: same concept as previous settings only for your inline scripts.

Styles
CSS optimization can also cause errors, but can greatly improve scores/load times. Play with the settings and check a few pages to make sure everything is OK. If merging stylesheets and minifying CSS cause errors, locate/exclude problematic files (same things with JavaScript).

  • Merge Styles: OFF – same reason you usually shouldn’t merge JavaScript files either.
  • Preload Styles: again, this is the same concept as preloading scripts only for your styles.

Fonts

  • Manually Preload Fonts: there are plenty of free plugins that preload fonts including Perfmatters, Pre* Party Resource Hints, or do it manually. There’s no reason to pay for this.

HTML

  • Smart Render: ON – new feature and looks similar to lazy rendering HTML elements.
  • Fix Invalid HTML: OFF – Johnny doesn’t recommend this since it delays cache building.
  • Minify HTML: if you’re not using a CDN to minify HTML, you can use Swift to do it instead.

 

3.4. Caching

General

  • Enable Caching: ON.
  • Caching Mode: DISK CACHE WITH REWRITES – this is what you should usually use especially on shared hosting, or use “memcached with PHP” if your host supports it.
  • Early Loader: ON – speeds up the caching process when it’s served through PHP.
  • Cache Path – this is just the directory for the cache path.
  • Cache Expiry Mode: ACTION BASED MODE is what Swift recommends. Time-based mode is the same but when the cache expires, it’s cleared even if no modifications were made.
  • Clear Cache on Update Post by Page, URL, Custom Rule: Swift already clears the cache in common areas, but if you need to clear specific things, you can do it using one of these.
  • Clear Cache After Update: ON – clears the cache after updating core/theme/plugins. Larger websites will probably want to disable this since it can often increase CPU usage.
  • Enable Caching For Logged In Users: OFF – only enable on membership websites (or similar) where you have lots of logged-in users where they need their own cached version.
  • Separate Mobile Device Cache: OFF – only use if you serve different content on mobile than desktop and the mobile site needs its own cache (non-responsive themes, AMP, etc).
  • Enable Browser Cache: ON – stores files in the browser so they can be accessed quicker.
  • Enable Gzip: ON – I would check if your host supports Brotli because it’s faster than Gzip.
  • Send 304 Header: OFF – speeds up repeated requests but should usually be left disabled.
  • Cache 404 pages: OFF – the benefit of this probably won’t outweigh how it increases CPU.
  • Cache Sitemap: Swift will use your sitemap URL to cache your website more efficiently.
  • Enable Dynamic Caching: OFF – leave this disabled unless you know what you’re doing.
  • Cacheable AJAX Actions: see Swift’s tutorial on caching AJAX requests if you want to enable this. You’re also able to set the AJAX Cache Expiry Time which is defaulted to 1440.

Tweaks

  • Ignore GET Params: add GET parameters to be excluded from caching.
  • Avoid Mixed Content: OFF – no need to do anything if your site uses HTTPS.
  • Keep Original Headers: ON – this keeps the original headers used by plugins.
  • Exclude Headers: add specific headers that shouldn’t be included in caching.
  • Case Insensitive URLs: OFF – URLs are usually not case sensitive, so disable.
  • Strict Host: ON – can prevent errors when using WWW vs. non-WWW versions.

Ajaxify

  • Preload Sensitivity: 50 – number of pixels before the viewport lazy loaded elements will start preloading. You can try increasing this if you want a smoother scrolling experience.
  • Ajaxify Placeholder: hidden means it’s empty until it’s loaded. You can also select “blurred” as well as “show cached” which will show the cached version until it’s loaded.

Exceptions
This is where you exclude certain parts of your website from being cached. You can do this by URL, post types, cookies, known crawlers, author pages, REST URLs, and even your RSS feed.

Warmup
Warmup stores URLs in for the next cache prebuild. Each URL has a priority number (shown in the dashboard settings) where they can be adjusted manually. Lower number = higher priority.

  • Prebuild Cache Automatically: ON – prebuilds cache after it’s cleared (only uncheck for large websites where constant cache rebuilding is consuming too many server resources).
  • Prebuild Speed: unlimited for powerful servers, moderate for mid-range servers, and reduced or slow for shared. The higher the prebuild speed, the more resources it needs.
  • Discover New Pages: OFF – only enable if Swift can’t detect all your important pages.
  • Warmup Table Source: AUTO OR SITEMAP – auto for small sites, sitemap for large sites or if your server is slow. As Johnny says, the sitemap option prioritizes important pages first.
  • URLs Per Page: 30 – this just shows how many URLs are shown in Swift’s warmup table.
  • Warmup Priority: DEFAULT – unless there’s a specific reason to change them, leave this.
  • Remove Redirects: ON – no reason redirects should be included in Swift’s warmup table.
  • Prebuild Pages – only enable the pages that are actually being used by your visitors (usually only archives for category pages). No need to prebuild things like tags/RSS feeds.
  • Enable Remote Prebuild Cache: OFF – only enable if the server can’t prebuild the cache.

Varnish

  • Enable Auto Purge – on if using Varnish which autopurges when Swift’s cache is cleared. After enabling this, enter your Varnish IP + port in the next field if you’re using Cloudflare.

 

3.5. CDN

General

  • Enable CDN: ON – only used for CDNs that use a CDN URL like BunnyCDN (not used for Cloudflare). Gijo from FlyingPress recommends the Cloudflare + BunnyCDN combination which is also what I use. I have a full BunnyCDN tutorial which shows you how to set it up.
  • CDN Hostname: this is where you enter your CDN URL (found in your CDN’s dashboard).

Cloudflare

  • The Swift Performance setup wizard should have already prompted you to add your Cloudflare API token (see Dashboard section). Otherwise, add it here and the settings should be configured automatically to purge Cloudflare’s cache once Swift’s is cleared.

MaxCDN/StackPath

  • StackPath isn’t a great CDN so you shouldn’t have to do anything here.

 

4. Image Optimizer

If you’re using Swift for image optimization, this shows you stats.

 

5. Database Optimizer

You can usually delete everything but post revisions. You probably want a few backups and Swift only gives you the option to delete all of them. I prefer to use WP-Optimize which lets you keep some post revisions, scheduled cleanups, and remove unused tables left by old plugins.

Wordpress database cleanup wp optimize settings
WP-Optimize is free and already does a great job in cleaning your database

 

6. Plugin Organizer

Only use the plugin organizer if you’re absolutely sure you know what you’re doing.

This can be used to disable elements on specific pages/posts where they’re not being used. I prefer Perfmatters but if you’re using Swift, the plugin organizer is free even on the Lite version.

Swift performance plugin organizer

 

7. Lite vs. Pro

With the free Swift Performance Extra plugin, most sites won’t need to use the Pro version. It already comes with most key features in the Pro version, but feel free to compare them yourself. The Pro version does include a database optimizer but this can easily be done in WP-Optimize.

Just be careful, there have been numerous reports of Swift’s bad billing practices. So if you decide to cancel, I would honestly call your bank to make sure they don’t keep charging you.

Swift performance pro pricing

Thanks for reading – drop me a comment if you have any questions!
Tom

You Might Also Like:

15 thoughts on “The Ideal Swift Performance Lite Settings (2022) With Cloudflare + CDN Instructions”

  1. Based on SWTE Group, Ltd’s / Swift Performance unethical billing practices, I recommend going with any alternative to Swift products. If you look at wordpress.org reviews, you’ll see many accounts of volatile and unstable products for Swift Performance plugins and unfortunately a very disappointing consumer experience. I canceled my subscription the day of my renewal and they charged me anyway and responded with a scripted rebuttal to refused to refund me regardless of my account status. Stay away

    Reply
  2. I’m wondering whether if i go for WP rocket or Swift performance pro. I’ve tried swift lite and couldn’t fix many issues on CSS, so added Autoptimize. It made the speed so fast, but it screwed up the mobile look. it looked like from 80s despite of 0.3 sec loading time. I came across your youtube and installed Cloudflare. then I found this. I was setting up in the way you did, i could somehow fix the mobile look problem, now i have slower and lower score on GTmetrix 90, not 99 anymore. I’m super newbie, so not having help button/explanation on Swift is hard for me. And your overall comparison of your speed was WP rocket…You said I should have minimal plugins. I also transferred host from Bluehost to Siteground as you said to speed up.I heard Siteground offers great in-house tools to speed things up.Which plugin should i get? I optimize images Ezgif.com because I focus on pinterest marketing and use canva a lot. But you said plug in won’t work for images already compressed.. What’s the must plugins to have as a blogger? It’s so overwhelming.. It’d be great if you can give me advice on plugins. Thank you.

    Reply
    • Hey Akiko,

      I’ll try to answer all your questions but let me know if you need any clarification.

      WP Rocket is much easier to configure than Swift and usually yields better results. They also have support as it’s a premium plugin. Just be sure to configure everything correct (eg. I have a tutorial on the settings) and you can get 10% off on their Coupons page. You might have better luck with WP Rocket – it’s also what I use. If using SiteGround, you may also want to test their SG Optimizer plugin.

      The problem is, each website is different, and different cache plugins yield different results depending on the website and cache plugin’s configuration. That’s why testing is required, but only test 1 at a time.

      Using the right (lightweight) plugins is more important than the amount of plugins. There seems to be an error with your website now but when you run your site through GTmetrix, look in your Waterfall tab and you will see exactly what is slowing down your site – whether it’s plugins, images, fonts, etc. If it’s a certain plugin causing your site to be slow, try to find an alternative lightweight plugin (do your testing in GTmetrix whenever you add new plugins to see how it affects your load time).

      Reply
  3. Tom, you said you are on a Siteground GoGeek plan in the article. But I can see that you are using their VPS server.

    Reply
    • I literally just switched to DigitalOcean on Cloudways about 4 days ago and am in the middle of revising my hosting recommendations. SiteGround is great for shared, but Cloudways is managed cloud hosting and cut my response time by 2x. Support isn’t as good, but speed is better.

      Reply
  4. Thanks for this guide. It really helped me. Thanks once more. I really recommend Swift over Wp-Rocket. I have used both.

    Reply
  5. Hi, have you tried SiteGround’s own cache plugin? I found they incorporated a lot of other features so you can actually have one plugin and avoid installing many others. Maybe you can write an article for SG users for anything else they should have? (such as Sucuri?)Thanks!

    Reply
    • Hey Annie,

      Yes I have tested it out. Long story short, their dynamic caching is faster than any other cache plugin. However, it still lacks features that come with Swift + WP Rocket. I use WP Rocket still, but may consider switching if they release even more speed features (database cleanup, integration of a CDN URL, etc). Until then, stick with Swift or WP Rocket.

      Reply
    • I still recommend WP Rocket if you can afford $39/year and have a decent sized site where speed is important, or just want a cache plugin that’s easy to configure. Otherwise, if going free, Swift is a good alternative. I still use WP Rocket.

      Reply

Leave a Comment