웹사이트 성능 최적화 (1) TTFB

성능 최적화가 중요한 이유

웹사이트 방문자는 머무를지 떠날지를 결정하기 전에 웹페이지에서 평균 15초를 보낸다고 합니다.

더 많은 사람들이 디지털 컨텐츠를 소비하기 위해 웹에 의존하고 서비스가 다양해지며 어느 때 보다 소비자들의 요구가 까다로워지고 있습니다. 비즈니스의 성공은 방문자를 유지하는 것에 달려있다고 할 수 있습니다.

이런 상황에서 웹사이트의 성능은 방문자를 유지하는데 중요한 역할을 합니다.

그러므로 웹 개발자는 성능 개선을 위해 서비스 환경에 맞는 최적화 방법들을 적용해야 합니다.

요청 후 첫번째 바이트(TTFB)까지

앞선 포스팅에서 웹사이트에 접속하면 웹 서버는 웹사이트 렌더링에 필요한 여러 데이터를 응답한다고 했습니다. 요청 후 최초로 바이트가 도달할 때까지를 TTFB라 합니다.

이 과정에서 고려할 부분은 아래와 같습니다.

1. 리디렉션 최소화

   리디렉션은 브라우저가 리소스를 검색하기 위해 새 위치에서 추가 HTTP 요청을 해야 하므로 페이지 로드 속도가 느려집니다. 리디렉션에는 두 가지 유형이 있습니다.

   • 동일 출처 리디렉션

     이러한 유형의 리디렉션은 관리 로직이 전적으로 웹 서버에 있기 때문에 전적으로 개발자가 제어할 수 있습니다.

     예) 사용자를 example.com/page/에서 example.com/page로 리디렉션

   • 교차 출처 리디렉션

     교차 출처 리디렉션은 직접 제어할 수 없지만 여러 리디렉션이 없는지 확인하는 것이 좋습니다. 예를 들어 HTTP 페이지에 연결되는 광고가 이에 상응하는 HTTPS로 리디렉션 되도록 하거나, 내 출처에 도착했지만 동일 출처 리디렉션을 트리거하는 교차 출처 리디렉션을 사용하는 경우를 예로 들 수 있습니다.

2. HTML 응답 캐시

   이 방법은 어떠한 컨텍스트에서도 변경되지 않는 정적 콘텐츠에 가장 적합하며, 리소스를 캐시하기에 적절한 시간을 적당하다고 생각되는 시간(분)으로 설정할 수 있습니다.

   이 때 HTTP 응답 헤더인 Etag,Last-Modified 응답 헤더를 사용하여 캐싱할 수 있습니다.

   • Etag

     주로 리소스 컨텐츠의 해시를 사용합니다.

   • Last-Modified

     리소스가 마지막으로 업데이트된 날짜 및 시간이 포함된 응답 헤더를 포함하는 방식으로 비슷하게 작동합니다.

3. 서버 응답

   응답이 캐시되지 않는 경우 서버 응답시간은 호스팅 업체와 백엔드 어플리케이션 스택에 따라 크게 달라집니다. 동적으로 생성된 응답을 제공하는 웹 페이지의 경우는 측정을 통해 개선을 시도해볼 수 있습니다. 느린 TTFB가 발생하는 경우 Server-Timing 응답 헤더를 사용하여 서버에서 소요된 시간에 관한 정보를 노출할 수 있습니다.

   Server-Timing: auth;dur=55.5, db;dur=220
   
   //auth 검증 55.5ms
   //db 사용 220ms
   

   호스팅 인프라를 검토하고 웹사이트에서 수신하는 트래픽을 처리하기에 적절한 리소스가 있는지 확인하는 것이 좋습니다. 공유 호스팅 업체는 종종 TTFB가 높아지기 쉬우며, 응답 시간을 더 빠르게 제공하는 전용 솔루션은 비용이 더 많이 들 수 있습니다.

4. 압축

   HTML, 자바스크립트, CSS, SVG 이미지와 같은 텍스트 기반 응답은 압축하여 네트워크를 통한 전송 크기를 줄여야 더 빠르게 다운로드할 수 있습니다. 가장 널리 사용되는 압축 알고리즘은 gzip 및 Brotli입니다. Brotli는 gzip을 약 15~20% 개선해 줍니다.

   • 가능한 경우 Brotli를 사용합니다. gzip은 대체 수단으로 사용해야 합니다.

   • 파일의 크기가 중요합니다.

     모든 유형의 데이터 압축의 효과는 압축 알고리즘이 더 압축 가능한 데이터 비트를 찾기 위해 작업할 수 있는 대량의 데이터가 있는지에 따라 달라집니다. 파일이 클수록 압축이 향상됩니다. 그러나 단순히 더 효과적으로 압축할 수 있다는 사실만으로 대용량 리소스를 제공하면 안 됩니다. 자바스크립트, CSS와 같은 대용량 리소스는 브라우저에서 압축 해제한 후 파싱 및 평가에 훨씬 더 많은 시간이 걸리며, 조금만 변경되더라도 파일 해시가 달라지므로 자주 변경될 수 있습니다.

   • 동적 압축은 서버응답 시간을 더 소모할 수 있습니다.

     자바스크립트, CSS, SVG 이미지와 같은 정적 리소스는 정적으로 압축되어야 하는 반면, HTML 리소스(특히 인증된 사용자를 위해 동적으로 생성된 경우)는 동적으로 압축되어야 합니다.

   직접 압축을 올바르게 수행하기는 쉽지 않으며 대부분 콘텐츠 전송 네트워크(CDN)(다음 섹션에서 설명)에서 처리하도록 하는 것이 가장 좋습니다.

5. CDN

   원본 서버의 리소스를 캐시하여 사용자에게 물리적으로 더 가까운 에지 서버에서 제공하는 분산 서버 네트워크입니다. 사용자와의 물리적 거리가 왕복 시간 (RTT)을 줄여주고 HTTP/2 또는 HTTP/3, 캐싱, 압축과 같은 최적화 덕분에 CDN은 원본 서버에서 콘텐츠를 가져올 때보다 더 빠르게 콘텐츠를 제공할 수 있습니다. 경우에 따라 CDN을 활용하면 웹사이트의 TTFB를 크게 개선할 수 있습니다.