텍스트 기반 애셋의 인코딩 및 전송 크기 최적화

Ilya Grigorik
Ilya Grigorik
X 홈페이지
Jeremy Wagner

불필요한 리소스를 다운로드하는 것 외에 페이지 로드 속도 향상은 최적화로 전체 다운로드 크기를 최소화하는 것입니다. 압축하는 과정입니다

데이터 압축 101

사용하지 않는 리소스를 다운로드하지 않도록 웹사이트를 설정한 후에는 다음 단계는 브라우저가 보유한 나머지 적격 리소스를 다운로드 리소스 유형(텍스트, 이미지, 글꼴 등)에 따라 사용할 수 있습니다. 선택할 수 있는 다양한 기법이 있습니다. 웹 서버에서 사용 설정되며, 특정 콘텐츠에 대한 전처리 최적화가 유형, 리소스별 최적화를 통해 있습니다.

최상의 실적을 제공하려면 다음 조건을 모두 충족해야 합니다. 기술:

  • 압축은 더 적은 비트를 사용하여 정보를 인코딩하는 프로세스입니다.
  • 불필요한 데이터를 제거하면 항상 최상의 결과를 얻을 수 있습니다.
  • 다양한 압축 기술과 알고리즘이 있습니다.
  • 최상의 압축을 달성하려면 다양한 기술이 필요합니다.

데이터 크기를 줄이는 프로세스를 데이터 압축이라고 합니다. 많은 사람들이 압축 개선을 위해 알고리즘, 기술, 최적화를 제공했습니다. 비율, 압축 속도, 다양한 압축에 필요한 메모리와 같은 사용할 수 있습니다.

데이터 압축에 대한 자세한 설명은 이 가이드의 범위를 벗어납니다. 그러나 압축이 어떻게 작동하는지 개략적으로 이해하는 것이 중요합니다. 페이지에 삽입되는 다양한 자산의 크기를 줄이는 데 사용할 수 있는 기술을 살펴봤습니다

이러한 기술의 핵심 원칙을 설명하기 위해 이를 위해 고안된 간단한 텍스트 메시지 형식을 최적화했습니다.

# Below is a secret message, which consists of a set of headers in
# key-value format followed by a newline and the encrypted message.
format: secret-cipher
date: 08/25/16
AAAZZBBBBEEEMMM EEETTTAAA
  1. 메시지에는 임의의 주석이 포함될 수 있으며, 이러한 주석은 댓글을 '#'으로 표시 를 입력합니다. 주석은 메시지 또는 메시지 동작을 파악할 수 있습니다
  2. 메시지에는 키-값 쌍('헤더'로 구분됨)인 헤더가 ":")이 메시지 시작 부분에 표시됩니다.
  3. 메시지에는 텍스트 페이로드가 포함됩니다.

다음에서 시작하는 이전 메시지의 크기를 줄이기 위해 수행할 수 있는 작업은 200자(영문 기준)?

  1. 댓글이 흥미롭지만 메시지의 의미에는 영향을 미치지 않습니다. 메시지를 전송할 때 이를 제거합니다.
  2. 헤더를 효율적인 방식으로 인코딩하는 좋은 기법이 있습니다. 대상 모든 메일에 '형식'이 있음을 알고 있는 경우 'date'를 지정하면 할 수 있습니다 이를 짧은 정수 ID로 변환하고 전송하기만 하면 됩니다 하지만 따라서 현재로서는 그대로 두는 것이 가장 좋습니다.
  3. 페이로드는 텍스트 전용입니다. 실제로 어떤 내용이 포함되어 있는지는 모르지만 "secret-cipher"를 사용하고 있는 것처럼 보이지만 많은 중복성이 있음을 보여줍니다. 예를 들어 반복되는 문자의 수만 세고 보다 효율적으로 인코딩할 수 있습니다. 예를 들어 "AAA"는 "3A"이 됩니다. 세 개의 A의 시퀀스를 나타냅니다.

이러한 기법을 조합하면 다음과 같은 결과가 생성됩니다.

format: secret-cipher
date: 08/25/16
3A2Z4B3E3M 3E3T3A

