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