5 ms·

JavaScript growth and third parties

57 points by panic 8y ago

SCdF 8y ago
Ironically after 47 minutes on HN their site doesn't load at all. Here is a cached version that works: http://webcache.googleusercontent.com/search?q=cache:https://speedcurve.com/blog/javascript-growth/ http://webcache.googleusercontent.com/search?q=cache:https:/...
- zeman 8y ago
  Can I just check, do you use Edge browser? We've (SpeedCurve) been seeing some issues where Edge goes bonkers and makes thousands of requests to our CDN and fails to load CSS which would look like a broken site.
  - SCdF 8y ago
    Apologies, it wasn't down because of HN! I can't edit the original post now, but it was just my computer blocking your domain at the hosts level via https://github.com/StevenBlack/hosts https://github.com/StevenBlack/hosts I should have realised, but it's the first time using that hosts list has ever stopped a website I've wanted to go to from loading, so I didn't think of it.
mschuetz 8y ago
I'd rather attribute that to ads, especially terrible ones that cause page reflow, than just javascript.
- vthriller 8y ago
  Page reflow is nothing compared to <canvas>es flying on top of the <video> thanks to some overengineered JS code.
CoderRefresh 8y ago
One of the big problems with JavaScript is that some developers don't know it very well (me included) but have to get some feature working, so import multiple frameworks/libraries to get their job done, most of which is not needed.
fithisux 8y ago
Yeeeeeeeeeeeeees.
rantanplan 8y ago
EDIT: The HN title changed so I don't know if this comment is relevant anymore. That sounds like saying "living is the leading cause of death". I mean, I don't particularly like JS, but it seems like we decided long ago that plain documents and links won't cut it. Everything, apparently, needs to be a rich web application with huge images and a gazillion of ads. Why is that Javascript's fault?
- ricardobeat 8y ago
  It is entirely possible to build rich web apps with very small size. As shown in the article, the main source of bloat are 3rd party scripts: ads, tracking, metrics, retargeting, security...
  - oraphalous 8y ago
    Everyone here is the choir... Now convince the client that they don't need to track every single possible click of the user - as they experience their "journey" through the site... ...convince the client that all those experience designers effusing about that "emotional layer" they added to that user journey didn't really result in 30% more engagement with the brand - as evidenced by exactly that same user tracking - convince em XD isn't just mouthing a load of horse shit. I mean - why do all the folks in XD dress in black all the time anyway. Would someone run a focus group on that please? Funny thing is - I don't even know if they are all full of shit or not. Maybe all this is all necessary - maybe not. I don't even know and I build this stuff for a living. Client seems happy so meh... But yeah - these large JS bundles aint the cause of these large JS bundles... ahem - I mean these slow sites...
    - cmoscoso 8y ago
      I keep JS disabled so most of this crap don't bother me.
    - ASalazarMX 8y ago
      There are these obscure files called "logs" which record every interaction with your server. They might be useful, IDK.
azeotropic 8y ago
I don't understand why JavaScript is so ubiquitous now. There seem to be very few cases where it is actually necessary and useful (e.g. a calculator form that does computations client side that would otherwise overwhelm the server). I am constantly surprised at the number of sites that should be totally static (e.g. a local restaurant's menu page) that display nothing at all when I visit with JavaScript disabled. Can someone who actually makes websites explain why this has happened? Is this about varying screen resolutions and aspect ratios in the era of phones and tablets? Can't you just use CSS instead?
- AnnoyingSwede 8y ago
  It tends to be things like trackers that report back what browser versions, supported plugins, cookies for directed adverts.
  - azeotropic 8y ago
    I suppose I should 'view source' to check a few, but are local restaurants actually using tracking code on menu pages? I'll by the lazy developer / uninformed business owner explanation or the flash cancer analogy, but the tracking explanation seems a little far-fetched. I get that Facebook, Amazon, Apple, and Google are all running ad networks trying to track me, and that globally this accounts for most of the bloat. I'm trying to understand the dynamic that causes what should be simple static websites to use JS in such a way that they display no information at all when JS is off.
- Veen 8y ago
  It may not be functionally necessary from the user's perspective, but much of this JavaScript is included because of the business model of the publisher. It has a function, even though it's not a function that's visible to the user.
