4 ms·

> not even mentioning the amounts of JS and the impact of it on performance The only reason it performed better is because Google would preload over 1MB of Jav

> not even mentioning the amounts of JS and the impact of it on performance The only reason it performed better is because Google would preload over 1MB of Javascript needed to run AMP on its search page. A cold start for AMP was barely better than most of the top sites that used it. It was cheating, pure and simple. Edit: IIRC it was also preloading the entirety of the search carousel, too. And you could get into the carousel only if you had an AMP page.

KronisLV 4y ago
> The only reason it performed better is because Google would preload over 1MB of Javascript needed to run AMP on its search page. I wonder what he actual metrics are for how often that was used, what % of people chose one of the AMP results, because those were at the top of the list. That preloaded data might be common for most of AMP pages, which is much better than the mess of each site having different React/Angular/Vue bundle versions or even jQuery versions back in the day. As a thought experiment, I wonder how much we could save on bandwidth, if all of the "popular" frameworks/libraries split their base code from each individual application's code (we already have code bundling, after all) and browsers included all of those packages of base code, preloaded. Maybe even follow SEMVER as close as possible, so the browser can always ship the latest minor/patch release for a given major release, to cut down on space needed in the browser. Something along the lines of: <script src="/browser/react@18"></script> <script src="/js/my-app-react-bundle.js"></script> Whereas another app that needs an older version could use: <script src="/browser/react@17"></script> <script src="/js/my-older-react-bundle.js"></script> And if you don't want to participate in such an initiative (or really want a custom version), you could always make sure that your web server serves the "/browser" directory itself. After all, browser install sizes are already horribly bloated, a few dozen MB will hardly matter at this point, whereas each site needing 1-5 MB of JS is absurd, especially because those are re-downloaded for each of them, despite the fact that most sites out there use one of like 3-5 popular solutions.

KronisLV 4y ago

> The only reason it performed better is because Google would preload over 1MB of Javascript needed to run AMP on its search page. I wonder what he actual metrics are for how often that was used, what % of people chose one of the AMP results, because those were at the top of the list. That preloaded data might be common for most of AMP pages, which is much better than the mess of each site having different React/Angular/Vue bundle versions or even jQuery versions back in the day. As a thought experiment, I wonder how much we could save on bandwidth, if all of the "popular" frameworks/libraries split their base code from each individual application's code (we already have code bundling, after all) and browsers included all of those packages of base code, preloaded. Maybe even follow SEMVER as close as possible, so the browser can always ship the latest minor/patch release for a given major release, to cut down on space needed in the browser. Something along the lines of: <script src="/browser/react@18"></script> <script src="/js/my-app-react-bundle.js"></script> Whereas another app that needs an older version could use: <script src="/browser/react@17"></script> <script src="/js/my-older-react-bundle.js"></script> And if you don't want to participate in such an initiative (or really want a custom version), you could always make sure that your web server serves the "/browser" directory itself. After all, browser install sizes are already horribly bloated, a few dozen MB will hardly matter at this point, whereas each site needing 1-5 MB of JS is absurd, especially because those are re-downloaded for each of them, despite the fact that most sites out there use one of like 3-5 popular solutions.