웹 성능 최적화까지 해보자-1

이 글은 웹 개발 스킬을 한 단계 높여 주는 프론트엔드 성능 최적화 가이드라는 책 기반으로 작성되었다.

 

웹 성능 최적화에 대해 배워보게 된 이유?

최근 프로젝트에서 프론트엔드 파트를 맡아 개발하다보니, 점점 기능이 많아지고, 코드를 작성할 일이 늘어나게 되었다.

그래서, 내가 작성하고 있는 코드가 올바른 방향으로 가는 코드인지, 아니면 그저 기능 구현을 위한 코드인지 궁금해지기 시작했다.

그래서, 성능 최적화에 대해서 알아보다가 이 책을 알게 되었다.

해당 책을 읽고 성능 최적화에 대해 배워서 프로젝트에도 꼭 적용해보면 좋은 경험이 될 것 같다.

 

웹 성능 최적화가 뭐야?

웹 성능을 최적화하면 서비스 사용자에게 더 나은 사용자 경험(UX)를 제공할 수 있고 이로 인해 가입률과 전환율은 높이고 이탈률은 낮춰서 더 많은 수익을 창출할 수 있다.

웹 성능을 결정하는 요소는 크게 로딩 성능과 렌더링 성능으로 나눌 수 있다.

• 로딩 성능
  • 서버에 있는 웹 페이지와 웹 페이지에 필요한 기타 리소스를 다운로드할 때의 성능
  • 다운로드해야 하는 리소스 수를 줄이거나 크기를 줄이는 것이 로딩 성능을 개선할 가장 좋은 방법
  • 코드를 분할해 다운로드하거나 리소스에 우선순위를 매겨 중요한 리소스를 먼저 다운로드하는 것도 로딩 성능 개선에 도움을 준다.
• 렌더링 성능
  • 다운로드한 리소스를 가지고 화면을 그릴 때의 성능
  • 렌더링 성능에 가장 큰 영향을 주는 게 자바스크립트 코드
  • 코드를 얼마나 효율적으로 작성했느냐에 따라 화면이 그려지는 속도와 사용자 인터랙션의 자연스러운 정도가 달라진다.

 

블로그 서비스의 웹 성능을 최적화시켜보자!

우리가 최적화시켜볼 블로그 사이트는 글 목록 페이지와 글 상세 페이지로 구분되어 있다.

 

이 장에서 학습할 최적화 기법은 다음과 같다.

• 로딩 성능 최적화
  • 이미지 사이즈 최적화
  • 코드 분할
  • 텍스트 압축
• 렌더링 성능 최적화
  • 병목 코드 최적화

 

최적화 전에 개념부터 알아보자.

 

이미지 사이즈 최적화

너무 큰 사이즈의 이미지를 사용하게 되면 네트워크 트래픽이 증가해서 서비스 로딩이 오래 걸린다.

너무 작은 사이즈의 이미지를 사용하면 이미지 화질이 저하되어 서비스 이용이 불편해진다.

따라서 적절한 이미지 사이즈를 찾아 사이트에 적용하면 성능을 높일 수 있다.

 

코드 분할

첫 페이지 진입 시 당장 사용하지 않는 코드가 포함되어 있을 수 있다.

이때 코드 분할을 통해 당장은 필요 없는 코드를 떼어내고 필요한 시점에 따로 로드할 수 있다.

 

텍스트 압축

HTML, CSS, JS 같은 리소스는 다운로드 이전에 서버에서 미리 압축할 수 있다.

이렇게 하면 원래 사이즈보다 더 작은 사이즈로 다운로드할 수 있어 웹 페이지가 더 빠르게 로드된다.

 

병목 코드 최적화

서비스를 느리게 만드는 코드를 병목 코드라고 하는데, 병목 코드를 어떻게 찾아내고 어떤 방법으로 최적화할 수 있는지 알아보자.

 

Lighthouse 툴을 이용한 페이지 검사

