Here goes:
- The built in caching with Trellis is a “micro-cache” as apposed to a long-term/duration cache. The default cache of 30 seconds is exactly that, a cache that is valid for 30 seconds. Yes, this would generally be geared towards handling a large volume of concurrent users. From some benchmarking, I’ve had found that a $5 DO server can handle around 1,000 concurrent users with a fairly average WordPress site (very scientific measurement).
- Unless you had some very specific requirements, probably not. If you have a low volume of visitors, the FastCGI cache will still work. If you visit a page and the cache has expired, you will still be served the cached content and the cache will be rebuild in the background for the next visitor. You can observe this by visiting a Trellis-based site with cache enabled and looking at the response headers. You should see either,
fastcgi-cache: HIT
, ‘MISS’ orEXPIRED
. The Roots stack is pretty amazingly optimised, so between the great performance you get out of the server from Trellis and the FastCGI cache, you should be all good on the perf front, even if you miss the cache. - Yes, gzip is enabled. Again, you can check the headers – you should see
content-encoding: gzip
- Only thing I would recommend is figuring out a good image optimisation strategy for images uploaded through WordPress (theme images will be optimised by Sage) and setting an expiry date for various file types (Help setting expiry date for static resources (images) in Trellis?).
Also, worth noting that if you enable SSL, you will also serve assets concurrnently via HTTP/2. Demo and more info: https://http2.akamai.com/demo.