10 ms·

The main culprit, imo is javascript. People/clients want more and more complex things, but javascript and its libraries are the main culprit. Image compression,

The main culprit, imo is javascript. People/clients want more and more complex things, but javascript and its libraries are the main culprit. Image compression, minification...it helps, but if the page needs a lot of JS, it's going to be slower. Slightly off topic, but I have a site that fully loads in ~2 seconds but Google's new "Page Speed Insights" (which is tied to webmaster tools now) give it a lower score than a page that takes literally 45 seconds to fully load. Please someone at Google explain this to me. At least GTMetrix/Pingdom actually makes sense.

xenospn 6y ago
Giant CSS bundles as well.
jefftk 6y ago
If you post the links for the two sites I would enjoy looking at them to figure out why PSI is giving such strange scores
dgb23 6y ago
That statement seems to general. JS in of itself is not a performance issue in many cases. It can even improve performance in terms of speed/responsiveness.
- 9HZZRfNlpR 6y ago
  Responsiveness never, it does make complex projects easier but the problem is that developers often make them complex for the sake of it.
  - ly 6y ago
    I disagree with "responsiveness never". Imagine you have a "tabs" component on a page, each tab has some text (for example [1]). With javascript, you can hide the content of the first tab and show the second tab on click, almost instantly. Without javascript the second tab would be a link to another HTML page where the second tab is shown. Exact same behaviour for the user, however the one with a few lines of javascript will feel way more responsive than the one without, where the user has to wait for a new page to load. [1] https://getbootstrap.com/docs/4.0/components/navs/#javascript-behavior https://getbootstrap.com/docs/4.0/components/navs/#javascrip...
    - theandrewbailey 6y ago
      Without Javascript, the tab can be a label that activates a radio button next to a hidden div that also has a input:checked~div { display: block;} CSS on it. No Javascript required. https://codepen.io/dhs/pen/diasg https://codepen.io/dhs/pen/diasg
      - ly 6y ago
        Yeah, you're right that simple tabs can also be implemented using css, but I still disagree. Another example: how about a simple search on a table [1]. In this case the search is instant. Without JS you would have to have a submit button and wait for the request. Even if you also added a button the JS version it would still feel more responsive, as again, you're not waiting for the request. [1] https://www.w3schools.com/howto/tryit.asp?filename=tryhow_js_filter_table https://www.w3schools.com/howto/tryit.asp?filename=tryhow_js...
        lelandbatey 6y ago
        I'm not sure I've ever seen a case where I have a data set that's small enough to be quickly searchable (and quickly re-renderable) using client-side JS but big enough that I need dedicated and app-like sort, search, or query functionality. And where such a set of data to exist, that data set would almost certainly be _growing_ with time, meaning even if it started out as something where I can have snappy JS search, as time passes the JS search grows heavier and slower through time. Additionally, when it comes to client-side spreadsheets I have seen far more terrible half client-side, half server-side implementations (being only able to sort within a page, instead of across all pages of results). If I had to choose one, I'd choose a world were all we had were server side spreadsheets.
        ly 6y ago
        I’ve implemented front-end (fuzzy) search in multiple projects over the years. When the dataset is known to be small enough it’s great. I have also seen the horrible half/half implementations you mention where it should have just been implemented on the server side, and I totally agree with you there. However it was just an example to show that a unsubstantiated blanket statement like “responsiveness never” is just wrong. I’m not saying doing search in JS is always (or even often) better, but it can be sometimes if done well.
  - amiga 6y ago
    Job security!
- grishka 6y ago
  People misuse and abuse JS all the dang time. Take Twitter: you follow a link to a tweet from somewhere else, but first thing you see as the page loads is not the tweet — it's everything but the tweet itself. There's a spinner instead of it, because rendering it server-side would've made too much sense, I guess. Gotta make an API request from the client and render it client-side just because that's so trendy. In other words, there are too many websites that are made as "web apps" that should not be web apps.
  - bananaface 6y ago
    Which is made way worse by the fact that tweets are 280 characters of text. It's absurd that Twitter has a higher delay than a few round trips when they aren't reloading any structural content. Wtf are these people on 300k salaries doing all day?
    - grishka 6y ago
      This strict character limit is a defining feature of microblogging, and it has nothing to do with engineering.
      - ezconnect 6y ago
        His point is it's just 280 characters of text to download to the client to show the tweet. The client have downloaded probably 1,000x that much text before he can even see what he wants to see.
  - munk-a 6y ago
    Ah - but here you're hitting a wall. You could build a very lean twitter with minimal advertising and a more sane tweet presentation order - but nobody on the business side of things actually wants you to build that. They want you to build a social media platform that can be leveraged with synergies and RoI to maximize user retention and hopefully get a bit of Ad money out of the process somewhere along the way.
    - 6y ago
