바로 사용 가능한 기술 소개
페이지 로드 속도가 중요한 이유는 무엇인가요?
대부분의 사용자는 일반적으로 느린 페이지 로드를 사용자가 겪는 주된 원인으로 꼽았습니다 (Google에서 실시한 사용자 연구 중 54%). 따라서 페이지 로드 속도가 빨라서 비즈니스 성과가 향상된 것은 어쩌면 당연한 일입니다. 실제로 방문자가 웹사이트와 상호작용하기 전에도 짜증을 내면 그 가치를 충분히 인지할 수 있을 정도로 오래 머무르지 못할 가능성이 높습니다. 실제로 254개 전자상거래, 금융, 여행 사이트에 대한 Google의 또 다른 연구에 따르면 로드 시간이 2초 이하인 사이트의 전환율이 15% 더 높은 것으로 나타났습니다.
최대 콘텐츠 렌더링 시간 (LCP) 속도 향상
측정하지 않는 것은 개선할 수 없다는 말이 있습니다. 웹 사용자 환경의 경우 코어 웹 바이탈은 사용자 환경의 근본적인 측면을 포착하도록 설계된 사용자 중심의 견고한 측정항목입니다. 특히 최대 콘텐츠 렌더링 시간 (LCP)은 사용자에게 표시되는 가장 큰 텍스트 또는 이미지 블록이 표시되는 데 걸리는 시간을 보고하여 페이지의 로드 성능을 측정합니다. 우수한 사용자 환경을 제공하려면 LCP가 페이지가 처음 로드되기 시작한 후 2.5초 이내에 발생해야 합니다 (즉, 양호한 LCP 기준점).
일반적인 페이지의 LCP에 기여하는 요소를 살펴보겠습니다.
사용자가 페이지를 방문하면 브라우저가 서버에 HTML을 요청합니다. 서버는 HTML로 응답하여 CSS, JavaScript, 글꼴, 이미지 등 다음에 가져올 항목에 대한 추가 힌트를 브라우저에 제공합니다. 이러한 응답이 돌아올 때 브라우저는 응답을 평가하기 위한 작업도 수행해야 하며, 최종적으로 페이지에 구성요소를 배치하고 페인트해야 합니다. 그러나 대부분의 시간은 이러한 패킷이 장치에서 서버로 이동한 다음 장치로 다시 돌아오기를 기다리는 데 소비됩니다. 실제로 Google의 데이터 (Android용 Chrome, 중앙값)에 따르면 일반적으로 사용자에게 표시되는 지연 시간의 약 40% 는 서버에서 첫 번째 바이트가 반환될 때까지 기다리는 데 소비됩니다.
미리 가져오기의 효과
이러한 모든 파일을 미리 가져올 수 있다면(즉, 사용자가 페이지를 방문하기 전에 가져옴) 속도가 크게 향상되어 페이지를 표시하기 전에 평가, 레이아웃 계산, 페인팅과 같은 몇 가지 작업만 수행하면 됩니다.
앞서 공유한 데이터를 감안할 때, 주요 리소스를 미리 가져오기만 해도 여전히 훨씬 더 빠른 페이지 로드를 달성할 수 있습니다. 동일한 사이트의 경우 rel=prefetch와 같은 프리미티브를 사용하면 이러한 유형의 기법을 쉽게 사용할 수 있습니다. 하지만 크로스 사이트 시나리오에서는 그렇게 간단하지 않습니다.
크로스 사이트 탐색
미리 가져오기는 오래 전부터 사용되어 왔지만, 사용자가 다른 사이트에 있는 동안 한 사이트에서 페이지를 미리 가져올 때는 한 가지 더 고려해야 할 사항이 있습니다.
리퍼러 사이트가 다른 사이트의 페이지를 미리 가져오도록 브라우저에 지시한다고 가정해 보겠습니다. 분명히 사용자는 이 미리 가져온 페이지의 링크를 클릭할 때 훨씬 더 빠른 페이지 로드로 더 나은 사용자 환경을 즐길 것입니다. 하지만 사용자가 이 링크를 클릭하지 않으면 어떻게 될까요? 고객은 연결된 웹사이트에서 추천 사이트에서 주제를 검색하는 동안 특정 주제에 관심이 있다는 사실을 알 것이라고 기대하지 않습니다. 하지만 미리 가져오기 요청은 다른 일반적인 요청과 마찬가지로 사용자의 IP 주소와 쿠키(있는 경우)를 전달하기 때문에 상당한 위험이 있습니다.
솔루션
개인 정보를 보호하는 크로스 사이트 미리 가져오기를 지원하기 위해 Google은 지난 3년 동안 비공개 미리 가져오기 프록시와 서명된 교환 (SXG)이라는 두 가지 솔루션을 개발했습니다. 또한 교차 출처 미리 가져오기가 상당한 속도 이점을 제공하는지 확인하기 위해 대규모 실험을 진행했습니다. 구체적으로, Google이 사용자의 다음 탐색을 위해 기본 HTML을 안전하게 미리 가져올 수 있는 사례를 살펴본 결과, LCP가 '양호한' 페이지 로드 비율이 14% 포인트 증가한 것을 확인할 수 있었습니다.
주요 고려사항
비공개 미리 가져오기 프록시와 서명된 교환은 동일한 사용 사례를 해결하지만, 기술마다 서로 다른 장단점이 있습니다. 따라서 최선의 선택은 사이트의 구체적인 요구에 따라 달라집니다. 장단점을 이해하는 데 도움이 되도록 다음 섹션에서는 크로스 사이트 미리 가져오기를 사용 설정하고 사용 가능한 두 가지 기술 중에서 선택할 때 고려해야 할 두 가지 주요 사항을 다룹니다. 각 기술에 대한 심층 분석 문서에서도 자세한 내용을 확인할 수 있습니다.
재방문자
크로스 사이트 미리 가져오기는 사이트를 처음 방문하는 사용자가 쉽게 사용 설정할 수 있습니다. 재방문자의 경우 사이트에 얼마나 많은 맞춤설정이 적용되는지에 따라 다릅니다. 이는 크로스 사이트 미리 가져오기 요청에 개인 정보 보호를 위해 쿠키를 포함할 수 없기 때문입니다.
- 신규 방문자에게는 시작할 쿠키가 없으므로 이러한 제한으로 인해 문제가 발생하지 않습니다. 따라서 사이트를 변경하지 않고도 이러한 사용자를 위해 크로스 사이트 미리 가져오기를 사용 설정할 수 있습니다.
- 재방문자를 위해 크로스 사이트 미리 가져오기를 사용 설정하려는데 사이트가 쿠키를 기반으로 맞춤설정되는 경우 사용자가 탐색한 후 이러한 맞춤설정된 요소를 지연 로드해야 합니다. 이렇게 하는 이유는 사용자가 명시적으로 웹사이트를 방문하도록 선택했기 때문에 탐색 시 쿠키 제한이 더 이상 필요하지 않기 때문입니다. 따라서 탐색 시에도 사이트는 평소와 같이 쿠키에 액세스할 수 있습니다. 구체적인 안내는 지연 로드 권장사항을 참고하세요.
- 현재 맞춤설정을 HTML로 직접 인코딩하는 경우에도 쿠키가 있는 경우에도 계속 인코딩할 수 있으며 미리 가져온 페이지의 대체 전략으로 지연 로드를 사용할 수 있습니다.
- 사이트가 쿠키를 기반으로 맞춤설정되지 않았거나 맞춤설정이 중요하지 않은 경우 신규 방문자와 동일한 콘텐츠를 재방문자에게도 제공하도록 선택할 수 있습니다.
현재 비공개 미리 가져오기 프록시는 재방문자에게 적용 범위를 확대하기 위해 (쿠키가 있는 링크) 신규 방문자 (쿠키가 없는 링크)에 대해서만 사용 설정되어 있습니다. 반면, Signed Exchange는 이미 처음 방문한 사용자와 재방문자 모두를 위해 크로스 사이트 프리패치를 이미 지원하고 있습니다 (위에서 설명한 접근 방식 사용).
미리 가져오기로 인한 추가 데이터 제공
크로스 사이트 미리 가져오기를 사용 설정하면 추가 데이터가 제공될 수 있습니다. 실제로 리퍼러가 페이지를 미리 가져왔지만 사용자가 링크를 클릭하지 않는다면 추가 트래픽이 발생하게 됩니다.
- 이 문제를 완화하려면 리퍼러가 미리 가져오기 요청을 덜 적극적으로 하도록 요청할 수 있습니다. 마찬가지로 리퍼러 또는 브라우저는 비교적 가볍지만 중요한 리소스 (예: 기본 리소스, 중요한 CSS 또는 자바스크립트 하위 리소스)에 집중하여 이 문제를 완화할 수 있습니다. 이는 기본적으로 속도 개선 효과와 추가 트래픽 간의 균형을 맞춘 것입니다.
- 또는 추가 캐싱을 선택하여 이 트래픽을 상쇄할 수 있습니다 (자세한 내용은 서명된 교환에 관한 이 섹션 참고). 이 경우 단점은 콘텐츠를 너무 오래 캐시하면 사용자에게 이전 정보가 표시될 수 있다는 것입니다. 이는 본질적으로 추가 데이터 게재와 콘텐츠 최신성 간의 절충안입니다.
최상의 결정을 내리려면 사이트가 최대 업데이트 빈도와 최소한의 추가 요청 사이에서 오가는 변동 추이를 확인해 보세요. 이 질문에 대한 답변은 궁극적으로 비즈니스와 사용자의 구체적인 요구 사항에 따라 달라집니다.
시작하기
이러한 기술은 사이트의 LCP를 즉시 개선할 수 있도록 Google 검색에 통합되었습니다. 이 기능을 통해 다른 인기 있는 참조자도 이 과정을 따라 웹을 훨씬 빠르게 만들 수 있길 바랍니다.
이러한 기술은 모두 동일한 사용 사례를 해결하지만 앞에서 설명한 주요 고려사항에 대해 서로 다른 장단점을 제공합니다. 하나의 기술로 시작한 다음 요구 사항 또는 이점에 대한 인식이 발전함에 따라 다른 기술로 전환할 수도 있습니다. 다음 심층 분석을 통해 특정 상황에 어떤 기술이 가장 적합한지 알아보십시오.