5 ms·

Why? Most trackers load async and don’t block the page from loading or rendering. I get it’s popular to hate but technically they load without blocking page f

by taf2 8y ago

Why? Most trackers load async and don’t block the page from loading or rendering. I get it’s popular to hate but technically they load without blocking page from rendering. A good read is https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index https://sites.google.com/a/webpagetest.org/docs/using-webpag...

jazzyjackson 8y ago
They may not be blocking, but it's an extra burden on my limited bandwidth (slows other connections down while it downloads) and balloons the memory usage of sites that are otherwise delivering static content.
- taf2 8y ago
  Usually the browser has a priority on each connection and when you load a script async the priority is set to low. Have a read here: https://developers.google.com/web/fundamentals/performance/resource-prioritization https://developers.google.com/web/fundamentals/performance/r...
  - jazzyjackson 8y ago
    Love knowing this kind of stuff, thanks
pmichalina 8y ago
Even just one poorly designed library can cause serious memory issues and trigger a ton of events. Usually it’s the marketing and ad people that throw around this “but they are async loaded”. That’s true, but doesn’t change the the fact that 40 trackers and their dependencies that come with it are slowing down and infringing on the users privacy. Let’s be real.
- taf2 8y ago
  Can you share an example site with 40 trackers? I believe you but it just doesn't seem common place.
  - runako 8y ago
    There has been a lot written about this, but here's a test I just ran on a random page on Huffington Post: https://www.webpagetest.org/result/181031_TT_443f9d1e666d08f708e1f78c5811ee5f/1/details/#waterfall_view_step1 https://www.webpagetest.org/result/181031_TT_443f9d1e666d08f... The article is probably <200 words, but the page is 3.2 MB and makes > 200 requests. There are 55 Javascript requests in there. Right, HuffPo is egregious. How about a site HN readers might frequent, something lightweight like Reddit? https://www.webpagetest.org/result/181031_H6_eaa2e64c99695156cd97c10867680cfb/ https://www.webpagetest.org/result/181031_H6_eaa2e64c9969515... Random Reddit page, content: medium-sized image. 164 requests, ~12 seconds to render the page on the test rig. 60 Javascript requests. 1.5 MB of JS downloaded to display the post, a 46kb image. There's a 30:1 ratio of JS to post content (what the user wanted to see) here. And there's other bloat beyond the JS. I just picked these two sites at random. You can do this all day with random websites. I would guess that most sites behind a .com (or .co.uk, etc.) will look similar. I don't mean to pick on these sites, just wanted to point out that these practices are widespread and even reputable developers engage in them. Which will make it more difficult to undo the rot.
    - taf2 8y ago
      I see there is a lot of JavaScript but are you certain that is JavaScript with the sole purpose of tracking or application code? I’m not gonna say these sites could not be implemented better but the claim was these are all tracking pixels. Is that true?
      - runako 8y ago
        You're parsing this too narrowly. I'm not making a claim about the purpose of each request. I'm looking at the totality and saying that maybe making 200 requests to display 200 words of content is overkill. The larger claim was that the pages are loaded with junk that affects the performance of the pages. The signal:noise ratio on modern sites is broken, and optimizing the junk can only accomplish so much. Developers need to advise stakeholders of the downside costs, performance among them, of loading sites with bloat. Here's an article I read a while back on the impact of specifically Javascript: https://medium.com/@addyosmani/the-cost-of-javascript-in-2018-7d8950fbb5d4 https://medium.com/@addyosmani/the-cost-of-javascript-in-201...
geekybiz 8y ago
They may load async but JS parse + compile + execute takes up client device CPU cycles and can block the main thread from responding back to user actions immediately. More so on mobile devices. This, and the fact that a typical page has multiple such trackers can cause notable overhead.
- taf2 8y ago
  Can you share some example sites where the CPU cycles on mobile are a major impact? I suspect maybe news websites? I just don't encounter many on a daily basis where it has an impact and most sites I look into for performance - the issue definitely isn't trackers. It's almost always oversized large css files and blocking js files. When you dig into the site you usually find that it will be very challenging to architect it to avoid the blocking script or shrink the css... but again would love to see some "typical" examples.