rozenmd 6y ago
From what I've seen building PerfBeacon.com, it seems more like images in e-commerce sites are the worst offenders. Slowest site I've tested so far had a page size of 8.5MB, 80% of that was images.
- doteka 6y ago
  Hah, if only it was images. At work, our b2b app loads about 5MB of minified and compressed JavaScript and I don’t even know anymore.
  - rozenmd 6y ago
    Ouch, does the app use code splitting at least?
    - anonymoushn 6y ago
      Atlassian products seem to use a really great code-splitting-like tech: 4MB js bundles are dynamically generated from a list of which modules should be included in the bundle which is dynamically generated by some other js on the page. So you're essentially guaranteed to get the same modules into your cache a dozen times in slightly different 4MB js bundles.
      - rozenmd 6y ago
        Are you referring to https://github.com/atlassian-labs/react-resource-router https://github.com/atlassian-labs/react-resource-router ?
        anonymoushn 6y ago
        I'm not sure what the tech is called other than the reason I spend multiple hours a week waiting for jira and confluence to load pages with like 300 words on them
  - Escapado 6y ago
vlunkr 6y ago
I think JS does play a big role, but my guess is that the 3rd party stuff is lots heavier than the scripts that actually make the page work. You have to write tons of code before the load time even matters, but when you have a bunch of "analytics", advertising, and social media integration scripts it adds up, especially when each ad is essentially it's own page with images and scripts. If you use Privacy Badger or similar plugins, you see that it's not uncommon for websites to have an obscene amount of these. TLDR: I think ads are slowing the internet down way more than React apps.
nomel 6y ago
Perhaps they test with simulated reduced bandwidth?
s1t5 6y ago
I'm not a web developer so I really have no idea about this - is WebAssembly a viable solution or have I just absorbed some hype without understanding the problems with JS?
- flohofwoe 6y ago
  WebAssembly on its own won't help with web page bloat. As with all things on web pages, it can both be used to add more bloat, or to reduce bloat. Web page bloat isn't mainly a technical problem and can't be solved by technology alone.
- austincheney 6y ago
  No. Webassembly is not faster than JavaScript enough to account for the features and APIs browsers supply with JavaScript. That being said WebAssembly is a superior alternative to JavaScript only when not recreating the interactions already available with JavaScript. Where WebAssembly shines are things like large binary media, games, and avoiding things like garbage collection.
bearjaws 6y ago
Users expect load times proportional to the content expected, if I am loading photoshop I don't expect it to be quick. However if I am loading Reddit, I expect it to be fast, and it seems the websites that should load the fastest are now loading the most 'non-essential' JS, leading to worse performance than peoples expectations. In my experience JS adds at most hundreds of miliseconds, and thats because people add dozens of marketing/tracking code that bog the site down. If you run ghostery / ublock the javascript eval time shrinks dramatically. Our web app has a very large Angular app and it still renders in under 200ms, but we don't have any "plugins" due to working with PHI.
- reaperducer 6y ago
  Users expect load times proportional to the content expected And how do you think that happened? It's not a chicken-and-egg problem. Web pages got fat, and users' expectations got lower. Lazy devs have trained people to expect the worst, not the best. The app ecosystem wouldn't be half the size it is if web pages worked as fast as native apps. If you run ghostery / ublock the javascript eval time shrinks dramatically. Are you going to be the one to explain to the marketing department why you put instructions for doing so at the top of each of your company's web pages?
