Full page cache?

[JonLaliberte]

Any thoughts on reducing/deferring session usage (or moving to Ajax for components that require it) to allow for more full page caching (I’m thinking especially edge cache)?
Most users are not logged in, so at a minimum by deferring sessions we can provide a faster experience for them when browsing.

[fballiano]

Hi @JonLaliberte, at the moment I was planning to use my fork of Lesti_FPC for full page cache but I was hoping that, since performance should be very good, we wouldn't even need an FPC, cause they all had their quirks and limitations :-\

session deferring is an interesting concept, but how to do that? cause every form now requires CSRF, which is session based, and we would need to remove dynamic components (cart count) or having hole-punch which loads the session anyway.

but if you have ideas on how to do that we're open to evaluate it for sure!

[JonLaliberte]

Hey @fballiano, my primary goal is performance. This was just one end to that. It would be nice if we could get cached at the edge as that would provide the best possible performance, but we can’t do that with sessions.

I had seen this prior discussion which got me thinking about it: OpenMage/magento-lts#1543

cause every form now requires CSRF, which is session based, and we would need to remove dynamic components (cart count) or having hole-punch which loads the session anyway.

This was my thought as well: If you hole punch the dynamic content, and you’re careful (needs to be inclusive of all modules), you can have CF ignore the session on specific pages (and to be safe force it to bypass the cache on specific paths, for example: /ajax, /checkout, etc).

Maybe it’s not needed though or is better handled some other way.

[fballiano]

@mageaustralia is working on something incredible about this exact topic and here's some explanation: https://demo3.mageaustralia.com.au/blog/maho-cloudflare-storefront

I'm not sure if we'll be able to include all of this in the default theme rather but we've stuff cooking ;-)

[JonLaliberte]

@mageaustralia @fballiano Wow... Color me very impressed and excited for this 😁

I'm not sure if we'll be able to include all of this in the default theme rather but we've stuff cooking ;-)

We'd need to do some heavy modification to any theme, so we'd end up having to use the default/custom theme that supports this to base all of our changes off of anyway.

From @mageaustralia's blog post:

The version is a hash of the product's key attributes (price, stock, name). When the page loads, client-side JavaScript checks:

It seems to me this should include any attributes that are visible on the page? Or does this risk becoming too heavy?

Compare versions - if different, trigger background refresh
Is the idea that the first user/client receives stale data, but then the cache is updated so future users get the fresh data? Or are you actually updating the client's data as well?

