My unofficial guide to speeding up WordPress with SWIFT Performance cache plugin! (Updated Dec 4, 2021)
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 (my other favorite being LiteSpeed Cache).
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 Swift users because I’m such a big fan of this incredible cache plugin.
I’ve done speed miracles with it on hundreds of client sites and realized the time I spent helping users could free 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 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 enabling everything.
(NOTE: I like my configurations so much better than the official Swift auto-configurations. For full explanation of why I chose these settings, see my DETAILED setup guide.)
- Install SWIFT Performance Lite (free version), or SWIFT Performance (premium). Click MANUAL settings, then Advanced View (top-right button).
- General > General – enable “Use Compute API” if you have paid version.
- General > Tweaks – put 301 HTTPS redirects into “Custom Htaccess” area here.
- Media > Images – disable “Lazy Load Images”.
- Media > Embeds – enable “Youtube Smart Embed” and “Lazy Load Iframes” if you have Youtube embeds or GoogleMaps NOT at the top of the your page.
- Optimization > General – disable “Optimize Prebuild Only” and “Fix Invalid HTML”. Enable “Disable Emojis” if you don’t use them.
- Optimization > Scripts – disable “Merge Scripts”.
- Optimization > Styles – disable “Merge Styles”.
- Caching > General – pick “Disk Cache with Rewrites” for Caching Mode, and “Action based mode” for Cache Expiry Mode. I’d use “Time based mode” only if your site has non-content updates often (like new comments or changes in product status).
- Caching > Tweaks – disable “Avoid Mixed Content”.
- Caching > Exceptions – exclude all post types except posts/pages/products or any other post types that are actually browsed on frontend with their own URL slug. Exclude any pages with contact forms. If you have WooCommerce, exclude the Account/Cart/Checkout pages.
- Caching > Warmup – choose “Unlimited” for Prebuild Speed if you have that option and your site is 1000 pages or less.
- Plugins > WooCommerce – enable “Cache Empty Minicart” but “Don’t disable” for Disable Cart Fragments, and disable WooCommerce Session Cache (BETA).
- CDN – enter your info if you have CDN.
- Hit [SAVE CHANGES] then [CLEAR CACHE], and Swift is done setting up!
- Check the Warmup Table – make sure all important pages are listed and pre-cache successfully. Click “Start Prebuild Cache” or go to Caching > Warmup and “Enable Remote Prebuild Cache” if they don’t. (It’s ok if a few 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. Or re-enable them individually to isolate problems. (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) – put your 301 HTTPS redirects in “Tweaks > Custom Htaccess” instead of htaccess.
- Contact forms not working? Exclude 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 Setup Guide
STEP #1 – Install SWIFT Performance plugin
Swift has few requirements but can work even if some of them aren’t available:
- Apache modules – mod_deflate, mod_filter, mod_setenvif…all 3 usually available on most servers.
- Loopback – this is when your server can visit itself. Sometimes not available if you block robots or indexing from crawling your site.
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. Most of you won’t have any plugin conflicts or rewrites issues, and if you do Swift tells you how to fix it. (NOTE: the script doesn’t detect LiteSpeed servers so the modules might be installed not detect, you are fine.) Even if you do see errors, continue anyway; Swift should still work.
STEP #2 – Go through Swift Performance Settings
Go to Swift settings and click [Advanced View] on top-right.
I’ve gone through all the settings and leave my detailed thoughts on them below. Anything I forget to mention means I left it at default settings.
- General > Hide Footprints – disabled, so I can see Swift comments in source code. (FYI: Cloudflare may remove HTML comments.)
- General > Use Compute API (premium) – awesome feature, enable it! Speeds up cache pre-build and reduces CPU usage. Especially useful on big sites (over 400 pages) and/or slow server.
- General > Clear Cache Role – default is fine, unless you want to allow editors or other users to clear cache after making site changes.
- General > Disable Admin Notices – enabled. Remove ads asking you to buy paid version.
- General > Disable Toolbar – enable if you don’t Swift options in the top toolbar.
- General > Page Specific Rules – allows you to override global Swift settings on a per-page basis. Really cool feature, but only necessary for fine-tuning super bloated sites.
- General > Beta Tester (premium) – allows you to try the latest features. I wouldn’t recommend for production sites. But can be fun for your own personal ones that you maintain on a daily basis.
- General > Collect Anonymized Data – disabled for me.
- General > Debug Log – enable only when diagnosing problems.
- General > Disable Cookies – I don’t use it. It’s for GDPR purposes; if you’re using another mechanism/filter to load cookies only after GDPR is agreed to. Cookies are only used for appcache and identify user for GA Bypass, must be UNCHECKED if you use these features. Doesn’t impact speed either way.
- General > Beta Tester – don’t enable for production sites. Enough said.
- Tweaks > Custom Htaccess – put 301 HTTPS redirects here. (This is much preferred than using SSL plugin!) If for whatever reason this messes up your site or creates ugly URL’s, try putting redirects directly in htaccess instead (I recommend anywhere ABOVE the Swift section).
- Tweaks > Background Requests – haven’t used it but it’s awesome! Prevents unnecessary AJAX requests from slowing down your page-load. (For example, removing ajax requests that aren’t critical to users…post views, etc).
- Heartbeat > Disable Heartbeat – ignore 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 content when editing, but can be CPU-resource heavy on admin and frontend pages. You can 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.)
- Heartbeat > Heartbeat Frequency – fine, still wanna decrease heartbeat impact on your server but don’t wanna disable? Simply raise the frequency. I think 120 seconds is safe but honestly if you’re having heartbeat issues, you should just get better webhosting.
- Cronjobs > Limit WP Cron – WordPress unnecessarily loads cron on all un-cached page loads. Lowering this is a great idea if you have high cron activity.
- Cronjobs > Enable Remote Cron – usually disabled. Enable if your site relies on cron jobs that misfire because A) your host disabled WP Cron, B) all your pages are cached, or C) you almost never log into WP-admin.
- Google Analytics > Bypass Google Analytics – awesome idea of locally-caching the Google Analytics JS script and merging it 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 (superficial benefit). Only problem is GA won’t work on uncached/excluded. To guarantee 100% GA function during cache prebuild and on uncached pages, I stuck with CAOS plugin or my theme to handle GA.
- Whitelabel (premium) – useful for agency or webhost trying to hide their speed-up secrets. Lets you rename Swift plugin and description so clients can’t tell that you’re using Swift.
- Images > Optimize Images on Upload (also enables next 4 settings) – I prefer ShortPixel for image compression, but Swift can save you lots of money and negate yet another plugin on your site.
- Images > Image source – Media Library is the default option. But the wp-content directory is really nice for when you have other images in the wp-content directory and not attached to the default WP media library. Really cool option.
- Images > Image Optimizer – experiment and figure out what works best for your site. Would be great if I had a comparison idea of what percentage quality equals ShortPixel’s LOSSY or GLOSSY compression…but I don’t. Test 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 enabled in case you want to restore originals later and re-optimize with another plugin, or to generate different media sizes. Or at least keep them until you find the best compression settings.
- Images > GenerateWebP – usually enabled. Generates WebP version of all images.
- Images > Serve WebP – use “picture elements” is the preferred option; use rewrites option if you have styling issues. How rewrite option can also fail if using CDN or Cloudflare. Test carefully.
- Images > Preload Image by URL – great to preload important images (like ones at top of page) to make them appear quickly.
- Images > Preload Image by CSS classname – more efficient way of preloading important images, by identifying their CSS classes.
- Images > Lazyload Images – disable! I hate lazyload. It’s a counter-intuitive tactic of speeding up page load by not loading everything. Guess what?…not loading everything initially means everything loads slower! Poor user experience and feels slower; annoying when scrolling quickly through busy sites or stores. But useless if you have only few images on most pages, and dreadful if you have images above the fold. Unnecessary if you’re on free CDN (Cloudflare), although can save you money if you’re on paid CDN. There are some rare use cases, like if you have really big images and/or many images AND your visitors don’t scroll quickly…but in 99% of cases, your site will appear to load faster without lazy load!
- Images > Exclude Images URL – exclude images from lazyload based on url string.
- Images > Exclude Images by CSS classname – more efficient way of excluding images from lazy load by using their CSS selectors.
- Images > Respect Lazyload Standards – should definitely by ENABLED, unless you want to override those settings from elsewhere.
- Images > Preload Sensitivity – specifies how soon lazy-loaded images should be loaded when user is scrolling to them. The 50-pixel default setting seems fine but you can always increase if users scroll fast (and you want the images to appear sooner).
- Images > Load Images on User Interaction – great tactic to only load images if browser is interacted with. Good way to keep server loads down and probably also improves page scores. It probably won’t make much difference if you’re already lazy loading images.
- Images > Inline Lazy Load Images – reduces HTTP requests by putting inline image request in base64 code. This should be left disabled IMO for modern browsers.
- Images > Lazyload Placeholder – choose your style of placeholder image. Most sites user transparent. Medium.com website likes blurred. Others do low-quality image. It’s really by personal preference. Images that aren’t key to the content don’t really matter. But if they are, you’ll probably want at least transparent to low quality.
- Images > Lazyload Background Images – hell no! Don’t enable this. You need those backgrounds (especially ones at the top) to come up immediately, or else your site appears slower!
- Images > Fix Missing Dimensions – useful to prevent layout shifts due to slow image-loads. But I personally don’t need it.
- 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.
- Images > Gravatar Cache – usually disabled. Only useful if you consistently have many comments. On my popular posts (500+ comments), uncached comment avatars alone make up 60% of the load time. But then again, why bother caching something that loads at the end of your posts anyway?
- Images > Gravatar Cache Expiry – I would use a long time like 1 month since most people never update their Gravatar images. And even if they did, who cares…it would matter if the cache doesn’t update immediately.
- 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 better for small websites.
- Embeds > Youtube Smart Embed (enables next option) – clever! I like it. Creates an image thumbnail (appearing just like a Youtube embed box but without loading all the laggy assets), which loads the video when clicked.
- Embeds > Exclude Youtube Videos – disables “smart embed” function on chosen videos. Useful if you have videos at top of website and/or want them to autoplay.
- Embeds > Preload Sensitivity – specifies how soon lazy-loaded YouTube embed iframes should be loaded when user is scrolling to them. The 50-pixel default setting seems fine but you can always increase if users scroll fast (and you want the iframe to appear sooner).
- Embeds > Lazy Load Iframes (enables next 2 options) – clever! I love Swift for this. Useful if you have multiple iframe video/video embeds on one page AND/OR they’re located far below the fold. Don’t enable if you have iframes at the top of your pages, it will delay your perceived page load! Common iframes are Youtube embeds, Googlemaps, or Facebook boxes.
- Embeds > Exclude Iframes by URL – awesome! Use it to exclude important iframes (like ones near the top of the site) from lazy loading.
- Embeds > Exclude Iframes by CSS classname – more efficient way of excluding YT iframes from lazy load by using their CSS selectors.
- Embeds > Respect Lazyload Standards – should probably be ENABLED unless you want to override settings from elsewhere and use your lazy load settings.
- Embeds > Preload Sensitivity – specifies how soon lazy-loaded YouTube embed iframes should be loaded when user is scrolling to them. The 50-pixel default setting seems fine but you can always increase if users scroll fast (and you want the iframe to appear sooner).
- Embeds > Load Iframes on User Interaction – loads iframes only after user has clicked or scrolled on page. Great for iframes lower on the page.
Optimization > General:
- Enable Server Push – I recommend disabled. It speeds up sites by preloading CSS/JS assets for your other pages so they load faster when clicked. It’s more beneficial for sites with lots of CSS/JS, but also more likely to cause problems on sites with lots of CSS/JS (broken elements, laggy load, high CPU usage). Test carefully if you enable it. Page scores may appear slower since each page load is now loading more assets. I also think it’s unnecessary if your site loads the same CSS/JS for every page (which is already browser-cached).
- Optimize Prebuild Only – uncheck so your site is always optimizing. Enable to limit when cache is built (not needed for most sites).
- Optimize in Background – usually disabled, but can be useful for big sites and/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. This makes Swift function like those “on-the-fly” cache plugins, which negates the benefit of prebuilding cache.
- Optimize 404 pages – leave this DISABLED to save server space. You don’t need page optimizations (CSS, JS, etc) for 404 pages anyway.
- Prebuild Booster – I prefer disabled. It prebuilds using memory resources rather than CPU. On strong servers, I prefer it off. It’s probably helpful on shared hosting (to avoid hitting CPU limits).
- Disable Emojis – disable if you don’t use emojis in content or comments. Browsers already show emojis already, anyway.
- Limit Simultaneous Threads – disable if you have your own server or a small site (100 pages or less). Enable and set to 1, 2, or 3 if you’re on shared server or want to prevent site from hogging server resources. Ideally, you’d want to use all resources to prebuild cache quickly.
- Merge Assets for Logged in Users – disable if you’re the only admin user. It theoretically speeds up sites with many logged-in users (membership/forums/etc) by combining and delaying CSS/JS. But really, you should just stay away from this entirely due to potential broken styles or functions. It also doesn’t help page scores either since they can’t reach logged-in areas.
- Prefetch DNS – leave ENABLED. It preloads and reduces DNS wait for any visits to or assets called from 3rd-party domains.
- Exclude DNS Prefetch – excludes domains from prefetching DNS. I’d disable specific ones maybe to limit charges/triggers by 3rd-party asset requests?
- Normalize Static Resources – useless if you use “Merge Scripts” and “Merge Styles”. It improves higher page speed scores, but not actual speeds. I enable this but never for sites often updating their design. Many caching engines (also Cloudflare) already intelligently cache static assets with query strings.
- 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, but it really depends. I think the tradeoff is between merging 3rd-party scripts (decreasing their external load time), VS keeping your overall merged scripts lighter. The more scripts you have overall and/or the more these 3rd party scripts don’t affect your overall load, the more I think you should leave them excluded. Otherwise, merging these 3rd party scripts will give you a faster page speed score BUT slow down your perceived load time for real users.
- Footer Scripts – love this feature but haven’t used it. It prevents non-critical scripts from being combined with front-loading scripts and further delaying your initial load. Honestly, all these little things to think about are why I don’t recommend merging scripts!
- Deferred Scripts – don’t merge this scripts, but keep them deferred. Good for any scripts that cause problems when combined, but you also don’t want them loading first (when excluded from combine).
- 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.
- Footer Inline Scripts – I would not mess with this. If they’re inline, it’s probably for a good reason. This is advanced stuff!
- Exclude Script Localizations – enabled 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 disable; it’s a vanity feature. Resolves longer expire times on 3rd party JS/CSS (Pingdom/GTmetrix complaint), but may break things.
- Safe Mode – might fix errors during JS combine.
- 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 post types (pagebuilder, products, portfolio, gallery, 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.
- Block Scripts – block scripts from loading. In case you don’t need them or want to refactor them elsewhere (like in header or footer).
- Preload Scripts – use this to load slow/bloated JS scripts that are necessary for page rendering (like visual elements near the top of the site).
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 (but less impact), most beneficial with more stylesheets but also higher chance of broken styles. The best use is to cache entire CSS with a long expiry time so users don’t have to keep downloading it. The worst use is doing it for GTmetrix/Pingdom scores. Since CSS is so 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. I think “unused CSS” is safer option but also less aggressive; whereas viewport is faster but may leave out some necessary styling. This feature benefits more for super-bloated sites.
- Extra Critical CSS – add any other CSS that you need loaded ASAP on page load that was missed out by the auto-generated critical CSS.
- Extra CSS – add extra CSS to the regular CSS rather than critical CSS.
- Print critical CSS inline – puts critical CSS into the header instead of a separate file. I would only recommend this if your CCSS is very small and/or you only have very few pages on your site (like 3). Because otherwise you’re adding unnecessary CSS weight to each HTML requests when that CSS coulda been cached on its own as a static asset.
- 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 – clever but I don’t use it. It manually includes CSS, letting you prevent specific JS from loading without losing the CSS calls inside.
- Preload Styles – use this to preload key CSS files, ideally the ones related to your overall theme design and ATF items.
- Force Swap Font Display (enables next option) – in my opinion, DISABLED! It solves FOIT issue by giving you FOUT issue, which is much worse UX in my opinion. (Most people using this do it for higher page scores.)
- Exclude Force Swap Font Display – type name of font-family to exclude from force-swap. Good use case would be any menu fonts loading at the top of the page. As the font reload would look especially jarring to visitors.
- Disable Full CSS – clever way of disabling all unnecessary CSS but be careful! It may leave out necessary CSS so test it carefully. If having issues, can try adding missing CSS into “extra critical CSS” or just disable altogether.
- Compress Critical CSS – shortens the super long CSS class names to save some bytes. Useful if you have bloated plugins with super long CSS class names/ids (e.g. “ubermenu-item ubermenu-item-type-post_type ubermenu-item-object-page ubermenu-item-has-children ubermenu-item-9544 ubermenu-item-level-0 ubermenu-column ubermenu-column-auto ubermenu-has-submenu-drop ubermenu-has-submenu-mega”)… lol, yes. That’s a real class name.
- Remove Keyframes – remove CSS keyframe animations from critical CSS. Should be safe to enable unless you have animations or slideshows relying on CSS keyframes instead of JS at the top of your site. Just test it and see.
Optimizations > Fonts:
- Manual Preload Fonts – decide what fonts to preload. Probably not necessary IMO. Unless you got tons of slow-loading fonts.
- Use Local Fonts – if you’re loading any webfonts (from external sources), this saves and loads them locally. Beautiful feature!
- Exclude Local Fonts – in case you want to exclude any from being hosted locally. I imagine this is only for fonts that display weirdly on your site when loaded locally, or ones that are seldom used or called throughout your site.
- Force Swap Font Display – shows a fallback font if your custom fonts take too long to load…avoiding the FOIT issue. However, if you have lots of real-world experience, you’ll know that FOIT is nowhere near as bad as FOUT…which is what happens if you use this feature. Therefore, I highly DO NOT recommend this! (Seriously, think about it. Any text that really needs to be shown that fast…should probably not be allowed to use a fallback font!)
- Exclude Force Swap Font Display – exclude specified fonts from using swap-fallback display method. I don’t use this because I don’t bother with swap display at all.
Optimizations > HTML:
- Fix Invalid HTML – I disabled as I assume it delays cache building. Enable it only if site has an issue.
- Minify HTML – I assume it delays cache building (and no noticeable benefit) so I disable if I have many pages or slow server. Cloudflare already minifies HTML/CSS/JS also.
Caching > General:
- Enable Caching – you must ENABLE this. If you don’t see this option or even the “Caching” tab, your host is probably disabling cache plugins. WPengine and some other hosts do this.
- 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 works 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. You can pick “Time based mode” if your site has non-content updates often (like new comments or changes in product status).
- Bypass Nonce – only available when using Action Based expiry mode. Basically extending nonce life indefinitely to match the cache expire. Sometimes site functions (e.g. cached forms) don’t work correctly because plugin nonces expires before the cache expires. This feature fixes that problem.
- Cache Expiry Time – normally I use Action Based Mode for expiry, which is basically an expiry time of “forever”. So if you’re using Time Based expiry mode, then pick whatever interval you think your site cache should be refreshed. That’s your call to make.
- Extend Nonce Life – sometimes site functions (e.g. cached forms) don’t work correctly because plugin nonces expires before the cache expires. This feature fixes that problem.
- 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 since I use Action Based Mode which auto-clears after any changes. Folks using Time Based Mode may want to clear any page that shows dynamic content. (For example, clearing home page or blog category pages so they show the latest posts.)
- Clear Cache on Update Post by Custom Rule – much more efficient regex/wildcard way of custom clearing multiple pages when posts are updated.
- Clear Cache After Update – probably better to leave this ENABLED. You might prefer disabled if your site is huge (takes forever or many server resources to preload) and has so many themes or plugins that update automatically.
- Enable Caching for logged in users – to be safe, only enable 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 sees user B’s info). You should exclude account/profile pages from caching in general!
- Separate Mobile Device Cache – disable! Only used if you have AMP enabled via theme/plugin or specific design or ads for mobile visitors. If you don’t know what AMP is, do not enable this!
- Enable Browser Cache – enable! It helps performance.
- Enable Gzip – leave enabled!
- Send 304 Header – disable.
- Cache 404 pages – enable only if you have a small site and/or the same non-existent URL’s are visited often. Otherwise, it can quickly clog up your warmup table.
- Cache Sitemap – love this function! Enter a sitemap url here so the preloader caches things in a more intelligent manner. Back in the old days, Swift was randomly scanning your site for urls and often preloaded unimportant pages first.
- Enable Dynamic Caching – one of Swift’s amazing advanced features, leave it alone for now. (Intended for developers or pros.) Can cache or allow compatibilities with features like multi-currency, etc. I’ll explain it later.
- Cacheable AJAX Actions – another incredible advanced feature. Leave it alone.
- AJAX Cache Expiry Time – leave it alone…unless you know that you need it longer.
- Ignore Query String – leave this unchecked!
Caching > Tweaks:
- Enable Proxy Cache – interesting feature I haven’t used yet. Uses Cloudflare’s “cache everything” rule to cache pages and get super fast load. Only issue is how to clear these pages upon changes or updated information.
- Proxy Cache Maxage – should be spelled “max-age”. Default setting is a day. Seems fine but longer is ok too if your site doesn’t update much.
- Proxy Cache Only – saves cached files only on the proxy. This is a good way to save disk space for large sites or sites with limited hosting plans. But I assume your site might load slower if the proxy cache is cleared and you don’t have a local cache?
- Ignore GET Params – use this to ignore certain URL parameters. All the standard FB, UTM, GA are ignored by default. But there might be more from whatever ad network you use or 3rd-party referrals.
- Avoid Mixed Content – disabled. It can create issues for asset URL’s! Only necessary if your site is still using HTTP but has some 3rd-party requests in HTTPS (like GoogleMaps). Most sites are in full HTTPS already!
- Keep Original Headers – I leave it enabled.
- Exclude Headers – exclude specified headers from your cached pages.
- Case Insentive URLs – I leave it disabled. Never had a use-case for it. All your URL’s should be lower-case anyway.
- Strict Host – basically generates cache only for one version of your site domain (with or without www). This probably helps prevent display problems related to that issue, but also save storage space. Good idea to use but make sure you have a permanent site redirect to force users to the right version of your site domain.
- Ajaxify Placeholder – display options your lazyloaded elements. You can use the default “hidden” which is empty until it loads, or a “blurred” box like Medium, or “show cached” which shows cached version until it updates to the live version afterwards.
- Ignore Query String – I don’t use it. URL’s with query strings exist for a reason…it’s risky to ignore them if you don’t know what you’re doing.
Caching > Ajaxify:
WOW, this whole section is freaken cool and clever!!!
- Lazyload Shortcodes – only use for shortcodes that aren’t used for ATF content.
- Lazyload Template Parts – very clever! You can practically lazy load everything below your ATF. Be careful that it doesn’t affect your SEO.
- Lazyload Nav Menus – can use for any menu except the ones loading at the top of your site.
- Lazyload Blocks – use to lazyload your heaviest/laggiest Gutenberg blocks, or ones that cause you a bad page score.
- Lazyload Widgets – lazyload widget positions that are slow-loading or causing bad page scores.
- Preload Sensitivity – decide how soon lazy-loaded elements should be loaded when user scrolls to them. The 50-pixel default setting seems fine but you can always increase if users scroll fast (and you want the images to appear sooner).
- Ajaxify Placeholder – display options your lazyloaded elements. You can use the default “hidden” which is empty until it loads, or a “blurred” box like Medium, or “show cached” which shows cached version until it updates to the live version afterwards.
- Lazyload elements – clever tactic of using lazyload to dynamically load parts of the site that shouldn’t be cached. For example: recent comments, related posts, recently viewed products, forms, etc. Anyone wishing for object caching or the ability to un-cache certain parts of their pages can use this feature.
Caching > Exceptions:
- Exclude Post Types – you should exclude all post types EXCEPT posts, pages, products, and any post type that shows on the front-end with its own unique URL slug. (If don’t exclude any post types; 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!) Pro tip: it’s faster to type the first letter of items or press the down arrow key on your keyboard, than to click around.
- Exclude Pages – you should exclude any pages with “live info”, “private data”, or don’t work properly when cached. Good examples are pages with forms, dynamic WooCommerce (account, cart, checkout, wishlist), fancy sales pages (with tracking scripts), and 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. (I highly recommend adding “#revision#”, “#autosave#”, and “#json#” in here to prevent those items from caching. You can also add “/feed” or others as well.)
- Exclude Cookies – prevent users with specified cookies from seeing cached pages. Useful for showing live/updated pages for certain users.
- 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 specified search engines or crawlers from seeing cached pages. They see uncached pages showing most recent content, but can also increase server load if they visit often.
- 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:
- Prebuild Cache Automatically – usually checked, one of Swift’s top features. (Only time you shouldn’t use prebuild is when you have so many pages, like over 1k, that server is always busy prebuilding, or you have so much traffic that they prebuild pages for you already.)
- Prebuild Speed – always try to use “Unlimited” if you have your own server/VPS or don’t have many pages (400 or less). If you’re on shared hosting with resource limits, pick one of the other options or your host might penalize you for “High CPU/resource usage”.
- Discover New Pages – it’s better unchecked, but you should enable this if Swift can’t find all your pages. Only issue is it sometimes caches many unneeded items but you can exclude them anyway.
- Warmup Table Source – auto is fine for smaller or lightweight sites with few pages. But if you have many pages and/or your server is slow, I highly recommend sitemap option to prioritize important pages first. Sometimes Swift prebuild mechanism will put low priority items first (like tags) which means your key pages take longer to precache after a purge.
- URLs page page – decide how many urls are shown in your warmup table. Higher number if you’re on a fast server and/or have tons of pages. Lower number if your warmup page takes forever to load.
- Warmup Priority – can drag this around but the default setting is best IMO!
- Remove redirects – this should probably be enabled. And also if you see them, you should find-replace these outdated URL strings in your site database.
- 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 Terms – check only if you think users often click on your term pages (e.g. tags). Otherwise, leave it disabled if you’re one of those sites that only have like 100 posts but 1000 tags! (Basically, you don’t want your prebuild to waste time precaching tag pages instead of content.)
- Prebuild REST URLs – unchecked for me. Not necessary to prebuild these.
- Prebuild Feed – unchecked for me as well. Not necessary!
- Enable Remote Prebuild Cache (premium) – usually DISABLED! Use only when your server can’t visit itself and can’t prebuild cache; maybe because you blocked bots or indexing? It can speed up or slow down your prebuild depending on your setup, often fixing prebuild issues.
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.
- Exclude Pages – clever addition! It’s great to exclude unnecessary pages from desktop appcache. Reminder: desktop appcache allows 100MB total.
- Exclude Strings – a more efficient way of excluding items from desktop appcache based on URL string.
- 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.
- Exclude Pages – really useful since mobile appcache is only 5MB, so you should pick only your most essential pages.
- Exclude Strings – again, use it to exclude items from mobile appcache.
As always, Swift is on some next-level shit again! They have special optimization settings that show if you have certain plugins installed.
- Contact Form 7 > Smart Enqueue Assets – I love it! One of my longest standing complaints about CF7 was that it loads its CSS/JS on every page even when you’re not using forms! I’ve always told everyone to switch to Caldera but with this setting, you don’t have to (if you love CF7). Enable this but check carefully in case Swift doesn’t properly detect all your CF7 forms. Still though, you should switch to Caldera anyways!
- Elementor > Lazyload Youtube Background – enable this unless your video embeds are used in the hero section of your site. Another option, you can enable this but use the lazyload-exclude attributes for your hero embeds.
- WooCommerce > Cache Empty Minicart – enable!
- WooCommerce > Disable Cart Fragments (premium) – I usually disable! It speeds up that annoying WooCommerce admin-ajax call that lags your waterfall reports BUT disables your minicart count (the little number in the cart icon at top of your site). You can disable it on all pages, disable it only on some, or leave it on if 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 > WooCommerce Session Cache (BETA – premium) – disable. It caches users’ shopping items in cart, but doesn’t work perfectly. Site sometimes feels slower with this on and sometimes mixes cart sessions between users. Test carefully if you use it.
- WooCommerce > Ajaxify Prices – only needed if your site shows different prices to different users (like based on location, etc). It lazyloads prices use ajax, after the cached page loads.
- 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 > Use Different Hostname – in case your CDN uses a different hostname for SSL domain version of your assets. I’ve never seen this needed.
- General > SSL CDN Hostname – should probably be empty, as most CDN’s use the same hostname regardless of http or https.
- General > CDN Custom File Types – specify what files (extensions) to cache on CDN. I don’t understand why this is needed, don’t know if it’s a whitelist or what. Test with and without, and see.
- General > Exclude File Types from CDN – exclude files from CDN for various reasons. Maybe because of CDN costs, or because the file is loaded faster (or more reliably) from your server?
- 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.)
- Cloudflare > Cloudflare Auth Method – I guess it depends on which one you have access to.
- Cloudflare > Cloudflare Account Email – fill in your account email.
- Cloudflare > Cloudflare API Key – put in your Cloudflare global API key.
- Cloudflare > Cloudflare Host – put your domain name (without the www).
- 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!)
Hit [SAVE CHANGES], clear cache, and Swift is done setting up!
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 – Other features
You’re welcome to check out the other tools here but make sure you’re careful and make a backup if you don’t know what you’re doing. I’ll go over these in a more advanced guide!
- 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. Can also try regenerating CSS in your theme and other plugins as well.
- Broken visual elements – check “Optimization > General > Fixing invalid HTML”.
- Weird characters/symbols – disable GZIP from caching options.
- 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]. Try disabling “Cache 404 pages”.
- 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. Change your “max_input_vars” to something high (like 5000). You can ask your webhost to help you with it. But either way…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.
- Weird www or non-www URL issues – place the proper htaccess redirects placed. You can do it in Swift’s custom htaccess, or open up your htaccess and put the code at the very top above Swift htaccess code.
- Cache size is HUGE – uncheck “Separate Scripts” and “Separate Styles” option, or better to just not merge them. Don’t cache for logged-in users. Also exclude unnecessary post types.
- Website still won’t load after deleting Swift – if you had issues and want to delete Swift, make sure you delete Swift from plugin directory, also mu-plugins, also remove Swift .htaccess rules. Then run manually trigger WP-cron. I’ve seen instances where Swift prevented WP-cron from running and so many cron jobs were backed up and lagged the server a bit even after delete. Once you’ve triggered WP-cron manually, it can be 5-10 minutes before your site regains useable state.
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! 😀