프론트 엔드 성능 2021: 계획 및 지표

이 가이드는 프론트엔드 성능 모니터링 , 세션 재생 및 제품 분석을 결합하여 더 나은 고객 경험을 구축하는 데 도움이 되는 서비스인 LogRocket의 친구들로부터 친절하게 지원되었습니다. LogRocket 은 다음을 포함한 주요 지표를 추적합니다. DOM 완료, 첫 번째 바이트까지의 시간, 첫 번째 입력 지연, 클라이언트 CPU 및 메모리 사용량. 지금 LogRocket의 무료 평가판을 받으십시오.

목차

1. 준비하기: 계획 및 측정항목
   성능 문화, 핵심 Web Vitals, 성능 프로필, CrUX, Lighthouse, FID, TTI, CLS, 장치.
2. 현실적인 목표 설정
   성능 예산, 성능 목표, RAIL 프레임워크, 170KB/30KB 예산.
3. 환경 정의
   프레임워크 선택, 기본 성능 비용, Webpack, 종속성, CDN, 프런트 엔드 아키텍처, CSR, SSR, CSR + SSR, 정적 렌더링, 사전 렌더링, PRPL 패턴.
4. 자산 최적화
   Brotli, AVIF, WebP, 반응형 이미지, AV1, 적응형 미디어 로딩, 비디오 압축, 웹 글꼴, Google 글꼴.
5. 빌드 최적화
   JavaScript 모듈, 모듈/모듈 패턴, 트리 쉐이킹, 코드 분할, 범위 호이스팅, Webpack, 차등 서비스, 웹 작업자, WebAssembly, JavaScript 번들, React, SPA, 부분 수화, 상호 작용 시 가져오기, 타사, 캐시.
6. 배달 최적화
   지연 로딩, 교차 관찰자, 렌더링 및 디코딩 지연, 중요한 CSS, 스트리밍, 리소스 힌트, 레이아웃 변경, 서비스 작업자.
7. 네트워킹, HTTP/2, HTTP/3
   OCSP 스테이플링, EV/DV 인증서, 패키징, IPv6, QUIC, HTTP/3.
8. 테스트 및 모니터링
   감사 워크플로, 프록시 브라우저, 404 페이지, GDPR 쿠키 동의 프롬프트, 성능 진단 CSS, 접근성.
9. 빠른 승리
10. 한 페이지에 모든 것
11. 체크리스트 다운로드(PDF, Apple Pages, MS Word)
12. 다음 가이드를 놓치지 않으려면 이메일 뉴스레터를 구독하세요.

준비하기: 계획 및 측정항목

미세 최적화는 성과를 추적하는 데 유용하지만 프로세스 전반에 걸쳐 내려진 모든 결정에 영향을 미칠 수 있는 측정 가능한 목표를 염두에 두고 명확하게 정의된 목표를 염두에 두는 것이 중요합니다. 몇 가지 다른 모델이 있으며 아래에 논의된 모델은 상당히 독단적입니다. 초기에 우선 순위를 설정해야 합니다.

1. 공연문화를 정착시킨다.
   많은 조직에서 프론트엔드 개발자는 일반적인 기본 문제가 무엇인지, 이를 해결하기 위해 어떤 전략을 사용해야 하는지 정확히 알고 있습니다. 그러나 성과 문화에 대한 확고한 지지가 없는 한 각 결정은 부서 간의 전쟁터가 되어 조직을 사일로로 분해할 것입니다. 비즈니스 이해 관계자의 동의가 필요하며 이를 얻으려면 속도(특히 나중에 자세히 다룰 핵심 성능 지표)에 대한 사례 연구 또는 개념 증명을 수립해야 메트릭 및 핵심 성과 지표에 이점이 있습니다. ( KPI ) 그들은 관심을 가지고 있습니다.

   예를 들어, 성능을 보다 가시적으로 만들기 위해 전환율과 응용 프로그램 로드 시간 간의 상관 관계와 렌더링 성능을 표시하여 수익 성능에 미치는 영향을 노출할 수 있습니다. 또는 검색 봇 크롤링 속도(PDF, 27–50페이지).

   개발/디자인 팀과 비즈니스/마케팅 팀 간의 긴밀한 연계 없이는 성과가 장기적으로 유지될 수 없습니다. 고객 서비스 및 영업 팀에 들어오는 일반적인 불만 사항을 연구하고 높은 이탈률 및 전환율 하락에 대한 분석을 연구합니다. 성능 향상이 이러한 일반적인 문제 중 일부를 완화하는 데 어떻게 도움이 되는지 알아보십시오. 이야기하고 있는 이해 관계자 그룹에 따라 논쟁을 조정하십시오.

   모바일과 데스크톱(예: Google Analytics 사용) 모두에서 성능 실험을 실행하고 결과를 측정합니다. 실제 데이터를 사용하여 회사 맞춤형 사례 연구를 구축하는 데 도움이 됩니다. 또한 WPO 통계에 게시된 사례 연구 및 실험의 데이터를 사용하면 성능이 중요한 이유와 성능이 사용자 경험 및 비즈니스 메트릭에 미치는 영향에 대한 비즈니스의 민감도를 높이는 데 도움이 됩니다. 하지만 성과가 중요하다고 말하는 것만으로는 충분하지 않습니다. 또한 측정 가능하고 추적 가능한 목표를 설정하고 시간이 지남에 따라 이를 관찰해야 합니다.

   거기에 도착하는 방법? 장기적 성과 구축에 대한 강연에서 Allison McKnight는 Etsy에서 공연 문화를 구축하는 데 그녀가 어떻게 도왔는지에 대한 포괄적인 사례 연구를 공유합니다(슬라이드). 보다 최근에 Tammy Everts는 크고 작은 조직 모두에서 매우 효과적인 성과 팀의 습관에 대해 이야기했습니다.

   조직에서 이러한 대화를 나누는 동안 UX가 경험의 스펙트럼인 것처럼 웹 성능은 분포라는 점을 명심하는 것이 중요합니다. Karolina Szczur가 말했듯이 "하나의 숫자가 열망하는 등급을 제공할 수 있을 것으로 기대하는 것은 잘못된 가정입니다." 따라서 성과 목표는 세분화되고 추적 가능하며 유형적이어야 합니다.