새 메시지는 길이가 56자입니다. 이는 원본 메시지를 72% 늘릴 수 있었습니다. 상당한 감소입니다.

이는 압축 알고리즘이 어떻게 압축되고 텍스트 기반 리소스의 전송 크기 줄이기 실제로 압축은 알고리즘은 이전 예에서 보여주는 것보다 훨씬 더 정교하며 웹에서는 압축 알고리즘을 사용하여 시간을 절약할 수 있습니다 텍스트 기반 자산에 압축을 적용하면 웹페이지는 리소스 로드 시간을 줄일 수 있으므로 리소스의 효과를 리소스를 압축하지 않았을 때보다 더 빨리 작업할 수 있습니다

축소: 사전 처리, 컨텍스트별 최적화

여기서 설명하는 첫 번째 기술은 축소입니다. 축소는 가능하지 않지만 이는 엄밀히 말하면 압축 알고리즘으로서 불필요하고 압축 알고리즘이 리소스 가독성을 높이기 위해 소스 코드에 사용되는 중복 문자 있습니다. 하지만 기능을 유지하는 데 가독성이 필요하지는 않습니다. 해당 소스 코드의 로드를 지연하거나 찾을 수 있습니다.

축소는 콘텐츠별 최적화의 한 유형으로, 제공되는 리소스의 크기를 줄일 수 있으며, Google Cloud 리소스를 사용할 수 있습니다 예를 들어, 번들러는 리소스를 자동으로 축소할 수 있는 일반적인 소프트웨어 유형으로, 30%의 응답률을 나타냅니다.

중복되거나 불필요한 데이터를 압축하는 가장 좋은 방법은 이를 제거하는 것입니다. 그러나 임의의 데이터만 삭제할 수는 없습니다. 그러나 어떤 상황에서는 데이터 형식과 그 속성에 대한 콘텐츠별 지식이 있다면 전송에 영향을 주지 않으면서 페이로드의 크기를 실제 의미 또는 능력입니다.

<html>
  <head>
    <style>
      /* awesome-container is only used on the landing page */
      .awesome-container {
        font-size: 120%;
      }

      .awesome-container {
        width: 50%;
      }
    </style>
  </head>
  <body>
    <!-- awesome container content: START -->
    <div>
      This is my awesome container, and it is <em>so</em> awesome.
    </div>
    <!-- awesome container content: END -->
    <script>
      awesomeAnalytics(); // Beacon conversion metrics
    </script>
  </body>
</html>

앞서 살펴본 HTML 스니펫과 스니펫에 포함된 3가지 다른 콘텐츠 유형을 포함:

  1. HTML 마크업
  2. 페이지의 프레젠테이션을 맞춤설정하는 CSS입니다.
  3. 상호작용 및 기타 고급 페이지 기능을 강화하는 JavaScript

