Yes, I skimmed a bit on the "registration" flow. it is a simple "mailto" link with 3 advantages: a) provides the required name and email, b) verifies you're a legitimate person and c) white-list our team email so we are never marked as spam.
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.
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.
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).
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.
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.
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.
Good point - by default Google Lighthouse is aiming at the 85th percentile of mobile connection speed, meaning you can ignore these metrics because you have a faster connection or device, but they are still true for ~15% of your mobile traffic. That's the reality of simply delaying scripts - you'll want to delay them more to achieve faster loading time, but the more you delay them the more data you lose.
is there a reason why you can't have a deployment/set of pods per client? the article keeps mentioning every solution failed when the whole dataset hit a certain limit.
Naturally it depends on the business use case or product situation, but a lot of XYZ per client architectures fail because some things don't "scale down" enough while others don't "scale up" enough.
Warning: Broad generalizations ahead.
Most successful shard strategies work because each division is hopefully roughly uniform. It's kinda like with binary tress, they work best when balanced. Clients are often more of a long tail, skewed, distribution. You often have tons and tons of small clients where the per-client overhead could be painful, while at the same time your biggest clients might outgrow what you can support in a shard.
To strawman your pods/client, dealing with 1k vs 1mm individual deployments is way different than dealing with a clientId column where the unique elements go from 1k to 1mm. Good indexing might be cheaper. But if you different regulation domains (HIPPA, GDPR, China, etc.) it can be easier to just run whole different data centers.
These balancing acts are what make data infra problems fun to work on.
