4 ms·
I've built my service https://urlscan.io https://urlscan.io to some extent to be able to track the impact of certain scripts / hosts on the overall size of the
by heipei 9y ago
I've built my service https://urlscan.io https://urlscan.io to some extent to be able to track the impact of certain scripts / hosts on the overall size of the website. You can find the breakdown by hostname under "Request Stats" on the right. But, for this use case, it would be perfectly sufficient to use the Chrome Devtools and filter by "facebook" for example.
Here is a scan where the 200KB Facebook sdk.js is being transferred (62KB gzipped) just to display some like buttons. Repeat for other networks like Twitter (114KB) and Google: https://urlscan.io/result/fa422ac0-3b2c-4ba7-a182-31921cc61ea6 https://urlscan.io/result/fa422ac0-3b2c-4ba7-a182-31921cc61e.... Remember: Even if you don't mind the transfer of 200kB, that volume of JavaScript will take some time to parse, especially on mobile.
- onion2k 9y agoFacebook's like button code generator tool[1] includes the entire SDK even if you configure it to only show a like button with no other social graph features. I guess there is an argument that having every site that uses Facebook's API having the same .js file will take advantage of browser caching better but it's still irritatingly wasteful. [1] https://developers.facebook.com/docs/plugins/like-button https://developers.facebook.com/docs/plugins/like-button
- eknkc 9y agoThe caching argument is solid though. I think it's the best cached piece of js after google analytics. Should still affect the parse time and overall responsiveness of pages though.
- ssttoo 9y agothe configurator on that page generates: 1/ sdk+like button or 2/ just an iframe with no sdk 1/ is better (proper resizing in different locales) but 2/ is always an option and it saves 60K of JS