Just remember not to use this solution when you want to display user-specific data – generating a separate cache for every user doesn’t seem reasonable. All this while still using the same URL and without any URL parameters hacks. It means that by controlling the value of this cookie you can show one version of a page to one group of your customers and a second one to another group. It is one of the main factors that take part in resolving which page FPC should return to a user.
If you want to display different versions of a page to different user groups then you can use the X-Magento-Vary cookie. …however, sometimes you need to punch (through) him X-Magento-Vary
But fear not, there are ways to work around such issues. If you mark any block (even one that’s being used only on a single page) as non-cacheable, nothing at all is going to be cached since default.xml applies to layouts on every page. Mind that the same thing applies to default.xml. After all, FPC returns a complete generated site and cannot deliver 80% of static HTML and then somehow fetch missing blocks from Magento. However, it’s going to make the whole page related to such layout change non-cacheable. This is great but can be a bit limiting when it comes to situations in which you want to introduce some customizations that should be different for different customers.Īt first, marking such elements as non-cacheable could seem like a good enough solution.
MAGENTO 2 PRIVATE CACHE FULL
In summary, full page cache serves the visitors a pre-generated version of the site, meaning that Magento itself doesn’t have to generate HTML but it can be instantly served by FPC instead. One of the best ways to ensure best possible loading times for the visitors is to use full page cache – preferably Varnish – but even disk cache speeds up the experience by orders of magnitude. Magento is and has always been a bit slow and resource-intensive application. Full Page Cache hole punching in Magento 2 FPC is your friend, not your enemy…
0 kommentar(er)