csark11 6y ago
What's your site's URL?
neurostimulant 6y ago
Page Speed Insight mainly measure how fast your above-the-fold content loads. It doesn't matter if your page loads a bunch of heavy js and images as long as it's deferred/lazy-loaded and doesn't block initial render. For example, amp pages actually load a lot of js for its component, but it doesn't block above-the-fold render and thus scored really great on page speed insight. Personally, I think page speed insight is one of google's strategy to encourage people to use AMP more. Edit: Also, I find it comical that when you include recaptcha v3 on your website, your page speed insight score can drop almost 20 points. It is as if google don't want you to use recaptcha at all.
- sli 6y ago
  > but it doesn't block above-the-fold render and thus scored really great on page speed insight Which is ridiculous and just builds in the ability to game the system, because in my experience, amp pages take upwards of 5-8 seconds before anything of use to me actually loads, while the non-amp version loads in a fraction of that time. I imagine someone is benefiting from amp, otherwise it wouldn't be used, but I have not experienced a single case where the amp version of a site wasn't significantly slower.
  - neurostimulant 6y ago
    I think a while ago you could get perfect 100 score on page speed insight by putting all your content inside an iframe :)
    - tester756 6y ago
      Last time I tried WebAssembly website that's loading 4-5 MB of data and it managed to score something like >95 meanwhile page was ready after like 5-10sec.
austincheney 6y ago
More specifically the culprit is generally unnecessary string parsing. Every CSS selector, such as querySelectors and jQuery operations, requires parsing a string. Doing away with that nonsense and learning the DOM API could make a JavaScript application anywhere from 1200x-10000x faster (not an exaggeration). Most JavaScript developers will give up a lung before giving up accessing the page via selector strings. Suggestions to the effect are generally taken as personal injuries and immediately met with dire hostility.
- chubot 6y ago
  [citation needed] There are a lot of other reasons why client side JS is slow, including page reflows, bad use of the network, etc. I'm not a front end dev but I have fixed many performance problems before, and I've never seen parsing CSS selectors as a bottleneck. I've seen some data driven work like this: https://v8.dev/blog/cost-of-javascript-2019 https://v8.dev/blog/cost-of-javascript-2019 I don't think they mentioned parsing CSS selectors anywhere. Shipping too much code is a problem, because megabytes of JS is expensive to parse, but IIUC that is distinct from your claim.
  - austincheney 6y ago
    > I'm not a front end dev But I am. You are correct in that there many other opportunities to further increase performance. If performance were that important you would also shift your attention to equally improve code execution elsewhere in your application stack. > and I've never seen parsing CSS selectors as a bottleneck. It doesn’t matter what our opinions are or what we have/haven’t seen. The only thing that matters are what the performance measurements say in numbers. EDIT To everybody asking for numbers I recommend conducting comparative benchmarks using a perf tool. Here is a good one: http://jsbench.github.io/ http://jsbench.github.io/ I posted a performance example to HN before and people twisted themselves into knots to ignore numbers they could easily validate and reproduce themselves.
    - bscphil 6y ago
      It's funny, you say > It doesn’t matter what our opinions are or what we have/haven’t seen. The only thing that matters are what the performance measurements say in numbers. But your only argument here is not numbers, but appeal to authority: > > I'm not a front end dev > But I am. I don't have any particular reason to doubt you, but if objective numbers should rule the day here, maybe you could link to an article comparing the performance of a simple application using CSS selectors and then switching to using the DOM API?
xchip 6y ago
The question is, why does your site needs so much javascript? Most prob is for tracking :/
- partiallypro 6y ago
  The great irony for Google is that their own tracking pixels for Analytics, GTM, AdWords, Adsense are some of the biggest culprits for pages hanging on loads.
  - XCSme 6y ago
    That's because you are not using AMP. /s
heisenbit 6y ago
Angular, React, Vue, etc. are all getting better reducing the bloat. Javascript packaging and tree shaking is also much better. A lot of old compatibility stuff for IE etc. also can be dumped now. JS compilation got faster. The reason we are not seeing any speedup is the code that is not needed: Tracking and advertisements - this stuff seems to fill any size and speed gains.
EE84M3i 6y ago
Something I've noticed is that Dead Code Elimination for Javascript sucks. Yes, there are the (relatively) single "tree shaking" algorithms, but there because of various language issues, it's very hard to mark code as completely unused. Because of this it's extremely common to pull in a library and have a bunch of code that's never used in production!
- SV_BubbleTime 6y ago
  Unused code shouldn’t cause a performance issue though, should it? Isn’t this just a matter of downloading it, but never branching into?
  - MereInterest 6y ago
    Performance on the web is more than just runtime. That time spent downloading the Javascript and parsing it is part of the page's load time, even if the Javascript isn't executed.
  - benaadams 6y ago
    Need to both download and compile it