- BerislavLopac 8y ago
  A wild guess is that these days the developers tend to specialise along the front/back end line. So a user-facing Web interface of any kind is usually assigned to front-end developers, which is now mostly synonymous with "Javascript developer", or even more specifically "React/Angular/etc developer" (just like on the back end side we commonly have Django/RoR/Magento/etc developers"). I used to be a full-stack developers, trying to balance my apps/pages just right between the server and browser side. But lately it's much easier to just focus on building APIs and let the front-end devs deal with all the interaction, forms and other user-facing stuff.
petetnt 8y ago
While I do acknowledge that increase in generic third-party things like ads and trackers definitely plays a certain role here isn't the study is kind of moot unless sites with similar feature sets are compared.
- TeMPOraL 8y ago
  You can compare site's performance with it's performance under uMatrix or even uBlock. The amount of nonessential third-party JS is really a big problem.
z3t4 8y ago
O(c^n) is what makes websites slow. Piling libraries, frameworks, trackers, and other third party services on-top of each other, that each has thousands of dependencies.
- VMG 8y ago
  Also there is nothing special about websites. The same is true for programs and mobile apps.
Dowwie 8y ago
Google Mail feels like it's transmitting over a 57.6k modem these days. If developers at Google can't make fast JavaScript front ends, what are the odds that an average front end developer can?
- chungy 8y ago
  To be fair, Google for years have been perfect examples of developers that can't optimize to save their life. Virtually every other site is faster than any of their sites.
- nailer 8y ago
  It's 6MB (closer to 7 if you round it). https://twitter.com/mikemaccana/status/1073538289582436352 https://twitter.com/mikemaccana/status/1073538289582436352
  - onion-soup 8y ago
    did you just compare a bundle size with the modem bandwidth?
    - nailer 8y ago
      Not the JS bundle (if that's what you mean), the site itself (to get to the point where you can use gmail). And yes, why wouldn't I? My 50Mb/s cable modem can download the fully featured Fastmail (500K) 13x faster than GMail. That's how bandwidth works.
- ape4 8y ago
  That's why they added the splash animation. Which also has to be downloaded.
- pumanoir 8y ago
  The odds are pretty high. A bunch of google "apps" are pretty inefficient. Like every company, Google has a spectrum of good, ok and bad programmers. It seems like they are working hard on making gmail slower every release.
onion-soup 8y ago
Fixed: Ad-tracking libraries is the main cause for making websites slow
hkt 8y ago
Web pages were better than web apps. Whisper it.
onion2k 8y ago
Poorly implemented JS makes websites slower. Well implemented JS makes websites faster. The lesson here is not "use less JS" because you'll miss out on some things that JS can do that actually improves (perceived) performance, but rather it's "Use JS intelligently or risk harming your site's performance." The raw number of downloads doesn't impact the speed at all if most of them are done asynchronously in the background while the browser is idle after the first paint and after the page is interactive. Developers seem to have forgotten progressive enhancement entirely and just piled more and more JS in to the first page load. Consequently users complain about JS, but JS itself is not the problem. There are patterns for building websites that are fast, in terms of both literal download and rendering speed and the perceived speed the user feels. We 'just' need better developers who actually care about the sites they build.
- lucideer 8y ago
  Imo, the real problem is that most people believe what you're saying is true, but if we assume that JS itself is not the problem, and that finding the right patterns for building fast websites with JavaScript, the next question becomes: who do we look to to learn the right patterns from. For most people, the intuitive thing is to look to successful companies: Google, Facebook, etc. The problem here is two fold: (1) operating at scale often has requirements that supercede making individual pages fast for individual visitors and (2) massive market dominance/semi-monopolies/vendor-lock-ins means these companies don't really need to compete on perf. See Facebook.com/gmail.com as lovely examples of some of the worst performance on the web. You're right that one can make a webpage fast with correctly implemented js, but I disagree that people can make webpages fast en masse with correctly implemented js; dissuading the use of JS is much more likely to have a positive effect than expecting people to somehow spontaneously learn how to write good js.
- SignsOfABeast 8y ago
  I call this no-js-first. There are apps that are blazing fast and have a lot of fancy/modern js stuff in it, they simply don't require any of it at all.
VMG 8y ago
Probably it is not the specific language that is to blame here, but the fact that websites are programs at all. We all know plenty of slow Python, C and C++ programs. I think there are some general "laws" that dictate this 1. all things that are programmable will be programmed at some point 2. all programs, no matter what language, we become as slow as the users will tolerate
ivanhoe 8y ago
And the saddest thing is that this javascript is mainly used for a) tracking and b) useless UI features that stopped being impressive to anyone like 10 years ago (highjacking the scroll, parallax, sliders, etc.)
kowdermeister 8y ago
Judging by the bundle sizes, the numbers aren't that bad if you consider the increasing of internet speed: https://www.nngroup.com/articles/law-of-bandwidth/ https://www.nngroup.com/articles/law-of-bandwidth/ Given that HTTP2 will be more and more available, the number of requests isn't a problem either. Global, fast CDN-s are thing for a while. What would be worrying about client side JS is needless use of heavy frameworks, like Angular, CPU hogging tracking scripts or lame ads, dark UX marketing widgets.
- jamil7 8y ago
  The problem with a heavy bundle isn't just delivery it's parsing and execution the bundle aswell.
  - kowdermeister 8y ago
    Of course, that's what I meant by heavy frameworks.
    - jamil7 8y ago
      Ah ok sorry, I misunderstood.
