The only benefit you could see from this
The only benefit you could see from this would be from delaying the loading of GTM until after consent or something like that which is likely to break GTM rather than improve performance.
15 Replies
Yes I know about the custom HTML module, so no issues with that in particular.
So to check if I understand this correctly, I won't see any bit of performance improved from loading GTM through Zaraz? 😦
My goal ideally was to improve at least a bit the web vitals, GTM is bloated af sadly
And last but not least, thanks for the response!
I'm not a Cloudflare person btw. Just someone using Zaraz on a bunch of sites.
But yes there's no way for Zaraz to improve the performance of GTM because it's not emulating the GTM JS like it is for the already integrated services like HubSpot.
Another bit of info in case it's useful, I don't need to delay GTM after a consent or anything like that. It will load everywhere
I was thinking that at least though Zaraz I could free the main thread a bit
Zaraz improves performance by shifting the processing of tracking and analytics services into Cloudflare workers instead of on the users browser.
It can only do this for services which it has a Cloudflare worker implementation (referred to as a managed component) of the JS library.
I'm not sure how you expect Zaraz to shift the processing of GTM out of the main thread?
Zaraz has no integration with GTM at all at present so the only way to "integrate" it with Zaraz is to load it through a custom html element. This is virtually the same as you just putting the html for the GTM tag directly into your HTML code yourself.
If you want to move GTM out of the main thread you can look into a tool called partytown
It has a GTM integration and is designed to do exactly what you want. It shifts third party services out of the main thread.
However. it has a big caveat. You may find your GTM scripts don't work as expected when run through partytown because scripts that expect to be running in the main thread are not happy when they are run in a worker.
You can read more about the issues directly on the partytown website. It runs through all the potential issues with this approach
Yeah I already checked partytown, but sadly it doesn't support NextJS with its appdir, that's the exact framework we are using right now. Bad luck this time there.
You pointed a couple of good stuff in your messages so thank you!
My wrong thought I guess was to think that loading GTM like at the DNS level though Zaraz could improve something related to web vitals.
I will wait for partytown or something else to support nextjs and its appdir to see if I could improve something there. It's not a metter or life or death but for sure there's room for improvement in performance
Zaraz wouldn't/isn't able to mess with anything DNS related on GTM.
I haven't used nextjs but partytown have instructions for loading partytown within nextjs on their website.
Yes but there's a catch, like almost everything in tech 😂 . In the partytown's website you will see an example using the nextjs pages structure, and in the Vercel's website, they say this (image and link below):
https://nextjs.org/docs/pages/building-your-application/optimizing/scripts#offloading-scripts-to-a-web-worker-experimental
Optimizing: Scripts | Next.js
Optimize 3rd party scripts with the built-in Script component.
So mostly sure I will need to wait a bit untill this is somewhat stable
You will likely be waiting a fair chunk of time tbh. Equivalently I'm not really sure you need nextjs and partytown to be integrated to do what you are trying to do. You aren't trying to move nextjs to web workers. All you want to do is move GTM. I don't see why you couldn't just load partytown outside of next and include gtm. But then again I am not a nextjs user so I may be missing something there.
Anyways I will do some tests with partytown, I'm mostly reading their docs for this usecase mostly.
Hope it works, and if not I will learn a couple of things in the way
But I would really be looking at how you migrate what's in your GTM into Zaraz to best improve your site.
That would be the ideal case, we agree there. But for timing and priorities I cannot take the time to dive into our GTM (I'm not nearly a regular gtm user) to see what's there, how I can migrate individually the pieces to Zaraz, etc.
And most important, at this point, performance isn't an issue luckily 🤞🏾
But I migrated our Hubspot chat widget to zaraz in half an hour and it worked like a charm, so good for Zaraz 👏🏾
If you are worried about core web vitals then performance is an issue?
As far as the performance don't affect the SEO, we haven't an issue. And at this moment we haven't seen the SEO affected. Web vitals are saying our performance is around 72-75, so we are ok in agreement with the client
Their pages are kinda huge also, so we cannot do magic, but both parts (client and us) are happy with the results
Accesibility and SEO scores 100 in web vitals
It's debatable how much core web vitals affects SEO.
Realistically though one of the major benefits is simply browser performance for the end user. People on lower performance devices like older phones can end up with really laggy experiences with sites with poor js performance.
Core web vitals can be an indicator of this to some extent
I would say though you should look at the real user data in the Crux and ideally through Cloudflare Observatory rather than relying on the lighthouse tests