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