OliverJones 8y ago
The wheel of karma keeps on turning. Rich-client / client-server / rich-client / client-server. It's been going on since core memory supplanted rotating drum memory. It's not going to stop. Javascript is an INSANELY GREAT way of implementing rich clients; the best I've seen in my almost half-century in the trade. (Progress. Duh.) The modern clients (browsers) now have compilation right. V8 and its competitors are astonishing. But as always we have to get the distribution right: security, caches, progressive and async loading, agendas under control (meaning justified amounts of third party stuff).
singularity2001 8y ago
> In terms of the number of JavaScript requests, first party has gone up 50% from 4 to 6 requests, whereas third party has increased 140% from 5 to 12 requests. > Third party growth in terms of JavaScript size is more alarming. First party JavaScript doubled from 53 KB to 106 KB. Third party JavaScript octupled(!) from 32 KB to 258 KB. one more reason to use NoScript

57 points by panic 8y ago

SCdF 8y ago

Ironically after 47 minutes on HN their site doesn't load at all. Here is a cached version that works: http://webcache.googleusercontent.com/search?q=cache:https://speedcurve.com/blog/javascript-growth/ http://webcache.googleusercontent.com/search?q=cache:https:/...

zeman 8y ago
Can I just check, do you use Edge browser? We've (SpeedCurve) been seeing some issues where Edge goes bonkers and makes thousands of requests to our CDN and fails to load CSS which would look like a broken site.
- SCdF 8y ago
  Apologies, it wasn't down because of HN! I can't edit the original post now, but it was just my computer blocking your domain at the hosts level via https://github.com/StevenBlack/hosts https://github.com/StevenBlack/hosts I should have realised, but it's the first time using that hosts list has ever stopped a website I've wanted to go to from loading, so I didn't think of it.

mschuetz 8y ago

I'd rather attribute that to ads, especially terrible ones that cause page reflow, than just javascript.

vthriller 8y ago
Page reflow is nothing compared to <canvas>es flying on top of the <video> thanks to some overengineered JS code.

CoderRefresh 8y ago

One of the big problems with JavaScript is that some developers don't know it very well (me included) but have to get some feature working, so import multiple frameworks/libraries to get their job done, most of which is not needed.

fithisux 8y ago

Yeeeeeeeeeeeeees.

rantanplan 8y ago

EDIT: The HN title changed so I don't know if this comment is relevant anymore. That sounds like saying "living is the leading cause of death". I mean, I don't particularly like JS, but it seems like we decided long ago that plain documents and links won't cut it. Everything, apparently, needs to be a rich web application with huge images and a gazillion of ads. Why is that Javascript's fault?