이러한 콘텐츠 유형마다 유효한 콘텐츠를 구성하는 항목에 대해 코멘트 지정을 위한 다른 규칙 등이 있습니다. 질문 '이 페이지의 크기를 어떻게 줄일 수 있는가?'입니다.

  • 코드 주석은 개발자에게 가장 친한 친구이지만 브라우저는 있습니다! CSS (/* ... */), HTML (<!-- ... -->), 자바스크립트 제거 (// ...) 댓글이 페이지의 총 전송 크기와 하위 리소스도 제공합니다
  • '스마트함' CSS 압축 프로그램은 우리가 .awesome-container의 규칙을 정의하고 두 선언을 축소합니다. 다른 스타일에 영향을 미치지 않고 하나로 변환하여 더 많은 바이트를 절약합니다. 넓은 이러한 종류의 중복성을 제거하는 것은 누적될 수 있지만 그렇지 않을 수도 있습니다. 공격적으로 적용할 수 있는 것이어야 합니다. 서로 다른 컨텍스트(예: 미디어 쿼리 내에서)에서 반드시 중복되지 않습니다.
  • 공백과 탭은 HTML, CSS, JavaScript에서 개발자의 편의를 위한 것입니다. 추가 압축기를 사용하면 모든 탭과 공백을 제거할 수 있습니다. 다른 앱과의 중복 삭제 기법을 사용하는 경우 이러한 종류의 최적화는 공정하게 적용할 수 있습니다. 필요한 경우 이러한 공백이나 탭이 페이지의 예를 들어, 반복 레이어의 실행 내에 있는 공간을 보존하려는 사용자가 콘텐츠를 쉽게 읽을 수 있도록 하기 때문에 보게 될 것입니다.
<html><head><style>.awesome-container{font-size:120%;width:50%}</style></head><body><div>This is my awesome container, and it is <em>so</em> awesome.</div><script>awesomeAnalytics()</script></body></html>

이전 단계를 적용하면 페이지가 516자에서 204자로 줄어들어 약 60%의 비용을 절감합니다 물론 읽기가 쉽지는 않지만 사용할 수 있도록 하기 위해 반드시 그런 것은 아닙니다. 또한 최신 개발 관행은 형식이 올바르고 읽기 쉬운 버전의 소스 코드를 유지할 수 있음 분리하는 것이 중요합니다 결합됨 소스 맵 - 변환된 파일의 읽기 가능한 표현을 제공합니다. 프로덕션 코드를 사용하면 프로덕션 환경의 버그 문제를 더 쉽게 해결할 수 있습니다. 우수한 개발자 환경을 제공하는 동시에 성능을 최적화할 수 있습니다 사용자 경험을 개선해야 합니다.

<ph type="x-smartling-placeholder">

앞의 예는 중요한 사항인 범용 예를 들어 임의의 텍스트를 압축하도록 설계된 압축 프로그램은 압축하는 작업일 수 있지만 압축되는 것을 CSS 규칙 접기, 또는 수십 개의 다른 콘텐츠별 최적화할 수 있습니다 이것이 바로 사전 처리, 축소 및 기타 컨텍스트 인식 중요합니다

<ph type="x-smartling-placeholder">

마찬가지로, 위에서 설명한 기법은 단순히 텍스트 기반 모델을 넘어 확장될 수 있습니다. 합니다. 이미지, 동영상, 기타 콘텐츠 유형은 모두 고유한 형식의 메타데이터 및 다양한 페이로드가 있습니다 예를 들어, 컴퓨터로 사진을 찍을 때마다 카메라 파일을 사용하는 경우, 파일에는 일반적으로 카메라 설정, 지정할 수 있습니다. 애플리케이션에 따라 이 데이터는 완전히 쓸모가 없는 것일 수도 있습니다. 나 삭제할 가치가 있는지 고려해야 합니다 실제로 이 메타데이터는 최대 수십 킬로바이트에 이를 수 있습니다

간단히 말해 애셋의 효율성을 최적화하기 위한 첫 번째 단계로서, 다양한 콘텐츠 유형의 인벤토리를 찾고 콘텐츠별 최적화를 적용할 수 있습니다. 이후 이러한 최적화를 자동화하려면 빌드 및 출시 단계를 확인하여 최적화가 적용되도록 하세요 프로덕션에 신곡을 발표할 때마다 꾸준히 유지해야 합니다

압축 알고리즘을 사용한 텍스트 압축

텍스트 기반 애셋의 크기를 줄이기 위한 다음 단계는 압축 알고리즘을 제공합니다. 그러면서도 한 걸음 더 나아가 텍스트 기반 페이로드에서 반복 가능한 패턴을 검색하여 사용자의 브라우저에 도달하면 압축을 풀 수 있습니다. 이 결과적으로 해당 리소스가 상당히 크게 줄어들고 다운로드 시간이 빨라졌습니다.

  • gzip 및 Brotli는 일반적으로 사용되는 압축 알고리즘으로 텍스트 기반 애셋: CSS, JavaScript, HTML
  • 모든 최신 브라우저는 gzip 및 Brotli 압축을 지원하며 Accept-Encoding HTTP 요청 헤더에서 둘 다 지원합니다.
  • 서버가 압축을 사용하도록 구성되어야 합니다. 웹 서버 소프트웨어 은 종종 모듈이 텍스트 기반 리소스를 기본적으로 압축할 수 있도록 합니다.
  • gzip과 Brotli는 모두 압축 수준을 조정하는 것입니다. gzip의 경우 압축 설정 범위는 1부터 9까지, 9가 가장 좋음 Brotli의 경우 이 범위는 0~11이며 최고가 되는 것입니다. 하지만 압축 설정이 높을수록 시간이 더 필요합니다. 대상 압축된 리소스를 동적으로 압축한 이 범위 가운데에 있는 설정이 가장 좋은 절충안을 제공하는 경향이 있습니다. 압축비와 속도 사이의 차이가 있습니다 그러나 정적 압축은 이는 응답이 미리 압축되어 각 데이터에 사용할 수 있는 가장 공격적인 압축 설정을 사용하세요. 압축 알고리즘입니다.
  • 콘텐츠 전송 네트워크 (CDN)는 일반적으로 확인할 수 있습니다 CDN은 동적 및 정적 압축도 관리할 수 있으므로 걱정해야 할 압축 요소가 하나 줄어듭니다.

gzip 및 Brotli는 컴퓨터의 모든 스트림에 적용 가능한 바이트. 그들은 내부에서 이전에 조사된 정보 중 일부를 기억합니다. 이후에 중복 데이터 프래그먼트를 찾아서 바꾸려고 효율적으로 사용할 수 있습니다

<ph type="x-smartling-placeholder">

실제로 gzip과 Brotli 모두 텍스트 기반 콘텐츠에서 가장 잘 작동하며 더 큰 파일의 경우 최대 70-90% 의 압축률을 제공합니다. 그러나 이러한 다른 알고리즘을 사용하여 이미 압축된 자산이 있는 경우(예: 무손실 또는 손실(lossy) 압축 기술을 사용하는 대부분의 이미지 형식 개선할 수 있습니다

모든 최신 브라우저는 Accept-Encoding HTTP 요청 헤더. 하지만 호스팅 업체의 웹 서버가 올바른 웹 서버를 제공하거나 압축되어 있는 것입니다.

파일 알고리즘 압축되지 않은 크기 압축된 크기 압축비
angular-1.8.3.js 브로틀리 1,346 KiB 256 KiB 81%
angular-1.8.3.js gzip 1,346 KiB 329 KiB 76%
angular-1.8.3.min.js 브로틀리 173 KiB 53 KiB 69%
angular-1.8.3.min.js gzip 173 KiB 60 KiB 65%
jquery-3.7.1.js 브로틀리 302 KiB 69 KiB 77%
jquery-3.7.1.js gzip 302 KiB 83 KiB 73%
jquery-3.7.1.min.js 브로틀리 85 KiB 27 KiB 68%
jquery-3.7.1.min.js gzip 85 KiB 30 KiB 65%
lodash-4.17.21.js 브로틀리 531 KiB 73 KiB 86%
lodash-4.17.21.js gzip 531 KiB 94 KiB 82%
lodash-4.17.21.min.js 브로틀리 71 KiB 23 KiB 68%
lodash-4.17.21.min.js gzip 71 KiB 25 KiB 65%

앞의 표는 Brotli와 gzip 압축을 모두 사용할 경우 절약되는 비용을 보여줍니다. 몇 가지 잘 알려진 JavaScript 라이브러리를 제공합니다. 절감액은 65% 에서 100만 건으로 파일 및 알고리즘에 따라 86% 이상입니다. 참고로 Brotli와 gzip 모두 각 파일에 압축 수준을 적용했습니다. 어디서나 가능한 경우 gzip보다 Brotli를 사용하는 것이 좋습니다

<ph type="x-smartling-placeholder">

압축을 사용하는 것은 압축 해제를 위한 가장 간단하면서도 효과적인 최적화 중 하나입니다. 있습니다. 웹사이트에서 이를 활용하지 않으면 사용자를 위해 성능을 개선할 수 있는 큰 기회가 될 수 있습니다 다행히도 많은 웹 서버는 이 중요한 최적화를 가능하게 하는 기본 구성을 제공하므로 특히 CDN은 적절한 방식으로 콘텐츠를 구현하는 데 압축 속도와 비율의 균형을 유지합니다.

압축이 작동하는 것을 빠르게 확인하는 방법은 Chrome DevTools를 열고 Network 패널에서 선택한 페이지를 로드한 후 네트워크 패널에 표시됩니다

<ph type="x-smartling-placeholder">
</ph> DevTools 판독값이 실제 크기와 전송 크기 비교 <ph type="x-smartling-placeholder">
</ph> 기본 스토리지의 전송 크기 (즉, 압축된)를 표현한 모든 페이지 리소스의 크기와 네트워크에서 시각화된 실제 크기를 비교합니다. 패널로 이동합니다.

앞의 이미지와 마찬가지로 다음과 같은 세부정보가 표시됩니다.

  • 요청 수, 즉 요청을 위해 로드된 리소스 수 있습니다.
  • 모든 요청의 전송 크기입니다. 이는 Kubernetes의 압축입니다.
  • 모든 요청의 리소스 크기입니다. 이는 해당 리소스에 대한 페이지가 압축 해제된 후에 표시됩니다.

Core Web Vitals에 미치는 영향

측정항목을 반영하는 측정항목이 없으면 실적 개선을 측정할 수 없습니다. 확인할 수 있습니다 Core Web Vitals 이니셔티브는 실제 사용자 환경을 반영하는 측정항목에 대한 인식을 제고하는 것입니다. 이는 단순한 페이지 로드 시간처럼 사용자 경험 품질과 명확하게 해석되지 않습니다.

이 가이드에 설명된 최적화를 Core Web Vitals에 미치는 영향은 각 웹사이트의 리소스에 따라 최적화 및 관련 측정항목 하지만 다음과 같은 경우에는 이러한 최적화를 적용하면 웹사이트의 Core Web Vitals를 개선할 수 있습니다.

  • 축소 및 압축된 HTML 리소스는 애플리케이션의 하위 리소스의 검색 가능 여부를 판단하여 있습니다. 이렇게 하면 페이지의 최대 콘텐츠 페인트가 (LCP): rel="preload"와 같은 리소스 힌트를 사용하여 리소스를 너무 많이 사용하면 검색 가능성이 낮아진다는 점에서 발생할 수 있습니다. 탐색 요청에 대한 HTML 응답을 보장함 그 안에 있는 리소스를 최대한 빨리 검색할 수 있기 때문에 미리 로드 스캐너에 의해 표시됩니다.
  • 일부 LCP 후보는 압축을 사용하여 더 빨리 로드할 수도 있습니다. 대상 예를 들어 LCP 후보인 SVG 이미지는 리소스 로드가 길이를 단축할 수 있습니다. 이것은 최적화는 다른 이미지 유형에 적용할 수 있습니다. 다른 압축 방법을 통해 본질적으로 압축되는 것(예: JPEG 손실(lossy) 압축을 사용합니다
  • 또한 텍스트 노드는 LCP 후보일 수도 있습니다. 디코더에 웹 글꼴을 사용하고 있는지 여부에 따라 웹페이지입니다. 웹 글꼴을 사용 중이라면 웹 글꼴 최적화가 관행이 적용됩니다. 하지만 웹 글꼴을 사용하지 않는 것이 아니라 리소스 로드 시간을 유발하지 않고 글꼴이 표시되는 CSS를 압축하면 이 시간이 줄어듭니다. 즉, 잠재적인 LCP 텍스트 노드가 더 빨리 발생할 수 있습니다.

결론

텍스트 기반 애셋의 인코딩 및 전송을 최적화하는 방법은 하지만 큰 영향을 미칩니다. 리소스를 압축하고 압축하기 위해 최선을 다하는 것이 압축이 이러한 최적화의 이점을 누리고 있습니다.

무엇보다 이러한 프로세스가 자동화되고 있는지 확인해야 합니다. 대상 압축하려면 번들러를 사용하여 요건을 충족하는 리소스에 축소를 적용합니다. 압축을 지원한다는 것을 알고 있지만 그 밖에는 압축하는 것입니다 이 작업을 최대한 간단하게 하기 위해 CDN을 사용하면 자동으로 압축을 자동화할 수 있습니다. 매우 빠르게 수행할 수 있습니다.

이러한 기본 실적 개념을 웹사이트의 성능을 최적화할 수 있는 모든 수단을 동원해 기반이 탄탄해야 하고 후속 최적화도 탄탄한 기반을 토대로 해야 합니다. 몇 가지 권장사항을 살펴보겠습니다