In this short presentation, Subhash Yadav of Valuebound has explained about “Caching in Drupal 8.” A cache is a collection of data of the same type stored in a device for future use. Caches are found at every level of a content's journey from the original server to the browser.

1. Drupal 8 Caching
Subhash Yadav
https://www.drupal.org/u/subhashuyadav

2. A cache is a stored copy of a resource so future requests for that
resource can be served faster.
The data stored in a cache might be the result of an earlier
computation, or the duplicate of data stored elsewhere.
Caches are found at every level of a content's journey from the
original server to the browser.
What is cache?

3. Why Caching?
● Faster than recomputing a result or reading from a slower
data store; thus the, more requests can be served from the
cache, the faster the system performs i.e. maximum output
with minimum latency.
● Eases the load of the server
● Improves responsiveness

4. HTTP Headers
HTTP Headers is where caching information is exchanged between the origin
server and cdn, proxies including varnish all the way to the browser.
Example : HTTP/1.x 200 OK
Transfer-Encoding: chunked
Date: Fri, 27 Nov 2017 04:36:25 GMT
Server: LiteSpeed
Connection: close
X-Powered-By: W3 Total Cache/0.8
Expires: Fri, 27 Nov 2017 05:36:25 GMT
Etag: "pub1259380237;gz"
Cache-Control: max-age=3600, public
Content-Type: text/html; charset=UTF-8
Last-Modified: Sat, 28 Nov 2009 03:50:37 GMT
Content-Encoding: gzip
Vary: Accept-Encoding, Cookie, User-Agent

5. The Expires header sets a time in the future
when the content will expire. This header is
probably best used only as a fall back.
Expires

6. A unique hash identifier of the cacheable object that the browser
caches.
Whenever a cached response is requested again, browser checks
with server if the eTag of the response is modified. If response is
not modified server returns 304 not modified else 200 along
with new response & new eTag.
Etag

7. The date-time this cacheable object was last cached.
(Similar to eTag)
Last-modified

8. When a cache receives a request that can be satisfied by a
cached response that has a Vary header field, it must not use
that cached response unless all header fields as nominated
by the Vary header match in both the original (cached)
request and the new request.
This can be useful for serving content dynamically.
Vary

9. Each resource can define its caching policy via the
Cache-Control HTTP header.
Cache-Control directives control who can cache the
response, under which conditions, and for how long.
Cache-Control

10. no-cache: Indicates that the returned response can't be used to satisfy a
subsequent request to the same URL without first checking with the
server if the response has changed.
no-store: It simply disallows the browser and all intermediate caches
from
storing any version of the returned response.
public / private: If the response is marked as "public", then it can be cached, even
if
it has HTTP authentication associated with it, and even when the
response status code isn't normally cacheable.
private marked responses are typically intended for
a single user, so
an intermediate cache is not allowed to cache them but browser can
cache them.
Cache-Control Directives

11. max-age : Configures the maximum age that the content may be cached
before
it must revalidate or re-download the content from the origin server.
This replaces the Expires header for modern browsing.
This option takes its value in seconds with a maximum valid
freshness time of one year (31536000 seconds).
s-maxage : This is very similar to the max-age setting, in that it indicates the
amount of time that the content can be cached.
The difference is that this option is applied only to intermediary
caches.
Cache-Control Directives

12. All things that either are directly renderable or are used to determine
what to render provide cacheability metadata.
Cacheability metadata consists of three properties:
cache tags : For dependencies on data managed by
Drupal, like
entities & configuration.
cache contexts : For variations, i.e. dependencies on the request
context.
cache max-age : For time-sensitive caching, i.e. time dependencies
Cacheability metadata

13. Cache tags provide a declarative way to track which cache items
depend on some data managed by Drupal.
The role of the tags is to identify cache items across multiple bins for
proper invalidation.
In a typical scenario, a user may have modified a node that appears in
two views, three blocks, and on twelve pages. Without cache tags, we
couldn't know which cache items to invalidate. So we'd have to
invalidate everything and sacrifice effectiveness to achieve
correctness. With cache tags we can have both.
Cache Tags

14. Syntax: “Thing:identifier”
Example: node:5 -- cache tag for node entity 5
user:4 -- cache tag for user entity 4
node_list -- list cache tag for node
$tags = array('node:1', 'user:7');
Drupal::cache()->set($cid, $data,
CacheBackendInterface::CACHE_PERMANENT, $tags);
// Invalidate all cache items with certain tags.
DrupalCoreCacheCache::invalidateTags($tags);
Cache Tags

15. ● Cache contexts provide a declarative way to create context-
dependent variations of something that needs to be cached.
● Determines how to vary items according to request.
● Similar to D7 block constants like DRUPAL_NO_CACHE /
DRUPAL_CACHE_PER_ROLE / DRUPAL_CACHE_PER_PAGE,
but with many more options.
● Cache contexts are hierarchical in nature.
Cache Contexts

16. Example : theme -- vary by negotiated theme.
user.roles -- vary by the combination of
roles
$variables['#cache']['contexts'][] = 'url.path';
Cache Contexts

17. Cache max-age
● Cache max-age provides a declarative way to create time-
dependent caches.
● Controls how long an item may be cached by number of seconds.
● 0 means cacheable for zero seconds, i.e. not cacheable
● DrupalCoreCacheCache::PERMANENT means cacheable
forever, i.e. this will only ever be invalidated due to cache tags.
(In other words: ∞, or infinite seconds)

18. ● Varnish is just a web-server in front of origin webserver.
● Also known as a caching HTTP reverse proxy.
● It can be used with cache tags to make cache invalidation easy.
● Every request to the origin web-server goes through varnish.
● If varnish doesn’t have a request cached, the request is passed to
the backend. Upon response, varnish reads the response
headers and if response is cacheable varnish caches the
response for next similar requests.
Varnish cache

19. ● Varnish will only cache resources that are requested through an
idempotent HTTP verb, which are the verbs that do not change
the state of the resources.
● HTTP verbs that Varnish can handle: GET, HEAD
● PUT, POST, DELETE, TRACE, OPTIONS cannot be cached by
the varnish.
● Varnish default cache setting is 120 sec (2 min).
Varnish cache

20. You need to do three things to make sure Varnish works well with the
cache tags generated by Drupal:
● Update your Varnish VCL so it handles BAN requests properly.
Location : /etc/default/varnish/default.vcl
http://foshttpcache.readthedocs.io/en/stable/varnish-
configuration.html#tagging
Varnish cache

21. Varnish cache
● Send a cache tags header:
Drupal's Purge module automatically configures
Purge-Cache-Tags headers.
● Send a BAN request when content or configuration changes:
Add an HTTP Purger using Generic HTTP Purger module.
Configure a cron job to process the Purge queue.

22. Thank you