Is there fallback if any parts of the Cloudflare infrastructure are down? Not thinking so much about the specific edge cache (if the edge is down, we have to accept that we're down), but what about if workers or kv store are not functional?

[mageaustralia]

As it stands now, the page is stored / cached without the layered attributes, they are instead loaded dynamically via the API. If you view the network console when the page loads you will see how they load in dynamically. The reason is two fold. One is the issue you're stating and the second reason is to prevent bots scraping a million useless URLs on your site ie: all the layered combos. We use Amasty improved Nav that we've extended heavily for landing pages of specific combos of category + attributes. I'd like to bring this concept over at some point in the future but it's a whole other bunch of work and I'm absolutely maxed out at the moment. On the CloudFlare front. Honestly, we have used CloudFlare for 10+ years and I could count on one hand the interruptions of services. With the edge cache, if the workers are down, your user should get the edge cached version and THEN within 150ms, the content should be updated to the latest from the Maho API directly.

…

On Thu, 5 Mar 2026, 4:05 am Jonathan Laliberte, ***@***.***> wrote: @mageaustralia <https://github.com/mageaustralia> @fballiano <https://github.com/fballiano> Wow... Color me very impressed and excited for this 😁 I'm not sure if we'll be able to include all of this in the default theme rather but we've stuff cooking ;-) We'd need to do some heavy modification to any theme, so we'd end up having to use the default/custom theme that supports this to base all of our changes off of anyway. From @mageaustralia <https://github.com/mageaustralia>'s blog post: The version is a hash of the product's key attributes (price, stock, name). When the page loads, client-side JavaScript checks: It seems to me this should include any attributes that are visible on the page? Or does this risk becoming too heavy? Compare versions - if different, trigger background refresh Is the idea that the first user/client receives stale data, but then the cache is updated so future users get the fresh data? Or are you actually updating the client's data as well? Is there fallback if any parts of the Cloudflare infrastructure are down? Not thinking so much about the specific edge cache (if the edge is down, we have to accept that we're down), but what about if workers or kv store are not functional? — Reply to this email directly, view it on GitHub <#608 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAH7QV4OSEPQZFWGJNGZ7K34PBO4DAVCNFSM6AAAAACWFUBWESVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMMBQGAZTENA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[JonLaliberte]

Nice! Yeah, we've been using Cloudflare for a while as well. I've only seen a few instances in their status logs where Workers experience any kind issues which is why I asked.
Edge cache itself has been very reliable though.

Is your plan to contribute any/most/all of this back to the Maho project?

[mageaustralia]

Is your plan to contribute any/most/all of this back to the Maho project?

I've got a PR for all the REST / GraphQL API that the frontend utilises here: #578 It was a massive amount of work in and of itself and Fabrizio is currently backlogged because of the recent spike in interest in Maho. For the Storefront work, I've Open Sourced it here: https://github.com/mageaustralia/maho-storefront and docs are here: https://docs.mageaustralia.com.au/ *A few issues:* - I am not 100% sure yet if it actually fits with Fabrizio's vision for Maho - It's still under heavy development and tied strictly to Cloudflare atm - I need it to fit my needs first and foremost before I worry too much about the needs for Maho or the rest of the community. - I'd like it to be portable across different Edge providers but for now, CF is my target because it's who we use. - I need to wait until the API is confirmed to be merged into core - I'd like to get more Payment modules working with it. - I'm still working out how to handle 3rd party extensions in a modular fashion ie: https://github.com/MahoCommerce/module-braintree ( I have this working now) After that, and talking with Fabrizio I can reassess whether it's a good fit for Maho core but for now, it is open source and can be used by others (though it might be a little rough getting started)

…

On Thu, Mar 5, 2026 at 7:16 AM Jonathan Laliberte ***@***.***> wrote: Nice! Yeah, we've been using Cloudflare for a while as well. I've only seen a few instances in their status logs where Workers experience any kind issues which is why I asked. Edge cache itself has been very reliable though. Is your plan to contribute any/most/all of this back to the Maho project? — Reply to this email directly, view it on GitHub <#608 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAH7QV25X43FGFJ6KNKACVL4PCFKJAVCNFSM6AAAAACWFUBWESVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMMBQGIYDEMA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[mageaustralia]

I'll just add that I've also investigated leveraging much of the same techniques with DaisyUI / UnoCSS / Hotwire Turbo / Stimulus as a standard Maho theme (phtml) to make it more digestible or traditional without the edge complexity. It looks like it will be doable and a large amount of the work can be portable back to a standard .phtml theme. I'd already worked on a DaisyUI theming system before for Maho but feel I have more solidified ideas now. On Thu, Mar 5, 2026 at 7:40 AM Matthew Campbell ***@***.***> wrote:

…

> Is your plan to contribute any/most/all of this back to the Maho project? I've got a PR for all the REST / GraphQL API that the frontend utilises here: #578 It was a massive amount of work in and of itself and Fabrizio is currently backlogged because of the recent spike in interest in Maho. For the Storefront work, I've Open Sourced it here: https://github.com/mageaustralia/maho-storefront and docs are here: https://docs.mageaustralia.com.au/ *A few issues:* - I am not 100% sure yet if it actually fits with Fabrizio's vision for Maho - It's still under heavy development and tied strictly to Cloudflare atm - I need it to fit my needs first and foremost before I worry too much about the needs for Maho or the rest of the community. - I'd like it to be portable across different Edge providers but for now, CF is my target because it's who we use. - I need to wait until the API is confirmed to be merged into core - I'd like to get more Payment modules working with it. - I'm still working out how to handle 3rd party extensions in a modular fashion ie: https://github.com/MahoCommerce/module-braintree ( I have this working now) After that, and talking with Fabrizio I can reassess whether it's a good fit for Maho core but for now, it is open source and can be used by others (though it might be a little rough getting started) On Thu, Mar 5, 2026 at 7:16 AM Jonathan Laliberte < ***@***.***> wrote: > Nice! Yeah, we've been using Cloudflare for a while as well. I've only > seen a few instances in their status logs where Workers experience any kind > issues which is why I asked. > Edge cache itself has been very reliable though. > > Is your plan to contribute any/most/all of this back to the Maho project? > > — > Reply to this email directly, view it on GitHub > <#608 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAH7QV25X43FGFJ6KNKACVL4PCFKJAVCNFSM6AAAAACWFUBWESVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMMBQGIYDEMA> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >

[JonLaliberte]

I didn't realize how recent these developments were!

Originally, I was more focused on speeding up the non-dynamic parts of the site. Even if it were just for guests, that would be a positive benefit to the store (lower TTFB and snappier browsing lower bounce rates which typically increases sales). But, my mind is a bit more open now to speeding up everything 😁 and of course a faster cart, checkout, etc can only help with CVR.

It does seem like a big undertaking to get it working right now though - we'd have to do a full redesign/rewrite of the site - and considering how many custom components we have it could be a lot (many of them are our own at least).

I'll just add that I've also investigated leveraging much of the same
techniques with DaisyUI / UnoCSS / Hotwire Turbo / Stimulus as a standard
Maho theme (phtml) to make it more digestible or traditional without the
edge complexity. It looks like it will be doable and a large amount of the
work can be portable back to a standard .phtml theme. I'd already worked on
a DaisyUI theming system before for Maho but feel I have more solidified
ideas now.

Interesting.
For some background, although I went to school for CS, programming is only a hobby of mine now - I'm a store owner at this point. I dabble still, but unfortunately don't get to spend much time in the code (and when I do, these days, it's in Cursor 🤭).

I was not familiar with any of these frameworks/techniques before this comment to be honest.
This would be a more palatable change I would imagine, but if I understand correctly in regard to edge caching this would still have the same problem we have today (sessions prevent edge cache)?

[mageaustralia]

Hopefully you can see in the demo sites, simply how fast everything is - Also, the 'source' servers are Australian based so if you're in the US / EU, there will be ~180-200ms extra delay on API calls like cart / checkout than if you had a local server in your Zone - regardless, it's still way faster than any M1/M2 cart or checkout IMO.

This would be a more palatable change I would imagine, but if I

understand correctly in regard to edge caching this would still have the same problem we have today (sessions prevent edge cache)? Once we have a full Cart / Checkout API (re: My PR), it kind of opens up a lot of options - because you can cache on the edge and make api calls in the background to update any differences An example is showing the cart Qty - let's say the entire page is cached, you add to cart, go to the next page, it loads from cache but then it makes an api call to get your current cart contents. It's not all that different to how 'hole punching' works with Varnish / FPC, just a slightly different approach. The maho storefront idea was partially because I actually find Magento 1's theming to be really cumbersome, slow and painful - It's a lot of work to create new themes versus working in Shopify - I wanted a way to be able to bring that experience to Maho and create themes and theme concepts much faster without dealing with the XML / phtml layouts pain that is M1's way of doing things. So this was intended to solve many issues - The themes you see on demo2, and demo3 *were all created automatically by AI in around 30-60 minutes *-* including all products, attributes, categories, theme design and imagery - *Demo.mageaustralia uses Maho's core demo products but the rest of the colour scheme and imagery was created by Claude - even the blog post detailing the architecture and the images were all created and added using the API via Claude. They were done to test my theory that I could come up with a component based system that could create quite visually different themes by defining components and colour schemes in json.

…

On Thu, Mar 5, 2026 at 9:47 AM Jonathan Laliberte ***@***.***> wrote: I didn't realize how recent these developments were! Originally, I was more focused on speeding up the non-dynamic parts of the site. Even if it were just for guests, that would be a positive benefit to the store (lower TTFB and snappier browsing lower bounce rates which typically increases sales). But, my mind is a bit more open now to speeding up everything 😁 and of course a faster cart, checkout, etc can only help with CVR. It does seem like a big undertaking to get it working right now though - we'd have to do a full redesign/rewrite of the site - and considering how many custom components we have it could be a lot (many of them are our own at least). I'll just add that I've also investigated leveraging much of the same techniques with DaisyUI / UnoCSS / Hotwire Turbo / Stimulus as a standard Maho theme (phtml) to make it more digestible or traditional without the edge complexity. It looks like it will be doable and a large amount of the work can be portable back to a standard .phtml theme. I'd already worked on a DaisyUI theming system before for Maho but feel I have more solidified ideas now. Interesting. For some background, although I went to school for CS, programming is only a hobby of mine now - I'm a store owner at this point. I dabble still, but unfortunately don't get to spend much time in the code (and when I do, these days, it's in Cursor 🤭). I was not familiar with any of these frameworks/techniques before this comment to be honest. This would be a more palatable change I would imagine, but if I understand correctly in regard to edge caching this would still have the same problem we have today (sessions prevent edge cache)? — Reply to this email directly, view it on GitHub <#608 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAH7QVYF3LQ7PJ67MDSALA34PCXABAVCNFSM6AAAAACWFUBWESVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMMBQGMYDGMA> . You are receiving this because you were mentioned.Message ID: ***@***.***>