[kyle-rb]

These types of tests tend to be unfair to actual web apps, since they only really account for first-time-use.

Twitter is slow in this experiment because it has to load a bunch of JavaScript up front. But that's not the case in practical use! Twitter uses service workers and HTTP cache headers (e.g. `expires`) to make sure that most non-first-time-users aren't actually loading most things every time. Client-side rendering isn't the thing that's slow here, it's mostly the re-downloading of the rendering code every time when that's not realistic.

[acdha]

Note that WebPageTest supports repeat tests for exactly this reason - that closes the browser and restarts it without clearing the cache. Here’s what that looks like - it helps the first render a lot (0.5 vs 1s) but the largest paint is still 7s: better than 11 but still pretty slow.

https://www.webpagetest.org/result/220921_BiDcBJ_GQX/

One big thing to remember is that browser caching only works if you aren’t shipping updates frequently (bundlers have been an anti-pattern for many sites for the last few years) and aren’t storing too much. On mobile in particular a lot of sites load enough junk that they fall out of the cache. I use Twitter only via their web app and the page load time on a fast iPhone is still like 10 seconds or worse, when a well-optimized HTML page can be in the hundred of milliseconds.

[kyle-rb]

Browser caching is nicer with service workers - you can use the cached version and load/install the updated version in the background, so that the user can get the updated version on their next refresh.

[acdha]

That’s a nice improvement but it still hits the cache size issues and it creates some hard problems you have to get right (“why didn’t reload fix it?”).

Not everyone has the resources to support that level of investment and there’s a pitfall in the middle where you get the costs but don’t see the desired benefits.

[Self-Perfection]

That is way alternative frontends for bloated websites exist. For instance, one can read twitter via nitter, which uses zero JavaScript. Check how fast it loads: https://nitter.privacy.com.de/SpaceX/status/1571950786896330...

[modeless]

Client-side rendering absolutely does make Twitter, in particular, slow. They used to do server side rendering for the initial load not that long ago, and it was so much faster than it is now. Night-and-day difference. I guess they just stopped caring. Someone probably got a promotion for launching the new thing.

[kitsunesoba]

Any time I have to use the Twitter site instead of Twitterrific on both desktop on mobile, the difference is huge. The site is a never-ending barrage of loading spinners.

[wubsitesgood]

For what it's worth, Twitter has gone back and forth on this. They did serve useful HTML up-front in the recent past. It was faster for initial delivery and I'd imagine helped the odd person who was sent a link to a tweet and hadn't loaded the site in a while.

Other sites in the article fit a traditional website model where folks commonly land on pages from search results, but they're still very JS dependent for content. CNN and FedEx etc

[jeroenhd]

I've been using Nitter rather than Twitter for a while now, at least for reading tweets. A submit feature and SSE/a websocket listening for new posts would not kill Nitter's performance if that were its intentions to implement but the difference between the two is night and day.

Twitter is the slowest website I come back to after Reddit. It's a hot mess and the fully loaded web app isn't any faster. Yes, the megabytes of content being loaded for rendering 280 characters aren't indicative of web app performance, but clicking through to the main app is still slow and unreliable. My old phone used to get hot from the Twitter web app for no real good reason. There's less than a kilobyte of content in a tweet yet I have constant issues with getting all images to load when they come into view or scrolling back up without having the content jump around because some recommendations block decided it exists again now.

Getting faster devices solved Twitter's problems for me for a while but it's still ridiculous if you open Nitter and compare the performance. It's a clear example of what's wrong with modern web development because the "traditional" design of Nitter does everything I want it to do and 90% of what most people want it to do (needs tweets, DMs to become interactive) at a fraction of the load time.