What's TypeScript compiling? Use a treemap to find out

It's not mentioned in the article, but we also added an eslint rule to ban importing `googleapis` so that this won't happen again in the future.

When I'm in a browser, 99% of the time I expect the page to have what I'm looking for. I rarely care if its interactive. In fact, the more interactive it is, the less enjoyable the experience is. This holds even firmer when I'm on a desktop.

With webpages, any delays make intuitive sense and are accepted by the user. With an interactive web app, the web app gets blamed for any delays or latency because there is no full-page refresh.

However, if you have a landing page that someone might only visit once, then you want to optimize for as little JavaScript as possible, and in that case, just a pure server-side render might be best for that job.

Tricks that work on desktop - where a web application might stay open in a browser tab for weeks at a time - don't apply on mobile. On mobile, I'm much more likely to drop into your app for a few minutes to achieve a single goal, then navigate away and un-load it again.

So assuming that I'm going to pay that loading price once and then keep interacting with your application doesn't actually work - most of my interactions with your app will be a cold start, often with an empty cache too since browser caches on mobile devices (especially cheaper Android phones) are much smaller.

There's no inherent need for a real estate investment dashboard to act like an app instead of a plain old website. It might serve many of the developers needs, and maybe some of the customers, too - but such a feature could just as easily be served as a plain old webpage as it could a heavy front loaded application.

This whole thread is full of people saying things like, "When _I'm_ building a webapp," and "_My_ projects end up loading slowly," etc. Google is saying things like, "When 400 people are working on a web app, how can we avoid it turning into a shit show."

That said, if your application is actually complex enough to warrant this upfront download cost, might make sense.

YMMV as always

EDIT: in case it wasn't obvious, I was talking about Blazor WASM not Blazor server

I was under the impression that production builds often include tree-shaking/dead-code-elimination as one of the steps?

Tree shaking is a big win for bundle size. One of my big takeaways from looking at these visualizations is that we badly need an equivalent for type declaration files.

but you also didn't "Make them fast!" in response to the criticism. i know because i've profiled and purged plenty of google's JS from sites in the past. in most cases, this analytics/tag-manager JS far outweighed the site's own JS, to the tune of 5:1.

always found it odd how a company that makes V8, Blink, Chrome's DevTools, LightHouse, Closure Compiler, then evangelizes and blogs about performance but in the end doesnt take its own medicine.

Turn off ads? Disable third-party scripts site-wide? Don't send over any audio? How about webfonts? Tracking? Webgl? Webgl2?

Would it not make more sense to ask the user (or their agent) what features they want to use, before trying to figure out which dependencies are needed to make them work?

Could we optimize not just for speed and utility but also user feedback?

Giant dependencies and time to interactive have been battling each other for decades. It's not just how much code you run on first paint, that's a discipline in its own right. But until the javascript and CSS load you don't really control much of anything in the browser lifecycle.

So you work and work on those, and you've gotten through a bunch of performance-as-feature gates, but then someone throws three analytics packages on that together are proportional to the code you sweated to carve out of the initial payloads. You can usually defer those, but how easy that was depends on which generation of web browser you're talking about.

What you can't control is how much work those libraries due on the page while they bootstrap. As recently as the last project I worked on in my current job, I discovered that something like 60% of the event loop blocking was coming from some analytics library that was stuck in a reflow loop that was taking longer than we had saved on code that a couple of my poor coworkers had been working on for ages, to the point you could hear the exhaustion in their voices in standup.

That one was mostly tripping up due to a performance bug in an old version of jquery (mutation on read), but other examples in this problem domain are often not so simple to fix.

Ultimately this is a social problem, but I've seen it way too many times.Someone high in the org chart didn't insist that we run the application exactly as it would run in production. In a Saas situation a customer may say "I want to be able to add stuff to my pages, can you do that?" and nobody catches on that they want to run analytics, and not just for one dashboard, but for the old one they can't let go of and the new one that is cooler but only answers 80% of their questions. And then they want a third party live chat which is somehow as slow as the two analytics libraries combined.