압축 사전을 사용한 Google 검색 개선

Carlos Mateo Muñoz

Barry Pollard

게시일: 2025년 5월 14일

압축 사전 전송은 요청 간에 반복되는 콘텐츠를 압축할 수 있는 새로운 표준으로, 2024년 말 Chrome 130에서 출시되었습니다. Google 검색은 이 새로운 기술을 채택하여 크게 개선되었습니다.

기회

방문하는 웹페이지에는 중복이 많이 있습니다. 동일한 웹사이트의 많은 페이지는 동일한 코드(HTML, CSS 또는 JavaScript)로 구성되며, 이 모든 코드 사이의 콘텐츠만 변경됩니다. 각 결과는 완전히 고유한 콘텐츠를 생성하는 수백 가지 기능의 고유한 조합이지만, 이를 생성하기 위해 브라우저로 전송되는 코드에는 여전히 많은 공통점이 있습니다.

시각적으로 대부분의 검색 결과 페이지는 입력된 검색어와 관계없이 다소 유사합니다. 상단에는 Google 로고, 검색창, 일부 컨트롤이 있습니다. 중간에는 검색 유형을 위한 일부 탭이 있고, 왼쪽에는 사용자를 돕는 다양한 위젯과 간격이 있는 검색 결과 목록이 있으며, 오른쪽에는 '정보' 패널이 있는 추가 컨텍스트가 있습니다.

마지막으로 하단에는 페이지 매김 옵션과 표준 바닥글이 있습니다. 이것은 시각적으로 사용할 수 있는 것일 뿐이며, 이 페이지를 생성하기 위해 백그라운드에서 많은 코드 (HTML, CSS, JavaScript)가 실행됩니다. 이 코드의 대부분은 성능 최적화로 페이지의 HTML에 직접 인라인됩니다. 이렇게 하면 페이지를 더 빠르게 로드할 수 있지만, 외부에서 캐시된 리소스가 허용하는 것처럼 여러 결과 페이지 간에 코드를 공유하지 않는다는 단점이 있습니다.

웹의 압축

압축은 웹에서 많이 사용되는 기술입니다. gzip 또는 Brotli나 Zstandard와 같은 최신 알고리즘으로 리소스를 압축하면 무손실 압축으로 파일 내에서 반복을 방지하여 전송하기 전에 서버에서 모든 정보를 최대한 압축할 수 있습니다. 그러면 브라우저에서 압축된 바이트를 압축 해제하여 원래 콘텐츠를 복원할 수 있습니다. 이미지의 경우 손실 압축은 사용자에게 눈에 띄게 다를 수 없는 추가 바이트를 삭제하여 유사한 이점을 제공합니다.

최근까지 웹의 압축은 리소스 내의 압축으로 제한되었습니다. 여러 리소스 간에 압축할 수 없었으며, 여러 페이지 간에는 압축할 수 없었습니다. 이는 웹 엔지니어가 해결하고자 하는 제한사항으로 오랫동안 인식되어 왔습니다.

압축 사전 전송으로 해결하세요!

압축 사전 전송은 공유 '사전'을 사용하여 리소스 간에 압축을 허용하는 새로운 표준으로, 공유 사전의 참조로 일반적인 바이트 시퀀스를 대체할 수 있습니다.

Brotli 및 Zstandard와 같은 최신 압축 알고리즘은 일반적인 용어의 사전 사용을 지원하므로 이러한 용어를 사전의 더 작은 참조로 대체하여 더 큰 압축을 허용합니다. Brotli는 일반적인 웹 용어의 기본 제공 사전과 함께 제공됩니다. 압축 사전 전송은 서버와 브라우저가 맞춤 사전을 공유할 수 있는 방법을 제공하여 이를 기반으로 합니다.

맞춤 사전은 사이트에서 이미 사용 중인 리소스일 수 있습니다. 예를 들어 app.v2.js를 다운로드할 때 app.v1.js를 사전으로 사용하여 기본적으로 차이점만 다운로드할 수 있습니다 (일반적으로 '델타 압축'이라고 함). 또는 <link rel="compression-dictionary"> 태그 (또는 이와 동등한 Link HTTP 헤더)로 별도의 사전 리소스를 지정할 수 있습니다.

이렇게 하면 이전에 언급한 검색 결과 페이지와 같이 공유 콘텐츠 또는 코드가 많은 리소스의 다운로드 크기를 크게 줄일 수 있습니다.

Google 검색의 압축 사전 사용

