6 ms·

A single page solution for a site wide issue.

• KevanM 9y ago
  Not that I don't appreciate the efforts that they put in to helping developers--and I'm sure this is for the single-page PWA crowd--but CSS and JS is far more complicated than looking at a single page (especially for big organisations).
  • Swizec 9y ago
    If it's not for this page, then why are you loading it? Load it when the user goes to that other page. That's the idea behind bundle splitting and whatnot. Don't send users code they don't need yet. Most of them are never going to get to the part of the page that does need that code.
    • lucaspiller 9y ago
      Depending on what you are loading it may be more efficient to bundle everything in one file. If you are only loading a few kb per page, the overhead and extra time required for the network requests mean it's probably not worth splitting code.
      • amelius 9y ago
        > it may be more efficient In many cases it may not. Remember that you have to fetch data anyway when loading a new page. You could load the new parts of the CSS on the same connection.
        • dddddaviddddd 9y ago
          Especially over HTTP/2
      • danhardman 9y ago
        Agreed. I often find the extra initial loading time is worth the improved user experience across the rest of the website once the bundles CSS file is cached.
      • Swizec 9y ago
        Yep, I agree. Optimization is about tradeoffs :) At my day job we use app splitting rather than page splitting. Instead of breaking our codebase into individual pages and loading only those files, it's broken into apps. So you might load too much stuff for what you're currently doing, but you're never loading code that's completely unrelated. A downside to that is that if you hit all our apps in one browsing session, you might download some vendor libraries like 10 times. But it's unlikely that a real user would ever do that.
        • eterm 9y ago
          > you might download some vendor libraries like 10 times That reminds me that I once found 3 versions of jquery (or perhaps jquery-ui, my memory fades) linked from the same page. One was linked in the master (yes, this was webforms), one was being injected through a user control and the last was written into the page. All three were all different versions so were all being downloaded. This came to light when a controls stopped working when one version was 'updated'.
        • lucaspiller 9y ago
          We do something similar, but common code is shared. Webpack has a feature called chunking which we use to put everything from node_modules into it's own bundle which is loaded across multiple apps. Then the app specific code is loaded on each page. https://webpack.js.org/plugins/commons-chunk-plugin https://webpack.js.org/plugins/commons-chunk-plugin It does result in code being loaded when it isn't always needed, but in our case most libraries are used in every app.
    • corobo 9y ago
      Because now the entire thing is loaded into the browser cache and doesn't need loading at all across the entire site
      • hinkley 9y ago
        Also you don't have the combinatorial explosion of making sure that the CSS for the new sidebar/footer/reusable element is available every time it appears in a page. It also simplifies debugging specificity issues a little (but shuffles the problem around a bit).
• abraham 9y ago
  The tool will record over multiple pages. As you navigate to additional pages the numbers will be updated to include code usage on the new page.
• paulirish 9y ago
  This is now fixed. ;) The Coverage panel in Chrome 59 is the debut, but it's gotten a lot of improvements since then. In Chrome Beta (or you can always look in Canary), the data is reported live as things happen, and indeed results do aggregate across different page navigations. Which is what you would expect. Demo: https://zippy.gfycat.com/PopularWarmCoqui.mp4 https://zippy.gfycat.com/PopularWarmCoqui.mp4
• geuis 9y ago
  https://github.com/geuis/helium-css https://github.com/geuis/helium-css