CSS 축소(minify), 정말 해야 할까? 2KB를 위해 잃는 것들
한 줄 요약
공백과 주석만 제거하는 CSS 축소는 성능 이득이 거의 없습니다. gzip이나 Brotli 압축만 적용해도 충분하며, 축소를 추가해서 얻는 건 고작 몇 KB인 반면 코드 가독성은 완전히 잃게 됩니다.
여기서 말하는 '축소'란?
먼저 용어를 정리하고 넘어가겠습니다. 이 글에서 다루는 축소(minification)는 다음을 의미합니다.
- 포함: 모든 공백과 주석 제거
- 제외: 중복 규칙 제거, 선택자 결합 같은 구조적 최적화
즉, 코드를 실질적으로 개선하는 최적화가 아니라 단순히 문자를 걷어내는 작업만 놓고 이야기합니다.
실제로 얼마나 줄어들까?
CSS-Tricks가 소개한 Bootstrap 사례를 보면 숫자가 명확해집니다.
| 처리 방식 | 크기 | |---|---| | 원본 | 147KB | | gzip만 적용 | 22KB | | 축소 + gzip | 20KB |
gzip 하나만으로 이미 147KB → 22KB, 약 85%가 사라집니다. 여기에 축소를 더해봐야 추가 절감은 2KB에 불과합니다. 그것도 Bootstrap이라는 대형 라이브러리 기준으로요.
이 2KB를 다른 것과 비교해 보면 감이 옵니다. 해당 CSS-Tricks 페이지는 압축된 HTML만 38KB이고, 전체 압축 전송량은 1.80MB입니다. 2KB는 전체의 0.1%대에 불과한 셈이죠.
파싱 속도는 어떨까?
"다운로드는 그렇다 쳐도, 브라우저가 공백을 읽느라 느려지지 않을까?"라는 의문이 남습니다. 이를 확인하기 위한 실험이 진행됐습니다.
실험 방법
- URL로 난수 시드와 선언 블록 개수를 받아 무작위 스타일시트를 생성
- 임의 공백의 포함 여부를 선택 가능
- 문서에
<link>를 삽입한 시점부터load이벤트 발생까지만 측정
결과
- 선언 블록 10,000개 → 9~10ms
- 선언 블록 100,000개 → 95~105ms
- 현실적인 규모인 1,000개 → 차이를 측정하기조차 어려움
공백 유무에 따른 차이는 데스크톱과 휴대전화 모두에서 미미했습니다. 애초에 100,000개 블록이라는 비현실적인 규모에서도 100ms 안팎이라는 점에 주목할 만합니다.
저사양 기기에서도 마찬가지
"고사양 기기라서 그런 거 아닐까?"라는 반론에 대비해, 더 현실적인 조건의 테스트도 진행됐습니다.
동일한 서버에 크기·주석·축소 여부만 다른 CSS를 배치하고 같은 HTML 페이지를 올린 뒤, 여러 기기·연결·브라우저에서 WebPageTest를 돌린 결과입니다.
- 저사양 기기 + 느린 연결 환경에서 최대 차이는 1,000개 블록에서 54ms
- 흥미롭게도 100,000개 블록에서는 오히려 차이가 더 작았음
큰 스타일시트일수록 차이가 줄어든다는 건, 이 차이가 축소 효과라기보다 측정 노이즈에 가깝다는 신호로 읽을 수 있습니다.
그래서 무엇을 잃는가
성능 이득이 미미하다면, 반대편의 비용을 따져봐야 합니다.
- 학습 자원의 훼손: 다른 웹페이지의 소스를 들여다보는 일은 HTML과 CSS를 배우는 훌륭한 방법입니다. 축소는 이 경로를 막아버립니다.
- 불필요한 빌드 단계: 관리하고 디버깅해야 할 파이프라인이 하나 늘어납니다.
- 개발자 도구로 충분함: 브라우저에는 이미 코드 정리(pretty-print) 기능이 있어, 읽기 좋은 형태로 되돌리는 별도 처리 단계를 둘 이유도 없습니다.
정리하며
결론은 명확합니다.
밀리초 단위 개선마다 수백만 달러가 걸린 대기업이면서, 동시에 스타일시트의 신호 대 잡음비가 극단적으로 낮은 경우가 아니라면 — gzip 또는 Brotli 압축만으로 충분합니다.
두 조건이 모두 해당되는 팀은 생각보다 훨씬 적습니다. 대부분의 프로젝트에서 CSS 축소는 눈에 보이지 않는 이득을 위해 눈에 보이는 가독성을 지불하는 거래에 가깝습니다.
혹시 지금 빌드 파이프라인에 CSS 축소 단계가 있다면, 한번 물어보세요. "이걸로 우리가 실제로 얻는 게 뭐지?" 서버 압축 설정을 확인하는 편이 훨씬 큰 효과를 낼지도 모릅니다.