Magento 2: why we use cache mechanism at a block level?

Question

I have a doubt that I see some cache codes in layout xml like below

 <referenceContainer name="store.menu">
            <block class="Vendor\Megamenu\Block\Megamenu"
                name="megamenu"
                template="Vendor_Megamenu::Vendor/Megamenu/megamenu.phtml"
                before="-" ttl="3600">
                 <arguments>
                    <argument name="cache_lifetime" xsi:type="number">3600</argument>
                </arguments>
             </block>
        </referenceContainer>

So I do not define cache at block level so Magento 2 Full page mechanism will get that block in cache automatically ,so My question is if Magento 2 already do full page in cache blocks so why we define block level cache ?

Answer 1

According to Wikipedia, the cache is a component that stores data, so future requests for that data can be served faster.

In Magento 2, a full-page cache module stores the entire HTML code of a generated page in the cache storage. As storage, Magento by default uses File cache or Varnish cache.

When your store visitor opens any page in the browser, his or her request goes to the Magento 2 cache system:

• If the requested page is inside cache storage, it is quickly returned to the visitor. The speed of such an operation is very high.

• If the requested page is not present in the cache storage yet, Magento will generate this page, add it to the cache storage, and return it to a customer. The speed of such an operation is much lower.

We can see that if a page is served from the cache, Magento sends a response very fast. If a page is not in the cache - the response is slow.

The correct work of the cache system directly affects the store speed. As you know, the speed influences the store's performance in Google search results and the conversion of store visitors into buyers.

Magento 2 Page Cache greatly improves the speed of the store. Your store should be correctly developed and use ‘cache-friendly’ extensions to use all the potential of the Magento cache system. Don’t forget that the store speed may affect your Google search results.

The cache system is extremely relevant and necessary, and Magento 2 speed optimization is a very important task.

Note: Varnish cache is ultra-fast and recommended for any size store, but it requires additional steps to instal and configure.

UPDATE
In the layout XML file we do not get all the blocks from the cache. There are some blocks in which the data shows. So that changes when you change the data block is shown. This type of block is essential which is why magento determines the cache at the block level.

let's assume we have created one block and this block is cacheable. When the first time page loads this html is shown and stored in cache. when next time reload this page block comes from cache. so your any updates or changes are not reflected. That's why Magento uses cache at the block level because some blocks are always shown correctly and update information on the frontend.

Answer 2

FPC

By default in Magento 2 cache lifetime fo public content is set to 86400 seconds (1 day). This means all public cache content will be invalidated after this period. It is called as Time To Live (TTL).

However, FPC also allows to set a different TTL for a block if required. This can be done in the layout XML by setting a ttl attribute (value in seconds).

TTL

Whenever FPC detects a TTL value for the block, it wraps it inside an Edge Side Include (ESI) tag and requests this block in a separate request. This will work only if the caching application is set to Varnish.

e.g. In DOM it will appear something as below

<esi:include src="http://domain.com/rb-ee/page_cache/block/esi/blocks/%5B%22catalog.topnav%22%5D/handles/WyJkZWZhdWx0IiwiY21zX2luZGV4X2luZGV4IiwiY21zX3BhZ2VfdmlldyJd/"></esi:include>

The esi wrapping occurs in below Observer

vendor/magento/module-page-cache/Observer/ProcessLayoutRenderElement.php

Drawback:

• Varnish does not support ESI over HTTPS. So ESI will work only for pages served over HTTP only.
• Usage of too many ESIs is discouraged as it may lead to performance issues

e.g. Refer file vendor/magento/module-theme/view/frontend/layout/default.xml

<block class="Magento\Theme\Block\Html\Topmenu" name="catalog.topnav" template="Magento_Theme::html/topmenu.phtml" ttl="3600" before="-"/>

So here the entire page will be cached for the default TTL time of 86400 seconds (1 day), but as the top menu has a shorter TTL of 3600 seconds it will expire many times during the day and will be requested again.

Cache Lifetime

You can set a different cache lifetime for a particular block using cache_lifetime in layout XML.

<block class="your_block">
    <arguments>
        <argument name="cache_lifetime" xsi:type="number">3600</argument>
    </arguments>
</block>

For this to work, your block class needs to implement the IdentityInterface and a getIdentities method, which must return a unique identifier.

e.g. Below is the example of how it is handled for CMS static blocks

<?php

namespace Magento\Cms\Block;

use Magento\Framework\View\Element\AbstractBlock;

/**
 * Cms block content block
 */
class Block extends AbstractBlock implements \Magento\Framework\DataObject\IdentityInterface
{
    ...
    public function getIdentities()
    {
        return [\Magento\Cms\Model\Block::CACHE_TAG . '_' . $this->getBlockId()];
    }
    ...
}

The \Magento\Cms\Model\Block::CACHE_TAG constant is defined as 'cms_b'. So a CMS static block having entity id of 3, the generated cache tag will be 'cms_b_3'.

The getIdentities method can return as many tags as required, for e.g. on category page it will return a tag for the category (e.g. 'catalog_category_6'), and also return several tags for child products (e.g. 'catalog_product_1').

For a particular page, FPC combines all the block tags from the layout, and then adds them to the response in a custom HTTP header: X-Magento-Tags

With the FPC pages now associated with one or several cache tags, the cache invalidation becomes a process of identifying the necessary tags and purging the associated content using observer events.

For the built-in cache these are configured in the Magento_PageCache module.

For the Varnish cache the configuration and observers are in Magento_CacheInvalidate module.