빠르게 로드되는 웹사이트를 구축하는 첫 번째 단계는 페이지 HTML에 대해 서버로부터 적시에 응답을 받는 것입니다. 브라우저의 주소 표시줄에 URL을 입력하면 브라우저가 서버에 GET 요청을 전송하여 해당 URL을 검색합니다. 웹페이지에 대한 첫 번째 요청은 HTML 리소스이며, 지연을 최소화하면서 HTML이 빠르게 도착하도록 하는 것이 핵심 성능 목표입니다.
HTML에 대한 초기 요청은 여러 단계를 거치며, 각 단계는 다소 시간이 걸립니다. 각 단계에 소요되는 시간을 줄이면 첫 바이트 소요 시간 (TTFB)이 단축됩니다. TTFB가 페이지 로드 속도에 초점을 두어야 하는 유일한 측정항목은 아니지만 TTFB가 높으면 최대 콘텐츠 렌더링 시간(LCP) 및 콘텐츠가 포함된 첫 페인트 (FCP)와 같은 측정항목에 지정된 '양호' 기준점에 도달하기가 어려울 수 있습니다.
리디렉션 최소화
리소스가 요청되면 서버는 영구 리디렉션 (301 Moved Permanently 응답) 또는 임시 리디렉션 (302 Found 응답)으로 리디렉션으로 응답할 수 있습니다.
리디렉션은 브라우저가 새 위치에서 추가 HTTP 요청을 실행하여 리소스를 검색해야 하므로 페이지 로드 속도가 느려집니다. 리디렉션에는 두 가지 유형이 있습니다.
- 완전히 출처 내에서 발생하는 동일 출처 리디렉션. 이러한 유형의 리디렉션은 관리 로직이 전적으로 웹 서버에 있기 때문에 전적으로 개발자가 제어할 수 있습니다.
- 다른 출처에서 시작된 교차 출처 리디렉션. 이러한 유형의 리디렉션은 일반적으로 제어할 수 없습니다.
교차 출처 리디렉션은 광고, URL 단축 서비스, 기타 서드 파티 서비스에서 주로 사용됩니다. 교차 출처 리디렉션은 제어할 수 없지만 여러 리디렉션이 없는지 계속 확인해야 할 수도 있습니다. 예를 들어 HTTP 페이지로 연결되는 광고가 이에 상응하는 HTTPS 페이지로 리디렉션되도록 하거나 출처에 도착한 후 동일 출처 리디렉션을 트리거하는 교차 출처 리디렉션을 사용하는 경우를 예로 들 수 있습니다.
HTML 응답 캐시
HTML 응답 캐싱은 어려운데, 그 이유는 응답에 CSS, JavaScript, 이미지, 기타 리소스 유형 등 다른 중요한 리소스에 대한 링크가 포함될 수 있기 때문입니다. 이러한 리소스는 각 파일 이름에 고유한 지문을 포함할 수 있으며, 이 지문은 파일 콘텐츠에 따라 변경됩니다. 즉, 캐시된 HTML 문서는 배포 후 오래된 하위 리소스에 대한 참조를 포함할 수 있으므로 비활성 상태가 될 수 있습니다.
그럼에도 불구하고 캐시 수명이 짧으면(캐싱이 없는 것이 아니라) CDN에서 리소스를 캐시할 수 있어 원본 서버와 브라우저에서 제공되는 요청 수가 감소하여 리소스를 다시 다운로드하지 않고 재확인할 수 있는 등의 이점이 있습니다. 이 방법은 어떠한 컨텍스트에서도 변경되지 않는 정적 콘텐츠에 가장 적합하며, 리소스를 캐시하는 적절한 시간을 적절한 시간(분)으로 설정할 수 있습니다. 정적 HTML 리소스의 경우 5분이 안전하며, 주기적인 업데이트가 눈에 띄지 않게 진행되도록 합니다.
페이지의 HTML 콘텐츠가 어떤 식으로 맞춤설정(예: 인증된 사용자)된 경우 보안 및 최신성을 포함한 다양한 문제를 위해 콘텐츠를 아예 캐시하지 않는 것이 좋습니다. HTML 응답이 사용자의 브라우저에 의해 캐시되면 해당 캐시를 무효화할 수 없습니다. 따라서 이러한 경우에는 HTML을 모두 캐시하지 않는 것이 가장 좋습니다.
HTML을 캐싱할 때 주의하려면 ETag 또는 Last-Modified 응답 헤더를 사용하는 것이 좋습니다. ETag(항목 태그라고도 함) 헤더는 요청된 리소스를 고유하게 나타내는 식별자로, 보통 리소스 콘텐츠의 해시를 사용합니다.
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
리소스가 변경될 때마다 새 ETag 값을 생성해야 합니다. 후속 요청에서는 브라우저가 If-None-Match 요청 헤더를 통해 ETag 값을 전송합니다. 서버의 ETag이 브라우저에서 전송한 응답과 일치하는 경우 서버는 304 Not Modified 응답으로 응답하고 브라우저는 캐시의 리소스를 사용합니다. 이로 인해 여전히 네트워크 지연 시간이 발생하지만 304 Not Modified 응답은 전체 HTML 리소스보다 훨씬 작습니다.
그러나 리소스의 최신 상태 재검증과 관련된 네트워크 지연 시간은 여전히 나름의 단점입니다. 웹 개발의 다른 많은 측면과 마찬가지로 절충 및 절충은 피할 수 없습니다. 이 방법으로 HTML을 캐시하기 위한 추가적인 노력이 가치가 있는지, 아니면 안전한 상태를 유지하고 HTML 콘텐츠를 전혀 캐시하지 않는 것이 가장 좋은지 판단하는 것은 개발자의 몫입니다.
서버 응답 시간 측정
응답이 캐시되지 않으면 서버의 응답 시간은 호스팅 업체와 백엔드 애플리케이션 스택에 따라 크게 달라집니다. 동적으로 생성된 응답을 제공하는 웹페이지(예: 데이터베이스에서 데이터 가져오기)는 백엔드에서 상당한 컴퓨팅 시간 없이 즉시 제공할 수 있는 정적 웹페이지보다 TTFB가 높을 수 있습니다. 로드 스피너를 표시한 후 클라이언트 측에서 모든 데이터를 가져오면 보다 예측 가능한 서버 측 환경에서 잠재적으로 예측할 수 없는 클라이언트 측 환경으로 전환됩니다. 클라이언트 측 작업을 최소화하면 일반적으로 사용자 중심 측정항목이 개선됩니다.
사용자의 필드에서 느린 TTFB가 발생하는 경우 Server-Timing 응답 헤더를 사용하여 서버에서 소요된 시간에 관한 정보를 노출할 수 있습니다.
Server-Timing: auth;dur=55.5, db;dur=220
Server-Timing 헤더의 값에는 여러 측정항목과 각 측정항목의 지속 시간이 포함될 수 있습니다. 그런 다음 이 데이터는 Navigation Timing API를 사용하여 현장에 있는 사용자로부터 수집한 다음 이를 분석하여 사용자가 지연을 겪고 있는지 확인합니다. 앞의 코드 스니펫에서 응답 헤더에는 두 가지 타이밍이 포함됩니다.
- 사용자 인증 시간 (
auth)으로, 55.5밀리초가 걸렸습니다. - 데이터베이스 액세스 시간(
db)(220밀리초 소요)
또한 호스팅 인프라를 검토하고 웹사이트에서 수신하는 트래픽을 처리하기에 충분한 리소스가 있는지 확인하는 것이 좋습니다. 공유 호스팅 제공업체는 종종 높은 TTFB에 취약하며, 더 빠른 응답 시간을 제공하는 전용 솔루션은 더 많은 비용이 들 수 있습니다.
압축
HTML, JavaScript, CSS, SVG 이미지와 같은 텍스트 기반 응답은 압축하여 네트워크를 통한 전송 크기를 줄여야 다운로드 속도를 높일 수 있습니다. 가장 널리 사용되는 압축 알고리즘은 gzip과 Brotli입니다. Brotli는 gzip을 통해 약 15% ~20% 의 개선을 실현합니다.
압축은 대부분의 웹 호스팅 업체에서 자동으로 설정하지만 압축 설정을 직접 구성하거나 조정할 수 있는 경우 고려해야 할 중요한 사항이 있습니다.
- 가능한 경우 Brotli를 사용합니다. 앞서 언급했듯이 Brotli는 gzip보다 현저하게 개선되었으며 Brotli는 모든 주요 브라우저에서 지원됩니다. 가능하면 Brotli를 사용하세요. 단, 기존 브라우저에서 다수의 사용자가 웹사이트를 사용하는 경우, 전혀 압축하지 않는 것보다 압축이 더 낫기 때문에 gzip을 대체 수단으로 사용해야 합니다.
- 파일 크기가 중요합니다. 1KiB 미만의 매우 작은 리소스는 잘 압축되지 않거나 아예 압축되지 않는 경우도 있습니다. 모든 유형의 데이터 압축의 효과는 압축 알고리즘이 더 압축 가능한 데이터 비트를 찾기 위해 작업할 수 있는 대량의 데이터가 있는지에 따라 달라집니다. 파일이 클수록 더 나은 압축이 이루어집니다. 하지만 더 효과적으로 압축할 수 있다는 사실만으로는 대용량 리소스를 제공하지 마세요. 자바스크립트, CSS와 같은 대용량 리소스는 브라우저에서 압축을 해제한 후 파싱 및 평가에 훨씬 더 많은 시간이 걸리며, 조금만 변경되더라도 파일 해시가 달라지므로 더 자주 변경될 수 있습니다.
- 동적 압축과 정적 압축의 차이점을 알아보세요. 동적 압축과 정적 압축은 리소스를 압축해야 하는 시점에 관해 서로 다른 접근 방식을 취합니다. 동적 압축은 요청될 때 리소스를 압축하며, 때로는 요청될 때마다 리소스를 압축합니다. 반면에 정적 압축은 파일을 미리 압축하므로 요청 시 압축을 수행할 필요가 없습니다. 정적 압축은 압축 자체와 관련된 지연 시간을 제거하므로 동적 압축의 경우 서버 응답 시간에 추가될 수 있습니다. JavaScript, CSS, SVG 이미지와 같은 정적 리소스는 정적으로 압축되어야 하는 반면, HTML 리소스(특히 인증된 사용자를 위해 동적으로 생성된 경우)는 동적으로 압축되어야 합니다.
직접 압축을 하는 것은 어려운 일입니다. 다음 섹션에서 설명하는 콘텐츠 전송 네트워크 (CDN)를 통해 이 작업을 처리하는 것이 가장 좋습니다. 그러나 이러한 개념을 알면 호스팅 제공업체가 압축을 올바르게 사용하고 있는지 확인하는 데 도움이 될 수 있습니다. 이러한 지식을 통해 압축 설정을 개선하여 웹사이트의 최대 이점을 얻을 수 있는 기회를 찾을 수 있습니다.
콘텐츠 전송 네트워크 (CDN)
콘텐츠 전송 네트워크 (CDN)는 원본 서버의 리소스를 캐시하여 사용자에게 물리적으로 더 가까운 에지 서버에서 제공하는 서버의 분산 네트워크입니다. 사용자와의 물리적 근접성은 왕복 시간 (RTT)을 줄여주는 반면, HTTP/2 또는 HTTP/3, 캐싱, 압축과 같은 최적화로 CDN이 콘텐츠를 원본 서버에서 가져오는 경우보다 더 빠르게 제공할 수 있습니다. CDN을 활용하면 경우에 따라 웹사이트의 TTFB가 크게 개선될 수 있습니다.
학습한 내용 테스트
직접 관리할 수 있는 리디렉션 유형은 무엇인가요?
Server-Timing 헤더에는 여러 측정항목이 포함될 수 있습니다.
최종 사용자와 물리적으로 가장 가까운 서버 유형은 무엇인가요?
다음 과정: 핵심 경로 이해
이제 웹사이트 HTML과 관련된 성능 고려사항에 익숙해졌으므로 웹사이트 HTML을 최대한 빠르게 로드할 수 있습니다. 이것은 웹 성능 학습의 시작에 불과합니다. 다음으로 주요 렌더링 경로에 관한 이론을 다룹니다. 이 모듈에서는 렌더링 차단 및 파싱 차단 리소스와 같은 주요 개념과 가능한 한 빨리 브라우저에서 페이지의 초기 렌더링을 가져오는 데 있어 이러한 리소스가 수행하는 역할을 설명합니다.