I want to configure my Magento 2 site to use section.io and Varnish Cache. What steps do I need to take for this implementation?
How Magento 2 Deployment Works
A few things to keep in mind for Magento 2 deployment:
- Magento 2 needs to send Varnish (via section.io) correct cache-control response headers so that Varnish knows to cache a response, otherwise there will be long TTFB (Time to First Byte - how long it takes for the HTML document to be delivered to the browser).
- What Magento 2 sends to Varnish is different to what Varnish sends to the browser because Varnish overwrites the cache-control response headers just before it sends a response to the browser.
- Magento 2 sends purge requests to Varnish (via section.io) whenever products or pricing are updated. If there are regular cron jobs or updates happening in Magento 2 this can cause the Varnish (via section.io) cache to be cleared regularly which results in poor performance (and cache misses for requests).
Go Live Steps
To go live on Magento 2 with section.io its important to ensure several steps have been completed:
Install our Magento 2 extension (Complete account setup, Platform setup, HTTPS setup, DNS change): https://www.section.io/docs/magento/#magento-2-extension
Switch Magento 2 from FPC (developer mode) to Production mode (Varnish). Complete only up to step four: http://devdocs.magento.com/guides/v2.0/config-guide/varnish/config-varnish-magento.html
Confirm Magento 2 is sending the correct Cache-Control response headers for HTML documents (such as the homepage). Follow the Magento 2 guidelines to confirm appropriate cache control responses: http://devdocs.magento.com/guides/v2.0/config-guide/varnish/config-varnish-final.html#config-varnish-final-verify-headers
Troubleshooting Cache-Control Headers
If Magento 2 is sending incorrect response headers (such as “Cache-Control:max-age=0, must-revalidate, no-cache, no-store”), there are several actions you can take to attempt to resolve:
Codebase: Check your Magento 2 codebase for layout xml configuration issues
- If any block is marked: cacheable=“false” then Magento 2 will not send appropriate cache-control responses.
- If for example the footer layout block is marked like the above, then no pages will be cached in Varnish
- To review this scan your codebase for any blocks with cacheable=“false” attribute
Headers: Check Apache / nginx isn’t overwriting cache-control response headers (for text/html documents)
- Check all Apache configuration files (*.conf, .htaccess etc)
- Look inside Apache files for the text “Expires” to find and review all usage of mod expires (http://httpd.apache.org/docs/current/mod/mod_expires.html)
- Look inside Apache files for text “Header” to find and review all usage of mod header (http://httpd.apache.org/docs/current/mod/mod_headers.html)
- Check all nginx configuration for settings that overwrite response headers
Cache: Validate the Magento cache: http://devdocs.magento.com/guides/v2.0/config-guide/varnish/config-varnish-final.html#config-varnish-final-verify-cache
Troubleshooting Vary Response Headers
If there are problems after the above steps have been resolved, review “Vary” response headers from Magento 2:
- It is important to understand the Vary response header being sent from Magento 2 to Varnish (via section.io). This is a different than the response header being sent from Varnish (via section.io) to the browser.
- A Vary response header with this value: “Vary:Accept-Encoding,User-Agent” will cause Varnish (section.io) to split its cache by User-Agent. This will result in poor cache hit rate because a user on a desktop Chrome (51) and a user on a desktop Chrome (52) will not be served the same page from cache. Instead the cache will MISS until there is the exact same browser version making requests.
- Recommend only having “Accept-Encoding” in the Vary response header - Either remove config inside Apache/nginx that is adding Vary “User-Agent” or add additional configuration inside Apache/nginx to set the Vary response header to Vary: Accept-Encoding.