HTML 축소는 HTML, CSS 및 JavaScript에서 공백, 주석 및 불필요한 문자를 제거하여 동일한 코드가 더 적은 바이트에 도달하도록 하는 단계입니다. 그것은 효과가 있으며, 먼저 도달하는 것은 거의 항상 잘못된 것입니다.
서버 압축은 소스를 건드리지 않고 대부분의 동일한 바이트를 복구하며 휴대폰에서 직접 저장한 단일 이미지의 무게는 페이지의 모든 스크립트와 스타일시트를 합친 것보다 더 큽니다.
이 가이드에서는 중요한 순서, 축소로 저장되는 항목, 압축으로 저장되는 항목, 문서를 축소해야 하는 경우에 대해 설명합니다.
<!-- before -->
<div class="card">
<h2>Weekly overview</h2>
<p>Signups rose.</p>
</div>
<!-- after -->
<div class="card"><h2>Weekly overview</h2><p>Signups rose.</p></div>
동일한 페이지, 더 적은 바이트. 그런 다음 서버는 응답을 압축하고 반복되는 공백에서 압축은 매우 우수합니다. 축소 제거의 상당 부분은 어쨌든 비용이 거의 들지 않습니다.
그렇다고 해서 쓸모가 없는 것은 아닙니다. 평판이 시사하는 것보다 더 작은 레버를 만들고 더 큰 레버를 다음에 수행할 가치가 있습니다.
축소 전 중요한 순서
| 레버 | 전형적인 효과 | 노력 |
|---|---|---|
| 이미지를 적절하게 압축하세요 | 대형 | 낮음 |
| Brotli 또는 gzip 활성화 | 대형 | 하나의 구성 라인 |
| 외부 종속성 제거 | 중대형 | 낮음 |
| 오프스크린 이미지 연기 | 중간 | 하나의 속성 |
| CSS 및 JS 축소 | 작은 | 빌드 단계 |
| HTML 축소 | 가장 작은 | 빌드 단계 |
이미지는 크기순으로 볼 때 거의 항상 페이지에서 가장 큰 것입니다. 하나의 압축되지 않은 스크린샷과 완벽하게 축소된 마크업이 있는 페이지는 느린 페이지입니다.
진정한 승리는 압축이다
Content-Encoding: br
대체 수단으로 gzip을 사용하는 Brotli. 둘 다 어디에서나 지원되며 일반적으로 서버 또는 전달 네트워크의 단일 구성 라인으로 활성화됩니다.
일단 켜져 있으면 텍스트를 더욱 축소하는 것은 수익이 감소하는 것입니다. 즉, 이미 압축된 내용을 압축하는 것입니다.
먼저 고쳐야 할 것
압축하기 전에 크기 조정
가장 흔한 낭비: 800픽셀 열에 4000픽셀 이미지가 표시되는 것입니다. 브라우저는 4,000개의 픽셀을 모두 다운로드하고 그 중 4분의 3을 삭제합니다. 디스플레이 너비의 약 2배로 크기를 조정합니다.
큰 이미지를 삽입하지 마세요.
base64 이미지는 크기의 1/3을 추가하고 더 나쁜 경우 전체 문서가 도착할 때까지 페이지 렌더링을 차단합니다. 이미지가 많은 경우에는 별도의 파일을 사용하세요.
<img src="chart.webp" alt="Signups by source" width="1600" height="1000" loading="lazy">
loading="lazy"는 스크롤 없이 볼 수 있는 부분의 모든 내용을 연기합니다. width 및 height는 이미지가 도착할 때 페이지가 점프하지 않도록 공간을 예약합니다.
기하학적인 것이라면 SVG를 선호하세요
인라인 SVG는 일반적으로 동등한 사진보다 작고 어떤 확대/축소에서도 선명하며 요청이 전혀 필요하지 않습니다.
페이지가 다른 곳에서 가져오는 내용을 제거하세요.
차트 라이브러리와 글꼴 서비스는 전체 페이지보다 클 수 있으며 각각은 귀하가 제어할 수 없는 곳에 대한 요청입니다. 이를 div 및 시스템 글꼴 스택으로 대체하면 더 작고 내구성이 향상됩니다. 자체 포함 HTML을 참조하세요.
축소가 진정으로 도움이 되는 경우
매우 큰 반복 마크업. 1,000개의 테이블 행이 있는 페이지에는 실제 중복성이 있지만 데이터 배열에서 해당 행을 생성하는 것이 더 나은 해결 방법입니다.
크기가 제한된 장소에 있는 페이지. 그러면 모든 바이트는 성능 문제가 아니라 제약이 됩니다.
댓글이 많은 긴 CSS. 댓글은 제작 시 순수한 오버헤드입니다.
손으로 축소하지 마세요.
<!-- do not do this to your source -->
<div class=card><h2>Weekly overview</h2><p>Signups rose.
축소된 소스는 유지 관리가 불가능하며 3개월 후에는 귀하가 이를 읽을 수 있습니다. 축소는 읽을 수 있는 소스를 가져와 압축된 출력을 생성하는 빌드 단계에 속합니다.
빌드 단계가 없으면 소스를 읽을 수 있는 상태로 둡니다. 압축된 연결과의 차이는 작으며 읽을 수 있는 마크업의 가치는 수백 바이트 이상입니다.
축소된 페이지와 이를 편집해야 하는 사람
축소된 파일은 하나의 긴 줄입니다. 동일하게 렌더링되므로 사람이 읽거나 수정할 수 없습니다.
손으로 편집하거나 동료가 텍스트를 클릭하여 수정하는 페이지의 경우 읽을 수 있는 소스는 유지되어야 하며 축소가 발생하는 경우 작업하는 파일이 아닌 빌드 단계를 종료하는 도중에 발생해야 합니다.
실제로 문서 페이지를 느리게 만드는 이유
순서대로: 카메라 크기로 저장된 이미지, 응답 속도가 느린 주소에서 로드된 글꼴, 외부 라이브러리를 기다리는 스크립트, 아무것도 표시하기 전에 브라우저에서 스스로 조립되는 페이지입니다.
마크업의 공백이 목록에 없습니다. 크기가 조정된 이미지, 시스템 글꼴 스택 및 그 안에 있는 스크립트가 포함된 독립된 페이지는 축소 없이 빠르며 나중에 축소하면 압축으로 절약할 수 있는 몇 퍼센트가 절약됩니다.
올바른 순서로 페이지를 더 가볍게 만들기: 4단계
- 먼저 이미지의 크기를 조정하고 압축합니다. 여기에 바이트가 있습니다. 메가바이트 미만의 페이지는 일반적으로 모두 이미지입니다. 포트폴리오 가이드는 산술을 보여줍니다.
- 서버가 텍스트를 압축하는지 확인하세요. HTML, CSS 및 JS의 gzip 또는 brotli. 대부분의 호스트는 기본적으로 이를 수행합니다. 응답 헤더에 그렇게 나와 있습니다.
- 빌드된 항목만 축소하고 소스를 읽을 수 있도록 유지하세요. 빌드 단계는 도중에 축소될 수 있습니다. 귀하가 직접 편집하거나 동료가 클릭하여 수정하는 페이지는 읽을 수 있는 상태로 유지되어야 합니다.
- 전후를 측정하세요. 네트워크 패널에 전송된 바이트가 표시됩니다. 숫자가 거의 움직이지 않으면 무게가 다른 곳에 있는 것입니다.