by taf2 8y ago

jazzyjackson 8y ago

They may not be blocking, but it's an extra burden on my limited bandwidth (slows other connections down while it downloads) and balloons the memory usage of sites that are otherwise delivering static content.

taf2 8y ago
Usually the browser has a priority on each connection and when you load a script async the priority is set to low. Have a read here: https://developers.google.com/web/fundamentals/performance/resource-prioritization https://developers.google.com/web/fundamentals/performance/r...
- jazzyjackson 8y ago
  Love knowing this kind of stuff, thanks

pmichalina 8y ago

Even just one poorly designed library can cause serious memory issues and trigger a ton of events. Usually it’s the marketing and ad people that throw around this “but they are async loaded”. That’s true, but doesn’t change the the fact that 40 trackers and their dependencies that come with it are slowing down and infringing on the users privacy. Let’s be real.

taf2 8y ago
Can you share an example site with 40 trackers? I believe you but it just doesn't seem common place.
- runako 8y ago
  There has been a lot written about this, but here's a test I just ran on a random page on Huffington Post: https://www.webpagetest.org/result/181031_TT_443f9d1e666d08f708e1f78c5811ee5f/1/details/#waterfall_view_step1 https://www.webpagetest.org/result/181031_TT_443f9d1e666d08f... The article is probably <200 words, but the page is 3.2 MB and makes > 200 requests. There are 55 Javascript requests in there. Right, HuffPo is egregious. How about a site HN readers might frequent, something lightweight like Reddit? https://www.webpagetest.org/result/181031_H6_eaa2e64c99695156cd97c10867680cfb/ https://www.webpagetest.org/result/181031_H6_eaa2e64c9969515... Random Reddit page, content: medium-sized image. 164 requests, ~12 seconds to render the page on the test rig. 60 Javascript requests. 1.5 MB of JS downloaded to display the post, a 46kb image. There's a 30:1 ratio of JS to post content (what the user wanted to see) here. And there's other bloat beyond the JS. I just picked these two sites at random. You can do this all day with random websites. I would guess that most sites behind a .com (or .co.uk, etc.) will look similar. I don't mean to pick on these sites, just wanted to point out that these practices are widespread and even reputable developers engage in them. Which will make it more difficult to undo the rot.
  - taf2 8y ago
    I see there is a lot of JavaScript but are you certain that is JavaScript with the sole purpose of tracking or application code? I’m not gonna say these sites could not be implemented better but the claim was these are all tracking pixels. Is that true?
    - runako 8y ago
      You're parsing this too narrowly. I'm not making a claim about the purpose of each request. I'm looking at the totality and saying that maybe making 200 requests to display 200 words of content is overkill. The larger claim was that the pages are loaded with junk that affects the performance of the pages. The signal:noise ratio on modern sites is broken, and optimizing the junk can only accomplish so much. Developers need to advise stakeholders of the downside costs, performance among them, of loading sites with bloat. Here's an article I read a while back on the impact of specifically Javascript: https://medium.com/@addyosmani/the-cost-of-javascript-in-2018-7d8950fbb5d4 https://medium.com/@addyosmani/the-cost-of-javascript-in-201...

geekybiz 8y ago

They may load async but JS parse + compile + execute takes up client device CPU cycles and can block the main thread from responding back to user actions immediately. More so on mobile devices. This, and the fact that a typical page has multiple such trackers can cause notable overhead.

taf2 8y ago
Can you share some example sites where the CPU cycles on mobile are a major impact? I suspect maybe news websites? I just don't encounter many on a daily basis where it has an impact and most sites I look into for performance - the issue definitely isn't trackers. It's almost always oversized large css files and blocking js files. When you dig into the site you usually find that it will be very challenging to architect it to avoid the blocking script or shrink the css... but again would love to see some "typical" examples.