1. 목표: 가장 빠른 경쟁자보다 최소 20% 더 빠릅니다.
   심리학 연구에 따르면 사용자가 귀하의 웹사이트가 경쟁업체의 웹사이트보다 빠르다고 느끼도록 하려면 최소 20% 빨라야 합니다. 주요 경쟁업체를 연구하고 모바일 및 데스크톱에서 수행하는 방법에 대한 메트릭을 수집하고 경쟁업체를 능가하는 데 도움이 되는 임계값을 설정합니다. 하지만 정확한 결과와 목표를 얻으려면 먼저 분석을 연구하여 사용자 경험을 철저히 파악해야 합니다. 그런 다음 테스트를 위해 90번째 백분위수의 경험을 모방할 수 있습니다.

   경쟁업체의 성과에 대한 좋은 첫인상을 얻으려면 Chrome UX 보고서( CrUX , 기성품 RUM 데이터 세트, Ilya Grigorik의 비디오 소개 및 Rick Viscomi의 세부 가이드) 또는 RUM 모니터링 도구인 Treo를 사용할 수 있습니다. Chrome UX 보고서에서 제공합니다. 데이터는 Chrome 브라우저 사용자로부터 수집되므로 보고서는 Chrome 전용이지만 광범위한 방문자에 대해 성능, 가장 중요한 핵심 성능 평가 점수를 상당히 철저하게 분포시킵니다. 새로운 CrUX 데이터 세트는 매월 두 번째 화요일에 발표됩니다.

   또는 다음을 사용할 수도 있습니다.

   • Addy Osmani의 Chrome UX 보고서 비교 도구,
   • Speed ​​Scorecard(수익 영향 추정기 제공),
   • 실제 사용자 경험 테스트 비교 또는
   • SiteSpeed ​​CI(합성 테스트 기반).

   참고 : Page Speed ​​Insights 또는 Page Speed ​​Insights API(아니요, 더 이상 사용되지 않습니다!)를 사용하는 경우 집계가 아닌 특정 페이지에 대한 CrUX 성능 데이터를 얻을 수 있습니다. 이 데이터는 "랜딩 페이지" 또는 "제품 목록"과 같은 자산의 실적 목표를 설정하는 데 훨씬 더 유용할 수 있습니다. 그리고 CI를 사용하여 예산을 테스트하는 경우 대상 설정에 CrUX를 사용한 경우 테스트된 환경이 CrUX와 일치하는지 확인해야 합니다( Patrick Meenan에게 감사드립니다! ).

   속도의 우선 순위를 정하는 이유를 보여주기 위해 도움이 필요하거나, 느린 성능과 함께 전환율 감소 또는 이탈률 증가를 시각화하고 싶거나, 조직에서 RUM 솔루션을 옹호해야 하는 경우, Sergey Chernyshev는 데이터를 시뮬레이션하고 시각화하여 요점을 파악하는 데 도움이 되는 오픈 소스 도구인 UX 속도 계산기를 구축했습니다.

   

   

   때로는 CrUX에서 가져온 데이터를 다른 데이터와 결합하여 속도 저하, 사각 지대 및 비효율이 있는 곳(경쟁업체 또는 프로젝트)을 빠르게 해결해야 하는 경우가 있습니다. Harry Roberts는 작업에서 주요 페이지 유형별로 성능을 분류하고 주요 메트릭이 어떻게 다른지 추적하는 데 사용하는 Site-Speed ​​Topography Spreadsheet를 사용하고 있습니다. 스프레드시트를 Google 스프레드시트, Excel, OpenOffice 문서 또는 CSV로 다운로드할 수 있습니다.

   

   그리고 끝까지 진행하고 싶다면 사이트의 모든 페이지에서 Lighthouse 성능 감사를 실행할 수 있습니다(Lightouse Parade를 통해). CSV로 저장한 출력과 함께. 이렇게 하면 경쟁업체의 특정 페이지(또는 페이지 유형)가 더 나쁘거나 더 나은 성과를 거두고 무엇에 집중해야 하는지 식별하는 데 도움이 됩니다. (자신의 사이트의 경우 데이터를 분석 엔드포인트로 보내는 것이 더 나을 수 있습니다!).

   

   이러한 방식으로 데이터를 수집하고, 스프레드시트를 설정하고, 20%를 줄이고, 목표( 성과 예산 )를 설정합니다. 이제 테스트할 측정 가능한 항목이 있습니다. 예산을 염두에 두고 대화형 시간을 단축하기 위해 최소한의 페이로드만 제공하려는 경우 합리적인 경로에 있는 것입니다.

   시작하는 데 리소스가 필요하십니까?

   • Addy Osmani는 성능 예산 책정을 시작하는 방법, 새로운 기능의 영향을 수량화하는 방법, 예산이 초과되었을 때 시작하는 방법에 대한 매우 상세한 글을 작성했습니다.
   • 성능 예산으로 설계에 접근하는 방법에 대한 Lara Hogan의 가이드는 설계자에게 유용한 지침을 제공할 수 있습니다.
   • Harry Roberts는 Request Map,
   • Jonathan Fielding의 Performance Budget Calculator, Katie Hempenius의 perf-budget-calculator 및 Browser Calories는 예산을 만드는 데 도움이 될 수 있습니다.
   • 많은 회사에서 성과 예산은 열망이 아니라 오히려 실용적이어야 하며, 특정 지점을 지나치지 않도록 유지 신호 역할을 합니다. 이 경우 지난 2주 동안 최악의 데이터 포인트를 임계값으로 선택하고 거기에서 가져올 수 있습니다. Performance Budgets는 이를 달성하기 위한 전략을 실용적으로 보여줍니다.
   • 또한 빌드 크기를 보고하는 그래프로 대시보드를 설정하여 성능 예산과 현재 성능을 모두 볼 수 있습니다 . 이를 가능하게 하는 많은 도구가 있습니다. SiteSpeed.io 대시보드(오픈 소스), SpeedCurve 및 Calibre는 그 중 일부에 불과하며 perf.rocks에서 더 많은 도구를 찾을 수 있습니다.

   

   예산이 확보되면 Webpack Performance Hints 및 Bundlesize, Lighthouse CI, PWMetrics 또는 Sitespeed CI를 사용하여 빌드 프로세스에 통합하여 pull 요청에 예산을 적용하고 PR 주석에 점수 기록을 제공하십시오.

   전체 팀에 성능 예산을 공개하려면 Lightwallet을 통해 Lighthouse에 성능 예산을 통합하거나 빠른 Github Actions 통합을 위해 LHCI Action을 사용하십시오. 그리고 사용자 정의가 필요한 경우 엔드포인트 API인 webpagetest-charts-api를 사용하여 WebPagetest 결과에서 차트를 작성할 수 있습니다.

   그러나 성과 인식은 성과 예산만으로 이루어지면 안 됩니다. Pinterest와 마찬가지로 종속성이 많고 번들을 부풀릴 수 있는 파일 및 디렉터리에서 가져오기를 허용하지 않는 사용자 지정 eslint 규칙을 만들 수 있습니다. 전체 팀에서 공유할 수 있는 "안전한" 패키지 목록을 설정합니다.

   또한 귀하의 비즈니스에 가장 유익한 중요한 고객 작업에 대해 생각해 보십시오. 중요한 작업에 대한 허용 가능한 시간 임계값을 연구, 논의 및 정의하고 전체 조직이 승인한 "UX 준비" 사용자 타이밍 표시를 설정합니다. 대부분의 경우 사용자 여정은 여러 부서의 작업과 관련이 있으므로 허용 가능한 시간에 맞춰 조정하면 향후 성능 논의를 지원하거나 방지하는 데 도움이 됩니다. 추가된 리소스 및 기능에 대한 추가 비용이 표시되고 이해되는지 확인합니다.

   구축 중인 제품의 새로운 기능에서 리팩토링, 새로운 글로벌 청중에게 다가가기까지 다양한 기술 이니셔티브와 성과 노력을 조정합니다. 따라서 추가 개발에 대한 대화가 발생할 때마다 성능도 대화의 일부입니다. 코드 기반이 최신이거나 리팩토링되는 중일 때 성능 목표에 훨씬 더 쉽게 도달할 수 있습니다.

   또한 Patrick Meenan이 제안한 것처럼 설계 과정 에서 로딩 순서와 절충안을 계획하는 것이 좋습니다. 어떤 부분이 더 중요한지 조기에 우선 순위를 지정하고 표시 순서를 정의하면 지연될 수 있는 부분도 알게 됩니다. 이상적으로는 해당 순서가 CSS 및 JavaScript 가져오기의 순서도 반영하므로 빌드 프로세스 중에 처리하기가 더 쉬울 것입니다. 또한 페이지가 로드되는 동안(예: 웹 글꼴이 아직 로드되지 않은 경우) "중간" 상태에 있어야 하는 시각적 경험을 고려하십시오.

   조직에 강력한 성과 문화를 구축했으면 시간이 흘러도 우선 순위를 그대로 유지하기 위해 이전 자신보다 20% 더 빠른 것을 목표로 삼으십시오( Guy Podjarny에게 감사드립니다! ). 그러나 봇 트래픽 및 계절성 효과와 함께 고객의 다양한 유형 및 사용 행동(Tobias Baldauf가 케이던스 및 집단이라고 부름)을 고려하십시오.

   기획, 기획, 기획. 초기에 빠른 "낮은 성과" 최적화에 들어가고 싶은 마음이 들 수도 있고 빠른 승리를 위한 좋은 전략일 수도 있습니다. - 맞춤형 성능 목표.

