[HN Gopher] Launch HN: Zaraz (YC W20) - Use third-party tools wi...
___________________________________________________________________
Launch HN: Zaraz (YC W20) - Use third-party tools without slowing
your website
Hi HN! We're Yair and Yo'av of Zaraz (https://zaraz.com). We make
websites faster by loading their third-party stack in an optimized
way. By "third-party" we mean utilities or additional products you
add to your website (eg. analytics), not things you build your
website with (eg. React). 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, since we have
total control on what data is revealed to our isolated environment,
we are using it to help companies protect the privacy of their
visitors by masking PIIs, hiding IP addresses, disabling
fingerprinting etc. We designed our infrastructure as a set of
serverless, storageless and stateless functions - to make sure your
visitors data is never saved, not even by accident. We are
currently onboarding mostly enterprises and high-traffic websites,
but we plan to introduce a free tier after we are done creating a
self-onboarding flow. We are on a mission to make the web faster
and we want all websites to benefit from it! We would be thrilled
to hear what you think, and if you have more ideas on how to make
websites faster please do share them with us. Thank you!
Author : yoavm
Score : 82 points
Date : 2021-02-02 16:08 UTC (6 hours ago)
| koopuluri wrote:
| Your site loads so damn fast on my phone - visibly faster than
| any other site I've opened on my phone (mobile safari). Great job
| on showcasing your product's value in such a direct way and
| congrats on your launch!
| yoavm wrote:
| That's awesome to hear! It's honestly not crazy hard if you
| take care of it from day one. We tried our best sticking to
| SVGs (inlined when it makes sense), using PurgeCSS to clean our
| stylesheets, server-side rendering, system fonts, and most
| importantly, an optimized third-party stack ;)
| verganileonardo wrote:
| Saw them on PH yesterday. Really excited about this product
| mrwnmonm wrote:
| I still don't understand how this works?
|
| 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?
| yoavm wrote:
| You're right that it's more complicated with Real User
| Monitoring, and not everything can be done inside our Worker.
| However, we bundle the content of the RUM script with our
| response (saving the browser another request), and we make sure
| it actually arrives only to, let's say, 1% of your traffic, or
| never to those on 3G. With GTM, Segment, or any other client-
| side third party manager this would be impossible because the
| rules evaluation is done in the browser. I don't really
| recommend running a RUM script for _all_ of your traffic - IMHO
| it misses the point of giving your users a better experience.
| soumyadeb wrote:
| Isn't it going to be very costly to run this?
| [deleted]
| franze wrote:
| Hi, for the speed aspect I just use Google Tag Manager to inject
| a tag on "minimal user interaction" which is
|
| 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?
| yoavm wrote:
| Not quite what we do... Delaying everything to when there's an
| interaction will make your analytics data (including
| conversions and remarketing pixels) miss a lot of information,
| and could easily make the browser lag exactly when your users
| want to interact with the page. It's far from ideal. Zaraz
| isn't delaying your scripts, it truly is sending less JS to the
| browser.
| onassar wrote:
| Dope idea! Over 7-years, our third-party vendors/services
| architecture has gotten really complex, and was rebuilt multiple
| times. It's hard to get right, especially when considering
| versioning, ad blockers, conditional loading, etc.
|
| 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!
| yoavm wrote:
| Thank you! That's a very valid point and we've seen this with
| customers quite often: the thought of changing the whole
| underlying layer can (understandably) scare people.
|
| 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.
| onassar wrote:
| Yep that all makes sense. I'm sure it's a tough job. For some
| context, our front end manages just 7 different libraries,
| but it's a pain to deal with so many edge cases. The worst
| and trickiest one was definitely ad blocking. We deal with a
| lot of edge cases whereby we're loading external resources
| that are not ads, but depending on browser/extension
| settings, were getting blocked.
|
| 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.
| phemartin wrote:
| This product should be open-source and we pay for hosting.
| yoavm wrote:
| Honestly this currently isn't on our roadmap, but we are
| planning to allow people to build their own server-side
| integrations, making the platform infinitely extensible and
| customizable. For now, if a customer wants to integrate some
| custom in-house tool, we often do it for them.
| bujak300 wrote:
| funny name "zaraz" I love it, it means "instantly" in Polish
| kofejnik wrote:
| it also means 'right now' in Ukranian
| pavel_lishin wrote:
| It sounds a bit like that in Russian as well, but it also
| sounds a lot like "infection"...
| yetihehe wrote:
| "Zarazek" in polish is "germ", and it's a diminutive form of
| "zaraza" - "pestilence". Some people joke that "zaraz" is a
| big bacterium. Also it's not "instantly" (natychmiast). It's
| a little later than instantly, like "as soon as I finish
| doing what I'm doing".
| Metacelsus wrote:
| No, "zaraz" is more like "imminently" or "after a moment".
| "Instantly" would be closer to "teraz".
| aresant wrote:
| Absolutely love this product, this is such as stupid problem to
| still exist in 2021 and an elegant solution.
|
| Many 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.
| yoavm wrote:
| Thanks for the kind words! Yair will follow up soon :)
| rad_gruchalski wrote:
| Zaraz: "soon" in Polish.
| gingerlime wrote:
| shalom from another Yoav. This is such a creative idea! I hate it
| how much analytics and "secondary" code hurts performance, even
| when loaded async. Not to mention the potential for added privacy
| which appeals to me personally. What's high traffic enough to get
| onboarded? I'd be really curious to try this out.
|
| 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? :)
| yoavm wrote:
| Shalom to you too! I got your email, will write to you very
| soon. And thanks for the comment, it sounds like we're aligned
| on our mission for great performance and user privacy.
| rpastuszak wrote:
| It's a bit off-topic, but as a native speaker of Polish I really
| like the name of the product, "zaraz" === "soon" in PL.
|
| 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!
| mlukaszek wrote:
| Off-topic, but I find it funny that the domain you chose means
| "in a short moment" in Polish... That may not necessarily work
| for the kind of product you're making. :)
| yoavm wrote:
| Yeah it was quite hard to find something that works in all
| languages... In our mother tongue (Hebrew) it actually means "a
| catalyst", and also we heard that it means "right now" in
| Ukrainian. But we definitely missed it with Poland. Sorry!
| artembugara wrote:
| In Ukrainian, "zaraz" means pretty much the same. I would
| translate it as "now"
| yetihehe wrote:
| In polish "now" is more like "juz". Zaraz is a little later,
| like "i'll do it right away" - "zaraz to zrobie". "Juz to
| robie" - "I'm doing it now". "Zaraz" means "I'm almost
| finished with my current task and will do that thing next".
| lmkg wrote:
| Moving tags & scripts into a server-side application sounds
| similar to the new Server-Side Container type available from
| Google Tag Manager. Is there an overlap in the use case, and if
| so, what are the differentiators for Zaraz?
|
| 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.
| yoavm wrote:
| Great points! GTM server-side tagging is indeed similar to one
| of our features, Cloud Load. The main difference would be that
| GTM essentially gives you the server-side capabilities for
| Google Analytics only, and the rest you have to code yourself.
| We offer all those integrations out of the box, and we maintain
| them, so you don't need a dev team to do that.
|
| 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! :)
| davej wrote:
| This is a real problem. Marketing tools like Intercom and
| Fullstory made the Time-To-Interactive metric on our landing page
| 10x slower. It had a measurable effect on the search engine
| rankings too.
|
| Faster webpages - better search rankings - $$$$$.
| Metacelsus wrote:
| Is the name Zaraz from Polish, where it means "after a little bit
| of time"?
| yoavm wrote:
| Well honestly the true story is that it was simply a domain
| that we could afford, but we like to tell ourselves it's coming
| from Hebrew, where it means catalyst or accelerator.
| mluggy wrote:
| How is this different/more scalable than running google tag
| manager as async, with the rest of the scripts as defer/async as
| well.
|
| 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.
| KaoruAoiShiho wrote:
| Yeah I am confused about this too, 10 seconds sounds like a big
| exaggeration. Your site should load in 1-2 seconds and the
| marketing can come the third second. However the page should
| already be interactive after the first 2 seconds. Doesn't quite
| need another service.
| yoavm wrote:
| I know it's hard to believe, but thankfully there are tools
| to measure this. Try https://web.dev/measure/ and see for
| yourself - many popular websites reach interactivity after 10
| seconds.
|
| 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...
| yoavm wrote:
| Unfortunately, when it comes to analytics and conversion
| pixels, deferring everything isn't really a serious option
| because it literally means missing data. Essentially all your
| metrics would be skewed and your remarketing audiences would be
| missing potential users. But also from performance it isn't
| great - I came across this website yesterday that did more or
| less this, and the problem was that because everything was
| loaded just after the page was ready, things would get super
| slow the first few seconds you're trying to interact with it.
| mluggy wrote:
| If someone hasn't stayed long enough to trigger GA, is it
| really a user? :)
|
| 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).
| yoavm wrote:
| Philosophically it's a great question :) I'm not a
| marketer, but I'm pretty sure that if you'd ask one what
| they think about losing the ability to do remarketing for
| all the users who bounced within the first 10 seconds of
| their visit, they would tell you it's perhaps their most
| important audience.
|
| 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.
| zed88 wrote:
| Hey good luck with it, this is a genuine problem to be solved.
| Will give this a spin.
| ignoramous wrote:
| Congratulations on the launch! I run production workloads on
| Workers too and there's basically endless potential, especially
| with their Unbound and Durable Objects product line. There's a
| tonne of SaaS opportunities to be built on top of those. Excited
| to see what else you folks add to the current offering.
|
| 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
| yoavm wrote:
| Yeah, can't imagine how we would be able to do this without
| Cloudflare Workers honestly... It's a crazy powerful tool. As
| for Apps - I'm not sure I got your question but Apps they are
| mostly wrappers around other tools, so when we launch a self-
| onboard process we would definitely consider offering an CF App
| for easier onboarding. But really, it's not a big difference to
| our customers because all they need to do is add our one line
| script. If you meant why use Zaraz to load these tools and not
| Cloudflare Apps - that's simply because Cloudflare Apps still
| pushes those scripts into the page and slows it down.
| ignoramous wrote:
| > _...that 's simply because Cloudflare Apps still pushes
| those scripts into the page and slows it down._
|
| 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.
| billconan wrote:
| how does it work? I don't get it. We currently have fb pixel to
| track e-commerce conversion.
|
| 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?
| yoavm wrote:
| Let's say you currently have, for example, a few tools firing
| after a purchase: fbq('pay', amount)
| ga('send', { hitType: 'event', eventCategory: 'Interaction',
| eventAction: 'Purchase', eventLabel: amount }); ...
|
| You would replace this whole block with
| zaraz.track("payment", {amount})
|
| This would make one request go from the browser to Zaraz, and
| Zaraz will handle it from there. It would work _without_
| loading fbevents.js, analytics.js, and other tool-specific JS
| files.
|
| 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.
| cphoover wrote:
| I'm a little curious on the methods behind the analyzer tool.
| yoavm wrote:
| It's nothing special really - we run Lighthouse twice (as a GCP
| Function) on the URL, and using Puppeteer we simply block
| third-party scripts from loading on one of the runs. Then we
| compare the results. While this isn't technically the same as
| running Zaraz on the page, we consider this to be a fairly
| accurate estimation of the website would work with Zaraz,
| because on the majority of cases we manage to load tens of
| tools with literally no performance impact.
| CaveTech wrote:
| I'm curious as to whether or not you've studied the implications
| of executing certain 3rd party tags from a server side context.
|
| 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?
| yoavm wrote:
| It's indeed one of the toughest nuts, and also the one reason
| we don't simply "Cloud Load" all third-parties. It really is a
| case-by-case thing, but in general we developed some pretty
| sophisticated loading techniques to overcome exactly this
| issue. We gave quite a thorough example of how we're loading
| the Facebook Pixel on https://zaraz.com/engineers. I don't want
| to just copy-paste it here, but I'd be happy to say more about
| it if you have any questions. The short answer is yes, it's
| hard, we don't always do things server-side partly because of
| this, but we find other ways to still optimize even if some
| things have to go client-side.
|
| edit: fixing link
| CaveTech wrote:
| Thanks :)
|
| 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?
___________________________________________________________________
(page generated 2021-02-02 23:00 UTC)