Customer dataLayer push cached (wp-rocket)

Hi,

Thanks for this report.

Yes, I am aware of this issue but ’til now I did not had any better idea as to load the datalayer in an ajax call. The problem with this is that this will be another HTTP request during page load and usually people using WP Rocket or similar plugins want to load the site as fast as possible. Adding another request will go into the opposite direction.

The best solution would be is WP rocket would implement some sort of “do not touch this part” feature which would allow others to mark parts of the page as dynamic.

But I guess it should be a simple plugin option which can be enabled if someone can accept that this will add an extra request on each page load. Do you think this would worth? I mean would you use this even if you know the cons as well?

Hi.

I think we would use this if it were available, even though it would be one more request. to explain our use case:

With no page caching we typically have 1.2 – 1.8 second page generation, wp-rocket reduces this around 100-400ms (but a bit variable, sometimes longer).

We have implemented one post-load ajax request for mini-cart content + geoloate for the same reason we are discussing, so that the page is independent of the visitor and the same cached version can be served to all.

The post-load ajax request takes around 500ms, but is fired when the page is loaded, limiting its impact on performance metrics (important this year with Core Web Vitals).

Additionally, we are using wp-rocket’s delay execution facility so that GTM, a dozen other trackers and some other scripts aren’t executed until there is some interaction from the user (move/scroll/click/key). Perhaps not for everyone but it’s working for us, the performance gain is significant, particularly in google’s strict CWV assessment.

I expect I am underestimating the amount & complexity of data gtm4wp collects and presents, but.. If GTM4WP could load dynamic data in an ajax request I think we would use it. If the output was available through a do_action or do_shortcode that would give a little extra versaility, we could include it in our existing single ajax call.

Not sure if that helps, or if I’m missing some key problem of the issue…

Thanks
G

Perhaps also worth mentioning that /cart /checkout /order-received are typically all excluded from page caching, so transaction tracking data can still be generated with the page as normal, it’s just that user & cart items payload on all other pages that we’ve been having trouble with.

..and while I’m here, including a hashed version of the user’s email address in the payload would be really handy, required by some trackers for privacy/anonymity (eg. fbevents, pinterest). If in the datalayer it can be picked up directly in gtm for embedding these through tags.

Hi @monomatic,

Thanks for the very detailed explanation.
I am just finishing v1.14, I can not add this to the next version but I will definitely look at a solution after that.