My unofficial guide to speeding up WordPress with SWIFT Performance cache plugin! (Updated June 22, 2018)
The SWIFT Performance cache plugin was something I was really excited about because it made such a difference on my sites. I was previously cycling between 3 or 4 different cache plugins throughout various sites but can now replace almost all of them with just this one.
The only thing lacking was official documentation as many users still don’t understand what each option does or how to diagnose when problems arise. Since most of the official Swift team is busy developing their plugin, I decided to write my own community guide.
Read on for my best SWIFT Performance setup tips!
I am NOT an employee or official Swift developer in any way. I wrote this unofficial guide to help all Swift users because I’m such a big fan of this incredible cache plugin.
I’ve done speed miracles with it on nearly 200 client sites (if not more) and quickly realized the time I spent helping users freed up Swift developers to focus on implementing my fantasy features, instead of playing tech support.
In the spirit of self-empowerment and efficiency, please enjoy my guide below!
QUICK Swift Performance Setup Guide
Here’s the 5-minute setup version for busy people. It doesn’t take much to get fantastic results out of this amazing #1-ranked speed plugin. Just make sure you aren’t blindly checking everything.
- Install either SWIFT Performance Lite (free version), or SWIFT Performance (premium).
- Caching – choose “Action Based Mode” and check “Prebuild Cache Automatically”, “Enable Browser Cache”, “Enable Gzip”. (Enable Cloudflare/Varnish if needed.)
- Optimization – uncheck “Merge Scripts” and “Merge Styles”. (Disable emojis if you don’t use them.)
- Media – uncheck “Lazy Load Images”. Enable “Lazy Load Iframes” if you have Youtube embeds or GoogleMaps NOT at the top of the your page.
- Hit [Continue] and Swift is done setting up!
- Check the Warmup Table – make sure all important pages are listed in there. Wait for pre-caching to finish. Click “Start Prebuild Cache” or go to Caching > Warmup and “Enable Remote Prebuild Cache” if it doesn’t. (It’s ok if weird items show up or some items don’t cache.)
- Check if your site is caching – visit your site in Chrome incognito window without logging in. Right-click anywhere on the page, click “View page source” and scroll to the bottom. If you see “Cached with Swift Performance Lite”, it is working! (Try refreshing the page if you don’t.)
- Enjoy fast speeds! – or read on for more tips and troubleshooting steps.
If you have problems:
- Swift should be super fast! – if you’re not getting instant page loads, go back and reconfigure things! (PS: it really helps to have good webhosting.)
- Site design or function breaking somewhere? – disable Merge Scripts and Merge Styles. Later, you can re-enable them individually to isolate the problem. (Don’t forget to purge your CDN or Varnish after content/cache changes!)
- Problem with https/SSL redirects? (or weird URLs showing on front-end) – go to “Tweaks > Custom Htaccess” and put your 301 HTTPS redirects here instead of htaccess.
- Problem with contact forms not working? Try excluding the contact page from caching, or just switch to Caldera forms. I’ve had issues with Contact 7 (and hate that it loads on every page).
- “Cached with Swift” not showing in page source? – maybe the page isn’t caching, but could also mean something is stripping out HTML comments. (Cloudflare does this sometimes.)
- Still need help? – follow my detailed steps below. Free support available on Swift knowledgebase, WP repo, Facebook group, or ticket support (for premium users).
DETAILED Swift Performance Setup Guide
STEP #1 – Install SWIFT Performance plugin
STEP #2 – Go through the wizard
Setup wizard will check for plugin conflicts, enabled Apache modules, and rewrite permissions:
Most of you won’t have any plugin conflicts or rewrites issues, and if you do it tells you how to fix it. The modules aren’t required but help give the best performance. Most shared hosting accounts already have them; some VPS do not, ask your webhost/sys-admin to install. (NOTE: the script doesn’t detect LiteSpeed servers so the modules could be installed properly but still not detect, you are fine.) Even if you do see errors, continue anyway; Swift should still work.
Hit [CONTINUE WIZARD] and not [Use Autoconfigured Settings].
Required Apache modules:
Cache Expiry Modes (explained):
- Time based mode – useful if your content updates often without you doing it (for example: user comments).
- Action based mode – I always pick this one by default. It’s the best for me…yes, even for WooCommerce shops.
- Intelligent mode – I never had to use this.
Other options (default settings are fine)…
- Prebuild Cache Automatically – leave it checked.
- Enable Browser Cache – leave it checked.
- Enable Gzip – leave it checked.
- Cloudflare (Enable Auto Purge) – check if using Cloudflare.
- Varnish (Enable Auto Purge) – check if using Varnish.
- Merge Scripts – uncheck! (You don’t need it, don’t listen to silly page scores.)
- Merge Styles – uncheck! (Same reasons as above. Want more explanation?)
- Disable Emojis – check if you don’t have or need emojis in your site content/comments.
About those other options (for your curiosity)…
- Minify Scripts – I prefer without as it slows down your cache prebuild time and doesn’t offer much benefit. It may cause problems and also unnecessary if you have Cloudflare (which already does it).
- Bypass CSS Import – leave it checked if you’re using Merge Styles.
- Minify HTML – I prefer unchecked for faster prebuild (CloudFlare already does this also).
- Optimize Prebuild Only – you don’t need it.
- Optimize in Background – I never needed it, but may be useful on larger sites and/or a VPS server. This makes Swift function like those “on-the-fly” cache plugins.
- Limit Simultaneous Threads – useful on shared hosting with big sites; has no impact on smaller sites. Try a limit of 1-3; more threads allows faster cache prebuild. Don’t check this if you’re on VPS, unless the server can’t handle the load.
- Lazy Load Images – uncheck! I absolutely hate lazy load. Poor user experience and feels slower; annoying when scrolling quickly through sites or stores. It’s useful if you have that many images (over 70) or really large images. It’s useless if you have only a few images on most pages, and dreadful if you have images above the fold. Also unnecessary if you’re on free CDN (Cloudflare), although can save you money if you’re on paid CDN.
- Lazy Load Iframes – this is really useful for pages with embedded iframes BELOW the fold. Example iframe content are Youtube videos, Google Maps, some Facebook boxes as well. I leave this unchecked since my pages only have one video which I do want loaded right away.
- Optimize Images on Upload (premium) – I prefer ShortPixel and haven’t used Swift image compression. It’s your call. But if you want to save money, why not?
- Keep Original Images (premium) – I recommend this in case you want to restore originals and re-optimize later with another plugin (or generate different image sizes).
Click [Continue] one more time and you’re done! Go play around with the front-end (on incognito browser or any browser not logged-in) to test speeds. Or keep reading for more performance tweaks.
STEP #3 – Check Warmup Table
Check your SWIFT Warmup Table to see if it’s caching all your pages.
- CLICK the Swift Performance link from your dashbar (top) or admin side-panel (left) Tools > Swift Performance.
- SCROLL DOWN to Warmup Table and see if it’s caching all your content (posts, pages, products, etc). Big sites take more time.
- CACHE CATEGORIES – if some category pages don’t cache by default, enable “Prebuild Archives” in the cache settings.
- WAIT FOR PREBUILD – prebuilds should run automatically but if not, click “Start Prebuild Cache” or even “Reset Warmup Table”. It can take from minutes to hours depending on the website size. You’re almost ready to fly!
- CACHE NOT BUILDING? – don’t freak out if you see weird URL’s or that not all pages are cached. It’s normal behavior and fantastic that Swift has this warm-up table for you to diagnose issues. (FYI: many other cache plugins don’t cache everything either, but they lack a convenient table for you to know that.) As a diagnostic step, you can manually click “Cache page” on the uncached items or by visiting them on the front end.
- CHECK FRONTEND to see if your site is caching – open up Chrome incognito window and visit your site without logging in. Right-click anywhere and click “View page source”, then scroll to the bottom. If you see “Cached with Swift Performance Lite”, it is working! *CHEERS*
STEP #4 – Testing for issues
Without logging in, browse around your site on desktop and mobile. Everything should be fast, look and function normally. If everything is perfect, skip to the next step. If something is broken, it is 99% almost always because you enabled “merge scripts/styles”. (If you want my advice, don’t merge CSS/JS.)
Broken styling issues? (usually WooCommerce stores or pagebuilders)
…or broken functionality? (forms, sliders, or things not working when clicked)…read below:
- Go to Settings > Optimization > Scripts/Styles
- Disable “Merge Scripts” and “Merge Styles”
- Try the front-end again. If everything works, you can stop here (caching will still be really fast) or continue to isolate and resolve the issue.
Some of you will still insist on merging because you want that vanity page score. Ugh…I’m telling you, it’s not best practices for performance! But here’s what you can do if you insist:
- Re-enable one at a time “Merge Scripts” and then “Merge Styles” to isolate the issue.
- It’s usually just one CSS stylesheet or one JS script that’s causing the problem. You can try playing with the other Script/Styles optimization options to see if they solve the issue but that’s never worked for me. The proper way is to exclude that problematic CSS/JS (whichever one it is) from merging.
How to find and exclude problematic scripts/styles from merging:
- Isolation Method #1 – leave MERGE SCRIPTS and/or MERGE STYLES enabled, open up the site in Chrome > Developer Tools > Network (tab), and reload the page. Click the little red error circle to see which CSS/JS are missing. Exclude them from merging and see if things work.
- Isolation Method #2 – disable MERGE SCRIPTS and/or MERGE STYLES (or even caching altogether), and scan your site in Pingdom. Scroll down to the waterfall and sort the loaded items by file-type (neatly displaying all CSS/JS). Now go back to Swift settings and merge scripts/styles again but manually exclude whichever CSS/JS you think is causing the issue. (Hint: whatever’s breaking is probably related to the problem. Did a certain plugin or theme function stop working? Try disabling those CSS/JS.) Yes, it will take a lot of trial and error. It could be anywhere; maybe a plugin, maybe a theme.
There’s a lot I’m not spelling out because this is very technical and should be handled by advanced users. If you’re having this much issue with merging CSS/JS, you shouldn’t be doing it. It’s nobody’s fault…not yours, not the cache plugin, not your other plugins/themes. (Sure you can try another CSS/JS merge plugin like Autoptimize and it might work for your current setup but then break another day.) I really really don’t recommend merging CSS/JS!
The fact of the matter is: every WordPress extension requires it’s own set of code to function and when you mix different code together, conflicts may arise. For best practices over the long term, you really shouldn’t be merging CSS/JS anyway!
STEP #5 – Performance tweaks
This is the best part! I’ve gone through all the settings and leave my thoughts on them below. Anything I forget to mention means I left it at default settings.
- General > Disable Cookies – it’s for GDPR purposes; like if you want to use another mechanism/filter to load cookies only after GDPR is agreed to. Cookies are used for appcache and identify user for GA, UNCHECK if you use appcache or bypass GA feature. Doesn’t impact speed either way.
- General > Hide Footprints – I prefer unchecked so I can see Swift comments in the source code. (FYI: Cloudflare may remove HTML comments.)
- General > Use Compute API (premium) – speeds up cache pre-build and reduces CPU usage. Awesome feature, enable it!
- General > Enable Remote Cron – if you don’t know what it’s for, disable it.
- General > Debug Log – only for diagnosing problems.
- Tweaks > Normalize Static Resources – useless if you use both “Merge Scripts” and “Merge Styles”. Otherwise, enable this for higher page speed scores. I left this on. (Cloudflare has this option, too.)
- Tweaks > Prefetch DNS – leave it checked.
- Tweaks > Collect domains from scripts – leave it checked.
- Tweaks > Gravatar Cache – should be off for most sites. It’s useful if you consistently have many comments. On my popular posts (500+ comments), uncached comment avatars alone make up 60% of the load time.
- Tweaks > Custom Htaccess – put your 301 HTTPS redirects here if your pages aren’t redirecting from HTTP to HTTPS. (This is much preferred than using SSL plugin!)
- Tweaks > Background Requests – leave it alone.
- Heartbeat > Disable Heartbeat – don’t worry about this unless your admin area is slow (caused by certain plugins and/or many logged-in users). WordPress Heartbeat API is a cool function that tracks user sessions in admin and auto-saves your content, but can be CPU-resource heavy on admin and frontend pages. I normally disable all except Post/Pages. If certain admin/front-end plugins stop working, then leave it all on but increase the frequency. (You can use Heartbeat Control plugin instead for more granular options.)
- Google Analytics > Bypass Google Analytics – really awesome idea of caching a local copy of Google Analytics JS script and merging it in with site JS (theoretically removes one external call to google). In terms of speed, it didn’t help so much but does give you a higher page speed score (only superficial benefit). To guarantee 100% GA function during cache prebuild, I ended up sticking with CAOS plugin or my theme to handle GA.
- Whitelabel (premium) – useful for agency or webhost trying to hide their speed-up secrets. 😉
- Images > Optimize Images on Upload (also enables next 4 settings) – I much prefer ShortPixel for image compression, but it’s cool that Swift can save you lots of money and negate yet another plugin on your site.
- Images > JPEG quality – would be great if I had a comparison idea of what percentage quality equals ShortPixel’s LOSSY/GLOSSY compression algorithms…but I don’t. Play with it yourself.
- Images > PNG quality – play with it yourself.
- Images > Resize Large Images – useful for non-techies uploading oversized images straight off the camera. But otherwise, leave it off if you intentionally want large images for HiDPI (retina) screens.
- Images > Keep Original Images – leave this on in case you ever need the original images to compress using another image plugin, or to generate different media sizes. Or at least keep them until you find the best compression settings.
- Images > Inline Small Images – fantastic feature with lots of arguments for and against. Leave it UNCHECKED if you don’t know what it is, your small images aren’t at the top of your site, have many pages, or care about faster cache prebuild (like me). Try it CHECKED if you have many small images at the top (social or ecommerce icons) not using font format (FontAwesome), slow image calls, or very few pages. It’s probably best for small websites.
- Images > Lazyload – no! I hate lazyload.
- Images > Force Responsive Images – most themes already have responsive images. Enable it if your theme/pagebuilder (I hate you, Thrive Architect) wastefully loads large images on mobile. If this feature fails to make your images responsive, leave it off.
- Embeds > Lazy Load Iframes – clever clever!!! I love Swift for this. It’s useful if you have multiple iframe video/video embeds on one page AND/OR they’re located far below the fold. Don’t enable this if you have iframes at the top of your pages, it will delay your perceived page load! Perfect examples of iframes are Youtube videos, Googlemaps, or Facebook boxes.
Optimization > General:
- Merge Assets for Logged in Users – don’t use if you’re the only one logged-in. It helps sites with many logged-in users (membership/forums/etc) by combining and delaying JS. But really, you should just stay away from this entirely. It also doesn’t help page scores either since they can’t reach logged-in areas.
- Optimize Prebuild Only – uncheck so it can optimize your site anytime. Check it if you want to control when cache is built (not needed for most sites).
- Optimize in Background – I have it off. But it can be useful for big sites or VPS servers. I have several sites with 100-200 posts on VPS and have been fine without it. You can play with it for yourself.
- Fix Invalid HTML – I leave it off as I assume it delays cache building. I would enable it only if site has an issue.
- Minify HTML – I assume it delays cache building so I leave it off if I have many pages or slow server. Cloudflare already minifies HTML/CSS/JS also.
- Disable Emojis – disable if you don’t use emojis in content or comments.
- Limit Simultaneous Threads – enable and set to 1, 2, or 3 if you’re on a shared server or want to prevent this site from hogging server resources. Uncheck if you’re on your own VPS, to use all server resources to prebuild cache quickly.
- DOM Parser Max Buffer – I never mess with this.
Optimization > Scripts:
- Merge Scripts (enables/disables other options) – I wouldn’t merge JS if I were you. It combines all your JS files into one file and load. There’s a weird balance; it’s safer to use when you have fewer scripts (but less impact), has more impact with many scripts but also higher chance of conflict or delaying page load. The best use for it is to delay/lazyload some scripts. The worst use is for higher page test scores.
- Aync Execute – async execution sounds great but wasn’t checked by default. Maybe it breaks functionality when JS doesn’t load in order. Leave it off, or just test it carefully.
- Exclude 3rd Party Scripts – off by default (probably faster that way). I would enable only if something breaks.
- Exclude Inline Scripts – just like above but for inline scripts. Maybe you have Google Tag Manager or other scripts that need to load from exact positions in the code (header/body/footer). Exclude them by entering a distinct text string found in the code, like “tagmanager” for GTM. If it doesn’t work, just don’t merge JS at all.
- Exclude Script Localizations – checked by default and I don’t know what it is so I leave it alone.
- Minify with API – check it only if the default minify JS option above causes errors.
- Proxy 3rd Party Assets – I uncheck, it’s a vanity feature. Resolves longer expire times on 3rd party JS/CSS (Pingdom/GTmetrix complaint), but may break things.
- Separate Scripts – clever idea of generating different merged JS for each page instead of one global merged JS for all pages (loading scripts even on pages where they aren’t used). It’s useful if you have many different page types (pagebuilder, WooCommerce, forums, etc). Only issue is it delays cache-build and can eat up lots of space if you have many pages.
- Print merged scripts inline – awesome idea deferring JS load till the end! It works best if you don’t have much JS and the top of your site doesn’t use JS (menus, image sliders, critical pop-ups, etc….if any, exclude them). UNCHECK if JS is needed for initial page items or you like faster prebuild (like me).
- Lazy Load Scripts – amazing for preventing 3rd party scripts from lagging your site load (e.g. Tawk.to, ads, caldera, etc). Works beautifully and improves your page scores without affecting front-end function. Don’t use it for GA/GTM!
- Include Scripts – I never used but think it’s to include scripts that are called from other scripts which you excluded.
Optimization > Styles:
- Merge Styles (enables/disables other options) – just like with JS, I wouldn’t if I were you. It combines all CSS files into one file. There’s a weird balance; it’s safer to use with fewer stylesheets (less impact), has most impact with more stylesheets but higher chance of broken styles. The best reason is to help overall CSS sheet cache, and with a long expiry time so users don’t have to keep downloading it. The worst reason is doing it for GTmetrix/Pingdom scores. Because CSS is always critical to page rendering, I don’t recommend merging it (or at least not theme-related CSS).
- Generate Critical CSS – speeds up “perceived load time”, rendering the top of the site first. I think it’s unnecessary nowadays, causes FOUT issues and slows down overall load time. Test it on and off for yourself. I always prefer it off. (To enable it, use a critical-CSS generator online. Don’t leave this blank!)
- Print full CSS inline – I don’t recommend it unless your page is super lightweight.
- Separate Styles – great tactic generating different merged CSS for each page instead of one global CSS for all pages (loading styles even on pages where they aren’t used). It’s useful if you have many different page types (pagebuilder, WooCommerce, forums, etc). Only issue is it possibly delays cache-build and eats up lots of space if you have many pages. I prefer it only on smaller websites with multiple page variations; big sites, I don’t merge.
- Minify CSS – I would stick to “basic” if I was going to use this at all. Choose “Don’t minify” if you prefer faster cache-building and/or already have it enabled from Cloudflare. Makes no impact on smaller sites.
- Bypass CSS Import – makes more sense to be enabled by default.
- Exclude 3rd Party CSS – try this if you have CSS problems.
- Exclude Styles – manually exclude CSS from here if you have CSS problems. Enter a distinct word instead of entire asset URL. (e.g. put”special” instead of “https://domain.com/theme/special-file.css”.) The main reasons for excluding styles are 1) to fix broken styling, or 2) to load it faster, e.g. not merging slider CSS so that it loads first and renders the top of your site faster. Merged styles are slower to load because you have to wait for entire combined CSS to load.
- Exclude Inline Styles – can fix CSS-merge issues. Some themes/plugins have CSS inline but Swift removes and merges it with global CSS. To put back inline styles, enter distinct text found in the CSS code. If you don’t know how to troubleshoot all this, just don’t merge CSS at all.
- Include Styles – I don’t use it. It can manually include CSS, letting you prevent specific JS from loading without losing the CSS calls inside.
Caching > General:
- Enable Caching – you have to CHECK this. If you don’t see this option or even the “Caching” tab, your host probably disabling cache plugins. WPengine and some other hosts do this as well.
- Caching Mode – disk cache with rewrites is fastest, disk cache with php is slightly slower but may have less issues. Some cache plugins (CometCache) prefer the php route. They argue it’s better but I only care what’s fastest. Memcached with PHP should be very fast as well but depends on your hosting environment. Memcached probably better on VPS than on shared hosting.
- Early Loader – should be checked.
- Cache Path – check this directory if caching or prebuild doesn’t work, might be wrong path from old server. (Go to cPanel “File Manager” for the right path.)
- Cache Expiry Mode – I prefer “Action Based Mode” for 99% of sites.
- Clear Cache on Update Post by Page – I don’t use it. Swift clears cache often.
- Clear Cache on Update Post by URL – I never had to use this.
- Enable Caching for logged in users – to be safe, only use IF you have many logged-in users. Don’t enable “Share Logged in Cache” unless all logged-in users should see the same content, otherwise it crosses user data (e.g. user A logs in and sees user B’s info). You can also exclude account/profile pages to prevent users seeing each others info.
- Separate Mobile Device Cache – enable only if you have AMP enabled via theme/plugin. If you don’t know what AMP is, do not enable this!
- Case Insensitive URLs – I never had to use this.
- Enable Browser Cache – it helps performance. Leave it on!
- Enable Gzip – leave this on!
- Send 304 Header – unchecked for me.
- Cache 404 pages – don’t cache unless the same ones are visited often.
- Ignore Query String – leave this unchecked!
- Enable Dynamic Caching – one of Swift’s amazing advanced features, leave it alone for now. (Intended for developers or pros.) I’ll explain it later.
- Cacheable AJAX Actions – another incredible advanced feature. Leave it alone.
- AJAX Cache Expiry Time – leave it alone.
Caching > Exceptions:
- Exclude Post Types – most sites should exclude all except posts, pages, products, and any post type that shows on the front-end with its own unique URL slug. (It’s fine if you don’t exclude any; but the site will cache all items even if they don’t show on the front-end, further delaying cache prebuild for critical items. Big sites should definitely exclude unnecessary post types!)
- Exclude Pages – any pages with “live info” or don’t work properly when cached, you can exclude them here. Commonly excluded pages are contact pages (forms don’t send), or WooCommerce (account, cart, checkout, wishlist), fancy sales pages (with tracking scripts), or any other dynamic/private pages.
- Exclude URLs – exclude any URL’s that couldn’t be single out using post types or pages above. You can use REGEX to exclude many URL’s at once. (Put “/feed” or “#json#” in here if you can’t stop those items from caching.)
- Exclude Content Parts – useful for excluding specific content or post types that show on multiple pages. Enter distinct text to keep specific content from caching.
- Exclude User Agents – prevent certain devices from seeing cached pages.
- Exclude Crawlers – prevent certain search engines or crawlers from seeing cached pages; they see uncached pages showing most recent content.
- Exclude Author Pages – I check this. Author pages aren’t visited often, so focus your caching mechanism on other pages.
- Exclude Archive – I prefer UNCHECKED. Blog category pages are visited often and do run slow if not cached. Not caching them ensures they show the latest posts but it’s unnecessary as Swift rebuilds cache pretty often.
- Exclude REST URLs – CHECKED. You don’t need these items pre-cached.
- Exclude Feed – CHECKED. You don’t need these items pre-cached. They load fast enough and aren’t visited often. Plus, it can double the number of items in your cache table (how messy).
Caching > Warmup:
- Enable Remote Prebuild Cache (premium) – can speed up or slow down your prebuild depending on your setup, sometimes fixes prebuild when it doesn’t work.
- Prebuild Cache Automatically – usually checked, one of Swift’s top features. (Use cases: prevent prebuild when server is busy, or caching only visited pages.)
- Discover New Pages – it’s better unchecked, but enable this if Swift can’t find all your pages. Only issue is it sometimes caches many unneeded items.
- Prebuild Author Pages – UNCHECK. This option pre-caches author pages but I prefer caching them only when they’re actually visited.
- Prebuild Archive – this should be CHECKED to pre-cache category pages.
- Prebuild REST URLs – unchecked for me. Not necessary to prebuild these.
- Prebuild Feed – unchecked for me as well. Not necessary!
Caching > Varnish:
- Enable Auto Purge – enable if you’re using Varnish. It clears Varnish cache automatically, so you don’t have to do it manually every time Swift clears cache.
- Custom Host – usually not necessary, unless you’re using Cloudflare or other DNS proxy. Enter the Varnish server IP and port here.
Caching > Appcache:
Incredible feature but 99.99% of you shouldn’t mess with this!!! It can slow down your prebuild without any noticeable benefit. The feature downloads your site into the user’s browser on first visit, dramatically speeding up navigation. Keep in mind the default appcache size for devices (100MB for desktop, 5MB for mobile) as per official Swift documentation.
The 100MB desktop limit can actually fit an entire for most smaller sites (especially if you’re not merging CSS/JS). The 5MB mobile limit may or may not fit the entire site. There is where it comes in handy to cache only certain pages. Honestly, this appcache function alone is so beautifully thought-out it could have been its own plugin or at least a paid add-on. I am forever grateful to Swift for including special features like this!
PS: I don’t use appcache at all for my own sites! Regular Swift caching functions have been amazing enough! (Also, my sites are already coded super lean already.)
- Enable Appcache for Desktop – check to enable this feature.
- Appcache Mode – depends on the size of your site. Pick “Full site” if your entire site cache fits within 100MB, or use Exclude Pages function to make it fit. Pick “Specific pages only” if your site is much bigger than 100MB, or you prefer only specific pages for app-cache…then use Include Pages function to select them. I think most sites should pick only the main pages. This allows you to build/load appcache faster onto users’ browsers, focusing on the most visited pages. (FYI: your site cache size can be found on the Swift Dashboard.)
- Desktop Max Size – not sure how this applies. I leave it alone.
- Enable Appcache for Mobile – check to enable. (NOTE: it uses more data.)
- Appcache Mode – since mobile appcache limit is only 5MB, you’ll most likely have to use the “Specific pages only” option and pick your most crucial pages.
- Mobile Max Size – I don’t mess with it.
These settings only show if you have WooCommerce installed.
- Cache Empty Minicart – leave it checked, I can’t see any reason why not.
- Disable Cart Fragments (premium) – depends on your use case. It speeds up that annoying WooCommerce admin-ajax call that lags your waterfall reports. The WC cart fragments function updates the little number in your shopping minicart icon at the top right of your site. It’s a nice feature but not essential, especially if it slows down your site. You can disable it on all pages, disable it only on some, or leave it on because it doesn’t affect the site/server much. It’s your choice. (Yes, this feature can replace the Disable Cart Fragment plugin by LittleBizzy.)
- WooCommerce Session Cache (BETA – premium) – I think it caches your user’s shopping items in cart. Test to make sure it works.
- General > Enable CDN – check if you’re using a CDN. This feature does NOT replace your CDN plugin; keep your CDN plugin enabled if you have one. Swift’s CDN settings are only for purging CDN, not for activating it! (PS: Cloudflare is not considered a CDN in the traditional sense; use the Cloudflare tab instead.)
- General > CDN Hostname – put the hostname URL without the “https://”. It should be something like “cdn.yourdomain.com” or “yourdomain.cdn-name.com”.
- General > Enable CDN on SSL – check this if your site uses https (which it should be, we’re in 2018).
- General > SSL CDN Hostname – should probably be empty, as most CDN’s use the same hostname regardless of http or https.
- Cloudflare > Enable Auto Purge – check it if you have Cloudflare. Otherwise, you’d have to manually purge Cloudflare cache every time you make changes on your site or Swift cache. (Make sure you enter your account email and API key.)
- MaxCDN (StackPath) > Alias/Key/Secret – fill it out if you’re using MAXCDN.
Import / Export:
I never use this as different sites will have different settings. Besides, I can configure Swift in only 2 minutes anyway. **TIP: whenever you import settings, check the “Caching > General > Cache Path” to make sure it’s the right address.
- Import/Export from FILE – safest option, it downloads the settings to your computer. To import a file, first open it up on your computer using code editor (like Notepad++ in Windows, or TextWrangler in OSX), copy all the text and then enter into the import box in Swift.
- Import/Export from URL – fastest option, you can quickly copy settings from one site to another. (Again, don’t forget to check the cache path!)
- Image Optimizer (premium)– I prefer ShortPixel but this works, too.
- Database Optimizer – useful, but be careful not to break things! It doesn’t impact speed much unless you have thousands of auto-loaded transients. It’s more for reducing database size than for speed. (Yes, this can replace WP Optimize.)
- Critical Font (premium) – really clever feature! I can’t believe Swift thought of this…if only all custom iconfont services were this easy! For most users, it helps if you have Font Awesome 4.x and older. It regenerates icon fonts using only necessary icons so you’re not wasting 150ms loading the entire Font Awesome library of 5,000 icons on every page. (Newer FA 5 uses SVG.)
- Plugin Organizer – simply incredible feature and warms my heart. I can’t believe they gave this away for free. It should be a premium plugin or at least not overlooked by the community. It’s easy to use but from a caching standpoint, I consider this advanced speed-up strategy so I won’t cover it in this guide.
- Upgrade to PRO – should you do it? Is it worth it? Just to support this incredible plugin alone, yes it’s worth it. But as for what features make the most impact…Compute API (reduces server CPU usage), Enable Remote Prebuild (resolves many difficult caching problems), Image Optimizer (save money on image optimization), WooCommerce caching (more features), Whitelabel (hide your speed-up secrets), critical font (speeds up older FontAwesome).
STEP #6 – Final functions check
Make sure nothing is broken!
- Clear your cache, also purge CDN or Varnish (if you have them).
- Wait for caching to complete, then check every page.
- FRONT END CHECK: posts, pages, forms, shopping cart, affiliate tracking.
- BACK END CHECK: pagebuilders, other admin tools.
- CACHING: are the items in table caching? Do you see the SWIFT comments in the source? (Sometimes items don’t appear as cached in the table but are in fact cached on the front end.)
- Website is still slow – either your webhosting is really bad, website too bloated, or you have the wrong settings. Check other plugins, too. Anything with redirection, security, e-commerce, or causes many database queries can slow a site.
- Broken styles (CSS) or functions (JS) – disable merge scripts/styles. Also make sure your theme or other performance plugins are not trying to merge as well. (Avoid having multiple performance plugins doing the same function.) Swift appcache feature might also break CSS.
- Contact forms not working – exclude the contact page from caching. Try switching to Caldera forms. I’ve had issues with Contact 7 (and hate that it loads on every page).
- Weird scrolling or screen refreshes – disable “smooth scroll” or other scrolling effects in your theme settings. And if the screen refresh won’t go away, please stop merging JS. (Or at least exclude the JS causing it.)
- Excluded/unwanted items still caching – unwanted items showing up in your warmup table? Try clicking [Reset Warmup Table].
- Items not caching? – make sure cache directory address is correct and writeable. Try removing some items from “Exclude Post Types”.
- Items not pre-caching – make sure “Prebuild Cache Automatically” is enabled. Can also try “Enable Remote Prebuild Cache”, or other caching modes (less ideal). Make sure your robots.txt file isn’t blocking everything “Disallow: /” (common on staging sites).
- White screen of death (WSOD) or error 500 – it’s unfortunate but not every plugin is compatible with others. You can restore your site by deleting the Swift section in htaccess, delete “wp-content/cache” directory, delete “wp-content/plugins/swift-performance” directory, also delete “swift-performance-loader.php” in wp-content/mu-plugins directory. Another trick I’ve found is to change your php version, then change back.
- High CPU usage – some complain Swift causes high CPU usage, but this isn’t accurate. Swift has an aggressive (really fast) pre-caching mechanism that uses all available resources to pre-cache your pages. It’s much faster than other cache plugins taking forever to pre-cache your site (like 10 pages/hour). Some popular remedies: limit simultaneous threads to 1-3, turn off Merge Scripts/Styles, turn off minify HTML. You can also disable pre-building cache, but then the first visit will be slower.
- Swift Dashboard or Warm-up Table not loading – this can happen for huge sites with thousands of cached items. As long as you can access your Swift Settings and pages are caching on the front-end, you are fine!
- “Cached with Swift” not showing in page source – it could mean that the page isn’t caching, but could also mean something is stripping out HTML comments. Maybe you have Cloudflare enabled? Disable it temporarily and see if the comment shows.
Need Expert Help?
I’ve tried my best to offer detailed advice for everyone. But there will always be sites that need special configuration. Still have problems? Contact one of the Swift support channels mentioned below.
- Free help is available on the Swift Performance Users Facebook group (fastest response, official support team and myself are on there), Swift Lite WordPress repo (slower response), or Swift website ticket (great option and more privacy for paid users).
- More explanations about features can be found on official Swift knowledgebase (not fully documented), or the free Facebook group above.
- If you need help but still insist on doing things on your own, please respect your level and avoid messing with settings that you don’t understand. Swift has features for newbies as well as developers and server experts.
If you would like paid help or even just a free look at your site, don’t hesitate to contact me. (I configure Swift on dozens of sites every month.)
Take care and may the “Swift” be with you! 😀