Improving site performance by shipping more CSS

9 comments

• meerita 49 minutes ago
  I don't know how they perceive the performance. I see 41 network requests. That's 2.1 MB of CSS over the wire, blocking rendering and hurting painting and loading speed. There's 400 KB of Tailwind, 87 KB of general CSS, plus another 200 KB of other general CSS. They need to embrace functional CSS properly. I'm sure they could have a single CSS file under 80 KB that renders everything.
  [-]
  • karolusrex 4 minutes ago
    These type of comments often come from a place of arm-chair reasoning where you might not sit on the experience of working hands-on in a large team on a large product. While it’s probably true that X kB sufficient, that amount of performance optimisation is usually not warranted at this scale. Maintaining a design system, working with scoped classes, legacy code, and dealing with the complexities of chunking and probably further challenges we are not aware of from the outside. It seems like a common sentiment on HN (maybe not you in particular) is that engineers should drop everything and work overtime on optimizing performance, when it comes to web apps
• Gualdrapo 1 hour ago
  Once (like a year ago or so) stumbled upon some person's post asking for someone to help them to "fix" some section at their website. It was done !important over !important over !important over !important. Said person was really convinced all it needed was another bunch of !important because apparently that was what ai spit for them, at least at that time
• efortis 1 hour ago
  There's room for improvement still. Currently, the production build is using long-dev class names. e.g. `DirectoryContent-module__Box_3__gl6dE` could be compiled to a shorter hash like `gl6DE3a2`.

  If you use Vite:

    css: {
      modules: {
        generateScopedName: mode === 'production'
          ? '[hash:base64:8]'
          : '[name]__[local]___[hash:base64:5]',
        }
      }

  [-]
  • robin_reala 31 minutes ago
    Those class names surely gzip better than hashes over the wire?
    [-]
    • efortis 12 minutes ago
      Here's a comparison using `brotli --best` on my app.

         53K _long.css
         38K _short.css
      
         11K _long.css.br
        8.9K _short.css.br
      

      Both, dev and prod, have hashes because that's part of what CSS Modules uses to avoid collisions.

      Besides download size, smaller names improve parsing speed too.
    • notpushkin 10 minutes ago
      This.

      The only thing hashing classes achieves is making it difficult for users to use ad blockers and/or custom CSS. I understand why e.g. Meta does it on their sites, but for GitHub it makes no sense.
  • eviks 50 minutes ago
    The improvement would be shipping human-readable structure to allow easier user overrides, not that hash abomination
  • Onavo 59 minutes ago
    Would you need a source map then for prod debugging?
• eviks 53 minutes ago
  Unfortunately the original blog post introducing the great CSS-in-JS system being removed is not in the "Related posts" section, would be nice to compare the thinking in the two
• a11ce 2 hours ago
  Sometimes, [GitHub] posts a [blog post in which they move away from] some terrible [way of doing things] I've never heard before, and it's a weird indirect way to learn how awful their other [design choices] must be.

  https://xkcd.com/2071/

  [-]
• parasti 1 hour ago
  And yet, there's been a glaring overflow bug on every repo page if the repo has a sponsor button on Firefox Android for months.
• varun_chopra 1 hour ago
  Honestly, hats off to them. It's hard to get anything done with Copilot so I'm amazed they even managed to do this.
• jay37184 1 hour ago
  css-in-js? Rofl. Whats next? Html-in-js?
  [-]
  • UqWBcuFx6NV4r 1 hour ago
    Yes.
• IndiaInfraNotes 13 minutes ago
  [flagged]