HTML Minifier 벤치마크 — 48개 사이트에서 어떤 도구가 이겼나

한 줄 결론부터

48개 실제 사이트(Apple, BBC, Google, MDN 등)로 돌린 벤치마크 결과를 상황별로 뽑으면 이렇다.

• 압축률이 최우선이다 → htmlnano (aggressive 모드에서 평균 −13.8%)
• 속도가 최우선이다 → minify-html (평균 8ms)
• 무난한 균형이 필요하다 → HTML Minifier Next
• 프로젝트가 이미 SWC 파이프라인이다 → @swc/html

왜 이 비교가 의미 있나

HTML을 압축하는 건 JS/CSS 압축만큼 흔하지는 않다. 하지만 정적 사이트나 SSR 결과물에서 HTML이 수백 KB를 차지하는 경우가 많고, 이 부분을 줄이면 초기 렌더 시간이 실제로 줄어든다. 문제는 HTML 압축 도구마다 철학이 달라서, 같은 "HTML 미니파이어"라는 이름 아래 압축률 차이가 두 자릿수 퍼센트까지 벌어진다는 점이다.

비유하면, 미니파이어는 이삿짐 포장 업체 같은 거다. 어떤 업체는 박스에 여유를 두고 안전하게 싸고, 어떤 업체는 공간을 쥐어짜서 박스 수를 줄인다. 결과물(목적지에 도착한 짐)이 같아 보여도, 박스 수가 다르고 포장 시간도 다르다. 도구 선택은 결국 "안전 여유 vs 부피 감소 vs 포장 시간" 중 어느 쪽에 가중치를 둘지의 문제다.

[💡 잠깐! 이 용어는?] 미니파이케이션(Minification): 코드의 동작을 바꾸지 않으면서 파일 크기만 줄이는 최적화. HTML에선 공백 제거, 주석 제거, 선택적 속성 축약 등이 해당한다. 너무 공격적으로 줄이면 렌더링이 깨질 수 있어서 "안전한 기본값"과 "공격적 모드"를 구분한다.

벤치마크 대상 도구

6개 도구가 대상이다. 각각 출신과 구현 언어가 다르다.

벤치마크 방법론

같은 48개 실제 사이트를 두 모드로 돌린다.

1. HTML 전용 모드 — "렌더 결과가 깨지지 않는 선"에서 가장 공격적인 설정
2. Max 모드 — 각 도구가 제공하는 모든 기능을 활성화 (공정 비교는 아니지만 상한선 확인용)

[💡 잠깐! 이 용어는?] 공정 비교(Apples-to-apples): 비슷한 조건에서 돌린 비교. 이 벤치마크의 Max 모드는 도구마다 활성화 기능이 달라서 공정 비교가 아니다. 참고용으로만 봐야 한다.

HTML 전용 모드 결과

평균 베이스라인은 374KB다. 보수적 설정에서의 압축률이다.

보수적 모드에서는 HTML Minifier Next가 압축률 1위다. 속도까지 고려하면 minify-html이 균형이 좋다. 30배 빠르면서 압축률 차이는 1%대다.

htmlcompressor.com이 754ms로 가장 느린 건 원격 API 호출이라 네트워크 왕복이 들어가기 때문이다. 빌드 파이프라인에 넣는 건 편의점 다녀오는 데 택시를 부르는 격이다. 가까운 거리를 매번 차 여행으로 돌리면, CI 시간이 무너진다.

Max 모드 결과

공격적 설정에서는 순위가 바뀐다.

htmlnano가 공격적 모드에서 확실히 앞선다. 특히 극단적인 케이스에서는 차이가 훨씬 크다.

• French Tech 사이트: 156 KB → 55 KB (−65.1%)
• Opera.com: 231 KB → 109 KB (−52.7%)

공백과 주석만 지우는 게 아니라 선택적 태그까지 정리하는 수준이다.

포인트: 공격적 모드는 테스트 필수다. htmlnano의 aggressive 설정은 선택적 닫는 태그를 생략하거나, 공백이 의미 있는 <pre> 주변을 건드릴 수 있다. 설정을 조절하면서 렌더 결과가 깨지지 않는지 봐야 한다.