1. 올바른 측정항목을 선택하세요.
   모든 지표가 똑같이 중요한 것은 아닙니다. 어떤 메트릭이 애플리케이션에 가장 중요한지 연구하십시오. 일반적으로 인터페이스의 가장 중요한 픽셀 을 렌더링하기 시작할 수 있는 속도와 렌더링된 픽셀에 대한 입력 응답 성을 얼마나 빨리 제공할 수 있는지에 따라 정의됩니다. 이 지식은 지속적인 노력을 위한 최상의 최적화 목표를 제공할 것입니다. 결국 경험을 정의하는 것은 로드 이벤트나 서버 응답 시간이 아니라 인터페이스가 얼마나 빠른지 인지하는 것 입니다.

   무슨 뜻이에요? 전체 페이지 로드 시간(예: onLoad 및 DOMContentLoaded 타이밍 사용)에 초점을 맞추는 대신 고객이 인식하는 페이지 로드의 우선 순위를 지정하십시오. 이는 약간 다른 측정항목 집합에 초점을 맞추는 것을 의미합니다. 사실, 올바른 메트릭을 선택하는 것은 명백한 승자가 없는 과정입니다.

   Tim Kadlec의 연구와 그의 강연에서 Marcos Iglesias의 메모를 기반으로 하면 기존 측정항목 을 몇 개의 집합으로 그룹화할 수 있습니다. 일반적으로 성능에 대한 완전한 그림을 얻으려면 이들 모두가 필요하며 특정 경우에는 그 중 일부가 다른 것보다 더 중요합니다.

   • 수량 기반 메트릭 은 요청 수, 가중치 및 성능 점수를 측정합니다. 경보를 발생시키고 시간이 지남에 따라 변경 사항을 모니터링하는 데는 좋지만 사용자 경험을 이해하는 데는 좋지 않습니다.
   • 마일스톤 메트릭 은 로드 프로세스의 수명 동안 상태를 사용합니다(예: Time To First Byte 및 Time To Interactive ). 사용자 경험 및 모니터링을 설명하는 데 적합하지만 이정표 사이에 어떤 일이 발생하는지 알기에는 적합하지 않습니다.
   • 렌더링 메트릭 은 콘텐츠가 얼마나 빨리 렌더링되는지에 대한 추정치를 제공합니다(예: 시작 렌더링 시간, 속도 인덱스 ). 렌더링 성능을 측정하고 조정하는 데는 좋지만 중요한 콘텐츠가 표시되고 상호 작용할 수 있는 시점을 측정하는 데에는 적합하지 않습니다.
   • 사용자 지정 메트릭 은 사용자에 대한 특정 사용자 지정 이벤트(예: Twitter의 첫 트윗 시간 및 Pinterest의 PinnerWaitTime)를 측정합니다. 사용자 경험을 정확하게 설명하는 데는 좋지만 메트릭을 확장하고 경쟁자와 비교하는 데는 좋지 않습니다.

   그림을 완성하기 위해 일반적으로 이러한 모든 그룹에서 유용한 메트릭을 찾습니다. 일반적으로 가장 구체적이고 관련성이 높은 항목은 다음과 같습니다.

   • 인터랙티브 시간 (TTI)
     레이아웃이 안정화 되고 주요 웹 글꼴이 표시되고 기본 스레드가 사용자 입력을 처리할 수 있을 만큼 충분히 사용 가능한 지점(기본적으로 사용자가 UI와 상호 작용할 수 있는 시간 표시)입니다. 사용자가 지연 없이 사이트를 사용하기 위해 경험해야 하는 대기 시간을 이해하기 위한 주요 측정항목입니다. Boris Schapira는 TTI를 안정적으로 측정하는 방법에 대한 자세한 게시물을 작성했습니다.
   • 첫 번째 입력 지연 (FID) 또는 입력 응답 성
     사용자가 귀하의 사이트와 처음 상호작용할 때부터 브라우저가 실제로 해당 상호작용 에 응답할 수 있을 때까지의 시간입니다. 사용자가 실제로 사이트와 상호 작용할 때 발생하는 그림의 누락된 부분을 설명하므로 TTI를 매우 잘 보완합니다. RUM 지표로만 사용됩니다. 브라우저에서 FID를 측정하기 위한 JavaScript 라이브러리가 있습니다.
   • 최대 함량 페인트 (LCP)
     페이지의 중요한 콘텐츠 가 로드되었을 가능성이 있는 페이지 로드 타임라인의 지점을 표시합니다. 페이지의 가장 중요한 요소는 사용자의 뷰포트에서 볼 수 있는 가장 큰 요소라고 가정합니다. 요소가 접히는 부분 위와 아래 모두에 렌더링되면 보이는 부분만 관련성이 있는 것으로 간주됩니다.
   • 총 차단 시간( 미정 )
     페이지가 안정적으로 상호작용하기 전에 페이지가 얼마나 비대화식인지의 심각도를 수량화하는 데 도움이 되는 측정항목입니다(즉, 기본 스레드에 최소 5초 동안 50ms( 긴 작업 ) 이상 실행되는 작업이 없음). 이 메트릭은 입력 응답을 방지할 만큼 충분히 오랫동안 메인 스레드가 차단된 첫 번째 페인트와 TTI(Time to Interactive) 사이의 총 시간을 측정합니다. 따라서 낮은 TBT가 좋은 성과를 나타내는 좋은 지표라는 것은 놀라운 일이 아닙니다. (고마워, Artem, Phil)
   • 누적 레이아웃 이동( CLS )
     이 측정항목은 사용자가 사이트에 액세스할 때 예상치 못한 레이아웃 변경 ( 리플로우 )을 얼마나 자주 경험하는지 강조합니다. 불안정한 요소와 전반적인 경험에 미치는 영향을 조사합니다. 점수가 낮을수록 좋습니다.
   • 속도 지수
     페이지 콘텐츠가 시각적으로 채워지는 속도를 측정합니다. 점수가 낮을수록 좋습니다. 속도 지수 점수는 시각적 진행 속도를 기반으로 계산되지만 계산된 값일 뿐입니다. 또한 뷰포트 크기에 민감하므로 대상 고객과 일치하는 테스트 구성 범위를 정의해야 합니다. LCP가 더 관련성 있는 메트릭이 되면서 중요성이 줄어들고 있다는 점에 유의하십시오( Boris, Artem에게 감사드립니다! ).
   • CPU 소요 시간
     페인팅, 렌더링, 스크립팅 및 로드 작업에서 메인 스레드가 차단 되는 빈도 와 기간 을 보여주는 메트릭입니다. 높은 CPU 시간은 버벅 거림 경험의 분명한 지표입니다. 즉, 사용자가 작업과 응답 사이에 눈에 띄는 지연을 경험할 때입니다. WebPageTest를 사용하면 "Chrome" 탭에서 "개발 도구 타임라인 캡처"를 선택하여 WebPageTest를 사용하는 모든 장치에서 실행되는 기본 스레드의 분석을 노출할 수 있습니다.
   • 구성 요소 수준 CPU 비용
     CPU 소요 시간 과 마찬가지로 Stoyan Stefanov가 제안한 이 지표 는 JavaScript가 CPU에 미치는 영향을 조사합니다. 아이디어는 개별적으로 전체 경험에 미치는 영향을 이해하기 위해 구성 요소당 CPU 명령 수를 사용하는 것입니다. Puppeteer 및 Chrome을 사용하여 구현할 수 있습니다.
   • 좌절 지수
     위에 나온 많은 메트릭이 특정 이벤트가 발생하는 시기를 설명하지만 Tim Vereecke의 FrustrationIndex는 메트릭을 개별적으로 보는 대신 메트릭 사이의 간격 을 봅니다. 제목이 표시됨, 첫 번째 콘텐츠가 표시됨, 시각적으로 준비됨 및 페이지가 준비된 모양과 같이 최종 사용자가 인식하는 주요 이정표를 보고 페이지를 로드하는 동안 좌절감을 나타내는 수준을 나타내는 점수를 계산합니다. 격차가 클수록 사용자가 불만을 가질 가능성이 커집니다. 사용자 경험을 위한 잠재적으로 좋은 KPI입니다. Tim은 FrustrationIndex와 작동 방식에 대한 자세한 게시물을 게시했습니다.
   • 광고 가중치 영향
     사이트가 광고에 의해 생성된 수익에 의존하는 경우 광고 관련 코드의 가중치를 추적하는 것이 유용합니다. Paddy Ganti의 스크립트는 두 개의 URL(하나는 일반, 다른 하나는 광고 차단)을 구성하고 WebPageTest를 통해 비디오 비교 생성을 요청하고 델타를 보고합니다.
   • 편차 측정항목
     Wikipedia 엔지니어가 언급한 바와 같이 결과에 얼마나 많은 편차 가 존재하는지에 대한 데이터는 도구가 얼마나 신뢰할 수 있는지, 편차 및 이상값에 얼마나 주의를 기울여야 하는지 알려줄 수 있습니다. 큰 편차는 설정에 필요한 조정의 지표입니다. 또한 특정 페이지를 안정적으로 측정하기가 더 어려운지(예: 상당한 변동을 일으키는 타사 스크립트로 인해)를 이해하는 데 도움이 됩니다. 새 브라우저 버전이 출시될 때 성능의 충돌을 이해하기 위해 브라우저 버전을 추적하는 것도 좋은 생각일 수 있습니다.
   • 맞춤 측정항목
     사용자 지정 메트릭은 비즈니스 요구 사항과 고객 경험에 따라 정의됩니다. 중요한 픽셀, 중요한 스크립트, 필요한 CSS 및 관련 자산을 식별하고 사용자에게 얼마나 빨리 전달되는지 측정해야 합니다. 이를 위해 Hero Rendering Times를 모니터링하거나 Performance API를 사용하여 비즈니스에 중요한 이벤트의 특정 타임스탬프를 표시할 수 있습니다. 또한 테스트가 끝날 때 임의의 JavaScript를 실행하여 WebPagetest로 사용자 정의 메트릭을 수집할 수 있습니다.

   첫 번째 의미 있는 페인트 (FMP) 는 위의 개요에 나타나지 않습니다. 서버 가 데이터를 얼마나 빨리 출력하는지에 대한 통찰력을 제공하는 데 사용되었습니다. 긴 FMP는 일반적으로 메인 스레드를 차단하는 JavaScript를 나타내지만 백엔드/서버 문제와도 관련될 수 있습니다. 그러나 이 측정항목은 케이스의 약 20%에서 정확하지 않은 것으로 나타나 최근에 더 이상 사용되지 않습니다. 보다 안정적이고 추론하기 쉬운 LCP로 효과적으로 대체되었습니다. Lighthouse에서는 더 이상 지원되지 않습니다. 안전한 페이지에 있는지 확인하기 위해 최신 사용자 중심 성능 메트릭 및 권장 사항을 다시 확인하십시오( 감사합니다, Patrick Meenan ).

   

   Steve Souders는 이러한 많은 지표에 대해 자세히 설명합니다. Time-To-Interactive는 소위 랩 환경 에서 자동화된 감사를 실행하여 측정되지만 First Input Delay는 실제 사용자 경험을 나타내며 실제 사용자는 눈에 띄게 지연됩니다. 일반적으로 항상 두 가지를 모두 측정하고 추적하는 것이 좋습니다.

   애플리케이션의 컨텍스트에 따라 선호하는 메트릭이 다를 수 있습니다. 예를 들어 Netflix TV UI의 경우 키 입력 응답성, 메모리 사용량 및 TTI가 더 중요하고 Wikipedia의 경우 처음/마지막 시각적 변경 및 CPU 소요 시간 메트릭이 더 중요합니다.

   참고 : FID와 TTI는 모두 스크롤 동작을 고려하지 않습니다. 스크롤링은 오프 메인 스레드이기 때문에 독립적으로 발생할 수 있으므로 많은 콘텐츠 소비 사이트에서 이러한 메트릭은 훨씬 덜 중요할 수 있습니다( 감사합니다, Patrick! ).

