SPA, Core Web Vitals, Core Web Vitals에서 이러한 항목을 처리하는 방법에 관한 일반적인 질문에 대한 답변입니다.
게시일: 2021년 9월 14일, 최종 업데이트: 2026년 8월 11일
2020년 5월에 웹 바이탈 이니셔티브를 처음 도입한 이후 Chrome팀은 프로그램에 관한 많은 유용한 질문과 의견을 받았습니다.
아마도 가장 많은 질문을 받은 주제이자 답변하기 가장 어려운 질문은 단일 페이지 애플리케이션 (SPA)에서 코어 웹 바이탈을 측정하는 방법과 SPA 아키텍처가 코어 웹 바이탈 점수에 미치는 영향일 것입니다.
이러한 질문에 답변하기 어려운 이유는 문제가 매우 미묘하기 때문입니다. 따라서 이 게시물에서는 가장 일반적인 질문에 최대한 자세한 내용과 컨텍스트를 제공하여 답변해 드리겠습니다.
하지만 구체적인 내용을 살펴보기 전에 Google은 사이트를 빌드하는 데 사용되는 아키텍처나 기술에 대해 선호하는 바가 없다는 점을 말씀드리고자 합니다. Google은 SPA와 다중 페이지 애플리케이션 (MPA) 모두 사용자에게 고품질 환경을 제공할 수 있다고 생각하며, 웹 바이탈 이니셔티브의 목표는 기술과 무관하게 환경을 측정하는 측정항목을 제공하는 것입니다.
자주 묻는 질문(FAQ)
다음은 이 주제에 관해 가장 자주 묻는 질문입니다. 의견 그룹에서 또는 문제를 제기하여 이 FAQ에 추가할 의견을 보내주시면 감사하겠습니다.
Core Web Vitals 측정항목에 SPA 경로 전환이 포함되나요?
처음 도입되었을 때 각 코어 웹 바이탈 측정항목은 현재 최상위 페이지 탐색을 기준으로 측정되었습니다. 페이지에서 새 콘텐츠를 동적으로 로드하고 주소 표시줄의 페이지 URL을 업데이트해도 Core Web Vitals 측정항목이 측정되는 방식에는 영향을 미치지 않습니다.
측정항목 값은 재설정되지 않았으며 각 측정항목 측정과 연결된 URL은 페이지 로드를 시작한 사용자가 이동한 URL입니다.
Chrome 151에서는 SPA 경로 전환에서 Core Web Vitals를 측정할 수 있는 새로운 API를 도입했습니다. 이 글을 쓰는 시점 (2026년 8월)에는 이러한 API가 web-vitals, RUM 솔루션, Chrome DevTools와 같은 도구와 같은 측정 라이브러리에서 사용되기 시작했습니다. Chrome은 아직 Chrome 사용자 경험 보고서 (CrUX)에 이러한 API를 통합하는 기간을 게시하지 않았습니다. 또한 다른 브라우저 엔진은 아직 이러한 새로운 API를 지원하지 않으므로 이러한 브라우저의 경우 전체 페이지 로드에서만 Core Web Vitals를 측정할 수 있습니다.
이 문제를 해결하기 어려웠던 이유는 무엇인가요?
현재 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 변경사항에서 '실제' 경로 변경사항을 안정적으로 식별할 수 있는 견고한 휴리스틱과 이러한 전환의 시작과 끝을 표시하는 명확한 신호가 없으면 이러한 경우 코어 웹 바이탈 측정항목을 보고하면 데이터가 흐려지고 사이트의 실제 사용자 환경을 덜 유용하거나 대표하게 됩니다.
소프트 탐색 작업은 두 가지 새로운 성능 API를 통해 이 문제를 해결했습니다.
PerformanceSoftNavigation: 사용자 상호작용으로 인해 페인트와 URL 변경이 모두 발생하는 시점을 측정합니다. 이 세 가지의 조합은 사용된 프레임워크와 이전에 언급된 일부 차이와 관계없이 '소프트 탐색'의 표준화된 정의를 제공합니다. 이를 통해 성능 타임라인을 별도의 '탐색'으로 분할하여 각 탐색에 대해 CLS 및 INP를 측정할 수 있습니다.InteractionContentfulPaint: 상호작용 후 '콘텐츠 페인트'를 측정하여 이러한 소프트 탐색에 대해 FCP 및 LCP를 측정할 수 있습니다.
이 두 API의 조합을 사용하면 전체 페이지 로드와 소프트 탐색 모두에서 Core Web Vitals를 측정할 수 있습니다.
SPA 경로 변경은 코어 웹 바이탈의 전체 페이지 로드와 동일한가요?
아니요. 이러한 유형의 탐색 간에는 여전히 많은 차이가 있으며, 이로 인해 코어 웹 바이탈 측정항목이 달라질 수 있습니다.
소프트 탐색에는 페이지에 콘텐츠가 있으며 새 '페이지'를 표시하기 위해 해당 콘텐츠의 일부 또는 전부를 업데이트합니다. 여러 면에서 이는 캐시되지 않은 전체 페이지 로드와 페이지 리소스의 일부 또는 전부가 캐시될 때의 페이지 로드 간의 차이와 유사하지만, 일부 콘텐츠가 렌더링된 상태로 유지될 수 있으므로 훨씬 더 극단적인 상태입니다.
이론적으로 주요 차이점은 소프트 탐색이 훨씬 더 빠를 수 있다는 것입니다. 하지만 다른 미묘한 차이도 있습니다.
새로운 소프트 탐색 API는 새 콘텐츠만 고려합니다. 따라서 <h1> 및 텍스트 콘텐츠를 업데이트하지만 페이지 간에 동일한 히어로 이미지를 유지하는 페이지는 다시 페인트되지 않은 경우 히어로 이미지를 LCP 후보로 간주하지 않습니다. 이로 인해 동일한 페이지가 전체 페이지 로드로 로드되는지 아니면 다른 기존 페이지의 소프트 탐색으로 로드되는지에 따라 LCP 시간을 계산하는 데 사용되는 요소가 달라집니다.
마찬가지로 사이트를 실행하는 데 필요한 많은 JavaScript가 이미 로드되어 있으므로 소프트 탐색의 INP가 더 적을 수 있습니다. 마찬가지로 소프트 탐색은 더 적거나 더 많을 수 있습니다. 동일한 콘텐츠가 전체 페이지 로드에서 CLS를 발생시키지만 소프트 탐색에서 로드하거나 다시 렌더링할 필요가 없는 경우 CLS가 발생합니다.
전체 페이지 로드 (탐색 상호작용 처리 후 측정)와 소프트 탐색 (상호작용 시작 시간부터 측정)에서 측정이 이루어지는 시점에도 약간의 차이가 있습니다.
앞서 언급한 바와 같이 이러한 차이점은 캐시되지 않은 페이지와 캐시된 페이지 간의 차이와 유사하며, Core Web Vitals가 측정하려는 개념은 여전히 적용됩니다. 그러나 코어 웹 바이탈 문제를 조사할 때는 이러한 미묘한 차이를 이해하는 것이 좋습니다.
SPA가 MPA보다 코어 웹 바이탈에서 우수한 실적을 거두기가 더 어렵나요?
SPA 아키텍처에는 SPA의 페이지가 MPA의 유사한 페이지와 마찬가지로 빠르게 로드되고 모든 코어 웹 바이탈 측정항목에서 마찬가지로 우수한 점수를 받는 것을 방지하는 고유한 요소가 없습니다.
그러나 적절하게 최적화된 MPA는 SPA에는 없는 코어 웹 바이탈 기준점을 충족하는 데 몇 가지 이점이 있습니다. 이는 앞서 설명한 소프트 탐색 작업으로 인해 대부분 완화되었지만 이러한 새로운 API가 아직 사용되지 않는 경우에도 여전히 적용될 수 있습니다. 그 이유는 MPA 아키텍처에서는 각 '페이지'가 콘텐츠를 동적으로 가져와 기존 페이지에 삽입하는 대신 전체 페이지 탐색으로 로드되기 때문입니다. 즉, MPA를 방문하는 사용자는 사이트에서 두 개 이상의 페이지를 로드할 가능성이 높으며, 이는 MPA의 모든 페이지 로드 분포에서 더 큰 비율이 일부 또는 모든 하위 리소스가 캐시되는 것을 포함한다는 의미입니다.
물론 MPA가 SPA보다 Core Web Vitals 측정항목에서 더 나은 실적을 거두려면 몇 가지 조건이 충족되어야 합니다.
- MPA는 동일 출처 페이지 로드가 75번째 백분위수에서 교차 출처 페이지 로드보다 실제로 더 빠르도록 하위 리소스 캐싱을 최적화해야 합니다.
- 사이트에서 페이지 로드 속도를 높이는 캐싱 이점을 얻으려면 MPA를 방문하는 사용자가 여러 페이지를 방문해야 합니다.
코어 웹 바이탈 평가는 페이지 방문의 75번째 백분위수를 고려하므로 데이터 세트에 실적이 우수한 페이지 방문이 많을수록 분포의 75번째 백분위수의 방문이 권장 기준점 내에 있을 가능성이 높아집니다.
코어 웹 바이탈 점수를 비교할 때 고려해야 할 중요한 사항은 데이터가 집계되는 방식입니다. 즉, 분포의 데이터 세트에 사이트 또는 출처의 모든 페이지가 포함되는지 아니면 특정 페이지 URL의 페이지 로드만 포함되는지입니다.
출처의 모든 페이지 점수를 집계할 때 개별 빠른 페이지는 출처 전체의 75번째 백분위수를 개선할 수 있습니다. 그러나 개별 페이지별로 집계할 때는 한 페이지의 점수가 다음 페이지의 점수에 영향을 미치지 않습니다. 즉, 페이지별로 MPA의 점수를 집계할 때 결제 페이지에서 확인된 빠른 캐시 로드는 사이트의 방문 페이지에서 발생하는 느린 초기 로딩의 점수를 개선하지 않습니다.
PageSpeed Insights 또는 개별 페이지 URL과 전체 출처의 점수를 모두 보고하는 Chrome 사용자 경험 보고서 API를 사용하여 다양한 집계 방법으로 사이트의 점수를 확인할 수 있습니다.
SPA 아키텍처가 Core Web Vitals 점수에 영향을 미칠 수 있는 또 다른 방법은 페이지의 전체 수명을 고려하는 측정항목입니다. SPA를 방문하는 사용자는 전체 세션 동안 동일한 '페이지'에 머무르는 경향이 있으므로 시간이 지남에 따라 누적되는 측정항목은 MPA보다 SPA에 더 가혹할 수 있습니다.
소프트 탐색 작업을 통해 Core Web Vitals를 측정하는 방식에서 SPA에 불이익이 없어야 한다고 생각합니다. 그러나 모든 도구 및 보고 솔루션에서 이러한 API를 완전히 통합하는 데는 시간이 걸립니다.
SPA 아키텍처가 사용자 환경을 개선한다면 이러한 개선사항이 측정항목에 반영되어야 하지 않나요?
예, 반영되어야 합니다. 오늘날 웹에서 SPA가 구현되는 다양한 방식을 고려할 때 환경이 얼마나 개선되었는지 대규모로 정량화하기는 어려웠습니다. 이제 측정 문제가 해결되었으며 이러한 새로운 API를 사용하면 SPA로 전환하여 얻은 개선사항이 측정항목에 반영됩니다.
사실 웹 성능 업계 (Google 포함)는 페이지 로드 자체에 투자한 만큼 페이지의 로드 후 성능에 관한 사용자 중심 측정항목을 개발하는 데 많은 시간과 노력을 투자하지 않았습니다. 이는 로드 후 성능이 중요하지 않아서가 아니라 로드 후 UX와 상호작용이 훨씬 더 다양하고 덜 명확하게 정의되어 있기 때문에 측정항목을 설계하기 어렵기 때문입니다.
하지만 이제 SPA 성능을 측정할 수 있는 로드 후 측정항목이 더 많아졌다고 해서 로드 후 환경이 개선되었다는 이유만으로 로드 환경을 무시하고 싶지는 않습니다.
웹 바이탈 이니셔티브의 목표 중 하나는 웹페이지를 로드하고 사용하는 가능한 한 많은 측면에서 우수한 사용자 환경을 장려하고 인센티브를 제공하는 것입니다. 좋은 환경이 충분히 있어 나쁜 환경을 보완할 수 있다면 나쁜 환경을 정당화하는 시나리오를 장려하고 싶지 않습니다. 사용자는 페이지가 빠르게 로드되고 새 콘텐츠로 빠르게 전환되기를 원하며, Google은 이러한 유형의 환경을 선호하는 측정항목을 설계하려고 노력했습니다.
사이트를 MPA에서 SPA로 전환했는데 점수가 하락했습니다. 예상되는 결과인가요?
상황에 따라 다름 주요 아키텍처 마이그레이션 후 점수가 변경될 수 있는 이유는 여러 가지가 있지만, 워밍 캐시 로드 수가 감소하면 일부 변경사항이 발생할 수 있습니다.
빠르게 확인하는 방법은 Lighthouse를 사용하여 방문 페이지 중 하나의 MPA 및 SPA 버전을 모두 테스트하는 것입니다. SPA 버전의 Core Web Vitals 측정항목에서 Lighthouse 점수가 낮으면 업데이트 후 로드 환경이 악화되었을 가능성이 높습니다.
코어 웹 바이탈에서 더 나은 점수를 받으려면 사이트를 SPA에서 MPA로 전환해야 하나요?
그렇지 않을 수도 있습니다. SPA 스택에 만족하지 않고 MPA가 더 나은 사용자 환경을 제공할 것이라고 생각할 만한 이유가 있는 경우에만 SPA에서 MPA로 전환해야 합니다.
소프트 탐색 작업을 통해 측정 문제를 해결했다고 생각하므로 이러한 이유만으로 이동하는 것은 적절하지 않습니다.
그러나 측정항목이 개선되는 것뿐만 아니라 성능이 개선될 것이라고 생각할 만한 이유가 있다면 SPA에서 MPA로 (또는 그 반대로) 이동하는 것이 좋습니다.
코어 웹 바이탈 점수가 SPA의 방문 페이지에만 보고되는 경우 경로 전환 후 '페이지'에서 발생하는 문제를 어떻게 디버그할 수 있나요?
코어 웹 바이탈 측정항목의 필드 데이터를 보고하는 Google 도구 (예: Search Console 및 PageSpeed Insights)는 Chrome 사용자 환경 보고서 (CrUX)에서 데이터를 가져옵니다. CrUX는 출처 또는 페이지 URL (즉, 로드 시 페이지 URL)별로 데이터를 집계합니다.
Google은 집계된 데이터에 SPA 경로별 데이터를 포함할 수 있도록 CrUX를 허용하는 작업을 진행하고 있습니다. 그러나 사이트 소유자는 이제 새로운 API를 사용하여 Core Web Vitals를 SPA 경로별로 미리 측정하여 점수가 어떻게 변경될 수 있는지 파악할 수 있습니다.
자세한 내용과 권장사항은 소프트 탐색 측정을 참고하세요.
MPA가 SPA에 비해 불공정한 이점을 갖지 않도록 Google은 어떤 조치를 취하고 있나요?
앞서 언급한 바와 같이 소프트 탐색 작업을 통해 현재 진행 중인 작업은 이와 관련하여 SPA에 불이익이 없어야 한다고 생각하지만, 모든 도구 및 보고 솔루션에서 완전히 통합하는 데는 시간이 걸립니다.
교차 출처 및 동일 출처 페이지 방문을 별도로 평가
오늘날 Core Web Vitals 측정항목은 모든 페이지 방문을 단일 버킷으로 집계합니다. 즉, 신규 방문과 재방문, 방문 페이지와 결제 페이지 또는 캐시 상태가 성능에 영향을 미칠 수 있는 기타 집계 유형을 구분하지 않습니다.
SPA와 MPA 성능 간의 차이를 정규화하는 한 가지 방법은 다양한 유형의 방문에 서로 다른 가중치를 적용하는 것입니다. 완전히 다른 기준점 권장사항을 적용할 수도 있습니다.
Google은 효과적인 캐시 구현에 보상을 제공하고 싶지만, 빠른 사이트 내 탐색이 느린 방문 페이지 로드를 보완할 수 있도록 하고 싶지는 않습니다. 또한 측정항목 점수를 개선하기 위해 긴 페이지를 짧은 페이지 모음으로 분할하도록 사이트에 인센티브를 제공하고 싶지도 않습니다.
교차 출처 및 동일 출처 페이지 방문을 별도로 평가하면 특정 사이트에서 한 유형의 상대적 인기도가 특정 측정항목의 분포를 왜곡하지 않으면서 두 가지 유형의 환경이 모두 중요하다는 점을 보장할 수 있습니다.
최종 의견
Google은 Web Vitals 측정항목을 개선하고 사용자에게 중요한 고품질 환경을 측정하고 인센티브를 제공하기 위해 최선을 다하고 있습니다. 하지만 현재 측정 격차가 존재한다는 점을 인정합니다. 이제 측정항목이 SPA 경로 전환을 포함할 수 있으므로 주요 격차 중 하나가 해결되었습니다.
또한 이러한 새로운 API (특히 InteractionContentfulPaint)는 소프트 탐색의 코어 웹 바이탈 측정 외에도 추가적인 용도와 잠재적 이점이 있다고 생각합니다. 도입의 주요 이유가 해결되었으므로 이제 이러한 API를 계속 빌드할 수 있게 되어 매우 기쁩니다.
이 게시물이 복잡하고 미묘한 주제를 이해하는 데 도움이 되었기를 바랍니다. 현재 또는 향후 웹 바이탈 측정항목에 관한 의견이 있으면 언제든지 이메일 web-vitals-feedback@googlegroups.com로 보내주세요.