Enable Caching – Enabled by default. Swift integrates more than 75% of web performance good practices automatically. Even without any of its options activated, the loading time of your website will decrease significantly. Run an enable/disable test with Swift’s default Auto Wizard configuration, and see how much faster your site has become already!
You’ll be able to see the improvement in loading time Swift Performance has achieved just by running Setup Wizard, Autoconfig configuration. If you have advanced knowledge about how the rendering of a website works in the browser, you can start to further optimize your setup based on recommendations from performance testing tools like GTmetrix, Pingdom Tools, or Google Developers PageSpeed Insights—although we think that websites’ scores don’t matter. Concentrate on the real speed of your site and improving it, if needed.
Caching Mode – If rewrites are working on your server you always should use Disk cache with Rewrites, this is the fastest method for serving cache. However sometimes you can’t edit the .htaccess file or the Nginx config so Disk cache with PHP is also available as a fallback. If memcached is installed you can select Memcached with PHP instead of Disk cache with PHP, but again, if available, you should choose the rewrites option. If using NGINX (Swift will work out of the box on NGINX servers, this configuration is not required. It just provides the rules that would otherwise be present in the .htaccess file on Apache servers. If necessary you can copy and paste these rules (You´ll find them in Swift Dashboard under Show Rewrite Rules) into your nginx.conf file.
Early Loader – If Swift have to serve the cache with PHP it will speed up the process. Please note that some requests will be served with PHP even if you choose the Disk with Rewrites caching mode.
Cache Path – If you are using Disk cache, you can specify a cache path. By default it will be /path/to/wp-content/cache. Swift detect and set correct path, after activating on the fly. Check this directory only if cache or prebuild doesn’t work.
Cache Expiry Mode – It is recommended to use Action based mode. Swift will clear the cache if the content was modified (post update, new post, new comment, comment approved, stock changed, etc). However if the site is using nonce or any other thing what can expire, you should choose the Time based expiry mode. Some plugins, eg Gravity forms, use nonce. To avoid issues, you should set cache lifespan to 10 hours or less. After the cache gets cleared, the HTML gets regenerated and references a correct nonce again. Hence, when your WordPress setup (theme, plugins) operates with nonces, the only way to keep them updated on cached pages is to set your Cache Expiry Mode in Swift to a value below 12 hours; 10 hours would be a starting point, but you may have go down to 8 or even less.
This will result in more frequent cache update activity on your server, and therefore more preload processes if Prebuild Cache Automatically is enabled. In case you notice any issues due to high server load, set a higher Cache Expiry Time.
Garbage Collection Interval – How often should check the expired cached pages (in seconds).
Clear Cache on Update Post by Page – It is useful if your site is using for example a WooCommerce shortcode to show products on homepage. Because it is a shortcode homepage cache won’t be cleared automatically if a post/stock/comment was updated, however you can specify pages manually here. Just click on the box and choose the page(s) which should be cleared after update post.
Clear Cache on Update Post by URL – It is useful if your site is using for example a WooCommerce shortcode to show products on homepage. Because it is a shortcode homepage cache won’t be cleared automatically if a post/stock/comment was updated, however you can specify URLs manually here. Use full URLs here.
Enable Caching for logged in users – This feature is great when you have user-specific content on your site. The website will be cached as normal for all visitors that are not logged in, using one set of cache files, and for each logged-in user using a separate cache. Enable Caching for logged in users can be useful when you have a membership website, or similar when an user must login to see content.Please note: all logged in users have a separate cache for every page. It can increase the total cache size, depending on the count of your users and number of pages!
Separate Mobile Device Cache – You can create separate cache for mobile devices, it can be useful if your site not just responsive, but it has a separate mobile theme/layout (eg: AMP). Usually you don’t need this option.
Enable Gzip – If you enable this option it will generate htacess/nginx rules for gzip compression. Compression should be configured on your server as well. GZip is a form of data compression — ie it takes a chunk of data and makes it smaller. The original data can be restored by un-zipping the compressed file. It is relevant to web apps and web sites because the HTTP protocol includes the ability to gzip data that is being sent. This means that when it is in use, your bandwidth costs for serving the site will be lower because people visiting the site will be downloading smaller files. View an example of Swift`s rewrite rules here.
Send 304 Header – A web server sends a HTTP/304 in response to a Conditional Validation request, indicating that the client’s copy of a resource is still valid and that the resource in question was Not Modified since the client cached its copy. Conditional validation enables clients to ensure that they have the latest resources without the performance overhead of the server re-sending all of its resources every time they are used. It is always good to send (it is necessary only for disk/memcached + php, with rewrites it handled by the server) but it can conflict on some hostings that because it is an option at all. 304 means not modified, so the browser knows that it shouldn’t download body of the request.
Cache 404 pages – To avoid caching .txt, .php and other pages will be cached, you need to disable this feature. Those URLs get only cached, if they are a result of a 404 return and cache 404 is enabled.
Enable Dynamic Caching – If you enable this option you can specify cacheable $_GET and $_POST requests. You can read and find out more about this feature here. Note. This feature requires advanced knowledge of website optimization and development. Enabling Dynamic Caching is a highly complex task, while the result may not even make your website load that much faster. Skipping this option might be your best choice unless you’re an experienced web developer who already knows how to handle with resources in general.
Cacheable AJAX Actions – With this option you can cache resource-intensive AJAX requests (eg AJAX search). You should specify the action names here. You can also set cache expiry time for AJAX requests in seconds. For example you can use it to cache custom ajax search or cache WP datatables ajax responses. It´s advanced stuff. If you don´t know how to use this feature, it`s better not to use it.
AJAX Cache Expiry Time – Cache expiry time for AJAX requests in seconds.
Enable Proxy Cache – With this option you can add s-maxage header to force proxies (eg Cloudflare) to cache pages. Cloudflare will cache only those pages which are cached by Swift. So WP-admin and other excluded pages won’t be cached. In general, comments and other dynamic stuff will work when you enable this feature and Cloudflare will cache same as Swift does. If something is not cached by Swift, it won’t be cached by Cloudflare.
Read more about this feature here.
please note: On Cloudflare only Enterprise plan allows to bypass cache by cookies, so by default if you enable this option, logged in users will get cached pages as well (like when you enable Shared Logged in Cache).
Ignore Query String – If you enable this option Swift will ignore query string. It will cache the page even if there is something in query string, and also will serve the cached page if it is already cached. Ignore Query String / Simple: Delivers the same resource to everyone independent of the query string (Note: The Ignore Query String setting only applies to static file extensions. This setting will remove the query string when generating the cache key, so that a request for “style.css?something” will be normalised to just “style.css” when serving from the cache). This feature is available only in Pro version.
Avoid Mixed Content – If your site can be loaded via HTTP and HTTPS as well it can cause mixed content errors. If you enable this option it will remove the protocoll from all resources to avoid it. Use it only on HTTPS sites. Manually finding mixed content can be time consuming, depending on the number of issues you have. The feature works out of the box. This feature is available only in Pro version.
Keep Original Headers – If you are using a plugin which send custom headers you can keep them for the cached version as well. Some security plugins add nosniff response header and some other headers-. With this feature you can keep your original headers. This feature is available only in Pro version.
Case Insensitive URLs – There may be URLs, or parts of URLs, where case doesn’t matter, but identifying these may not be easy. Users should always consider that URLs are case-sensitive. This feature convert those URLs to lower case for caching. This feature is available only in Pro version.
Lazyload elements – Ajaxify feature is designed to speed up page loading times and decrease traffic to your customers and users by only loading the content in view. You can specify CSS selectors (eg: #related-products or .last-comments) to lazyload elements on the page. These elements will be loaded via AJAX after the page loaded. It can be useful for elements which can’t be cached and should be loaded dynamically, like related products, recently view products, most popular posts, recent comments etc.. This feature is available only in Pro version.
In this section you can set Post Types, (Author)Pages, URLs, Content Parts, User Agents, Crawlers, Archive, Feed and Rest URLs which shouldn’t be cached. It is very simple to exclude a page or pages from the cache. Note that Swift Performance automatically excludes cart and checkout pages from most common ecommerce plugins, such as Woocommerce.
Exclude Post Types – Select post types which shouldn’t be cached. Swift will scan on Autoconfig and set most Post Types automatically to exclude from being cached. Just click on the box and choose the post type(s) which shouldn’t be cached.
Exclude Pages – Select pages which shouldn’t be cached. Just click on the box and choose the pages which shouldn’t be cached.
Exclude URLs – URLs which contains that string won’t be cached. Use leading/trailing # for regex.
Swift is using more aggressive optimization/preload functions than any other plugin on the market. That makes it better and faster, but sometimes it means that built for crawling links is a bit too aggressive. Again, remember that other cache plugs also catch up those URLs in the background, so you will never be aware.
When Swift crawled all URLs /Pages, some URLs may be come up, that you feel, it shouldn’t be included in the warmup table. With Swift, you are in full control of your caching engine. You can exclude them or simply ignore. On shared hosting or high resouce consuming websites, we recommend that you remove these URLs manually once. If you want these types of pages not to to be cached add each parameter in the Exclude URLs text field (one per line). eg, you want to exclude following pages which shouldn’t be cached:
Exclude Content Parts – Pages which contains that string won’t be cached. Use leading/trailing # for regex.
Exclude User Agents – User agents which contains that string won’t be cached. Use leading/trailing # for regex. If you have issues with the mobile version of your site being shown to desktop users, or vice versa, make sure you have enabled the option to create a separate cache for mobile devices in Settings->Caching->General: Separate Mobile Device Cache. Nevertheless, if you still have issues you can exclude specific User agents.
Exclude Crawlers – Exclude known crawlers from cache. Prevent Search Engines, such as Yandex or crawlers from visiting cached pages. Best practice is to leave this as website owners, can instruct search engines on how they should crawl a website, by using a robots.txt file. When a search engine crawls a website, it requests the robots.txt file first and then follows the rules within and moreover because Google ranks also on pagespeed so it is important that optimized pages are visited.
Exclude Author Pages – Enable to exclude them from caching.
Exclude Archive – Enable to exclude them from caching. WordPress supports automatic creation of archive pages. This ensures that you don’t have to think about making them by hand. Sadly, these pages tend to only consist of a list of posts based on a category / taxonomy / post type without any further introduction. This means that your visitors are left stranded on a page without much explanation about what they’re looking at. These pages also caching is actually unnecessary.
Exclude REST URLs – To exclude wp-json call URLs you need to enable this. You don’t need these items cached.
Exclude Feed – Enable to exclude them from caching. You don’t need (RSS)Feeds items cached as these files are very lightweight.
Enable Remote Prebuild Cache – Use our API to prebuild cache. It is a fallback option if loopbacks are disabled on the server. If you can use local prebuild it is recommended to leave this option unchecked.
Prebuild Cache Automatically – If this option is enabled, the plugin will prebuild the cache after it has been cleared. It is recommended to use with Optimize Prebuild Only option to achieve the best user experience. This option will use WordPress Cron Events. If default WP Cron is disabled, the plugin will load wp-cron.php in every minute while the plugin admin dashboard is opened. Prevent prebuild when server is busy, or caching only visited pages. Also on some shared hosting enviroments it is best practice not to enable prebuild.
With most cache plugins, when a page is visited for the first time, the page is build into the cache. The first visitor therefore, have to wait a little longer, before the page is fully loaded and served. Swift’s unique prebuild function ensures that a fast and cached page is always present and delivered.
Prebuild Speed – You can limit prebuild speed. It is recommended to use this feature on (limited) shared hosting. You can choose between Slow, Reduced, Moderate and Unlimited.
Discover New Pages – Let Swift to discover new pages for warmup (eg: pagination, plugin-created pages, etc.). Best is to leave it diabled.
Prebuild Author Pages, Prebuild Archive, Prebuild REST URLs and Prebuild Feed – See Exception section above for more explanation about these features. As prebuild can cause high CPU and , best is to leave them disabled.
While Swift is generating cache, the CPU usage can be higher than usual. Read more about best practice here.
Enable Auto Purge – If you enable this option the plugin will purge Varnish cache as well when it clears plugin cache. It is recommended to enable this option if you are using Varnish cache.
Custom Host – If you are using proxy (eg: Cloudflare) you may need this option. You can set here 127.0.0.1 or real IP.
Enable Appcache for Desktop – You can enable Appcache for desktop devices.. With Appcache you can select specific pages (or even the full site), which will be preloaded for the visitor on the first view using browser’s Application Cache. It can dramatically speed up navigation on your site. You can configure Appcache separately for desktop and mobile.
Appcache Mode – Appcache mode can be “Full site” or “Specific pages”. If you select Full site you can specify exceptions, if you select specific pages you can select the pages (or page rules) which should be preloaded and cached with Appcache
Desktop Max Size – Appcache maximum full size on desktop devices. That is the size that the visitor’s browser will download and cache. Default is 100Mb for desktop and 5Mb for mobile devices.
Exclude Pages – You can select pages which shouldn’t be cached with Appcache. This option will be available if you select Full site as Appcache Mode.
Exclude Strings – Cache pages with Appcache only if one of these strings is found in the URL. This option will be available if you select Specific pages as Appcache Mode.
Enable Appcache for Mobile – You can enable Appcache separately for mobile devices. All other options are the same as for desktop.
Note. If you would like to increase Appcache size for mobile devices to more than 5Mb, please note that the browser may will prompt the user for permission to use storage. This limit is undocumented, and highly variable. It is recommended to use the default 5Mb limit for mobile devices.