SPA, Core Web Vitals, 현재 측정 제한을 해결하기 위한 Google의 계획에 관한 일반적인 질문에 대한 답변
2020년 5월에 Core Web Vitals 이니셔티브를 처음 도입한 이후 Chrome팀은 이 프로그램에 관한 많은 질문과 의견을 받았습니다.
가장 많은 질문을 받았으며 가장 답하기 어려운 질문은 단일 페이지 애플리케이션(SPA)에서 Core Web Vitals를 측정하는 방법과 SPA 아키텍처가 Core Web Vitals 점수에 미치는 영향일 것입니다.
이러한 질문은 문제가 매우 미묘하여 답변하기가 어렵습니다. 따라서 이 게시물에서는 최대한 많은 세부정보와 맥락을 제공하여 가장 일반적인 질문에 답변하기 위해 최선을 다할 것입니다.
하지만 구체적인 내용을 살펴보기 전에 Google은 사이트를 빌드하는 데 사용되는 아키텍처나 기술에 관해 어떠한 선호도도 가지고 있지 않다는 점을 분명히 해야 합니다. SPA와 멀티페이지 애플리케이션 (MPA) 모두 사용자에게 양질의 환경을 제공할 수 있다고 생각하며, 웹 바이털 이니셔티브의 목적은 기술과 관계없이 환경을 측정하는 측정항목을 제공하는 것입니다. 현재 웹 플랫폼의 제약으로 인해 모든 경우에 적용할 수는 없지만 이러한 격차를 해소하기 위해 적극적으로 노력하고 있습니다.
자주 묻는 질문(FAQ)
Core Web Vitals 측정항목에 SPA 경로 전환이 포함되나요?
아니요. 각 Core Web Vitals 측정항목은 현재 최상위 페이지 탐색을 기준으로 측정됩니다. 페이지가 새 콘텐츠를 동적으로 로드하고 주소 표시줄에서 페이지의 URL을 업데이트하는 경우 Core Web Vitals 측정항목이 측정되는 방식에는 영향을 미치지 않습니다. 측정항목 값은 재설정되지 않으며 각 측정항목 측정값과 연결된 URL은 사용자가 페이지 로드를 시작한 페이지로 이동한 URL입니다.
Core Web Vitals 측정항목에서 SPA 경로 변경을 기존 페이지 로드와 동일하게 처리할 수 있나요?
안타깝게도 아직은 없습니다.
현재 SPA를 빌드하는 표준화된 방법은 없으며, 널리 사용되는 SPA 및 라우팅 라이브러리 중에서도 앱마다 사용자 환경이 상당히 다를 수 있습니다.
- 일부 SPA는 새 '전체 페이지' 콘텐츠를 로드할 때만 URL을 업데이트하는 반면, 다른 사이트는 작은 콘텐츠 변경사항이나 UI 상태 변경사항이 있을 때도 URL을 업데이트합니다.
- 일부 SPA는 History API를 사용하여 URL을 업데이트하는 반면, 다른 SPA는 이전 브라우저를 지원하기 위해 해시 변경사항을 사용합니다. 또 다른 SPA는 URL을 전혀 업데이트하지 않습니다.
- 일부 SPA는 콘텐츠를 로드한 다음 URL을 업데이트하는 반면, 다른 SPA는 콘텐츠를 로드하기 전에 URL을 업데이트합니다.
- 일부 SPA는 단일 JavaScript 태스크에서 콘텐츠를 한 번에 동기식으로 모두 로드하는 반면, 다른 SPA는 명확한 전환 종료 이벤트 없이 여러 태스크에서 콘텐츠를 비동기식으로 전환합니다.
- 일부 SPA는 항상 네트워크에서 콘텐츠를 로드하는 반면, 다른 SPA는 경로 변경사항이 메모리에서 즉시 로드되도록 모든 콘텐츠를 미리 로드합니다.
이러한 차이로 인해 SPA 경로 변경사항 또는 SPA 자체를 정의하고 식별하는 작업을 대규모로 수행하기가 매우 어렵습니다.
SPA 경로 변경이 논리적으로 MPA 페이지 로드와 동일한 경우도 있습니다. 이 경우 기존 Core Web Vitals 측정항목을 적용할 수 있으면 좋습니다.
그러나 다른 모든 URL 변경사항에서 '실제' 경로 변경사항을 안정적으로 식별하는 확실한 휴리스틱과 이러한 전환의 시작과 끝을 나타내는 명확한 신호가 없다면 이러한 경우 코어 웹 바이탈 측정항목을 보고하면 데이터가 혼란스러워지고 사이트의 실제 사용자 환경을 제대로 반영하지 못하게 됩니다.
SPA가 MPA보다 Core Web Vitals에서 좋은 실적을 거두기 더 어렵나요?
SPA 아키텍처에는 MPA의 유사한 페이지와 동일한 속도로 로드되고 모든 Core Web Vitals 측정항목에서 동일한 점수를 얻는 것을 방해하는 고유한 요소가 없습니다.
하지만 적절하게 최적화된 MPA는 현재 SPA가 충족하지 못하는 Core Web Vitals 기준점을 충족하는 데 몇 가지 이점이 있습니다. MPA 아키텍처에서는 각 '페이지'가 콘텐츠를 동적으로 가져와 기존 페이지에 삽입하는 대신 전체 페이지 탐색으로 로드되기 때문입니다. 즉, MPA를 방문하는 사용자는 사이트에서 두 개 이상의 페이지를 로드할 가능성이 더 높습니다. 이는 MPA의 모든 페이지 로드 분포에서 캐시되는 하위 리소스의 일부 또는 전부가 포함된다는 것을 의미합니다.
물론 MPA가 SPA보다 Core Web Vitals 측정항목에서 더 우수한 실적을 내기 위해서는 다음과 같은 몇 가지 조건이 충족되어야 합니다.
- 동일 출처 페이지 로드가 교차 출처 페이지 로드보다 실제로 더 빠르게 이루어지도록 하려면 MPA에 최적화된 하위 리소스 캐싱이 있어야 합니다(75번째 백분위수 기준).
- MPA를 방문하는 사용자는 사이트에서 캐싱 혜택을 받아 페이지를 더 빠르게 로드하려면 여러 페이지를 방문해야 합니다.
Core Web Vitals 평가는 페이지 방문의 75번째 백분위수를 고려하므로 데이터 세트에 실적이 우수한 페이지 방문이 많을수록 배포의 75번째 백분위수에 해당하는 방문이 권장 기준점 내에 있을 가능성이 높아집니다.
Core Web Vitals 점수를 비교할 때 중요한 점은 데이터가 집계되는 방식입니다. 즉, 배포의 데이터 세트에 사이트 또는 출처의 모든 페이지가 포함되는지 아니면 특정 페이지 URL의 페이지 로드만 포함되는지 여부입니다.
출처의 모든 페이지 점수를 집계할 때 개별적으로 빠른 페이지는 출처 전체의 75번째 백분위수를 개선할 수 있습니다. 하지만 개별 페이지별로 집계하면 한 페이지의 점수가 다음 페이지의 점수에 영향을 미치지 않습니다. 즉, 페이지별로 MPA의 점수를 집계할 때 결제 페이지에서 확인된 빠른 캐시 로드는 사이트의 방문 페이지에서 발생한 느린 초기 로드의 점수를 개선하지 않습니다.
PageSpeed Insights 또는 Chrome 사용자 환경 보고서 API를 사용하여 다양한 집계 방법에 대한 사이트의 점수를 확인할 수 있습니다. 이 API는 개별 페이지 URL과 전체 출처의 점수를 모두 보고합니다.
SPA 아키텍처가 핵심 웹 바이탈 점수에 영향을 미치는 또 다른 방법은 페이지의 전체 수명을 고려하는 측정항목입니다. SPA를 방문하는 사용자는 전체 세션 동안 동일한 '페이지'에 머무르는 경향이 있으므로 시간이 지남에 따라 누적되는 측정항목은 MPA보다 SPA에서 더 가혹할 수 있습니다.
2021년 4월 Google은 이 문제를 부분적으로 해결한 CLS 측정항목 변경사항을 발표했습니다. 이전에는 CLS가 전체 페이지 수명 동안 누적되었지만 이제는 특정 시간 간격(기본적으로 특정 페이지에서 가장 심각한 레이아웃 변경 폭발) 동안에만 누적됩니다.
하지만 새로운 CLS 정의가 적용되더라도 MPA에서 전체 페이지가 로드될 때와 달리 경로 전환 후 CLS 값이 '재설정'되지 않으므로 SPA는 여전히 불리합니다. 또한 경로 전환 후 발생하는 레이아웃 전환은 전환 시 주소 표시줄의 URL이 아닌 페이지가 로드될 때의 URL로 인해 발생하므로 혼란을 야기할 수 있습니다(아래에서 자세히 알아보기).
SPA 아키텍처로 사용자 환경이 개선되면 측정항목에 반영되어야 하지 않나요?
예, 맞습니다. 앞서 언급했듯이 오늘날 웹에서 SPA가 구현되는 다양한 방법을 고려할 때 경험이 얼마나 개선되었는지 정량화하기는 어렵습니다.
사실 웹 성능 업계 (Google 포함)는 페이지 로드 자체에 투자한 것만큼 페이지 로드 후 성능을 위한 사용자 중심 측정항목을 개발하는 데 시간과 노력을 투자하지 않았습니다. 이는 로드 후 성능이 중요하지 않기 때문이 아니라 로드 후 UX 및 상호작용이 훨씬 더 다양하고 잘 정의되어 있지 않아 측정항목을 설계하기 어렵기 때문입니다.
하지만 SPA 성능을 측정하기 위한 로드 후 측정항목이 잘 정의되어 있더라도 로드 후 환경이 개선되었다고 해서 로드 환경을 무시해서는 안 됩니다.
웹 바이탈 이니셔티브의 목표 중 하나는 웹페이지 로드 및 사용의 최대한 많은 측면에서 우수한 사용자 환경을 장려하고 인센티브를 제공하는 것입니다. Google은 불만족스러운 경험을 보상하기에 충분한 만족스러운 경험을 제공할 수 있는 경우 불만족스러운 경험을 정당화하는 시나리오를 장려하고 싶지 않습니다. 사용자는 페이지가 빠르게 로드되고 빠르게 새 콘텐츠로 전환되기를 원하며, Google은 이러한 유형의 환경에 적합한 측정항목을 설계하려고 노력했습니다.
따라서 사이트의 MPA 버전이 동일한 사이트의 SPA 버전보다 Core Web Vitals 측정항목의 75번째 백분위수에서 더 나은 결과를 얻을 수 있지만 SPA 버전은 '좋음' 기준점을 충족하기 위해 노력해야 합니다. SPA 버전이 대부분의 사용자에게 '좋음' 기준점을 충족하지 못하면 후속 페이지 내 탐색 환경이 우수하더라도 초기 로드 환경이 여전히 좋지 않은 것으로 인식될 수 있습니다.
향후 Google은 우수한 로드 후 환경을 장려하는 측정항목을 개발할 계획이며, 이는 초기 로드 환경을 손상시키지 않는 방식으로 고품질 SPA를 장려하는 가장 좋은 방법이라고 생각합니다. 이미 전체 페이지 수명 주기 동안 상호작용 지연 시간을 측정하는 다음 페인트에 대한 상호작용 (INP)이라는 새로운 측정항목을 제공했으며, SPA 경로 전환을 측정하는 측정항목을 비롯한 다른 로드 후 측정항목도 적극적으로 개발하고 있습니다(아래 참고).
사이트를 MPA에서 SPA로 전환했는데 점수가 하락했습니다. 원래 이렇게 작동하는 것인가요?
경우에 따라 다릅니다. 대규모 아키텍처 이전 후 점수가 변경되는 데는 여러 가지 이유가 있지만, 따뜻한 캐시 로드 수가 감소하면 점수가 일부 변경될 수 있습니다.
가장 빠른 방법은 Lighthouse를 사용하여 방문 페이지 중 하나의 MPA 버전과 SPA 버전을 모두 테스트하는 것입니다. SPA 버전의 Core Web Vitals 측정항목에서 Lighthouse 점수가 더 낮으면 업데이트 후 로드 환경이 악화되었을 가능성이 큽니다.
Core Web Vitals 점수를 높이려면 사이트를 SPA에서 MPA로 전환해야 하나요?
그렇지 않을 수도 있습니다. SPA 스택에 만족하지 않고 MPA가 더 나은 사용자 환경을 제공할 것이라고 생각되는 경우에만 SPA에서 MPA로 전환해야 합니다.
시간이 지남에 따라 Core Web Vitals 측정항목이 개선되고 전체 브라우징 환경을 더 많이 다루게 되면 우수한 UX를 제공하는 잘 빌드된 SPA를 보유한 팀의 Core Web Vitals 점수가 이를 반영할 것으로 예상됩니다.
Core Web Vitals 점수가 SPA의 방문 페이지에 대해서만 보고되는 경우 경로 전환 후 '페이지'에서 발생하는 문제를 디버그하려면 어떻게 해야 하나요?
Core Web Vitals 측정항목의 필드 데이터를 보고하는 Google 도구 (예: Search Console, PageSpeed Insights)는 Chrome 사용자 환경 보고서(CrUX)에서 데이터를 가져옵니다. CrUX는 출처 또는 페이지 URL (로드 시 페이지 URL)별로 데이터를 집계합니다.
위에 이미 나열된 모든 이유로 인해 CrUX는 SPA 경로별로 데이터를 집계할 수 없습니다. 하지만 자체 아키텍처에 익숙한 사이트 소유자는 이를 직접 측정할 수 있으며, 많은 분석 도구를 사용하면 SPA 경로 변경이 발생할 때 신호를 보내고 그에 따라 측정 데이터를 업데이트할 수 있습니다.
분석 도구로 웹 바이탈 측정항목을 측정할 때는 현재 경로 URL과 원래 페이지 URL을 모두 측정해야 합니다. 이렇게 하면 페이지 수명 주기 전반에서 발생하는 개별 문제를 디버그할 뿐만 아니라 Google 도구에서 측정항목을 측정하고 보고하는 방식에 맞게 원래 페이지 URL별로 집계할 수 있습니다.
이 주제에 관한 자세한 내용과 권장사항은 현장에서 성능 디버그를 참고하세요.
MPA가 SPA에 비해 부당한 이익을 얻지 못하도록 하기 위해 Google은 어떤 조치를 취하고 있나요?
위에서 언급한 것처럼 적절하게 최적화된 MPA는 캐시된 페이지 방문의 비율이 더 높을 수 있으므로 경우에 따라 75번째 백분위수에서 더 나은 Core Web Vitals 점수를 보고할 수 있습니다. 반대로 적절하게 최적화된 SPA의 실제 사용자 환경 개선사항은 현재 Core Web Vitals 측정항목에서 포착되지 않습니다.
Google은 이로 인해 웹 Vitals 이니셔티브의 목표와 완전히 일치하지 않는 인센티브가 생겨난다는 점을 인식하고 있으며 이를 해결하기 위한 방법을 적극적으로 모색하고 있습니다. 현재 YouTube는 단기적인 해결책과 장기적인 해결책, 두 가지를 모색하고 있습니다.
- 교차 출처 페이지 방문과 동일 출처 페이지 방문을 별도로 평가합니다.
- 더 나은 SPA 측정을 지원하는 새로운 API를 설계합니다.
교차 출처 및 동일 출처 페이지 방문을 별도로 평가
현재 Core Web Vitals 측정항목은 모든 페이지 방문을 단일 버킷으로 집계합니다. 즉, 신규 방문과 재방문, 방문 페이지와 결제 페이지, 캐시 상태가 성능에 영향을 줄 수 있는 기타 집계 유형을 구분하지 않습니다.
SPA 및 MPA 실적 간의 차이를 표준화하는 한 가지 방법은 방문 유형에 따라 가중치를 다르게 적용하는 것입니다. 경우에 따라 완전히 다른 기준 추천을 적용할 수도 있습니다.
효과적인 캐시 구현에 보상을 제공하는 것은 좋지만 빠른 내부 사이트 탐색으로 느린 방문 페이지 로드를 가릴 수는 없습니다. 또한 측정항목 점수를 높이기 위해 긴 페이지를 더 짧은 페이지 모음으로 나누도록 사이트에 인센티브를 제공하고 싶지 않습니다.
교차 출처 및 동일 출처 페이지 방문을 별도로 평가하면 특정 사이트에서 한 유형의 상대적 인기가 특정 측정항목의 분포를 왜곡하지 않도록 하면서 두 유형의 환경 모두 중요하다는 점을 확인할 수 있습니다.
더 나은 SPA 측정을 지원하는 새로운 API 설계
위에 언급된 것과 동시에 적극적으로 개발 중인 또 다른 솔루션은 새로운 App History API입니다. 이 API는 현재 SPA 패턴을 표준화하고 대규모로 SPA 사용량을 더 쉽게 측정하고 이해하는 데 도움이 됩니다.
App History API는 SPA 측정에 관한 두 가지 주요 기능이 있는 새로운 navigate 이벤트를 도입합니다.
- 링크 클릭, 양식 제출 또는 브라우저의 뒤로 또는 앞으로 UI를 통해 탐색이 시작된 경우에만 true로 설정되는
userInitiated플래그입니다. - 개발자가 탐색을 실행하기 위해 시작한 작업이 완료되었음을 신호할 수 있는 프로미스를 사용하는
transitionWhile()메서드입니다.
userInitiated 플래그는 명확한 사용자 의도를 나타내는 SPA 경로 전환의 시맨틱 시작점을 결정하는 데 사용할 수 있습니다. transitionWhile() 약속 확인은 브라우저가 페인트를 특정 경로 전환과 연관시켜 해당 전환과 관련된 최대 콘텐츠 페인트를 결정할 수 있도록 도와줍니다.
이전 섹션에 설명된 아이디어를 기반으로 SPA 경로 전환 시간을 MPA의 동일 출처 페이지 로드와 동일한 버킷으로 집계할 수도 있습니다. 이는 MPA에서 SPA로 이전하는 사이트에서 전후의 실적을 실제로 비교할 수 있게 되므로 매우 흥미롭습니다.
물론 이러한 판단을 정확하게 내릴 수 있는지 확인하기 위해서는 더 많은 연구가 필요합니다. 이 제안에 관한 제안이나 의견이 있으면 web-vitals-feedback@googlegroups.com으로 이메일을 보내 주세요.
최종 의견
Google은 웹 바이탈 측정항목을 개선하고 사용자에게 중요한 고품질 환경을 측정하고 이를 장려하기 위해 최선을 다하고 있습니다. 하지만 현재 측정 격차가 존재한다는 점을 알고 있습니다. 현재 이 측정항목은 사용자 경험의 모든 측면을 다루지는 않지만 이러한 격차를 해소하기 위해 적극적으로 노력하고 있습니다.
현재의 제한사항에도 불구하고 기존 측정항목에서 포착하는 영역은 웹의 상태와 성공에 매우 중요하다고 생각하며, 아키텍처와 관계없이 사이트가 권장 기준을 충족하지 못하는 경우 개선의 여지가 있다고 생각합니다.
이 게시물이 이 복잡하고 미묘한 주제에 대해 이해하는 데 도움이 되었기를 바랍니다. 현재 또는 향후 웹 성능 보고서 측정항목에 관한 의견이 있으면 언제든지 web-vitals-feedback@googlegroups.com으로 이메일을 보내주세요.