썸네일: Unsplash의Paul Hanaoka
출처 : 웹 성능 최적화 기법
웹 성능 최적화 기법(루비페이퍼 사) 도서에 대한 핵심 내용과 지식을 정리한 포스트입니다. 포스트에 올라오는 내용은 도서의 일부이기 때문에 더 자세한 내용이 궁금하신 분들은 출처에서 도서를 구매해 읽어보시는 것을 추천드립니다.
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) 단계의 테스트 케이스로 사용