각 도구별 상세

htmlnano

PostHTML 위에 만들어진 플러그인 기반 도구다. 기본값은 보수적이지만, 옵션을 켜면 공격적 최적화가 된다.

import htmlnano from 'htmlnano'
 
const options = {
  collapseWhitespace: 'aggressive',
  removeComments: 'all',
  removeOptionalTags: true,
  minifyCss: true,
  minifyJs: true,
}
 
const result = await htmlnano.process(html, options)
console.log(result.html)

고려할 만한 케이스: 정적 사이트 생성기의 후처리, 빌드 시간이 덜 중요한 경우.

주의할 점: removeOptionalTags: true는 <li>나 <tr>의 닫는 태그를 지울 수 있다. 이 자체는 HTML5 스펙에 맞지만, CSS 셀렉터나 DOM 파싱 로직이 이를 전제하면 깨진다. 집의 벽지를 뜯어내면 면적은 줄어들지만 벽 뒤에 붙여놨던 포스트잇이 같이 사라지는 느낌이다. 공간이 확보된 건 맞는데, 뭘 잃었는지는 나중에야 발견된다.

minify-html

Rust로 쓰여 있고 Node 바인딩을 제공한다. 속도가 가장 중요한 선택이다.

import { minify } from '@minify-html/node'
 
const minified = minify(Buffer.from(html), {
  minify_css: true,
  minify_js: true,
  keep_spaces_between_attributes: false,
})

고려할 만한 케이스: 대규모 정적 사이트, CI 빌드 시간 최적화가 중요한 프로젝트, SSR 응답 압축 미들웨어.

주의할 점: 기본값에서도 꽤 공격적이다. 프로덕션 적용 전에 주요 페이지를 eyeball 테스트해야 한다.

HTML Minifier Next

html-minifier가 유지보수 중단된 뒤 포크돼 업데이트를 재개한 프로젝트다. API가 기존 도구와 호환되어서 마이그레이션 비용이 낮다.

import { minify } from 'html-minifier-next'
 
const result = await minify(html, {
  collapseWhitespace: true,
  removeComments: true,
  minifyCSS: true,
  minifyJS: true,
})

고려할 만한 케이스: 기존에 html-minifier를 쓰던 프로젝트의 자연스러운 교체.

@swc/html

SWC 생태계의 HTML 미니파이어다. SWC를 이미 쓰고 있다면 도구 파편화를 줄일 수 있다.

주의할 점: Google 홈페이지를 처리할 때 오히려 57.8% 커지는 이상 현상이 관찰됐다. 엣지 케이스 처리가 아직 완벽하지 않다는 신호다. 기본 설정 그대로 믿지 말고 샘플 페이지에서 검증해야 한다.

선택 체크리스트

"예"가 많은 쪽이 답이다. 답이 여러 개면 minify-html부터 시작해서 필요할 때 htmlnano로 옮기는 게 현실적이다.

마무리

HTML 미니파이어는 "다 비슷비슷하겠지"라고 생각하기 쉽지만, 실제로 도구 간 차이가 압축률 5%대, 속도 수십 배 차이가 난다. 특히 공격적 모드는 도구마다 철학이 달라서 렌더 결과에 영향을 줄 수 있다.

• 대부분의 경우 minify-html이 균형 좋은 기본값
• 압축률을 쥐어짜야 한다면 htmlnano + 공격적 옵션
• 이미 html-minifier를 쓰고 있으면 HTML Minifier Next로 자연스럽게
• 공격적 옵션을 켤 때는 반드시 렌더 테스트

그리고 제일 좋은 방법은, 자기 프로젝트의 가장 큰 페이지 몇 개를 직접 돌려보는 거다. 벤치마크 평균은 참고일 뿐이고, 압축률과 안정성은 콘텐츠 특성에 따라 크게 달라진다.

참고:

• HTML and web page minification benchmarks: https://github.com/j9t/minifier-benchmarks
• htmlnano: https://htmlnano.netlify.app/
• minify-html: https://github.com/wilsonzlin/minify-html
• HTML Minifier Next: https://github.com/terser/html-minifier-terser