1. 핵심 Web Vitals를 측정하고 최적화합니다 .
   오랫동안 성능 메트릭은 서버가 응답하는 속도와 브라우저가 로드되는 속도에 대한 엔지니어링 관점에 초점을 맞춘 상당히 기술적인 것이었습니다. 메트릭은 서버 타이밍보다 실제 사용자 경험을 캡처하는 방법을 찾으려고 시도하면서 수년에 걸쳐 변경되었습니다. 2020년 5월, Google은 각각 사용자 경험의 고유한 측면을 나타내는 새로운 사용자 중심 성능 측정항목인 핵심 성능 지표를 발표했습니다.

   각각에 대해 Google은 허용 가능한 속도 목표 범위를 권장합니다. 이 평가를 통과하려면 전체 페이지 조회수의 75% 이상이 좋음 범위 를 초과해야 합니다. 이러한 측정항목은 빠르게 주목을 받았으며 2021년 5월에 핵심 성능 평가가 Google 검색의 순위 신호가 되면서( 페이지 경험 순위 알고리즘 업데이트 ) 많은 회사에서 성과 점수에 관심을 돌렸습니다.

   이러한 지표를 염두에 두고 경험을 최적화하기 위한 유용한 기술 및 도구 와 함께 각각의 핵심 핵심 성능을 하나씩 분석해 보겠습니다. (이 기사의 일반적인 조언을 따르면 더 나은 Core Web Vitals 점수를 얻을 수 있습니다.)

   • 가장 큰 내용이 포함된 페인트 ( LCP ) < 2.5초
     페이지 로드 를 측정하고 뷰포트 내에서 볼 수 있는 가장 큰 이미지 또는 텍스트 블록 의 렌더링 시간을 보고합니다. 따라서 LCP는 중요한 정보의 렌더링을 지연시키는 모든 것의 영향을 받습니다. 느린 서버 응답 시간, CSS 차단, 인플라이트 JavaScript(자사 또는 타사), 웹 글꼴 로드, 값비싼 렌더링 또는 페인팅 작업, 게으름 -로드된 이미지, 스켈레톤 화면 또는 클라이언트 측 렌더링.
     
     좋은 경험을 위해 LCP는 페이지가 처음 로드되기 시작한 후 2.5초 이내에 발생해야 합니다. 즉, 페이지의 첫 번째 보이는 부분을 가능한 한 빨리 렌더링해야 합니다. 이를 위해서는 각 템플릿에 대해 맞춤형 중요 CSS가 필요하고 <head> 주문을 조정하고 중요한 자산을 미리 가져옵니다(나중에 다룰 것입니다).

     낮은 LCP 점수의 주요 원인은 일반적으로 이미지입니다. 잘 최적화된 서버에서 호스팅되는 Fast 3G에서 2.5초 미만으로 LCP를 제공하려면 클라이언트 측 렌더링이 없고 전용 이미지 CDN에서 가져온 이미지가 모두 정적이며 이론상 최대 이미지 크기는 약 144KB에 불과합니다 . 이것이 반응형 이미지가 중요한 이유이며 중요한 이미지를 조기에 미리 로드하는 것( preload 포함)입니다.

     빠른 팁 : 페이지에서 LCP로 간주되는 항목을 찾으려면 DevTools에서 성능 패널의 "타이밍" 아래에 있는 LCP 배지 위로 마우스를 가져갈 수 있습니다( 감사합니다, Tim Kadlec !).

   • 첫 번째 입력 지연 ( FID ) < 100ms.
     UI의 응답 성을 측정합니다. 즉, 탭이나 클릭과 같은 개별 사용자 입력 이벤트에 반응할 수 있기 전에 브라우저가 다른 작업으로 얼마나 시간 을 많이 썼는지 측정합니다. 특히 페이지 로드 중에 메인 스레드가 사용 중이어서 발생하는 지연을 캡처하도록 설계되었습니다.
     
     목표는 모든 상호 작용에 대해 50–100ms 이내로 유지하는 것입니다. 거기에 도달하려면 긴 작업을 식별하고(>50ms 동안 기본 스레드 차단) 이를 분할하고 번들을 여러 청크로 코드 분할하고 JavaScript 실행 시간을 줄이고 데이터 가져오기를 최적화하고 타사의 스크립트 실행을 연기해야 ​​합니다. , JavaScript를 웹 작업자와 함께 백그라운드 스레드로 이동하고 점진적 수화를 사용하여 SPA에서 재수화 비용을 줄입니다.

     빠른 팁 : 일반적으로 더 나은 FID 점수를 얻기 위한 신뢰할 수 있는 전략은 더 큰 번들을 더 작은 번들로 나누고 사용자가 필요할 때 필요로 하는 것을 제공 하여 기본 스레드에서 작업을 최소화하여 사용자 상호 작용이 지연되지 않도록 하는 것입니다. . 이에 대해서는 아래에서 자세히 다루겠습니다.

   • 누적 레이아웃 이동 ( CLS ) < 0.1.
     부드럽고 자연스러운 상호 작용을 보장하기 위해 UI의 시각적 안정성 을 측정합니다. 즉, 페이지 수명 동안 발생하는 모든 예상치 못한 레이아웃 이동에 대한 모든 개별 레이아웃 이동 점수의 합계입니다. 개별 레이아웃 이동은 이미 표시되었던 요소가 페이지에서 위치를 변경할 때마다 발생합니다. 콘텐츠의 크기와 이동 거리에 따라 점수가 매겨집니다.
     
     따라서 시프트가 나타날 때마다 - 예를 들어 대체 글꼴과 웹 글꼴이 서로 다른 글꼴 메트릭을 사용하거나 광고, 포함 또는 iframe이 늦게 제공되거나 이미지/비디오 크기가 예약되지 않거나 늦은 CSS가 강제로 다시 칠하거나 변경 사항이 주입되는 경우 늦은 JavaScript — CLS 점수에 영향을 미칩니다. 좋은 경험을 위한 권장 값은 CLS < 0.1입니다.

   Core Web Vitals는 예측 가능한 연간 주기로 시간이 지남에 따라 진화해야 합니다. 첫 해 업데이트의 경우 First Contentful Paint가 Core Web Vitals로 승격되어 FID 임계값이 감소하고 단일 페이지 애플리케이션에 대한 지원이 향상될 것으로 예상할 수 있습니다. 보안, 개인 정보 보호 및 접근성(!) 고려 사항과 함께 더 많은 가중치를 얻은 로드 후 사용자 입력에 대한 응답을 볼 수도 있습니다.

   Core Web Vitals와 관련하여 살펴볼 가치가 있는 유용한 리소스와 기사가 많이 있습니다.

   • Web Vitals 리더보드를 사용하면 모바일, 태블릿, 데스크톱, 3G 및 4G에서 경쟁자들과 점수를 비교할 수 있습니다.
   • Core SERP Vitals, Google 검색 결과에 CrUX의 핵심 Web Vitals를 표시하는 Chrome 확장 프로그램입니다.
   • 간단한 GIF로 CLS를 시각화하는 레이아웃 시프트 GIF 생성기(명령줄에서도 사용 가능).
   • web-vitals 라이브러리는 Core Web Vitals를 수집하여 Google Analytics, Google 태그 관리자 또는 기타 분석 엔드포인트로 보낼 수 있습니다.
   • Patrick Meenan이 WebPageTest가 핵심 Web Vital에 대한 데이터를 노출하는 방법을 탐구하는 WebPageTest로 Web Vital을 분석합니다.
   • Addy Osmani와 함께하는 50분짜리 비디오인 Optimizing with Core Web Vitals에서는 전자 상거래 사례 연구에서 Core Web Vitals를 개선하는 방법을 강조합니다.
   • 실제의 누적 레이아웃 이동 및 실제 세계의 누적 레이아웃 이동은 CLS에 대한 거의 모든 것을 다루고 이탈률, 세션 시간 또는 Rage Clicks와 같은 주요 메트릭과 상관 관계가 있는 Nic Jansma의 포괄적인 기사입니다.
   • JavaScript에서 요청/호출될 때 속성 또는 메서드에 대한 개요와 함께 강제 리플로우는 브라우저가 스타일과 레이아웃을 동기적으로 계산하도록 트리거합니다.
   • CSS 트리거는 레이아웃, 페인트 및 합성을 트리거하는 CSS 속성을 보여줍니다.
   • 레이아웃 불안정성 수정은 WebPageTest를 사용하여 레이아웃 불안정성 문제를 식별하고 수정하는 방법입니다.
   • CLS에 대한 Boris Schapira의 또 다른 매우 상세한 가이드인 Cumulative Layout Shift, The Layout Instability Metric, 계산 방법, 측정 방법 및 최적화 방법.
   • 핵심 성능 향상 방법, 각 메트릭(FCP, TTI, TBT와 같은 다른 웹 바이탈 포함), 발생 시기 및 측정 방법에 대한 Simon Hearne의 자세한 가이드입니다.

   그렇다면 Core Web Vitals는 따라야 할 궁극적인 지표 입니까? 좀 빠지는. Cloudflare, Treo, SpeedCurve, Calibre, WebPageTest(이미 영사 슬라이드 보기에서), Newrelic, Shopify, Next.js, 모든 Google 도구(PageSpeed ​​Insights, Lighthouse + CI, Search 포함)를 포함한 대부분의 RUM 솔루션 및 플랫폼에 이미 노출되어 있습니다. 콘솔 등) 및 기타 여러 가지가 있습니다.

   그러나 Katie Sylor-Miller가 설명하는 것처럼 Core Web Vitals의 주요 문제 중 일부는 브라우저 간 지원이 부족하고 사용자 경험의 전체 수명 주기를 실제로 측정하지 않으며 FID 및 비즈니스 성과가 있는 CLS.

   Core Web Vital이 발전할 것으로 예상해야 하므로 성능 측면에서 현재 위치를 더 잘 이해하기 위해 Web Vital을 사용자 정의 측정 지표와 항상 결합 하는 것이 합리적으로 보입니다.