Google 검색팀은 검색 성능을 개선하기 위해 지속적으로 노력하고 있습니다. 이들은 이 기술의 잠재력을 확인하고 압축 사전을 조기에 채택했습니다.

검색은 검색 결과의 대표 샘플에서 빌드된 별도의 사전 파일과 함께 결과 페이지에 공유 Brotli 압축을 사용합니다. 강력한 자동화된 파이프라인은 사전이 최신 상태를 유지하도록 보장하며, 하루에 여러 번 출시되는 자주 변경되는 SRP 콘텐츠를 따라잡습니다. DevTools를 사용하여 작동 방식을 정확히 확인할 수 있습니다.

클라이언트가 검색 결과 페이지를 처음 로드할 때 서버는 rel=compression-dictionary 유형의 Link: HTTP 헤더를 사용하여 사전에 대한 링크를 제공합니다.

클라이언트가 Brotli 사전 압축을 지원하지만 아직 공유 사전을 캐시하지 않은 경우 브라우저는 유휴 시간 동안 이 사전을 다운로드합니다. 사전 응답에는 브라우저에 이 사전을 사용할 수 있는 리소스를 알려주는 Use-As-Dictionary 응답 헤더가 포함됩니다.

사전은 표준 cache-control 시맨틱스를 사용하며 이 헤더에 정의된 규칙과 일치하는 모든 리소스(이 예에서는 /search로 시작하는 페이지)에 사용할 수 있습니다.

향후 검색 결과 페이지 로드의 경우 브라우저는 Available-Dictionary HTTP 요청 헤더를 사용하여 서버에 사전이 있음을 알릴 수 있습니다. 페이지를 다시 로드하면 작동 중인 페이지가 표시됩니다.

로그 보존 체크박스를 사용 설정하고 필터링하면 두 응답을 비교할 수 있습니다.

이 예에서 첫 번째 요청은 전체 107kB 응답이며 Brotli (br) 압축을 사용하는 반면, 두 번째 다시 로드 요청은 크기가 거의 절반인 60kB이며 사전 압축 Brotli (dcb) 압축을 사용하여 다운로드 시간이 단축됩니다.

Chrome에서 chrome://net-internals/#sharedDictionary 페이지를 보고 공유 사전을 확인하고 처음부터 이 예를 반복하려면 공유 사전을 지우면 됩니다.

결과

이 변경사항은 2025년 봄에 검색 사용자에게 출시되었으며, 처음에는 Chrome 사용자에게 출시되었습니다. 표준 Brotli 압축에 비해 모든 Chrome 사용자의 평균 HTML 페이로드 크기가 23% 감소했습니다. 이 전체 평균에는 사전 압축되지 않은 결과 (예: 사전이 없는 신규 사용자)와 사전 압축된 검색 결과가 모두 포함됩니다. 사전 압축된 결과의 경우 이전 예에서 본 거의 50% 개선과 같이 절감액이 훨씬 더 큽니다.

그 결과 최대 콘텐츠 페인트 (LCP)가 전체적으로 1.7%, 지연 시간이 긴 네트워크에서 최대 9% 개선되었습니다. 이 수치는 작아 보일 수 있지만 Google 검색은 매우 최적화된 사이트이므로 이 정도의 개선은 매우 큽니다. 다른 사이트에서는 이 기술로 훨씬 더 큰 개선을 볼 수 있습니다.

사이트에서 사용해 보세요!

압축 사전 전송은 이제 모든 Chromium 기반 브라우저 (Chrome, Edge, Opera 등)에서 사용할 수 있습니다. 지원하지 않는 브라우저에서는 무시되는 점진적 개선사항이지만, 더 많은 브라우저에서 이를 지원하면 이점도 누릴 수 있습니다.

이 기술이 해결하는 문제는 Google 검색에만 국한되지 않습니다. 많은 사이트에서 검색에서 사용한 것과 같은 별도의 사전을 사용하거나 기존 리소스를 사전으로 사용하여 (예: 새 버전을 출시할 때 이전 버전의 앱) 압축 사전 전송의 이점을 누릴 수 있습니다.

이 기술의 작동 방식과 사이트에서 구현하는 방법을 자세히 알아보려면 MDN의 가이드를 확인하세요.

사전 기반 압축 리소스를 만들고 적절하게 제공하려면 서버 또는 빌드 프로세스에서 일부 설정을 해야 하지만, 성능 측면에서 결과는 매우 인상적일 수 있습니다.