It is known that page load time is one of the important aspects of search engine result position. Site speed is what stands between the website and the potential user.
Caching therefore plays an essential role in optimizing websites to deliver high-performance. Not only does it help support faster load times than otherwise possible, but it also helps in reducing latency. The information can be stockpiled at every level right from the original server to intermediate proxies to the browser.
Drupal encompasses numerous tools for caching content that can work for your site exceptionally and it’s important to know what they are and what they do. This blog will elucidate the caching mechanism in Drupal 8.
Drupal 8 Caching Modules
By default, Drupal 8 comes with 2 modules for implementing caching-
- Internal Page Caching:
The Internal Page Caching module when enabled, stores the complete page information even if the user visiting the site hasn’t logged in. Future anonymous visitors will then observe that the same content is loaded extremely fast since the page wasn’t put together from scratch. This module is useful for websites with a lot of unregistered users
- Internal Dynamic Page Cache:
The Internal Dynamic Page Cache module is designed to cache small sections of each page for all users whether they are logged in or not. Whenever the page content is requested by the same or different user, the module can pull in those individual parts to speed up the building of the page on the fly.
Understanding Caching At Different Layers
Caching in Drupal takes place at three separate levels: application, component, and page. Given below is the detailed description of each-
- Application-level Caching
Application-level caching is in-built in Drupal. However, you won’t see it in action until you scrutinize Drupal’s internal code. It is active by default and won’t even show older, cached pages.
The application-level caching in Drupal ensures that the cached pages are separately stored from the site content (which goes into the database). You can’t set this up, except for guiding Drupal where to save cached pages explicitly.
Drupal stores its external and internal data structures efficiently to enhance repeated users’ access when performing application-level caching. This isn’t the information that a site visitor sees in itself but forms a critical factor in constructing any page. The only level of refinements that can be made at this level is improving where this cached information is stored, like using Memcached instead of the database.
- Component-level Caching
Component-level caching works on front-end components such as blocks, panels, and views. For example, you might own a website having dynamic content but a single block remains constant. In fact, you may have the same block widely scattered across dozens of pages. Caching it can deliver improved performances significantly.
Though component-level caching is generally disabled by default, however, you can make it active with some simple configuration changes. You can initiate with identifying blocks, panels, and views on your site that remains the same across to later cache them strenuously. You will notice a strong speedup for authenticated users.
- Page-level Caching
As the name suggests, this page-level caching caches, stores, and delivers the entire page to the user. One of the most effective types of caching, it shows static HTML pages to users to improve site performance almost immeasurably.
Page-level caching gives you enough space to customize where you can use any number of caching servers, including Varnish, or CDNs like CloudFlare to deliver cached pages from servers close to the users’ location.
CDNs help you in bringing your site closer to your users. However, it only works for anonymous users by default. Fortunately, this drives huge traffic to any website.
A typical Drupal application comprises of all the layers mentioned above. However, to better understand the flow and learn how to debug a caching issue, a flowchart is given to illustrate how content is cached at different layers-
Learn more about caching from here-
Cacheability Metadata in Drupal 8. What is it?
Cacheability metadata is used to describe the thing which is rendered with respect to its dynamism. Сaching properties could be applied to any object and one can easily change the default cache settings of these three properties-
- Cache Tags
- Cache Contexts
- Cache Max-Age
- Cache Tags:
Tags are used to nullify cache entries when something on the site undergoes modification. (nullifying or invalidating means that the cache entry won’t get used, and will be reconstructed the next time that piece of content is rendered). Drupal comprises multiple cache tags to explicate all sorts of different scenarios from individual nodes and blocks, to site configuration settings, and menus.
For example, the cache tag ‘node:5’ gets invalidated any time the Drupal content node with ID 5 gets modified.
So, whenever content gets cached which depends on something related to node 5, the cache entry keeps track of that tag; then, saving the node causes that cache entry to get invalidated. This implies that any time you save something in Drupal, a relevant tag gets invalidated.
The tag for the same will look like this-
Syntax : “node:5”
node_list: List cache tags for node entities
- Cache Contexts:
Contexts are quite different from tags. Cache contexts are stored alongside cache entries and are designed to let content vary depending on what circumstances or situation it is showcased in.
For instance, you have a site with users of several different roles, and one block on the site is meant to show content differently depending on what roles the user seeing it has. This can’t be implemented through cache tags alone. However, it won’t be a good idea to leave the block completely uncached, instead, it can have the “user permissions” context applied to it. This way, the block can be cached multiple times- specifically one time for each combination of roles that the users see the block have. This way, an administrator can see something different from an editor who will see something different from a user who has both roles.
- Cache Max-age:
Cache max-age is the last step to handle cache invalidation. You have to simply set the time on how long the content should be cached for. This can vary from 0 seconds (to not cache content at all) to as long as you want.
Presuming that all of the tags and contexts being used are working as intended, this can be put to indefinite (default state in Drupal) since those can cover most scenarios where cached content might need to be created.
Given this, there is still no mechanism that notifies your Drupal site about the change in content, and therefore, no-cache tags can be invalidated and no context is helpful (as the content doesn’t vary by the situations in which it is displayed).
However, if you set a max-age of 3600 on the page, then it will cache its content for up to one hour before automatically invalidating, at which point the next person who views the page would get a brand-new updated version (fresh with new content from the remote service) which would then get cached for another hour. This way, you can leverage all the benefits of caching without causing your site to stop updating itself with content from the remote service.
Summing Up-
Caching lets you retrieve data instantly without having to request it from the source. Given that, it makes up a significant part of website speed optimization. If you want to ease surfing experience for your users on the site, then enable the cache for the same. Drupal 8 has enhanced its caching capabilities considerably.