2. 청중을 대표하는 장치에서 데이터를 수집하십시오.
   정확한 데이터를 수집하려면 테스트할 장치를 철저히 선택해야 합니다. 대부분의 회사에서 이는 분석을 조사하고 가장 일반적인 장치 유형을 기반으로 사용자 프로필을 생성하는 것을 의미합니다. 그러나 종종 분석만으로는 완전한 그림을 제공하지 못합니다. 타겟 고객의 상당 부분은 경험이 너무 느리고 해당 기기가 분석에서 가장 인기 있는 기기로 표시되지 않을 가능성이 있다는 이유로 사이트를 포기하고 다시 돌아오지 않을 수 있습니다. 따라서 대상 그룹의 공통 장치에 대한 연구를 추가로 수행하는 것이 좋습니다.

   IDC에 따르면 2020년 전 세계적으로 출하되는 모든 휴대전화의 84.8%가 Android 기기입니다. 평균 소비자는 2년마다 휴대폰을 업그레이드하며 미국 휴대폰 교체 주기는 33개월입니다. 전 세계적으로 가장 많이 팔리는 휴대폰의 평균 가격은 200달러 미만입니다.

   그렇다면 대표적인 기기는 최소 24개월 된 Android 기기로 가격은 200달러 이하이며 느린 3G, 400ms RTT 및 400kbps 전송에서 실행되지만 조금 더 비관적입니다. 물론 이것은 회사에 따라 매우 다를 수 있지만 대부분의 고객과 거의 비슷합니다. 실제로 대상 시장에 대한 현재 Amazon 베스트 셀러를 살펴보는 것이 좋습니다. ( 조언을 해주신 Tim Kadlec, Henri Helvetica 및 Alex Russell에게 감사드립니다! ).

   

   그러면 어떤 테스트 장치를 선택해야 할까요? 위에 요약된 프로필과 잘 맞는 것들. 약간 오래된 Moto G4/G5 Plus, 중급 Samsung 장치(Galaxy A50, S8), Nexus 5X, Xiaomi Mi A3 또는 Xiaomi Redmi Note와 같은 중급 장치를 선택하는 것이 좋습니다. 7 및 Alcatel 1X 또는 Cubot X19와 같은 느린 장치(아마도 개방형 장치 연구실에서). 더 느린 열 조절 장치에서 테스트하려면 약 100달러에 달하는 Nexus 4를 구입할 수도 있습니다.

   또한 각 기기에 사용되는 칩셋을 확인하고 하나의 칩셋을 과대 대표하지 마십시오 . 몇 세대의 Snapdragon과 Apple은 물론 저가형 Rockchip, Mediatek으로 충분할 것입니다 (고마워 Patrick!) .

   장치가 없는 경우 조절된 CPU(5배 속도 저하)로 조절된 3G 네트워크 (예: 300ms RTT, 1.6Mbps 감소, 0.8Mbps 증가)에서 테스트하여 데스크톱에서 모바일 경험을 에뮬레이트합니다. 결국 일반 3G, 느린 4G(예: 170ms RTT, 9Mbps 다운, 9Mbps 업) 및 Wi-Fi로 전환합니다. 성능에 미치는 영향을 보다 명확하게 하기 위해 화요일에 2G를 도입하거나 사무실에 스로틀링된 3G/4G 네트워크를 설정하여 더 빠른 테스트를 수행할 수도 있습니다.

   모바일 장치에서는 데스크톱 컴퓨터에 비해 4~5배 느려질 것으로 예상해야 합니다. 모바일 장치는 GPU, CPU, 메모리 및 배터리 특성이 다릅니다. 그렇기 때문에 평균적인 장치에 대한 좋은 프로필을 갖고 항상 그러한 장치에서 테스트하는 것이 중요합니다.



