웹 성능 지표와 예산

2023.03.29.

웹 성능 최적화 기법(루비페이퍼 사) 도서에 대한 핵심 내용과 지식을 정리한 포스트입니다. 포스트에 올라오는 내용은 도서의 일부이기 때문에 더 자세한 내용이 궁금하신 분들은 출처에서 도서를 구매해 읽어보시는 것을 추천드립니다.

1.4 웹 성능을 만드는 지표

프론트엔드와 백엔드

프론트엔드(Front-end) : 실제 웹 사이트에 접속해 요청 콘텐츠를 전달 받아 시각화하는 사용자 환경
백엔드(Back-end) : 콘텐츠 생성과 제공하는 공급자 환경
스티브 사우더스(Steve Souders)는 자신의 저서인 ⟪웹 사이트 최적화 기법(High Prefromance WebSites)⟫(ITC, 2008)에서 14가지 웹 성능 최적화 기법을 정의했으며 대부분 항목이 웹 성능을 최적화 하는데 여전히 중요함

최적화	내용
백엔드	1. Expires 헤더를 추가한다. 2. gzip으로 압축한다. 3. 페이지 재전송(redirection)을 피한다. 4. ETag를 설정한다. 5. 캐시를 지원하는 AJAX를 만든다.
프론트엔드	1. HTTP 요청을 줄인다. 2. 스타일 시트는 상단에 넣는다. 3. 스크립트는 하단에 넣는다. 4. CSS 표현식은 피한다. 5. 자바스크립트와 CSS는 외부 파일에 넣는다. 6. 자바스크립트는 작게 한다. 7. 중복 스크립트는 제거한다.
네트워크	1. 콘텐츠 전송 네트워크(CDN)을 사용한다. 2. DNS 조회를 줄인다.

1.4.1 사용자 환경 - 프론트엔드

프론트엔드는 사용자가 브라우저를 사용하여 보는 화면 자체를 의미한다.
- 웹 페이지 내용을 구현하는 언어로 HTML을 사용하며, 자바스크립트가 웹 페이지 로직을 담당하고 CSS로 UI를 구성한다.
- DB에서 조회한 값들, 이미지, 동영상 들도 프론트엔드 요소
프론트엔드는 감각적인 디자인으로 더 많은 사용자들이 웹 사이트로 유입될 수 있도록 끌어들이는 역할과 콘텐츠를 보기 편하게 전달하는 역할을 하며, 사이트의 얼굴에 해당하므로 빠르고 보기 쉽게 콘텐츠를 전달하는 것이 가장 큰 목적이다.

1.4.2 공급자 환경 - 백엔드

백엔드는 사용자에게 보이는 프론트엔드 콘텐츠를 실제 생산하고 저장하여 네트워크를 통해 전달한다.
대부분 백엔드 요소는 웹 서버 쪽에 구성되어 있어, 백엔드를 서버 사이드(server side), 프론트엔드를 클라이언트 사이드(client side)라 한다.
백엔드 내부에는 웹 서버가 수많은 클라이언트와 물리적 통신을 할 수 있도록 Java, JSP, ASP, PHP 등의 프로그래밍 언어로 개발된 서비스가 존재함
Database역시 백엔드의 요소이며 데이터 조회가 느려지면 그만큼 프론트엔드에서 브라우저 화면에 렌더링하는 시간에 영향을 줌
- 라우터(router), 네트워크 스위치(network switch) 역시 백엔드 요소
웹 성능 최적화를 위해선 프론트엔드 뿐만 아니라 백엔드 최적화도 점검해야 하며 대표적인 방법으로 데이터베이스 정규화(normalization)나 오래된 데이터 백업 후 삭제, 빠른 저장 장치 사용 등 방법이 있다.

1.4.3 전달 환경 - 네트워크

네트워크는 장소와 시간에 따라 속도가 변하기 때문에 성능 측정이 어렵다.
네트워크 성능을 제약하는 두 가지 요소는 대역폭(bandwidth)과 지연 시간(latency)이다.
- 대역폭(bandwidth) : 일정 시간에 처리할 수 있는 트래픽 양을 의미하며, 사용자 증가로 인해 전달 속도를 느리게 만들 수 있다.
- 지연 시간(latency) : 기술적 이유로 사용자에게 콘텐츠를 전달하지 못하고 지연되는 시간을 의미한다.
네트워크는 각 국가의 인터넷 서비스 사업자(Internet Service Provider, ISP)가 제공하는 서비스를 사용하고 있으며, ISP 품질에 따라 대역폭과 지연 시간도 달라질 수 있다.

1.5 웹 성능과 프론트엔드