cel1ne 6y ago
Yes, and the main culprit of JavaScript is excessive GC, because of excessive object-creation. Developers are careless because JS is so fast, but they forget the hundreds of milliseconds of GC-pauses that occur because they never think about the memory they are allocating and throwing away each second.

xenospn 6y ago

Giant CSS bundles as well.

jefftk 6y ago

If you post the links for the two sites I would enjoy looking at them to figure out why PSI is giving such strange scores

dgb23 6y ago

That statement seems to general. JS in of itself is not a performance issue in many cases. It can even improve performance in terms of speed/responsiveness.

9HZZRfNlpR 6y ago
Responsiveness never, it does make complex projects easier but the problem is that developers often make them complex for the sake of it.
- ly 6y ago
  I disagree with "responsiveness never". Imagine you have a "tabs" component on a page, each tab has some text (for example [1]). With javascript, you can hide the content of the first tab and show the second tab on click, almost instantly. Without javascript the second tab would be a link to another HTML page where the second tab is shown. Exact same behaviour for the user, however the one with a few lines of javascript will feel way more responsive than the one without, where the user has to wait for a new page to load. [1] https://getbootstrap.com/docs/4.0/components/navs/#javascript-behavior https://getbootstrap.com/docs/4.0/components/navs/#javascrip...
  - theandrewbailey 6y ago
    Without Javascript, the tab can be a label that activates a radio button next to a hidden div that also has a input:checked~div { display: block;} CSS on it. No Javascript required. https://codepen.io/dhs/pen/diasg https://codepen.io/dhs/pen/diasg
    - ly 6y ago
      Yeah, you're right that simple tabs can also be implemented using css, but I still disagree. Another example: how about a simple search on a table [1]. In this case the search is instant. Without JS you would have to have a submit button and wait for the request. Even if you also added a button the JS version it would still feel more responsive, as again, you're not waiting for the request. [1] https://www.w3schools.com/howto/tryit.asp?filename=tryhow_js_filter_table https://www.w3schools.com/howto/tryit.asp?filename=tryhow_js...
      - lelandbatey 6y ago
        I'm not sure I've ever seen a case where I have a data set that's small enough to be quickly searchable (and quickly re-renderable) using client-side JS but big enough that I need dedicated and app-like sort, search, or query functionality. And where such a set of data to exist, that data set would almost certainly be _growing_ with time, meaning even if it started out as something where I can have snappy JS search, as time passes the JS search grows heavier and slower through time. Additionally, when it comes to client-side spreadsheets I have seen far more terrible half client-side, half server-side implementations (being only able to sort within a page, instead of across all pages of results). If I had to choose one, I'd choose a world were all we had were server side spreadsheets.
        ly 6y ago
        I’ve implemented front-end (fuzzy) search in multiple projects over the years. When the dataset is known to be small enough it’s great. I have also seen the horrible half/half implementations you mention where it should have just been implemented on the server side, and I totally agree with you there. However it was just an example to show that a unsubstantiated blanket statement like “responsiveness never” is just wrong. I’m not saying doing search in JS is always (or even often) better, but it can be sometimes if done well.
- amiga 6y ago
  Job security!
grishka 6y ago
People misuse and abuse JS all the dang time. Take Twitter: you follow a link to a tweet from somewhere else, but first thing you see as the page loads is not the tweet — it's everything but the tweet itself. There's a spinner instead of it, because rendering it server-side would've made too much sense, I guess. Gotta make an API request from the client and render it client-side just because that's so trendy. In other words, there are too many websites that are made as "web apps" that should not be web apps.
- bananaface 6y ago
  Which is made way worse by the fact that tweets are 280 characters of text. It's absurd that Twitter has a higher delay than a few round trips when they aren't reloading any structural content. Wtf are these people on 300k salaries doing all day?
  - grishka 6y ago
    This strict character limit is a defining feature of microblogging, and it has nothing to do with engineering.
    - ezconnect 6y ago
      His point is it's just 280 characters of text to download to the client to show the tweet. The client have downloaded probably 1,000x that much text before he can even see what he wants to see.