운 좋게도 데이터 수집을 자동화하고 이러한 지표에 따라 시간 경과에 따른 웹사이트 성능을 측정하는 데 도움이 되는 많은 훌륭한 옵션이 있습니다. 좋은 성능 그림은 성능 메트릭, 실험실 데이터 및 필드 데이터 세트를 포함한다는 점을 명심하십시오.

• 합성 테스트 도구 는 사전 정의된 장치 및 네트워크 설정(예: Lighthouse , Calibre , WebPageTest )을 사용하여 재현 가능한 환경에서 실험실 데이터 를 수집하고
• RUM ( 실제 사용자 모니터링 ) 도구는 사용자 상호 작용을 지속적으로 평가하고 현장 데이터 를 수집합니다(예: SpeedCurve , New Relic — 도구도 종합 테스트 제공).

전자는 제품 작업 중에 성능 문제를 식별, 격리 및 수정하는 데 도움이 되므로 개발 중에 특히 유용합니다. 후자는 사용자가 실제로 사이트에 액세스할 때 실시간으로 발생하는 성능 병목 현상을 이해하는 데 도움이 되므로 장기 유지 관리 에 유용합니다.

탐색 타이밍, 리소스 타이밍, 페인트 타이밍, 긴 작업 등과 같은 기본 제공 RUM API를 활용하여 합성 테스트 도구와 RUM이 함께 응용 프로그램의 성능에 대한 완전한 그림을 제공합니다. 성능 모니터링을 위한 훌륭한 옵션인 Calibre, Treo, SpeedCurve, mPulse 및 Boomerang, Sitespeed.io를 사용할 수 있습니다. 또한 Server Timing 헤더를 사용하면 백엔드 및 프론트엔드 성능을 모두 한 곳에서 모니터링할 수도 있습니다.