프론트엔드는 데이터를 표현하는 역할뿐만 아니라 사용자가 입력한 다양한 형태의 데이터를 백엔드에 전달하는 역할도 한다.
대다수 웹 사이트의 웹 성능 측정 시, 프론트엔드에서 가장 많은 시간을 소요한다. (약 8~90%)
- 그 이유는 웹 서버가 아닌 사용자(브라우저) 관점에서 원하는 콘텐츠를 전달받았는지가 웹 성능의 기준이기 때문이다.

1.5.1 브라우저 렌더링

브라우저 렌더링 시 성능 지표를 PageSpeed로 조회해보면 단계별 성능 지표에 대한 정보가 나타난다.
- FCP(First Contentful Paint) : 첫 번째 텍스트 또는 이미지가 표시되는 데 걸린시간
- SI(Speed Index) : 페이지 콘텐츠가 얼마나 빨리 표시되는지에 대한 정보
- LCP(Largest Contentful Paint) : 가장 큰 텍스트 또는 이미지가 표시된 시간
- TTI(Time to Interactive) : 사용자와 페이지가 상호 작용할 수 있게 된 시간
- TBT(Total Blocking Time) : FCP와 TTI 사이 모든 시간의 합 (50ms 초과시 밀리초 단위 표시)
- CLS(Cumulative Layout Shift) : 표시 영역 안에 보이는 요소들이 얼마나 이동하는지에 대한 정보
각 단계별 소요 시간이 줄었는지 확인함으로서 성능 개선이 이뤄졌는지 알 수 있다.

1.6 웹 성능 예산

웹 성능이 비즈니스 성패를 좌우하는 경우가 많기 때문에, 웹 성능 목표를 명확한 지표로 만들고 관리하는 것이 중요하다.
- 가장 많이 사용되는 방법으로 **웹 성능 예산(web performance budget)**이 있다.
웹 성능 예산이란, 웹 성능에 영향을 미치는 다양한 요소를 제어하는 한곗값을 의미한다.
- ex) 모든 웹 페이지의 각 페이지 내 포함된 자바스크립트 크기는 1MB를 넘지 않아야 한다.
성능 예산은 크게 세 가지 분류로 나눌 수 있다.
- 정량 기반 지표
- 시간 기반 지표
- 규칙 기반 지표

1.6.1 정량 기반 지표(quantity based metrics)

이미지, 스크립트, 폰트 등 웹 페이지 제작에 필요한 요소들에 대한 한곗값을 말한다.
웹 페이지를 설계할 때 고려하는 대표적인 정량 기반 지표는 다음과 같다.
- 이미지 파일의 최대 크기
- 최대 웹 폰트 파일 개수
- 자바스크립트 파일 크기 합
- 타사 스크립트 개수 합
정량 기반 지표가 개선 됐다고 해서 단순히 웹 성능이 좋아질거란 보장은 없으며, 참고하되 실제 웹 성능 측정값에 대한 성능 예산이 필요하다.

1.6.2 시간 기반 지표(time based metrics)

milestone timing이라고도 부르며, 정량 기반 지표 단점을 보완하는 성능 예산이다.
DOMContentLoaded, Load 같이 브라우저에서 실제로 발생하는 다양한 웹 성능 이벤트 값을 측정하여 사용자가 느끼는 웹 성능에 대한 목표치를 설정하는 방식이다.
- FCP(First Contentful Paint) : 텍스트 또는 이미지와 같이 DOM의 첫 번째 비트를 표시하는 시점
- TTI(Time to Interactive) : 페이지가 사용자 입력에 안정적으로 응답하는 데 걸리는 시간

1.6.3 규칙 기반 지표

웹 성능 측정 도구들은 자체적인 웹 성능 지표를 측정하여 각 사이트의 성능 점수를 매기는 알고리즘을 갖고 있다. 이를 통해 어느 측정 지표의 점수가 낮아 개선 포인트로 삼아야 하는지 결정할 수 있다.
대표적인 규칙 기반 지표(rule based metrics)는 다음과 같다.
- WebPageTest의 성능 점수
- 구글 Lighthouse의 성능 점수

1.6.4 성능 예산 활용

가장 쉬운 접근 방법 중 하나는 아주 직관적으로 단순하게 성능 예산 목표치를 설정하고 웹 사이트 설계와 개발을 시작하는 것이다.
웹 페이지는 업데이트가 잦기 때문에 콘텐츠의 변화로 인해 웹 성능 요소가 변경될 수 있다.
- 메인 이미지 변경되거나 글꼴을 추가하거나 소셜 미디어 스크립트를 추가하는 등 행위는 성능 예산을 벗어나는 작업 등이 필요할 수 있다.
- 최근에는 형상 관리 및 새로운 버전을 빌드한 후 배포 이전에 최종 성능 예산을 측정하고 관리하는 방법도 사용한다.
  - 대표 예 : 구글 Lighthouse의 측정값을 빌드의 CI(Continuous Intergration) 단계의 테스트 케이스로 사용