더 빠른 페이지 로드를 위해 HTML을 축소하는 방법

HTML은 브라우저가 모든 페이지에 대해 가장 먼저 다운로드하는 것입니다. CSS가 스타일을 칠하거나 JavaScript를 실행하기 전에 문서가 도착하여 구문 분석되어야 합니다. 따라서 모든 불필요한 주석, 들여쓰기된 줄 및 태그 사이의 빈 간격은 중요한 경로에서 시간을 소비합니다. HTML을 축소하면 페이지의 모양이나 동작을 변경하지 않고 해당 문자가 제거됩니다. 이 가이드에서는 HTML 크기가 Core Web Vitals에 중요한 이유, 안전한 축소 제거 방법, 구체적인 바이트 전/후 예시, 이를 gzip 또는 Brotli와 결합하는 방법, 작업 흐름에서 축소해야 하는 시기, 절대로 중단해서는 안 되는 사항을 다룹니다.

LCP 및 TTFB에서 HTML 크기가 중요한 이유

Core Web Vitals는 빠르게 느껴지는 페이지를 보상합니다. HTML 크기를 가장 직접적으로 느끼는 두 가지 측정항목은 다음과 같습니다.

• TTFB(Time to First Byte): 브라우저는 구문 분석을 시작하기 전에 HTML 응답을 기다립니다. 문서가 작을수록 생성, 캐시, 전송 속도가 더 빠릅니다. 특히 모바일 네트워크와 멀리 떨어진 CDN에서는 더욱 그렇습니다.
• 콘텐츠가 포함된 최대 페인트(LCP): 기본 콘텐츠를 검색하고 렌더링할 만큼 브라우저에 충분한 HTML(및 중요한 CSS)이 있을 때까지 기본 콘텐츠를 그릴 수 없습니다. HTML 바이트 수가 적다는 것은 첫 번째 의미 있는 페인트 이전에 다운로드 및 구문 분석 작업이 적다는 것을 의미합니다.

HTML은 또한 다른 모든 것의 병목 현상입니다. 브라우저는 문서를 읽어 스타일시트, 스크립트, 이미지, 글꼴을 찾습니다. HTML 스트림이 도착할 때까지 해당 리소스는 표시되지 않습니다. 문서 축소는 이미지 최적화나 코드 분할을 대체하지 않습니다. 그러나 이는 중요한 경로에서 가장 저렴한 승리 중 하나이며 모든 페이지 보기와 결합됩니다.

HTML 축소가 제거하는 것

안전한 HTML 축소 대상 문자는 브라우저가 DOM을 구축할 때 무시합니다. 신중한 축소기는 일반적으로 다음과 같습니다.

• HTML 주석을 제거합니다(필요한 경우 IE 조건부 주석을 유지하는 경우가 많습니다).
• 사람이 가독성을 위해서만 존재하는 들여쓰기, 탭 및 빈 줄과 같은 태그 사이의 공백을 축소합니다.
• 렌더링된 텍스트를 변경하지 않고 마크업이 더 적은 수의 줄로 압축되도록 태그 주위의 불필요한 공간을 자릅니다.
• 마크업의 의미(동일한 요소, 속성, 표시되는 콘텐츠)는 그대로 유지합니다.

하지 않는 일: HTML 축소는 CSS나 JavaScript 압축기가 아닙니다. 인라인 스크립트 및 스타일 블록은 그대로 유지되어야 합니다(또는 전용 JS/CSS 축소기에 전달되어야 함). 또한 속성 값을 변경하거나, URL을 다시 작성하거나, 사용하지 않는 DOM을 제거하지 않습니다. 이는 별도의 최적화입니다.

이전과 이후: 실제 바이트 비교

다음은 대부분의 편집자 및 CMS 내보내기가 생성하는 방식(들여쓰기, 빈 줄 및 개발자 설명 포함) 형식의 작은 랜딩 페이지 조각입니다.

• <!DOCTYPE HTML>
• <html>
• <머리>
• <title>환영합니다</title>
• <!-- 사이트 헤더 -->
• <meta charset="utf-8">
• </head>
• <본문>
• <h1>안녕하세요</h1>
• <p>지금 시작하세요.</p>
• </body>
• </html>

해당 형식의 버전은 196바이트입니다. 축소됨, 주석 및 태그 간 공백이 사라집니다.

작은 조각 하나로 59바이트(약 30%)가 절약되었습니다. 실제 페이지는 더 큽니다. 디자인 도구 내보내기, CMS 템플릿 및 이메일 HTML에는 깊은 중첩, 반복 들여쓰기 및 남은 주석이 포함되는 경우가 많습니다. 이러한 파일에서 축소는 일반적으로 압축이 실행되기 전에 원시 HTML 크기의 15-40%를 자릅니다.

gzip 또는 Brotli와 축소 결합

