4 ms·

Based on my first scan, I've bookmarked this for the next time I have a perf issue on a site. One thing I didn't notice is that one of the biggest speedups is

by runako 8y ago

Based on my first scan, I've bookmarked this for the next time I have a perf issue on a site. One thing I didn't notice is that one of the biggest speedups is removing junk from the pages. That could be too many JS trackers, user-hostile videos, or whatever. IMHO it's an underrated skill for Web developers to be able to push back with cogent arguments when asked to ruin the performance of the sites they work on.

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?
- 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 runako 8y ago

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?
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.