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