Launch HN: Zaraz (YC W20) – Use third-party tools without slowing your website
Before we started this we worked on opposite sides of this battle for third-party inclusion: Yair was working for the folks asking to implement just-one-more analytics tool, while Yo'av was a developer trying (and often failing) to push back. Avoiding bloat to begin with would be preferable, but anyone working for even a medium-sized company knows how hard that is - usually when a higher up agrees to try or add a new tool, resistance is futile. Hence the question becomes, can you do it without harming your performance?
The average US top 5,000 website loads 22 different third-party tools - analytics, customer success, marketing and whatnot. We wrote a bot that scanned these websites and discovered that third-parties account for 40% of their “Time to Interactive”, and other metrics like TBT, FCP, FID and CLS were hurt in a similar way. From the user perspective, the page usually behaves exactly the same without these tools (...except 40% faster).
These new metrics are becoming more popular for two reasons. Firstly, users actually feel them - unlike events such as "DOMContentLoad" & "Load" that can be triggered long before the user can actually do anything, these metrics provide a much better proxy to the real user experience. Secondly, with Google soon penalizing slow websites, they're becoming more and more important for SEO. We see the growing popularity of these metrics as a good thing. We want a faster web.
Nowadays, the most common way to integrate a third-party into your website is either to just paste its `<script>` snippet somewhere in your code, or use some "Tag Management" software (awful name!) like Google Tag Manager, Tealium, or even a tool like Segment. All these options pretty much come with the same cost - everything loads by default together with your page, and users just have to wait and wait. If all this slowness doesn't feel so bad on your devices now, remember that much of the world accesses the internet through devices that are probably a lot slower than yours.
We built Zaraz to be a performance-first third-party manager. Each tool is different, but the concept is to run whatever we can on our backend instead of in the browser, leaving it to focus on loading your website. While other solutions serve all your visitors with the same script and then evaluate it in the browser (should we run this conversion pixel? Should we load this analytics tool?) - we do this on our backend. But the real magic is that we created an environment living inside a Cloudflare Worker, that executes the actual third-party scripts instead of having them run in the browser. Google Analytics, Reddit conversion pixel, LinkedIn Insight, you name it - we’re turning all those things into miniature server-side applications that your visitors’ browsers need not to worry about. If a certain tool still needs to fire a request from the browser (eg. it needs to set a cookie), only the resulting URL from evaluating its script will be sent back to the user browser. It’s a server side environment executing third-party code, that you have 100% control over. When we measure the speed of a website optimized with Zaraz, third-parties have close to zero effect on it, because the browser almost does nothing.
We are already serving a few customers in production, and we’re seeing huge improvements in speed (and revenues!) with all of them. Zaraz is probably the easiest way you can make your website faster, today (try our analyzer to see how we can improve your website: https://zaraz.com/analyze). Aside from performance, s...
85 comments
[ 4.3 ms ] story [ 49.7 ms ] threadMany of the 3rd party tools described are installed specifically to improve UX and conversion rate - eg measure user behavior, add a chatbot, etc.
And yet these 3rd party tools are unquestionably the largest deficit to load time plus even worse have huge variability.
- - -
Pulling a bit of a copy paste from a previous recent thread but from a "Why, who cares" perspective website (and app) speed are highly correlated with conversion and engagement ->
Google's headline research on the subject says "Improving your load time by 0.1s can boost conversion rates by 8%."
Some add'l data, sourced by Neilsen Group below:
- Google found that increasing the load time of its SERPs by half a second resulted in a 20% higher bounce rate.
- Google found 53% of mobile visits ended if a page took longer than 3 seconds to load.
- Akamai aggregated data from 17 retailers (7 billion pageviews) and found that conversion rates were highest for pages that loaded in less than 2 seconds; longer load times correlated with 50% drops in conversion rates and increased bounce rates, especially for mobile visitors.
- BBC found that for every extra second of page load time, 10% of users will leave.
Here's the best three simple resource illustrating objective third party results from increasing site speed:
- https://blog.hubspot.com/marketing/page-load-time-conversion...
- https://wpostats.com/
- https://www.cloudflare.com/learning/performance/more/website...
Here is a more compelling deeper look from a leader in the UX space:
- https://www.nngroup.com/articles/the-need-for-speed/
Here's a really well written article about how to PROVE to the powers that be that site speed is worth testing:
https://web.dev/site-speed-and-business-metrics/
- - - - -
Very excited about this startup, saw on Twitter yesterday and instantly reached out - look forward to testing.
For me, this is the kind of "Duhhhh, why didn't I think of that?" idea. I'm sure a challenge will be getting buy-in early enough, since more established code-bases won't make a switch like this casually. But if you're able to prove the value (like Segment) to early-stage products, I'm sure the stickiness and LTV will be super-duper high.
Congrats! Really great idea!
We've built a (soon-to-be-completely-)automated process of converting Google Tag Manager containers to Zaraz, and that helps a lot with convincing customers because everything Just Works without them needing to do anything (we also hook to their dataLayer events). For other tools it's still a work in progress, but in general we convert whatever stack a customer has to Zaraz as part of the onboarding process. Honestly that's one main reason why we don't yet offer a free tier.
This would naturally cause bugs due to our assumptions. So centralizing this logic, I think, could have a direct correlation to revenue.
eg. Stripe JS getting blocked, without us realizing it was for a small % of users.
I do analytics, and would love to have tools available to help customers not load the 200th tag into GTM. I don't think many customers actually want a bloated container, but their marketing team needs a new tag now and they don't have the bandwidth to do proper maintenance. Having a tool I could recommend would be beneficial.
Useful features would be ones for maintaining tags long-term, especially where tagging is done by multiple teams. E.g. error reporting that certain tags report 404's from the vendor because they are malformed, or haven't been fired since June of 2016 because they're for a page that was redesigned.
But more importantly, Cloud Load is only one out of many things we do. A library of facades for your widgets, firing conversion pixels together with the page.unload() event, evaluating which tools should be loaded on our backend instead of in the browser - all these are much outside the scope of GTM, server-side or client-side. We think they're invaluable because at the end of the day, many tools can't be loaded completely from the server. Everything that uses HTTP cookies or is interacting with the DOM would eventually needs to load in the page.
As for long-term maintain tags - since our bundling feature actually sends HTTP requests to your third-parties, we know when they give a 404. We're working on adding the "last fired" date to the dashboard too. Stay tuned! :)
Not so long ago I side-project fassttt.com and thought the biggest issues are server-side, with bad images and improper caching. Ended up creating a complete minifier/compressor/cdn-enabler.
I since realized the problems are mostly client-side. Cumbersome styling framework and JS rendering engines that are dynamic and VERY hard to optimize.
BTW, if people only care about site-speed score, see https://nitropack.io/ which almost always give you a 100 score.
Another option: only delay the scripts the first time user has landed on your page
I think the single script embed is a good path (much better than asking people to change DNS, remove scripts or such). Maybe you can optimize other areas using JS (like images).
We'd definitely be looking to optimizing other areas too, though honestly our approach was more to get rid of as much as client-side JS as possible. There are so many other tools that will help your do your first-party optimizations: images, caching, bundling, but we couldn't find anything that takes care of optimizing your third-party stack while keeping it 100% functional.
Here are a few examples I recently tried:
https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?ur...
https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?ur...
https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?ur...
That said, I'm curious why zaraz isn't a Cloudflare "app" that I can "install" to my website? Google Analytics, Google Tag Manager are already sold on the Cloudflare Appstore by other third-parties and this works for me nicely, as a developer, because most of those are hands-off, straight-forward setups.
So, pardon my bluntness, but as a developer, what is the unique proposition with zaraz versus running these Cloudflare apps (discounting the fact that open source versions exist too) that I'm failing to see?
[0] https://www.cloudflare.com/apps/category/insights
Gotcha. This wasn't obvious to someone already familiar with Cloudflare apps (you may want to add that in the FAQ or somewhere).
> ...Cloudflare Workers honestly... It's a crazy powerful tool
I'll keep an keen eye out for what you build next!
Thanks.
Let's say I want to use a RUM script of some service, it will analyze the performance of all of my scripts, and collect some data about the pages the users visit.
Now how the cloudflare worker would do that?
Scrollstart,touchdown for mobile devices
mousemove for desktop
onfocus for keyboard navigation / screenreaders
and an event that triggers on execution of this tag.
On that event I bind all the third party stuff, mostly with in some trigger group.
So basically it loads late - does not hold up rendering of the site - but also soon if there is interaction with the site.
Here is the Gist https://www.franz-enzenhofer.com/a/gtag-make-faster
So is this kinda the approach zaraz is doing?
Edit: we’re in the 2M visits range, although $950/mo sounds a bit steep... if it gets us to load as near instant as your homepage though, maybe it’s worth it? :)
I work in ad-tech, and we rolled out a feature much the same as this almost 4 years ago now. The issue is that many tracking scripts rely on 1st party signals (and seemingly, ips) for end-users to capture the full value of their use. Facebook and GAds specifically perform quite poorly when executed in a 3rd party context. Not that they don't track, but that they're often unable to attribute the event to the correct (or any) user. This works against efforts like re-targeting and optimization. In FB's case, their own server-side attribution solution has a "match rate", which in practice is quite low for any event that does not include 1st party information. FB cookies are only available for a subset of active customers as well.
What has been your experience w/ these things?
edit: fixing link
Your approach makes sense, have you managed to validate that these signals are equivalent in-platform (Facebook)? I don't know how deep I should go, but there's also a distinction between events tracked in Events Manager vs those tracked in Ads Manager, as well as a suite of changes w/ regards to Aggregated Event Management (AEM) that's rolling out now.
For your server side integration are you using the Conversion API or are you reconstructing the GET signatures for their FB pixel?
For the FB Pixel, we're doing both :) We do use the Conversion API (with the first-party cookie), but we sometimes do reconstruct the GET request on our backend and pass the final URL to the browser to execute. Most tools are not as complicated though.
Faster webpages → better search rankings → $$$$$.
if someone places an order, I call fbq('pay', amount), how can this be achieved with your system?
And what about hubspot's chat window? Mouseflow's screen recording?
For HubSpot's chat window we deliver a Facade (https://web.dev/third-party-facades/). Screen recording tools are harder to optimize, but we bundle their first JS with our response (saving a request for the browser), and we offer sampling them to only a percentage of your users (or based on some criteria, like not loading them for users with slow connections). We do this rules evaluation on our backend, unlike GTM and other tools that essentially are sending everything to all users and then evaluating things on the client side.
I can't tell you how many times I've been tasked with UI time-to-interactive Optimization, only to come to find we have great performance without all of our 3p requests. Yet, business/product/marketing don't understand or care, they want to eat their cake, and have it too. It's a terrible situation to be in when you have to report to a non-technical manager.
Now, as someone who worked in ad tech and spent countless hours trying to convince my colleagues to exercise empathy before dumping even more crap on publisher’s sites, I mildly regret that I didn’t come up with this idea myself. Good luck!
How does it help with Google Ads? What about Prebid?
One note though: I think it's a bit misleading when you say "We support your entire stack of third-party tools " or "We optimize everything for you!", it's obviously not true. Is there a list of integrations somewhere?