참고 : 예를 들어 DevTools는 구현 방식으로 인해 HTTP/2 푸시와 상호 작용하는 데 문제가 있으므로 브라우저 외부의 네트워크 수준 조절기를 선택하는 것이 항상 더 안전한 방법입니다( Yoav, Patrick 감사 합니다!). Mac OS의 경우 Network Link Conditioner, Windows Windows Traffic Shaper, Linux netem 및 FreeBSD dummynet에 사용할 수 있습니다.

Lighthouse에서 테스트할 가능성이 높으므로 다음을 수행할 수 있습니다.

• Lighthouse CI를 사용하여 시간 경과에 따른 Lighthouse 점수 추적(매우 인상적임)
• GitHub Actions에서 Lighthouse를 실행하여 모든 PR과 함께 Lighthouse 보고서를 가져옵니다.
• 사이트의 모든 페이지에서 Lighthouse 성능 감사를 실행하고(Lightouse Parade를 통해) 출력을 CSV로 저장합니다.
• 더 자세히 알아보려면 Lighthouse Scores Calculator 및 Lighthouse 메트릭 가중치를 사용하십시오.
• Lighthouse는 Firefox에서도 사용할 수 있지만 내부적으로 PageSpeed ​​Insights API를 사용하고 헤드리스 Chrome 79 User-Agent를 기반으로 보고서를 생성합니다.

