HTML 압축기

HTML을 굳이 경량화하는 이유

사람이 보려고 작성하는 HTML에는 브라우저가 필요로 하지 않는 것들이 가득합니다. 들여쓰기, 태그 사이의 줄바꿈, 개발자 주석, 이따금 들어 있는 빈 속성 같은 것들이죠. 어느 것도 페이지가 렌더링되는 방식에는 영향을 주지 않지만, 모두 바이트를 더합니다. 그 바이트에 방문자 한 명 한 명과 페이지 로드 하나하나를 곱하면 그 낭비는 실제 대역폭과 실제 대기 시간이 됩니다. 경량화는 겉치레용 문자를 걷어내, 회선을 타고 오가는 마크업을 브라우저가 필요로 하는 만큼만, 그 이하로는 줄이지 않고 작게 만듭니다.

더 작은 HTML은 의미 있는 콘텐츠의 첫 바이트가 더 빨리 오고, 호스팅과 CDN 대역폭 비용이 더 낮으며, 느리거나 데이터 요금이 부과되는 모바일 연결에서 더 나은 경험을 뜻합니다. 트래픽이 많은 사이트에서는 절감 효과가 누적되고, HTML은 브라우저가 가장 먼저 내려받는 리소스이므로 이를 줄이면 페이지가 더 일찍 렌더링되기 시작합니다.

압축기가 걷어내는 것

각 옵션은 비대함의 특정 원인을 겨냥합니다. HTML 주석 제거는 방문자가 결코 보지 않는 개발자 메모와 주석 처리된 코드를 지웁니다. 불필요한 공백 제거는 가독성을 위해서만 존재하는, 태그 사이의 공백, 탭, 줄바꿈의 연속을 축소합니다. 빈 속성 제거는 값이 없는 속성을 떨궈 내고, 선택적 HTML 태그 제거는 일부 문맥에서 목록 항목의 끝 태그처럼 HTML 명세가 생략을 허용하는 닫는 태그를 빼냅니다.

불리언 속성 축소는 작지만 깔끔한 이득입니다. disabled나 checked 같은 속성은 HTML에서 값이 필요 없으므로, disabled에 문자열 disabled를 지정한 풀어 쓴 형태가 속성 이름만으로 짧아집니다. 이 처리들은 함께 렌더링에 전혀 영향이 없는 문자를 제거하며, 그래서 표준 경량화가 잘 구성된 페이지에 안전한 것입니다.

실제 예제

네 칸 들여쓰기와, div 위의 HTML 주석, 그리고 checked에 문자열 checked를 지정해 작성한 체크박스 입력이 들어 있는 조각을 떠올려 보세요. 압축 후에는 들여쓰기와 줄바꿈이 축소되어 태그가 서로 붙고, 주석은 완전히 사라지며, 체크박스는 맨 checked 속성만 단 input으로 단순해집니다. 페이지는 브라우저에서 정확히 똑같이 보이고 동작하지만 바이트 수는 줄어들고, 통계 패널이 원본 크기, 압축 크기, 절감 비율을 보고해 주어 해당 파일에서의 이득을 확인할 수 있습니다.

걷어내도 안전한 것과 위험한 것

지켜야 할 경계는 페이지가 실제로 의존하는 공백입니다. pre와 textarea 요소 안에서는 모든 공백과 줄바꿈이 의미를 가집니다. 그대로 렌더링되므로 축소하면 출력이 눈에 띄게 달라지죠. 같은 주의가 CSS로 white-space를 설정해 서식을 보존하는 요소에도 적용됩니다. 주석은 보통 제거해도 안전하지만, 레거시 Internet Explorer 조건부 주석이나 템플릿 시스템·프레임워크가 표시로 읽는 주석처럼 기능을 지닌 것도 있어, 그런 것을 지우면 동작이 깨질 수 있습니다.

CSS와 JavaScript 경량화 옵션이 실험적이라고 표시된 데는 그만한 이유가 있습니다. style 태그와 속성 안의 인라인 CSS나 script 태그 안의 JavaScript를 경량화하는 일은 단순히 레이아웃 공백을 다듬는 것이 아니라 코드를 다시 쓰는 것이라 예외 상황이 존재합니다. 특히 스크립트가 특정 서식, 주석 기반 지시문, 다루기 까다로운 문자열 처리에 의존한다면 이 옵션을 켠 뒤 반드시 페이지를 테스트하세요.

경량화와 gzip의 관계

서버는 거의 언제나 HTML을 gzip이나 Brotli로 압축해 보내므로, 사람들은 가끔 그래서 경량화가 무의미하다고 짐작합니다. 그렇지 않습니다. gzip은 반복적인 텍스트를 압축하는 데 뛰어나, 경량화된 HTML 위에서 절감하는 상대 비율은 원시 HTML에서보다 작습니다. 하지만 두 기법은 서로 쌓입니다. 경량화 후 gzip 처리한 것이 미려하게 정렬한 후 gzip 처리한 것보다 여전히 더 작죠. 또한 경량화는 압축 해제 후 브라우저가 파싱해야 하는 바이트를 줄이고, 캐시에 저장되는 크기도 줄입니다.

둘을 상호 보완적인 계층으로 생각하세요. 경량화는 브라우저가 필요로 하지 않는 콘텐츠를 제거하고, gzip과 Brotli는 그러고 남은 것을 전송용으로 압축합니다. 둘 다 사용하면 처음부터 끝까지 가장 작은 페이로드가 나옵니다.

빌드 파이프라인에서 경량화가 자리하는 곳

운영 사이트에서는 경량화가 빌드나 배포 단계의 일부로 자동으로 일어나는 것이 이상적입니다. 그러면 편집하는 원본은 읽기 좋게 유지되고 배포하는 출력은 작게 유지됩니다. 대부분의 현대적 번들러와 정적 사이트 생성기에는 HTML 경량화 단계가 포함되어 있으며, 이 도구는 일회성 파일, 손으로 만든 랜딩 페이지, 이메일 템플릿, 곧 끼워 넣을 조각에 대해 같은 일을 빠르게 해 주는 수단입니다.

검사와 학습에도 편리합니다. 페이지를 붙여넣고 실행한 뒤 절감 비율을 읽으면 마크업이 얼마나 군더더기를 짊어지고 있는지 가늠할 수 있고, 이는 과도한 주석이나 깊게 들여쓴 템플릿처럼 원본에서 손볼 만한 습관을 드러낼 수 있습니다.

피해야 할 흔한 실수

가장 치명적인 실수는 공백에 의존하는 콘텐츠를 경량화한 뒤 pre 블록이나 코드 샘플 안의 텍스트가 서식을 잃은 것을 발견하는 것입니다. 그런 부분은 건드리지 말거나 신중하게 확인하세요. 또 다른 실수는 하위 단계가 의존하는 조건부 주석이나 지시문 주석을 걷어내는 것입니다. 더 미묘한 함정은 경량화된 파일을 직접 편집하는 것입니다. 공백이 사라지고 나면 코드를 유지하기 어려우므로, 읽기 좋은 원본을 항상 진실의 원천으로 두고 경량화된 버전은 생성된 산출물로 다루세요. 그리고 실험적인 CSS나 JS 처리를 켤 때마다 배포 전에 실제 페이지를 테스트하세요.