일반적인 HTML 성능 고려사항

로드 속도가 빠른 웹사이트를 구축하는 첫 번째 단계는 페이지의 HTML에 대해 서버로부터 적시에 응답을 받는 것입니다. 브라우저의 주소 표시줄에 URL을 입력하면 브라우저가 서버에 GET 요청을 전송하여 URL을 가져옵니다. 웹페이지의 첫 번째 요청은 HTML 리소스에 대한 요청이며 HTML이 지연을 최소화하여 빠르게 도착하도록 하는 것이 주요 성능 목표입니다.

HTML에 대한 초기 요청은 여러 단계를 거치며 각 단계에는 시간이 걸립니다. 각 단계에 소요되는 시간을 줄이면 첫 바이트까지의 시간 (TTFB)이 빨라집니다. TTFB가 페이지 로드 속도와 관련하여 집중해야 하는 유일한 측정항목은 아니지만 TTFB가 높으면 콘텐츠가 포함된 최대 페인트(LCP) 및 콘텐츠가 포함된 첫 페인트 (FCP)와 같은 측정항목의 지정된 '양호' 기준에 도달하기가 어려워집니다.

리디렉션 최소화

리소스가 요청되면 서버는 영구 리디렉션 (301 Moved Permanently 응답) 또는 임시 리디렉션 (302 Found 응답)으로 응답할 수 있습니다.

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

  1. 동일 출처 리디렉션: 출처 내에서만 발생하는 리디렉션입니다. 이러한 유형의 리디렉션은 완전히 제어할 수 있습니다. 리디렉션을 관리하는 로직이 웹 서버에 완전히 있기 때문입니다.
  2. 다른 출처에서 시작된 교차 출처 리디렉션 이러한 유형의 리디렉션은 일반적으로 사용자가 제어할 수 없습니다.

크로스 오리진 리디렉션은 광고, URL 단축 서비스, 기타 서드 파티 서비스에서 자주 사용됩니다. 크로스 오리진 리디렉션은 제어할 수 없지만 여러 리디렉션을 피하는지 확인하는 것이 좋습니다. 예를 들어 HTTP 페이지로 연결되는 광고가 HTTPS 페이지로 리디렉션되거나 크로스 오리진 리디렉션이 오리진에 도착한 후 동일 출처 리디렉션을 트리거하는 경우를 피해야 합니다.

HTML 응답 캐시

HTML 응답에는 CSS, JavaScript, 이미지, 기타 리소스 유형과 같은 다른 중요 리소스에 대한 링크가 포함될 수 있으므로 HTML 응답을 캐시하기는 어렵습니다. 이러한 리소스에는 파일의 콘텐츠에 따라 변경되는 고유 지문이 각 파일 이름에 포함될 수 있습니다. 즉, 캐시된 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% 개선됩니다.

압축은 대부분의 웹 호스팅 제공업체에서 자동으로 설정하는 경우가 많지만, 압축 설정을 직접 구성하거나 조정할 수 있는 경우 고려해야 할 몇 가지 중요한 사항이 있습니다.

  1. 가능한 경우 Brotli 사용 앞서 언급한 바와 같이 Brotli는 gzip에 비해 상당히 눈에 띄는 개선을 제공하며 모든 주요 브라우저에서 Brotli가 지원됩니다. 가능한 경우 Brotli를 사용하되, 기존 브라우저를 사용하는 사용자가 많은 웹사이트의 경우 gzip이 대체로 사용되도록 하세요. 압축이 전혀 없는 것보다 압축이 있는 것이 낫기 때문입니다.
  2. 파일 크기가 중요합니다. 매우 작은 리소스(1KiB 미만)는 잘 압축되지 않거나 전혀 압축되지 않는 경우도 있습니다. 모든 유형의 데이터 압축의 효과는 압축 알고리즘이 더 압축 가능한 데이터 비트를 찾기 위해 사용할 수 있는 많은 양의 데이터가 있는지에 따라 달라집니다. 파일이 클수록 압축이 더 잘 작동하지만, 더 효과적으로 압축할 수 있다는 이유만으로 매우 큰 리소스를 제공하지는 마세요. 예를 들어 JavaScript 및 CSS와 같은 대규모 리소스는 브라우저에서 압축 해제한 후 파싱하고 평가하는 데 훨씬 더 많은 시간이 걸리며, 미미한 변경사항만 있더라도 변경사항이 발생하면 파일 해시가 달라지므로 더 자주 변경될 수 있습니다.
  3. 동적 압축과 정적 압축의 차이점을 이해합니다. 동적 압축과 정적 압축은 리소스를 압축해야 하는 시점에 대한 접근 방식이 서로 다릅니다. 동적 압축은 요청 시점에 리소스를 압축하며, 때로는 요청될 때마다 압축합니다. 반면 정적 압축은 미리 파일을 압축하므로 요청 시 압축을 실행할 필요가 없습니다. 정적 압축은 압축 자체와 관련된 지연 시간을 제거하므로 동적 압축의 경우 서버 응답 시간이 늘어날 수 있습니다. 자바스크립트, CSS, SVG 이미지와 같은 정적 리소스는 정적으로 압축해야 하는 반면 HTML 리소스는 특히 인증된 사용자를 위해 동적으로 생성되는 경우 동적으로 압축해야 합니다.

직접 압축을 올바르게 수행하기는 어려우므로 다음 섹션에서 설명하는 콘텐츠 전송 네트워크 (CDN)에서 이를 처리하도록 하는 것이 좋습니다. 하지만 이러한 개념을 알면 호스팅 제공업체에서 압축을 올바르게 사용하고 있는지 파악하는 데 도움이 됩니다. 이 정보를 통해 압축 설정을 개선하여 웹사이트에 최대한의 이점을 제공할 수 있습니다.

콘텐츠 전송 네트워크 (CDN)

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

학습한 내용 테스트

어떤 유형의 리디렉션이 완전히 내 통제하에 있나요?

동일 출처 리디렉션
교차 출처 리디렉션입니다.

Server-Timing 헤더에는 여러 측정항목이 포함될 수 있습니다.

참입니다.
거짓입니다.

실제로 최종 사용자와 가장 가까운 서버 유형은 무엇인가요?

콘텐츠 전송 네트워크 (CDN)의 에지 서버입니다.
웹사이트의 원본 서버입니다.

다음: 중요 경로 이해

이제 웹사이트의 HTML과 관련된 성능 고려사항을 알았으므로 웹사이트를 최대한 빨리 로드할 수 있습니다. 하지만 이는 웹 성능 학습의 시작일 뿐입니다. 다음으로 중요 렌더링 경로의 이론을 살펴봅니다. 이 모듈에서는 렌더링 차단 및 파싱 차단 리소스와 같은 주요 개념과 브라우저에서 페이지의 초기 렌더링을 최대한 빨리 가져오는 데 이러한 개념이 어떤 역할을 하는지 설명합니다.