I would suggest that the enormous size of today's pages have taken us back to the behavior seen in the dial-up days.
Then: Page was slow because the delivery was via a 56k analog modem.
Today: Page is slow because the average page size is 2.2mb. Plus JavaScript parsing + execution time. Plus asynchronous calls to go load more stuff. Plus time to re-layout around the new stuff.
I work for a large health care company. They got on the JS bandwagon a while ago. We used to have huge sites that loaded fairly quickly (under 2 seconds) and cleanly. Now? The last two years doing accessibility work - a lot of these same sites which have been converted to Angular or React? They're taking in excess of 15-20+ seconds to load.
15-20+ seconds!!! What on earth are they doing to make it take that long? The React app at my last job was taking 2-4 seconds to load I joined the company (which I considered incredibly slow) and I had it at under a second by the time I left.
We did actually test on older machines too, but the machine didn’t make a huge difference in this case, because it was network requests making it slow not JS execution.
Aye, the network is also superb at work... I don't have stats but it won't surprise me if the typical user is on 4G/3G and half of those people will always browse to your site at just the time when they're in an area of poor connectivity (e.g. that may simply be how it is at their home).
> Page is slow because the average page size is 2.2mb. Plus JavaScript parsing + execution time. Plus asynchronous calls to go load more stuff. Plus time to re-layout around the new stuff.
I think it's mostly blocking chains of multiple networks requests that execute in sequence (taking a network round-trip each time). I inherited a slow ~2mb frontend app at work, which seemed horrendously bloated to me. It turned out to be not that easy to reduce to the size (due to large amounts of code depending on large libraries), but it also turned out to be possible to make it load fast without reducing the payload size.
There was no tracking or ad code except error reporting to bugsnag. Most of it was the firebase SDK. Which we did work towards removing, but which was a long term project because:
- Every single database read depended on it
- Many of them were subscriptions rather than simple reads, and so couldn’t be trivially replaced by an API call.
That's a lot better than it used to be. IIRC, at the time I was working on the mentioned app the Firestore SDK was 700kb minimum just by itself, and with Auth and Firebase Realtime Database as well I believe we were over a megabyte just for firebase! For comparison, our API abstraction layer for functionality not using Firebase was under a kilobyte.
Then: Page was slow because the delivery was via a 56k analog modem.
Today: Page is slow because the average page size is 2.2mb. Plus JavaScript parsing + execution time. Plus asynchronous calls to go load more stuff. Plus time to re-layout around the new stuff.