압축 사전을 사용한 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 사용자를 대상으로 출시되었습니다. 이로 인해 모든 Chrome 사용자의 HTML 페이로드 평균 크기가 표준 Brotli 압축에 비해 23% 감소했습니다. 이 전체 평균에는 사전 압축이 적용되지 않은 결과 (예: 사전이 없는 신규 사용자)와 사전 압축이 적용된 검색 결과가 모두 포함됩니다. 사전 압축 결과의 경우 절감 효과가 훨씬 더 큽니다. 이전 예시에서 볼 수 있듯이 거의 50% 의 개선이 이루어졌습니다.

그 결과 전반적으로 최대 콘텐츠 렌더링 시간 (LCP)이 1.7% 개선되었으며 지연 시간이 긴 네트워크에서는 최대 9% 개선되었습니다. 이 수치는 작아 보이지만 Google 검색은 최적화가 극도로 이루어진 사이트이므로 이 정도의 증가는 엄청난 것입니다. 다른 사이트에서는 이 기술로 더 큰 개선을 경험할 수 있습니다.

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

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

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

이 기술의 작동 방식과 사이트에 구현하는 방법에 관한 자세한 내용은 MDN 가이드를 참고하세요.

이렇게 하려면 서버 또는 빌드 프로세스에서 사전 기반 압축 리소스를 만들고 적절하게 제공하기 위한 설정이 필요하지만 성능 측면에서 상당히 인상적인 결과를 얻을 수 있습니다.