5 ms·
> Gmail used to be fast, and now it's slow and bloated. On my fiber connection, it takes nearly two seconds to render anything beyond a loading animation (gener
by _bxg1 7y ago
> Gmail used to be fast, and now it's slow and bloated. On my fiber connection, it takes nearly two seconds to render anything beyond a loading animation (generally a bad sign) and several more seconds to fully stream in content for various sections of the page. Why so slow? A quick trip to the Network tab in the browser console reveals that more than 4.6 megabytes of JavaScript are needed just for the list of emails to first render. After that point, 8 more megabytes of JavaScript stream in and various elements on the page render asynchronously. All this while, a further 3.5 megabytes of XHR data are transferred across more than 60 separate API calls.
What this reads as, to me, is "Gmail, a highly-stateful tool, is downloaded locally and then it requests a large portion of the user's inbox and other data for usage."
I highly doubt the JavaScript is re-downloaded every time the author visits Gmail. If it is, something has gone wrong. I don't think the initial load time is a good metric of performance for a true web app; on subsequent visits that 12.6MB should be loaded directly from disk, just like the binary of an installed native program.
Also, JSON is leaner than HTML, so the only reason that "3.5 megabytes of XHR data" would be larger than what was already being downloaded before is if Gmail is loading data more eagerly (loading the first several hundred entire messages of your inbox, for example, instead of just the subject lines of the first 50). This eager loading would presumably be done to make subsequent actions faster, and while we can debate the decision that was made in this particular case about exactly how eager to be, that isn't exactly an endemic issue like the author makes it out to be.
- cousin_it 7y ago> I highly doubt the JavaScript is re-downloaded every time the author visits Gmail. If it is, something has gone wrong. I don't think the initial load time is a good metric of performance for a true web app; on subsequent visits that 12.6MB should be loaded directly from disk, just like the binary of an installed native program. I don't know about Gmail, but this argument misses something important. A web app with several megs of JS is most likely being developed and pushed to production on a schedule (daily, or weekly, or something). So you're probably re-downloading the whole thing every few days. > Also, JSON is leaner than HTML Mmmaybe. With gzip, the difference isn't that large. And since not all developers are perfectly careful, the initial JSON will often contain stuff that isn't necessary for the initial UI state, so server side rendered HTML will often be leaner and faster.
- _bxg1 7y ago> A web app with several megs of JS is most likely being developed and pushed to production on a schedule (daily, or weekly, or something). So you're probably re-downloading the whole thing every few days. That's a fair point that I hadn't considered. But still: native apps get updates too. I've been annoyed by really frequent update prompts. Maybe the web streamlines the process to a point where devs may not notice the overhead it's causing for users, but that still comes back to being a UX issue, not a technical one, IMO. Maybe continuous-integration isn't a good idea when it comes to client software in general. Maybe releases need to be artificially slowed to a weekly or monthly cadence, for the sake of the user experience.
- cousin_it 7y agoThe problem is that the teams developing new features (or fixing bugs) will all push for faster releases. So anyone who advocates for slower releases needs to have a lot of political pull, for no clear political win. So it basically doesn't happen.
- pdimitar 7y agoAs another poster pointed out to you, the Gmail JS is likely updated very frequently. But it's not just that. It can't be THAT friggin' hard to split those JS resources in 3-5 files, or even 10 (having in mind the huge amount of HTTP requests their JS initiates). It's relatively easy to identify which parts are updated very often and which rarely change. There are numerous ways to optimise the time to first contentful paint. Google can absolutely pull it off. The reality is that they just don't care. And yes Gmail is slow, even on Chrome. Even on a modern Xeon workstation.