Maybe I should have been clearer with me follow on paragraph where I talk about parsing of JavaScript and downloading of that - rather than all other assets. I agree with you that the web is broken and that we send way too much to the client in the first place.
However, there are many ways of mitigating additional assets getting in the way of both being able to interact the site and see it within a reasonable amount of time. We look at this through the lense of performance, where downloading some assets in the background might not necessarily harming your experience.
That's not to say we shouldn't be optimising for the smallest amount of network requests a site should make and think carefully about when to load images in. Your examples are what bad looks like and it's a shame, but there are now more and more sites that do a stellar job (or starting to) of giving you a great experience with less downloaded.
However if you were to download a 5mb image asynchronously that isn't part of your initial above the fold, Vs a 5mb payload of react that's needed to run the site... I know which one is going to make your browser a very unhappy bunny.
Speaking from building both react and Preact sites serving millions of customers - the difference is noticeable when you add everything up.
Minification or not, starting with a 6x bundle size puts you in a precarious position to have to care more about how it grows over time adding other assets.
Downloading, parsing and then executing a larger bundle size will impact performance and we've been able to see time to interactive impact conversion on e-commerce sites. However you are right that there are many other factors at play here that will make the site better and I think the post misses the point about "bundle size".
The important differentiation for us with Preact is two things: native support for web components, and a significantly faster library when it comes to transformations and dealing with vdom - see here https://rawgit.com/krausest/js-framework-benchmark/master/we...
On your comment about browser cache, also true but it really depends - if you haven't appropriately split out your bundle then returning users will probably be redownloading react again and again with app updates. Also new users are super important because if you are trying to get new traffic you care about their experience not just returning users.
I think this is all super fair commentary and very balanced. As a Compute@Edge user though how do they test CloudFlare when the ToS says otherwise? Test and break the ToS and hope for the best? It's a bit of a shame that it exists.
Rudderstack user here (and ex Segment). Thanks for sharing this stuff, very cool project.
Just to answer some of this:
- rudderstack has deploy ready helm charts, which I'd argue are significantly better than docker compose or docker setups because they set up all the other niggly parts. Would be cool to see that here :)
- rudderstack has gone quite far away from replacing segment. It's true that their core API is compatible and I think your transformation layer is really cool. However it can be used for those use cases because rudderstack doesn't really care about users or user IDs and can be used for any sort of data generally.
There's a piece in the docs talking about the fact that you don't get caught by adblock - whilst this may be true when someone launches it, that's not true of your platform. That's just the fact that a lot of smaller businesses will not get their URLs added to the ad block lists. I think it's a bit misleading to mention that in such a way because technically we're all tracking users and ad block is a way for users to choose not to be tracked, not be tricked into being tracked because someone has masked the tracking script ;) if a huge client (a la Adidas or something) decided to use your scripts I'm sure someone would eventually add it to the ad block lists that get propagated.
One of the things that would be cool would be some sort of opt in configuration. Segment has some awful consent SDK that is really bad, would be cool to see what you do there. GDPR is a big deal and browser fingerprinting is data processing. It's worth looking at your comments on being GDPR compliant btw https://www.eff.org/deeplinks/2018/06/gdpr-and-browser-finge...
Speaking to some of the Google developers and the head of mobile web performance - not even Google use their own tool as a measure / benchmark for performance. PageSpeed Insights is both broken and convoluted at best.
- No support for HTTP/2
-- This means that if you follow all the "right" approaches for performance with HTTP/2, you'll be slapped with a terrible PageSpeed score due to it not taking into account the effect of multi plexing connections.
- Has constant bugs around determining the flow of assets on the page and thinks that assets at the bottom become render blocking when they do not
Google tend to use a combination of their own tooling + WebPageTest.org (which is also theirs) to test performance issues.
This tool is mainly geared at the non-developer type, but it's unfortunately misleading and just wrong. It doesn't measure speed, it measures performance methodologies and whether they have been implemented or not (and old ones at that).
The more important metrics are time to paint, time to domcontentready. Using WebPageTest will get you what you want. I find it pretty offensive and misleading that Google is using such a tool and promoting it to users, because frankly it misses the entire point of performance.
Things like this:
"Eliminate render-blocking JavaScript and CSS in above-the-fold content" when you're running an H/2 site with an appcache and pushing assets is just downright wrong.
It's sad that there's a general miscommunication within the company about performance. Ilya Gregorik and co say one thing, and the rest say another.
This does not solve the problem of bad documentation or bad libraries. Points to make his case are weak. Better autocomplete? Reliable libraries? The library still compiles to JS and you can still use TypeScript naively and incorrectly and ignore typesetting altogether.
TypeScript doesn't solve the problem at all. It merely adds another layer of complexity/knowledge to a Library that still compiles to JavaScript. Write it in JavaScript, deliver it in JavaScript. If your documentation and implicit typesetting is giving you pains, then you should revisit what you have written and how you've built your library. Not switch to something that tries to enforce better behaviour.
However, there are many ways of mitigating additional assets getting in the way of both being able to interact the site and see it within a reasonable amount of time. We look at this through the lense of performance, where downloading some assets in the background might not necessarily harming your experience.
That's not to say we shouldn't be optimising for the smallest amount of network requests a site should make and think carefully about when to load images in. Your examples are what bad looks like and it's a shame, but there are now more and more sites that do a stellar job (or starting to) of giving you a great experience with less downloaded.
However if you were to download a 5mb image asynchronously that isn't part of your initial above the fold, Vs a 5mb payload of react that's needed to run the site... I know which one is going to make your browser a very unhappy bunny.