깃허브가 버린 CSS-in-JS, CSS Modules로 넘기니 SSR 시간 55% 감소

깃허브 블로그에선 항상 저런 지독한 방식에서 벗어났다는 글이 올라오는데, 정작 그 전에 그렇게 만들었다는 걸 우회적으로 배우게 돼서 기분이 묘함.

한때 사이트 한 섹션 고쳐달라는 글을 봤는데 코드가 !important 천지였음. 거기다 AI가 알려준 방법이라며 또 !important를 때려넣자는 식이더라.

매일 깃허브를 쓰는데 체감이 잘 안 된다. 그런데 리포에 스폰서 버튼이 붙어 있으면 파이어폭스 안드로이드에서 몇 달째 오버플로우 버그가 그대로임.

프로덕션 빌드에 아직도 긴 개발용 class name을 그대로 쓰고 있더라. generateScopedName 설정으로 DirectoryContent-module__Box_3__gl6dE 같은 걸 gl6DE3a2 같은 짧은 해시로 바꾸면 됨.

그럼 프로덕션 디버깅하려면 소스맵을 따로 챙겨야 하는 거 아님?

오히려 사람이 읽을 수 있는 구조를 남겨서 사용자가 스타일 덮어쓰기 쉽게 하는 게 올바른 방향이지. 해시 덩어리는 거기서 못 씀.

그 class name들이 해시보다 전선상에서 gzip으로 더 잘 압축되는 거 아닌가?

sx를 소개한 원 글이 Related posts에 안 붙어 있는 건 아쉽네. 두 글을 놓고 비교해서 읽고 싶었는데.

성능이 어디서 개선됐다는 건지 모르겠어. 프로덕션에서 네트워크 요청이 41개에 CSS가 전선상 2.1MB라 렌더링을 막고 있거든. 80KB짜리 CSS 파일 하나로 충분할 텐데.

이런 비판은 대규모 팀에서 대규모 제품을 직접 만져본 경험이 없어서 나오는 말일 수 있음. 디자인 시스템 유지에 스코프 class, 레거시 코드, 청킹 문제까지 얹히면 그 정도 최적화에 매달릴 여유가 없음.

참고로 비슷한 사이트를 훑어봤는데 sourcehut는 원본 128KB에 전선상 28KB, codeberg는 원본 420KB에 전선상 66KB 정도라.

CSS in JS 비판하면서 CSS Modules로 옮겼다는 글 볼 때마다 아쉬워. vanilla-extract처럼 JS 런타임을 아예 안 보내면서 TypeScript 지원까지 챙길 수 있거든.

CSS in JS의 요점은 빌드 시점에 JS로 CSS를 만들어서 정리된 산출물을 뽑는 거였는데, 대체 누가 런타임에서 돌리는 거람.

난 매일 쓰는데 성능이 나아졌다는 느낌이 전혀 안 들어. 댓글 수가 많은 이슈나 큰 PR 열면 로딩이 엉망이라 차라리 느려진 것 같아.

데스크톱도 몇 년째 확실히 미끄러지고 있음. 컨플릭트 풀고 머지 가능한지 확인하는 데가 몇 분씩 걸리는 경우도 있던데 UI랑은 무관해 보여도 이상하더라.