페이지 속도가 수년에 걸쳐 SEO와 UX 모두에 대한 중요한 지표가 되면서 웹 성능 예산 도 전면에 나섰습니다. 이제 웹 성능은 특정 부서나 개인의 우선순위가 아닌 모든 부서의 공유된 관점이 필요한 주제라는 것이 더욱 분명해졌습니다.

이를 예를 들어 설명하자면 마케팅 부서에서는 전환을 구현하고 리마케팅/리타겟팅 코드, 다음과 같은 도구와 함께 크리테오와 RTB 하우스, 제품 기반 리타겟팅을 사용합니다. 또한 눈길을 사로잡는 사진과 애니메이션을 기대할 수도 있습니다. 한편, 제품 부서에서는 다음과 같은 도구의 통합을 요청할 수 있습니다. Hotjar 및 선명도. 반면, 소프트웨어 부서는 프런트엔드와 백엔드 모두에서 최대한 빠른 개발을 목표로 합니다. 페이지 속도에 대한 요구와 이와 관련된 비용은 실제로 균형을 이루고 있습니다. 이러한 균형을 효과적으로 구축하기 위해 웹 성능 예산이 등장했습니다.

웹 성능 예산에는 특정 플랫폼에서 플랫폼의 목표 속도를 설정하고 이 속도를 달성하기 위해 모든 이해관계자가 준수할 수치 목표를 설정하는 것이 포함됩니다. 간단히 말해서, 빠른 비용은 웹 성능 예산입니다.

 

image-5.png
출처: https://wp-rocket.me/blog/performance-budgets/

 

모든 것은 제안으로 시작됩니다. 특정 유형의 연결에서 페이지가 얼마나 빨리 열려야 하는지 제안합니다. 예를 들어 일부 성능 예산 제안은 다음과 같습니다.

  • 홈페이지를 열 수 있나요? 빠른 2G 모바일 연결(3Mbps)에서 1.6초 미만?
  • 검색결과 페이지를 열 수 있나요? 느린 5G 연결(3Kbps)에서 780초 미만?

다음으로, 이러한 제안을 달성하기 위한 실행 계획과 하위 측정항목을 만들고 이를 여러 부분으로 나눕니다.

제안 외에도 다른 성과 예산 목표가 있을 수 있습니다. 예를 들어:

  • 이동식 등대 확대 상세 페이지 점수가 80점 이상
  • 모든 이미지의 크기 줄이기 데스크톱 사이트에서는 500KB 미만

성과 예산 지표

성과 예산의 지표를 결정하는 데에는 세 가지 관점이 있습니다.

숫자 기반 측정항목

  • 최대 글꼴 수/최대 글꼴 크기
  • 최대 이미지 수/최대 이미지 크기
  • 스크립트, 스타일, 영상 등 최대 개수 / 스크립트, 스타일, 영상 등 최대 크기
  • 최대 HTML 크기
  • 최대 HTTP 요청 수
  • 타사 스크립트의 최대 수

 

image-7.png
출처: https://web.dev/vitals/

 

시간 기반 측정항목

  • 첫 번째 콘텐츠가 포함된 페인트(FCP) 시간
  • 최대 LCP(Contentful Paint) 시간
  • 첫 번째 입력 지연(FID) 시간
  • TTI(대화 시간) 시간
  • 총 차단 시간(TBT) 시간
  • CLS(누적 레이아웃 변경) 점수
  • 속도 지수 점수

규칙 기반 측정항목

  • 등대 점수
  • GTmetrix 점수
  • 웹페이지 테스트 점수
  • 이슬로우 점수
성과예산계산기.png
출처: https://www.performancebudget.io/

웹 성능 예산을 설정할 때 일반적으로 하나만 선택하는 것보다 이러한 모든 관점을 올바른 측정 기준으로 결합하는 것이 좋습니다. 당신이 사용할 수있는 성능 예산 시뮬레이터 목표 속도에 도달하는 데 필요한 숫자를 찾으세요.

페이지 유형을 별도로 평가

성능 예산을 결정할 때 중요한 점 중 하나는 사이트의 단일 페이지를 기준으로 삼지 않는 것입니다. 일반적인 실수는 홈페이지만 테스트하여 불완전한 평가로 이어지는 것입니다.

먼저 플랫폼을 검토하고 다양한 유형의 페이지를 식별해야 합니다. 그런 다음 플랫폼의 트래픽을 분석하여 가장 많은 트래픽을 수신하는 페이지를 식별하고 우선순위를 지정합니다. 결과는 다음과 유사한 테이블이 됩니다.

  • 홈페이지
  • 정적 목록 페이지
  • 동적 목록 페이지
  • 세부정보 페이지
  • 결제 페이지
  • 검색결과 페이지
  • 캠페인 페이지
  • 블로그 페이지

당신은에 집중해야합니다 이러한 페이지 유형의 성능 예산은 별도로, 우선순위에 따라.