ricardobeat 8y ago
It is entirely possible to build rich web apps with very small size. As shown in the article, the main source of bloat are 3rd party scripts: ads, tracking, metrics, retargeting, security...
- oraphalous 8y ago
  Everyone here is the choir... Now convince the client that they don't need to track every single possible click of the user - as they experience their "journey" through the site... ...convince the client that all those experience designers effusing about that "emotional layer" they added to that user journey didn't really result in 30% more engagement with the brand - as evidenced by exactly that same user tracking - convince em XD isn't just mouthing a load of horse shit. I mean - why do all the folks in XD dress in black all the time anyway. Would someone run a focus group on that please? Funny thing is - I don't even know if they are all full of shit or not. Maybe all this is all necessary - maybe not. I don't even know and I build this stuff for a living. Client seems happy so meh... But yeah - these large JS bundles aint the cause of these large JS bundles... ahem - I mean these slow sites...
  - cmoscoso 8y ago
    I keep JS disabled so most of this crap don't bother me.
  - ASalazarMX 8y ago
    There are these obscure files called "logs" which record every interaction with your server. They might be useful, IDK.

azeotropic 8y ago

I don't understand why JavaScript is so ubiquitous now. There seem to be very few cases where it is actually necessary and useful (e.g. a calculator form that does computations client side that would otherwise overwhelm the server). I am constantly surprised at the number of sites that should be totally static (e.g. a local restaurant's menu page) that display nothing at all when I visit with JavaScript disabled. Can someone who actually makes websites explain why this has happened? Is this about varying screen resolutions and aspect ratios in the era of phones and tablets? Can't you just use CSS instead?

AnnoyingSwede 8y ago
It tends to be things like trackers that report back what browser versions, supported plugins, cookies for directed adverts.
- azeotropic 8y ago
  I suppose I should 'view source' to check a few, but are local restaurants actually using tracking code on menu pages? I'll by the lazy developer / uninformed business owner explanation or the flash cancer analogy, but the tracking explanation seems a little far-fetched. I get that Facebook, Amazon, Apple, and Google are all running ad networks trying to track me, and that globally this accounts for most of the bloat. I'm trying to understand the dynamic that causes what should be simple static websites to use JS in such a way that they display no information at all when JS is off.
