Given the choice, we'd recommend Redis.
If every visitor to your site is allowed to see the exact same content, regardless of login status, session, cookies, etc, then static caching is the way to go. It completely bypasses ExpressionEngine and delivers the fastest page load times. In some cases you can get < 0.10 second response times or faster.
If your site heavily relies on member logins, dynamic data, or information that is unique to each visitor, then fragment caching is the way to go. For example, if someone logs in to your site and you display their username or profile icon indicating they are logged in, or if you are selling a product and have a checkout page that is unique to the user, then you want fragment caching. You can wrap large portions of your content in a fragment tag, then use the escape and pre-escape tags for the dynamic content. In the case of a store where you are selling products, you could use static caching for the product pages, then add an URL Ignore to ignore the /checkout or /cart sections of the site.
The Static driver saves all items as files on your web server, which works great for a single web server, and if Redis is not available to you. However, if you have multiple web servers, it is recommended to use Redis with Static enabled. This is very similar to Static caching where the entire contents of your pages are saved in Redis, but is better for multiple server enviroments because each server is using the same cache storage. Since the Static driver saves files to the server, you will have multiple instances of the same cached item. For example, if Jane comes to your site, and the load balancer sends her to server A, then John comes to your site and is sent to server B, John will not see the cached page that was created for Jane. Cache clearing also becomes more difficult because you will need to login to the control panel on each server to clear cache items.
Yes, absolutely. The embed tag will be parsed and cached as part of the fragment content.
Yes you can, but you must add all the query string keys, in this case
speedy_query_cache_whitelistconfig option. For example:
$config['speedy_query_cache_whitelist'] = [
site.com?category=fruit&utm_referrer=SomeVendor, then you will end up with the same page content cached twice. Bots and evil people also scan websites for vulnerabilities using query string parameters. If you pay attention to your server logs, you'll probably see a lot of requests to bogus pages. Now imagine every one of those bogus requests get cached separately, even though the content of each page is identical. For this reason, whitelisting query string parameters is the preferred and supported route. This method has been tested and proven based on over 2 years of use in production.