성능은 사용자 환경에서 중요한 부분이며 비즈니스 측정항목에 영향을 미칩니다. 훌륭한 개발자라면 성능 기준에 맞는 사이트를 만들 거라고 생각하고 싶을 것입니다. 하지만 사실 좋은 성능은 부작용이 거의 없습니다. 목표를 달성하기 위해서는 목표를 명확하게 정의해야 합니다. 실적 예산을 설정하여 여정을 시작하세요.
정의
실적 예산은 사이트 실적에 영향을 미치는 측정항목에 적용되는 한도입니다. 페이지의 총 크기, 모바일 네트워크에서 로드하는 데 걸리는 시간 또는 전송된 HTTP 요청의 수 등이 될 수 있습니다. 예산을 정의하면 웹 성능에 대한 논의를 시작하는 데 도움이 됩니다. 디자인, 기술, 기능 추가와 관련된 결정을 내릴 때 참고할 수 있는 참고 자료 역할을 합니다.
예산이 있으면 디자이너는 고해상도 이미지의 효과와 선택한 웹 글꼴의 수를 생각할 수 있습니다. 또한 개발자가 문제에 대한 여러 접근 방식을 비교하고 크기와 파싱 비용을 기준으로 프레임워크와 라이브러리를 평가할 수 있도록 도와줍니다.
측정항목 선택
수량 기반 측정항목 ⚖️
이러한 측정항목은 과도한 이미지와 스크립트를 포함할 경우의 영향을 강조하므로 개발 초기 단계에서 유용합니다. 또한 디자이너 및 개발자와 쉽게 소통할 수 있습니다.
이미 페이지 용량 및 HTTP 요청 수와 같은 성능 예산에 포함할 수 있는 몇 가지 사항을 언급했지만 이를 다음과 같이 더 세분화된 한도로 분할할 수 있습니다.
- 최대 이미지 크기
- 최대 웹 글꼴 수
- 프레임워크를 포함한 스크립트의 최대 크기
- 총 외부 리소스(예: 서드 파티 스크립트) 수
그러나 이 수치는 사용자 경험에 대해 잘 알 수 없습니다. 요청 수 또는 가중치가 동일한 두 페이지는 리소스가 요청되는 순서에 따라 다르게 렌더링될 수 있습니다. 페이지 중 하나의 히어로 이미지나 스타일시트와 같은 중요한 리소스가 프로세스에서 늦게 로드되면 사용자는 유용한 정보를 보게 될 때까지 더 오래 기다리게 되고 페이지가 느린 것으로 인지하게 됩니다. 다른 페이지에서 가장 중요한 부분이 빠르게 로드된다면 페이지의 나머지 부분이 로드되지 않더라도 눈치채지 못할 수 있습니다.
따라서 다른 유형의 측정항목을 추적하는 것이 중요합니다.
목표 달성 시기 ↩️
마일스톤 시간은 DOMContentLoaded 또는 load 이벤트와 같은 페이지 로드 중에 발생하는 이벤트를 표시합니다. 가장 유용한 타이밍은 페이지 로드 경험에 대한 정보를 알려주는 사용자 중심 성능 측정항목입니다. 이러한 측정항목은 브라우저 API를 통해 Lighthouse 보고서의 일부로 제공됩니다.
콘텐츠가 포함된 첫 페인트 (FCP)는 브라우저가 텍스트 또는 이미지와 같은 DOM의 첫 번째 콘텐츠를 표시하는 시점을 측정합니다.
상호작용 시간 (TTI)은 페이지가 완전히 상호작용하고 사용자 입력에 안정적으로 응답하는 데 걸리는 시간을 측정합니다. 이는 페이지에서 링크 클릭, 버튼 클릭, 입력 또는 양식 요소 사용과 같은 사용자 상호작용이 예상되는지 추적하는 매우 중요한 측정항목입니다.
규칙 기반 측정항목 💯
Lighthouse 및 WebPageTest는 가이드라인으로 사용할 수 있는 일반 권장사항 규칙을 기반으로 성능 점수를 계산합니다. Lighthouse는 간단한 최적화를 위한 힌트도 제공합니다.
수량 기반 실적 측정항목과 사용자 중심 실적 측정항목을 조합하여 추적하면 최상의 결과를 얻을 수 있습니다. 프로젝트 초기 단계에서는 애셋 크기에 집중하고 가능한 한 빨리 FCP 및 TTI 추적을 시작하세요.
기준 설정
사이트에 어떤 것이 가장 효과적인지 알 수 있는 유일한 방법은 직접 사용해 본 후 알아낸 결과를 테스트하는 것입니다. 경쟁 결과를 분석하여 현재 점수를 확인하세요. 🕵️
그렇게 할 시간이 없다면 다음과 같은 기본 수치를 사용하여 시작할 수 있습니다.
- 상호작용까지의 시간 5초 미만
- 주요 경로 리소스가 170KB 미만 (압축/축소됨)
이 숫자는 실제 기준 기기와 3G 네트워크 속도를 기반으로 계산됩니다. 오늘날 인터넷 트래픽의 절반 이상이 모바일 네트워크에서 발생하므로 3G 네트워크 속도를 시작점으로 사용해야 합니다.
예산의 예
사이트의 페이지마다 콘텐츠가 다양하므로 페이지 유형별로 예산을 할당해야 합니다. 예를 들면 다음과 같습니다.
- Google의 제품 페이지는 모바일에서 170KB 미만의 JavaScript를 제공해야 합니다.
- 데스크톱의 검색 페이지는 2MB 미만의 이미지를 포함해야 합니다.
- Moto G4 휴대전화의 느린 3G 환경에서 홈페이지가 5초 이내에 로드되고 상호작용해야 합니다.
- Lighthouse 성능 감사에서 블로그는 80점 이상이어야 합니다.
빌드 프로세스에 성능 예산 추가
이를 위한 도구 선택은 해당 작업에 전념할 수 있는 프로젝트 및 리소스의 규모에 따라 크게 달라집니다. 빌드 프로세스에 예산 책정을 추가하는 데 도움이 되는 몇 가지 오픈소스 도구가 있습니다.
정의된 임곗값을 초과하는 항목이 있으면 다음 중 하나를 수행할 수 있습니다.
- 기존 기능 또는 애셋 최적화하기 🛠️
- 기존 기능 또는 확장 소재 삭제하기 🗑️
- 새로운 기능 또는 저작물을 추가하지 않음 🇬⛔
실적 추적
사이트 속도가 충분히 빠르면 초기 출시 후에도 측정을 계속해야 합니다. 이러한 측정항목을 시간 경과에 따라 모니터링하고 실제 사용자로부터 데이터를 수집하면 성능 변화가 주요 비즈니스 측정항목에 어떤 영향을 미치는지 알 수 있습니다.
마무리
성능 예산의 목적은 프로젝트 전체의 실적에 초점을 맞추고 일찍 설정하면 나중에 역추적되는 것을 방지하는 데 도움이 됩니다. 이 페이지는 웹사이트에 무엇을 포함할지 결정하는 데 도움이 되는 참고 자료여야 합니다. 주요 아이디어는 목표를 설정하여 기능이나 사용자 환경을 저해하지 않으면서 성능의 균형을 더 잘 맞출 수 있도록 하는 것입니다.twitter
다음 가이드에서는 몇 가지 간단한 단계를 거쳐 첫 실적 예산을 정의하는 방법을 안내합니다.