- munk-a 6y ago
  Ah - but here you're hitting a wall. You could build a very lean twitter with minimal advertising and a more sane tweet presentation order - but nobody on the business side of things actually wants you to build that. They want you to build a social media platform that can be leveraged with synergies and RoI to maximize user retention and hopefully get a bit of Ad money out of the process somewhere along the way.
  - 6y ago

rozenmd 6y ago

From what I've seen building PerfBeacon.com, it seems more like images in e-commerce sites are the worst offenders. Slowest site I've tested so far had a page size of 8.5MB, 80% of that was images.

doteka 6y ago
Hah, if only it was images. At work, our b2b app loads about 5MB of minified and compressed JavaScript and I don’t even know anymore.
- rozenmd 6y ago
  Ouch, does the app use code splitting at least?
  - anonymoushn 6y ago
    Atlassian products seem to use a really great code-splitting-like tech: 4MB js bundles are dynamically generated from a list of which modules should be included in the bundle which is dynamically generated by some other js on the page. So you're essentially guaranteed to get the same modules into your cache a dozen times in slightly different 4MB js bundles.
    - rozenmd 6y ago
      Are you referring to https://github.com/atlassian-labs/react-resource-router https://github.com/atlassian-labs/react-resource-router ?
      - anonymoushn 6y ago
        I'm not sure what the tech is called other than the reason I spend multiple hours a week waiting for jira and confluence to load pages with like 300 words on them
- Escapado 6y ago

vlunkr 6y ago

I think JS does play a big role, but my guess is that the 3rd party stuff is lots heavier than the scripts that actually make the page work. You have to write tons of code before the load time even matters, but when you have a bunch of "analytics", advertising, and social media integration scripts it adds up, especially when each ad is essentially it's own page with images and scripts. If you use Privacy Badger or similar plugins, you see that it's not uncommon for websites to have an obscene amount of these. TLDR: I think ads are slowing the internet down way more than React apps.

nomel 6y ago

Perhaps they test with simulated reduced bandwidth?

s1t5 6y ago

I'm not a web developer so I really have no idea about this - is WebAssembly a viable solution or have I just absorbed some hype without understanding the problems with JS?

flohofwoe 6y ago
WebAssembly on its own won't help with web page bloat. As with all things on web pages, it can both be used to add more bloat, or to reduce bloat. Web page bloat isn't mainly a technical problem and can't be solved by technology alone.
austincheney 6y ago
No. Webassembly is not faster than JavaScript enough to account for the features and APIs browsers supply with JavaScript. That being said WebAssembly is a superior alternative to JavaScript only when not recreating the interactions already available with JavaScript. Where WebAssembly shines are things like large binary media, games, and avoiding things like garbage collection.

bearjaws 6y ago

Users expect load times proportional to the content expected, if I am loading photoshop I don't expect it to be quick. However if I am loading Reddit, I expect it to be fast, and it seems the websites that should load the fastest are now loading the most 'non-essential' JS, leading to worse performance than peoples expectations. In my experience JS adds at most hundreds of miliseconds, and thats because people add dozens of marketing/tracking code that bog the site down. If you run ghostery / ublock the javascript eval time shrinks dramatically. Our web app has a very large Angular app and it still renders in under 200ms, but we don't have any "plugins" due to working with PHI.

reaperducer 6y ago
Users expect load times proportional to the content expected And how do you think that happened? It's not a chicken-and-egg problem. Web pages got fat, and users' expectations got lower. Lazy devs have trained people to expect the worst, not the best. The app ecosystem wouldn't be half the size it is if web pages worked as fast as native apps. If you run ghostery / ublock the javascript eval time shrinks dramatically. Are you going to be the one to explain to the marketing department why you put instructions for doing so at the top of each of your company's web pages?

csark11 6y ago

What's your site's URL?

neurostimulant 6y ago

Page Speed Insight mainly measure how fast your above-the-fold content loads. It doesn't matter if your page loads a bunch of heavy js and images as long as it's deferred/lazy-loaded and doesn't block initial render. For example, amp pages actually load a lot of js for its component, but it doesn't block above-the-fold render and thus scored really great on page speed insight. Personally, I think page speed insight is one of google's strategy to encourage people to use AMP more. Edit: Also, I find it comical that when you include recaptcha v3 on your website, your page speed insight score can drop almost 20 points. It is as if google don't want you to use recaptcha at all.

