Caching at the Edge: CDNs for everyone
Drupal 8 has comprehensive knowledge about the cacheability of the things it renders. This opens new doors. Did you know Drupal 8 will be able to cache everything at the edge?
For sites with many mobile users (high latency due to network), global audiences (high latency due to distance) and performance-sensitive sites (e-commerce), Drupal 8 will be a huge leap forward.
We’ll be showing how easy and powerful it is using the CloudFlare and Fastly CDNs.
Cache tags
Instantaneous purging of all (and only!) the affected pages when an article is updated. No more manual purging by content editors. No more fiddling with URLs to purge. It all just works. Optimally.
Cache anonymous pages without any effort. On your own reverse proxy, and on many CDNs — thanks to standardized configuration.
This sounds nice, but that’s just the anonymous user case. What about authenticated users?
Cache contexts
The typical example: a shopping site, users categorized in groups according to interests, and a shopping cart.
Automatic caching of the entire page, minus the shopping cart, on the edge. Reused across all users in the same group. And, if the CDN supports it, even the shopping cart can be cached on the edge (and be kept up-to-date thanks to cache tags). Otherwise only thatneeds to talk to the origin (via AJAX, for example).
Cache authenticated pages without any effort. On your own reverse proxy, and on some CDNs — thanks to standardized configuration.
Goals
- The caching concepts
- Demos
- BigPipe, ESI, hybrid rendering strategies
- A peek at the future: ServiceWorker
Comments
I was inspired by your Drupal CDN module in D7, and I have written a CDN (not a module), using Nginx with HTTP/2, GeoDNS and Docker (with less than 20 lines of code). I have tested this CDN with Linode & DigitalOcean in the past one year and half, average 4-16TB traffic per month. It works very well and saved A LOT of money.
I am looking forward to releasing it as an open source project, but I need to do more work to glue a few parts together. The idea is that a normal user can just do a few clicks (on Linode, DigitalOcean or AWS) to deploy a CDN node or clusters for a website.
What I hope to learn is how to support D8 cache tags and context as CDN provider/software? Can you please point me to the direction?
Drupal 8’s responses have an
X-Drupal-Cache-Tagsheader, which has a space-delimited list of strings. That’s how a CDN (or any reverse proxy) can figure out which responses should be invalidated when a tag is invalidated.See:
Hello Wim,
I have installed the Fastly module for Drupal 8. It is working perfectly for anonymous users, but I noticed when I try to log in, it redirects me to my own server, rather than using Fastly.
Upon further research, according to this video here: DrupalCon Barcelona 2015: Caching at the Edge: CDNs for everyone we need to give fastly a custom VCL file in order for authenticated caching to work.
I am currently not familiar with Varnish, so I wouldn’t know how to make a proper VCL file. Do you mind sharing the authenticated user VCL file? or no such file applies to all Drupal 8 sites and they need to be customized depending on the site?
If the latter, where can I learn about making this authenticated user VCL file?
Thanks for your time.
Please create a bug report: https://www.drupal.org/node/add/project-issue/fastly — I’m sure they’ll be eager to fix that!
Hi Wim, this is great but one question. What’s the best solution for fast page-load times for authenticated users in D7? Everything seems to be better in D8, but what about people like me who can’t migrate because of crucial contrib modules which aren’t ported yet?
There is no single answer. It depends on your site. It depends on the current front-end & back-end performance, on the architecture, the audience (geographic distribution, most commonly used browsers), and so on.
There are plenty of blog posts and modules related to performance in Drupal 7. See all modules for Drupal 7!
Hi Wim. Very impressed with the caching metadata strategy for Drupal 8+. But I’ve searched far and wide for information on how the cache contexts work when there’s a CDN involved but with no success. Could you explain how this is expected to work? The only flow I can picture in my head that would work would be if Drupal used the vary header in its response to let the CDN know the cache context, but as far as I know many CDNs (even big ones like Cloudflare) don’t use the vary header as part of their caching process so I don’t see how it could work.
Or maybe that’s the answer? Do cache contexts only work with CDNs that support use of the Vary header?
Thanks again for your work on this.
CDNs (and reverse proxies such as Varnish) are typically used for anonymous responses only.
It is possible to make a CDN (or a reverse proxy) aware of cache contexts (e.g. logged in or not, user role, country — you name it), but it inevitably requires custom code and custom integration with the CDN.
Entry-level CDN plans do not support this. Factor in the custom code you need to make this happen and … this is an expensive solution. Fortunately it is rather powerful too.
But truth be told, for cases like these, you better make sure ahead of time that you’ll have decent cache hit ratios, otherwise it may just not be worth it. You’re likely better off with using your CDN as a TLS terminator and have it keep a connection alive with your origin.
I know that Fabian Franz has done it once before, if you still want this :)