거의 모든 프로덕션 서버는 이미 gzip 또는 Brotli를 사용하여 HTML을 압축합니다. 이러한 알고리즘은 반복되는 공간을 압축하는 데 탁월합니다. 따라서 축소만으로 인한 유선상의 이득은 원시 바이트 차이보다 작습니다. 축소는 세 가지 이유로 여전히 도움이 됩니다.

• 메모리, 디스크 캐시 및 CDN 원본 스토리지의 압축되지 않은 크기가 더 작습니다.
• 압축을 건너뛰거나 약한 경우에도 압축기 작업이 줄어들고 페이로드가 작아집니다.
• 압축 해제 후 HTML 구문 분석 속도가 빨라집니다. 토크나이저가 수행할 문자 수가 줄어듭니다.

HTML을 축소해야 하는 경우(빌드 및 배포)

마크업을 작성하는 동안이 아닌 프로덕션 단계에서 축소하세요.

• 정적 사이트 및 랜딩 페이지: 호스트 또는 CDN에 업로드하기 전 마지막 빌드 단계로 HTML을 축소합니다.
• 템플릿 및 이메일 HTML: 보내거나 게시하는 내보낸 파일을 축소합니다. 저장소나 ESP에 읽을 수 있는 소스를 유지하세요.
• CMS 또는 디자인 도구 내보내기: 배송되기 전에 비대해진 마크업에 대해 축소기를 한 번 실행합니다.
• 프레임워크 앱: 프로덕션 빌드에서 프레임워크 또는 번들러 HTML 축소 옵션을 선호합니다(많은 앱에서 이미 활성화되어 있음).

소스 제어에서 형식화된 HTML을 유지합니다. 차이점은 계속 읽을 수 있고 리뷰는 건전한 상태로 유지되며 한 줄짜리 문서를 직접 편집할 필요가 없습니다. 축소는 작성 형식이 아닌 출력 변환입니다.

깨지지 말아야 할 것: 스크립트, 스타일, 사전

공격적인 공백 제거는 잘못된 영역에 닿을 경우 페이지를 파괴할 수 있습니다. 안전한 HTML 축소기는 다음을 보호해야 합니다.

• 스크립트: JavaScript에는 개행 문자와 공백이 필요한 경우가 많습니다. <script> 내부를 제거하면 코드가 손상되거나 ASI 동작이 변경될 수 있습니다.
• 스타일: CSS에는 특정 공백이 필요합니다(예: calc()의 + 및 - 주변). 인라인 CSS를 CSS 축소기에 남겨두세요.
• pre 및 textarea: 공백은 의미 있는 콘텐츠입니다. 이를 축소하면 사용자가 보고 복사하는 내용이 변경됩니다.
• 조건부 주석: <!--[if IE]> 블록은 일부 레거시 이메일 및 지원 마크업에서 여전히 사용됩니다. 사용되지 않은 것을 알지 않는 한 보존하십시오.

축소기가 해당 지역에 대해 보수적이라면 신비한 생산 버그 없이 크기 승리를 얻을 수 있습니다. 해당 레이어도 압축하려는 경우 인라인 JS 및 CSS를 전용 축소기에 전달하세요.

자주 묻는 질문

HTML을 축소하면 페이지 모양이 바뀌나요?

아니요, 무사히 끝나면요. 주석을 제거하고 태그 사이의 공백을 축소해도 DOM 구조나 표시되는 텍스트는 변경되지 않습니다. 페이지는 동일하게 렌더링되어야 합니다. 전달된 파일에서는 사람이 읽을 수 있는 형식만 손실됩니다.

HTML 축소는 gzip 압축과 동일합니까?

아니요. 축소는 HTML 텍스트를 더 작은 유효 문서로 다시 작성합니다. Gzip 및 Brotli는 전송을 위해 바이트를 인코딩하며 압축 해제가 필요합니다. 둘 다 사용하십시오. HTML을 축소한 다음 네트워크에서 압축하십시오.

내 페이지가 얼마나 빨리 로드되나요?

원본 HTML이 얼마나 비대한지, 이미지와 스크립트에 비해 HTML이 얼마나 큰지에 따라 달라집니다. 축소는 종종 원시 HTML 바이트의 15-40%를 줄입니다. TTFB 및 LCP에 눈에 띄게 도움이 될 수 있는 HTML이 많은 페이지 또는 모바일 페이지에서 이미지가 많은 페이지에서는 절대 이득은 작지만 여전히 무료입니다.

개발 중에 HTML을 축소해야 합니까?

보통은 그렇지 않습니다. 개발 및 디버그하는 동안 읽을 수 있는 마크업을 유지하세요. 소스를 유지 관리할 수 있도록 프로덕션 빌드 또는 최종 게시 단계에서만 축소하세요.

내 페이지를 업로드하지 않고 온라인으로 HTML을 축소할 수 있나요?

예. 브라우저 기반 HTML 축소기는 장치에서 마크업을 처리하므로 개인 템플릿과 출시되지 않은 페이지가 컴퓨터를 떠나지 않습니다. 결과를 배포 단계에 붙여넣고, 축소하고, 복사하세요.