sli 6y ago
> but it doesn't block above-the-fold render and thus scored really great on page speed insight Which is ridiculous and just builds in the ability to game the system, because in my experience, amp pages take upwards of 5-8 seconds before anything of use to me actually loads, while the non-amp version loads in a fraction of that time. I imagine someone is benefiting from amp, otherwise it wouldn't be used, but I have not experienced a single case where the amp version of a site wasn't significantly slower.
- neurostimulant 6y ago
  I think a while ago you could get perfect 100 score on page speed insight by putting all your content inside an iframe :)
  - tester756 6y ago
    Last time I tried WebAssembly website that's loading 4-5 MB of data and it managed to score something like >95 meanwhile page was ready after like 5-10sec.

austincheney 6y ago

More specifically the culprit is generally unnecessary string parsing. Every CSS selector, such as querySelectors and jQuery operations, requires parsing a string. Doing away with that nonsense and learning the DOM API could make a JavaScript application anywhere from 1200x-10000x faster (not an exaggeration). Most JavaScript developers will give up a lung before giving up accessing the page via selector strings. Suggestions to the effect are generally taken as personal injuries and immediately met with dire hostility.

chubot 6y ago
[citation needed] There are a lot of other reasons why client side JS is slow, including page reflows, bad use of the network, etc. I'm not a front end dev but I have fixed many performance problems before, and I've never seen parsing CSS selectors as a bottleneck. I've seen some data driven work like this: https://v8.dev/blog/cost-of-javascript-2019 https://v8.dev/blog/cost-of-javascript-2019 I don't think they mentioned parsing CSS selectors anywhere. Shipping too much code is a problem, because megabytes of JS is expensive to parse, but IIUC that is distinct from your claim.
- austincheney 6y ago
  > I'm not a front end dev But I am. You are correct in that there many other opportunities to further increase performance. If performance were that important you would also shift your attention to equally improve code execution elsewhere in your application stack. > and I've never seen parsing CSS selectors as a bottleneck. It doesn’t matter what our opinions are or what we have/haven’t seen. The only thing that matters are what the performance measurements say in numbers. EDIT To everybody asking for numbers I recommend conducting comparative benchmarks using a perf tool. Here is a good one: http://jsbench.github.io/ http://jsbench.github.io/ I posted a performance example to HN before and people twisted themselves into knots to ignore numbers they could easily validate and reproduce themselves.
  - bscphil 6y ago
    It's funny, you say > It doesn’t matter what our opinions are or what we have/haven’t seen. The only thing that matters are what the performance measurements say in numbers. But your only argument here is not numbers, but appeal to authority: > > I'm not a front end dev > But I am. I don't have any particular reason to doubt you, but if objective numbers should rule the day here, maybe you could link to an article comparing the performance of a simple application using CSS selectors and then switching to using the DOM API?

xchip 6y ago

The question is, why does your site needs so much javascript? Most prob is for tracking :/

partiallypro 6y ago
The great irony for Google is that their own tracking pixels for Analytics, GTM, AdWords, Adsense are some of the biggest culprits for pages hanging on loads.
- XCSme 6y ago
  That's because you are not using AMP. /s

heisenbit 6y ago

Angular, React, Vue, etc. are all getting better reducing the bloat. Javascript packaging and tree shaking is also much better. A lot of old compatibility stuff for IE etc. also can be dumped now. JS compilation got faster. The reason we are not seeing any speedup is the code that is not needed: Tracking and advertisements - this stuff seems to fill any size and speed gains.

EE84M3i 6y ago

Something I've noticed is that Dead Code Elimination for Javascript sucks. Yes, there are the (relatively) single "tree shaking" algorithms, but there because of various language issues, it's very hard to mark code as completely unused. Because of this it's extremely common to pull in a library and have a bunch of code that's never used in production!

SV_BubbleTime 6y ago
Unused code shouldn’t cause a performance issue though, should it? Isn’t this just a matter of downloading it, but never branching into?
- MereInterest 6y ago
  Performance on the web is more than just runtime. That time spent downloading the Javascript and parsing it is part of the page's load time, even if the Javascript isn't executed.
- benaadams 6y ago
  Need to both download and compile it

cel1ne 6y ago

Yes, and the main culprit of JavaScript is excessive GC, because of excessive object-creation. Developers are careless because JS is so fast, but they forget the hundreds of milliseconds of GC-pauses that occur because they never think about the memory they are allocating and throwing away each second.