1. 테스트를 위해 "깨끗한" 및 "고객" 프로필을 설정합니다.
   수동 모니터링 도구에서 테스트를 실행하는 동안 바이러스 백신 및 백그라운드 CPU 작업을 끄고 백그라운드 대역폭 전송을 제거하고 왜곡된 결과를 피하기 위해 브라우저 확장 없이 깨끗한 사용자 프로필로 테스트하는 것이 일반적인 전략입니다(Firefox 및 Chrome에서).

   

   그러나 고객이 자주 사용하는 브라우저 확장 을 연구하고 전용 "고객" 프로필 로도 테스트하는 것도 좋은 생각입니다. 실제로 일부 확장 프로그램은 애플리케이션의 성능에 중대한 영향을 미칠 수 있으며(2020 Chrome 확장 프로그램 성능 보고서) 사용자가 많이 사용하는 경우 이를 미리 고려하는 것이 좋습니다. 따라서 "깨끗한" 프로필 결과만으로는 지나치게 낙관적이며 실제 시나리오에서 무너질 수 있습니다.

2. 동료들과 성과 목표를 공유하십시오.
   성과 목표가 팀의 모든 구성원에게 친숙한지 확인하여 선에서 오해를 피하십시오. 디자인, 마케팅 또는 그 사이의 모든 결정은 성능에 영향 을 미치며 전체 팀에 책임과 소유권을 분산하면 나중에 성능 중심 의사 결정이 간소화됩니다. 성능 예산 및 초기에 정의된 우선 순위에 따라 설계 결정을 매핑합니다.

목차

1. 준비하기: 계획 및 측정항목
2. 현실적인 목표 설정
3. 환경 정의
4. 자산 최적화
5. 빌드 최적화
6. 배달 최적화
7. 네트워킹, HTTP/2, HTTP/3
8. 테스트 및 모니터링
9. 빠른 승리
10. 한 페이지에 모든 것
11. 체크리스트 다운로드(PDF, Apple Pages, MS Word)
12. 다음 가이드를 놓치지 않으려면 이메일 뉴스레터를 구독하세요.