Veen 8y ago
It may not be functionally necessary from the user's perspective, but much of this JavaScript is included because of the business model of the publisher. It has a function, even though it's not a function that's visible to the user.
BerislavLopac 8y ago
A wild guess is that these days the developers tend to specialise along the front/back end line. So a user-facing Web interface of any kind is usually assigned to front-end developers, which is now mostly synonymous with "Javascript developer", or even more specifically "React/Angular/etc developer" (just like on the back end side we commonly have Django/RoR/Magento/etc developers"). I used to be a full-stack developers, trying to balance my apps/pages just right between the server and browser side. But lately it's much easier to just focus on building APIs and let the front-end devs deal with all the interaction, forms and other user-facing stuff.

petetnt 8y ago

While I do acknowledge that increase in generic third-party things like ads and trackers definitely plays a certain role here isn't the study is kind of moot unless sites with similar feature sets are compared.

TeMPOraL 8y ago
You can compare site's performance with it's performance under uMatrix or even uBlock. The amount of nonessential third-party JS is really a big problem.

z3t4 8y ago

O(c^n) is what makes websites slow. Piling libraries, frameworks, trackers, and other third party services on-top of each other, that each has thousands of dependencies.

VMG 8y ago
Also there is nothing special about websites. The same is true for programs and mobile apps.

Dowwie 8y ago

Google Mail feels like it's transmitting over a 57.6k modem these days. If developers at Google can't make fast JavaScript front ends, what are the odds that an average front end developer can?

chungy 8y ago
To be fair, Google for years have been perfect examples of developers that can't optimize to save their life. Virtually every other site is faster than any of their sites.
nailer 8y ago
It's 6MB (closer to 7 if you round it). https://twitter.com/mikemaccana/status/1073538289582436352 https://twitter.com/mikemaccana/status/1073538289582436352
- onion-soup 8y ago
  did you just compare a bundle size with the modem bandwidth?
  - nailer 8y ago
    Not the JS bundle (if that's what you mean), the site itself (to get to the point where you can use gmail). And yes, why wouldn't I? My 50Mb/s cable modem can download the fully featured Fastmail (500K) 13x faster than GMail. That's how bandwidth works.
ape4 8y ago
That's why they added the splash animation. Which also has to be downloaded.
pumanoir 8y ago
The odds are pretty high. A bunch of google "apps" are pretty inefficient. Like every company, Google has a spectrum of good, ok and bad programmers. It seems like they are working hard on making gmail slower every release.

onion-soup 8y ago

Fixed: Ad-tracking libraries is the main cause for making websites slow

hkt 8y ago

Web pages were better than web apps. Whisper it.

onion2k 8y ago

Poorly implemented JS makes websites slower. Well implemented JS makes websites faster. The lesson here is not "use less JS" because you'll miss out on some things that JS can do that actually improves (perceived) performance, but rather it's "Use JS intelligently or risk harming your site's performance." The raw number of downloads doesn't impact the speed at all if most of them are done asynchronously in the background while the browser is idle after the first paint and after the page is interactive. Developers seem to have forgotten progressive enhancement entirely and just piled more and more JS in to the first page load. Consequently users complain about JS, but JS itself is not the problem. There are patterns for building websites that are fast, in terms of both literal download and rendering speed and the perceived speed the user feels. We 'just' need better developers who actually care about the sites they build.

lucideer 8y ago
Imo, the real problem is that most people believe what you're saying is true, but if we assume that JS itself is not the problem, and that finding the right patterns for building fast websites with JavaScript, the next question becomes: who do we look to to learn the right patterns from. For most people, the intuitive thing is to look to successful companies: Google, Facebook, etc. The problem here is two fold: (1) operating at scale often has requirements that supercede making individual pages fast for individual visitors and (2) massive market dominance/semi-monopolies/vendor-lock-ins means these companies don't really need to compete on perf. See Facebook.com/gmail.com as lovely examples of some of the worst performance on the web. You're right that one can make a webpage fast with correctly implemented js, but I disagree that people can make webpages fast en masse with correctly implemented js; dissuading the use of JS is much more likely to have a positive effect than expecting people to somehow spontaneously learn how to write good js.
SignsOfABeast 8y ago
I call this no-js-first. There are apps that are blazing fast and have a lot of fancy/modern js stuff in it, they simply don't require any of it at all.

VMG 8y ago

Probably it is not the specific language that is to blame here, but the fact that websites are programs at all. We all know plenty of slow Python, C and C++ programs. I think there are some general "laws" that dictate this 1. all things that are programmable will be programmed at some point 2. all programs, no matter what language, we become as slow as the users will tolerate

ivanhoe 8y ago

And the saddest thing is that this javascript is mainly used for a) tracking and b) useless UI features that stopped being impressive to anyone like 10 years ago (highjacking the scroll, parallax, sliders, etc.)

kowdermeister 8y ago

Judging by the bundle sizes, the numbers aren't that bad if you consider the increasing of internet speed: https://www.nngroup.com/articles/law-of-bandwidth/ https://www.nngroup.com/articles/law-of-bandwidth/ Given that HTTP2 will be more and more available, the number of requests isn't a problem either. Global, fast CDN-s are thing for a while. What would be worrying about client side JS is needless use of heavy frameworks, like Angular, CPU hogging tracking scripts or lame ads, dark UX marketing widgets.

jamil7 8y ago
The problem with a heavy bundle isn't just delivery it's parsing and execution the bundle aswell.
- kowdermeister 8y ago
  Of course, that's what I meant by heavy frameworks.
  - jamil7 8y ago
    Ah ok sorry, I misunderstood.

OliverJones 8y ago

The wheel of karma keeps on turning. Rich-client / client-server / rich-client / client-server. It's been going on since core memory supplanted rotating drum memory. It's not going to stop. Javascript is an INSANELY GREAT way of implementing rich clients; the best I've seen in my almost half-century in the trade. (Progress. Duh.) The modern clients (browsers) now have compilation right. V8 and its competitors are astonishing. But as always we have to get the distribution right: security, caches, progressive and async loading, agendas under control (meaning justified amounts of third party stuff).

singularity2001 8y ago

> In terms of the number of JavaScript requests, first party has gone up 50% from 4 to 6 requests, whereas third party has increased 140% from 5 to 12 requests. > Third party growth in terms of JavaScript size is more alarming. First party JavaScript doubled from 53 KB to 106 KB. Third party JavaScript octupled(!) from 32 KB to 258 KB. one more reason to use NoScript