여기서는 Categories에서 Performance만 선택해서 분석을 진행한다.

 

아래는 Lighthouse 툴의 각 Mode와 Category들에 대한 설명이다.

Mode
- Navigation: Lighthouse의 기본 값으로 초기 페이지 로딩 시 발생하는 성능 문제를 분석
- Timespan: 사용자가 정의한 시간 동안 발생한 성능 문제를 분석
- Snapshot: 현재 상태의 성능 문제를 분석

Categories
- Performance: 웹 페이지의 로딩 과정에서 발생하는 성능 문제를 분석
- Accessibility: 서비스의 사용자 접근성 문제를 분석
- Best practices: 웹사이트의 보안 측면과 웹 개발의 최신 표준에 중점을 두고 분석
- SEO: 검색 엔진에서 얼마나 잘 크롤링되고 검색 결과에 표시되는지 분석
- Progressive Web App: 서비스 워커와 오프라인 동작 등, PWA와 관련된 문제를 분석

 

Lighthouse를 통한 해당 웹 페이지의 검사 결과는 다음과 같다.

먼저, FirstContentful Paint(FCP)에 대해서 알아보자.

FCP는 페이지가 로드될 때 브라우저가 DOM 콘텐츠의 첫 번째 부분을 렌더링하는데 걸리는 시간에 관한 지표이다.

FCP는 총점 계산 시 10%의 가중치를 갖는다.

 

Speed Index(SI)는 페이지 로드 중에 콘텐츠가 시각적으로 표시되는 속도를 나타내는 지표이다.

A 페이지는 1초마다 각 요소들을 보여줘서 4초가 되었을 때 전체 화면이 표시되는 반면, B 페이지는 그 전에는 각 요소를 보여주지 않고 4초가 되었을 때 전체 화면이 표시된다.

이런 경우 A 페이지가 SI에서 더 높은 점수를 받게 된다.

SI 또한 총점 계산 시 10%의 가중치를 갖는다.

 

Largest Contentful Paint(LCP)는 페이지가 로드될 때 화면 내에 있는 가장 큰 이미지나 텍스트 요소가 렌더링되기까지 걸리는 시간을 나타내는 지표이다.

LCP는 총점 계산 시 25%의 가중치를 가진다.

 

Time to Interactive(TTI)는 사용자가 페이지와 상호 작용이 가능한 시점까지 걸리는 시간을 측정한 지표이다.

즉 이 시점 전까지는 화면이 보이더라도 클릭 같은 입력이 동작하지 않는다.

TTI는 총점 계산 시 10%의 가중치를 가진다.

 

Total Blocking Time(TBT)는 페이지가 클릭, 키보드 입력 등의 사용자 입력에 응답하지 않도록 차단된 시간을 총합한 지표이다.

측정은 FCP와 TTI 사이 시간 동안 일어나고 메인 스레드를 독점해 다른 동작을 방해하는 작업에 걸린 시간을 총합한다.

이 시간은 총점 계산 시 30%의 가중치를 가진다.

 

Cumulative Layout Shift(CLS)는 페이지 로드 과정에서 발생하는 예기치 못한 레이아웃 이동을 측정한 지표이다.

레이아웃 이동은 화면상에서 요소의 위치나 크기가 순간적으로 변하는 것을 말한다.

CLS는 총점 계산 시 15%의 가중치를 가진다.

 

더 아래로 스크롤해보면 Opportunities 섹션과 Diagnostics 섹션이 나오는데, 해당 두 섹션은 웹 페이지의 문제점과 해결 방안, 그리고 문제를 해결함으로써 얻을 수 있는 이점이 무엇인지 보여준다.

Opportunities 섹션은 페이지를 더 빨리 로드하는데 잠재적으로 도움되는 제안을 나열하고, Diagnostics 섹션은 로드 속도와 직접적인 관계는 없지만 성능과 관련된 기타 정보를 보여준다.

 

다음 글부터 직접 최적화시켜보자.