일반적인 HTML 성능 고려사항

빠르게 로드되는 웹사이트를 구축하기 위한 첫 단계는 서버로부터 페이지 HTML에 대한 응답을 받습니다. 브라우저가 주소 표시줄에 나타나면 브라우저가 서버에 GET 요청을 전송하여 가져올 수 있습니다 웹페이지에 대한 첫 번째 요청은 HTML 리소스를 위한 것입니다. 최소한의 지연으로 HTML이 빠르게 도착하도록 하는 것이 있습니다.

HTML에 대한 초기 요청은 여러 단계를 거치며, 각 단계에는 있습니다. 각 단계에서 소요되는 시간을 줄이면 단계별 소요 시간을 단축할 수 있으며 첫 번째 바이트 (TTFB). TTFB가 유일한 측정항목은 아니지만 TTFB가 높으면 페이지 로드 속도를 높여 '우수'로 지정된 측정항목에는 최대 콘텐츠 렌더링 시간, (LCP) 및 콘텐츠가 포함된 첫 페인트 (FCP).

리디렉션 최소화

리소스가 요청되면 서버는 리디렉션에 응답할 수 있습니다. 영구 리디렉션 (301 Moved Permanently 응답) 또는 일시적인 1개 (302 Found 응답).

리디렉션을 사용하면 브라우저가 추가 HTTP 요청을 사용하여 리소스를 검색할 수 있습니다. 현재 두 가지 리디렉션 유형:

1. 전적으로 원본 내에서 발생하는 동일 출처 리디렉션 이러한 유형 를 관리하는 로직이 있으므로 리디렉션의 설정은 완전히 제어할 수 있습니다. 전적으로 웹 서버에 상주합니다.
2. 다른 출처에서 시작된 교차 출처 리디렉션 이러한 유형의 일반적으로 리디렉션은 제어할 수 없습니다.

교차 출처 리디렉션은 주로 광고, URL 단축 서비스 서드 파티 서비스에 대한 액세스 권한을 제공합니다 교차 출처 리디렉션은 제어할 수 없지만 여러 번 리디렉션(예: 광고가 HTTP 페이지로 연결되고 이 페이지가 HTTPS로 리디렉션됨 또는 원본에 도착하는 교차 출처 리디렉션이지만 동일 출처 리디렉션을 트리거합니다.

HTML 응답 캐시

응답에 기타 중요 리소스(예: CSS, JavaScript, 이미지, 기타 리소스) 있습니다. 이러한 리소스에는 각 인스턴스에 고유한 디지털 지문이 포함될 수 파일 이름을 기반으로 합니다. 이는 파일 내용에 따라 변경됩니다. 이는 캐시된 데이터가 HTML 문서는 배포 후 비활성 상태가 될 수 있습니다. 오래된 하위 리소스에 대한 참조를 포함합니다.

그럼에도 불구하고 캐싱을 사용하지 않고 짧은 캐시 수명을 사용하면 이점이 있습니다. 예를 들어 리소스가 CDN에서 캐시되도록 허용하여 요청을 보내어 원본 서버와 브라우저에서 리소스를 다시 다운로드하는 대신 재검증해야 하기 때문입니다. 이 접근 방식은 맥락에 상관없이 변하지 않는 정적인 콘텐츠에 적합하며 리소스 캐시 시간은 분 단위로 설정할 수 있습니다. 있습니다. 정적 HTML 리소스는 5분만 투자해도 괜찮으며, 정기 업데이트가 눈에 띄지 않게 하는 것입니다.

페이지의 HTML 콘텐츠가 맞춤설정되는 경우(예: 인증된 사용자의 경우, 사이트에 있는 모든 이메일 계정에 대해 콘텐츠를 보안이나 사이버 위협 등 정보를 제공합니다 HTML 응답이 캐시된 경우 캐시를 무효화할 수 없습니다. 그것은 따라서 이러한 경우에는 HTML 캐싱을 완전히 피하는 것이 가장 좋습니다.

HTML을 캐싱하는 경우 ETag 또는 Last-Modified 응답 헤더. ETag(항목이라고도 함) 태그—헤더는 요청된 리소스를 고유하게 나타내는 식별자입니다. 종종 리소스 콘텐츠의 해시를 사용합니다.

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

리소스가 변경될 때마다 새 ETag 값을 생성해야 합니다. 사용 설정됨 브라우저가 ETag 값을 If-None-Match 요청 헤더. 서버의 ETag가 일치하는 경우 요청이 전송되면 서버는 304 Not Modified 응답으로 응답합니다. 브라우저는 캐시의 리소스를 사용합니다. 이로 인해 여전히 네트워크 지연 시간: 304 Not Modified 응답은 전체 응답보다 훨씬 작습니다. 사용됩니다.

그러나 리소스의 최신 상태 재검증과 관련된 네트워크 지연 시간은 여전히 나름의 단점이 있습니다. 웹 개발의 다른 많은 측면과 마찬가지로 타협과 절충은 불가피합니다 당신이 알아내는 것은 당신에게 달려 있습니다. 이러한 방식으로 HTML을 캐시하는 데 추가 노력을 해도 그만한 가치가 있습니다. 문제가 없도록 하려면 HTML 콘텐츠를 전혀 캐시하지 않아도 됩니다.

서버 응답 시간 측정

응답이 캐시되지 않는 경우 서버의 응답 시간은 호스팅 업체 및 백엔드 애플리케이션 스택에 최적화되어 있습니다 웹 페이지의 동적으로 생성되는 응답(예: 데이터베이스에서 데이터 가져오기)을 위해 예: 게재 가능한 정적 웹페이지보다 TTFB가 높을 수 있음 즉각적으로 반응할 수 있게 되었습니다. 표시 중: 스피너를 로드한 다음 클라이언트 측에서 모든 데이터를 가져오면 예측 불가능한 서버 측 환경에서 잠재적으로 예측 불가능한 사용할 수 있습니다 클라이언트 측 작업을 최소화하면 일반적으로 사용자 중심 측정항목을 고려하는 것이 좋습니다

사용자의 필드에서 느린 TTFB가 발생하는 경우 정보를 노출할 수 있습니다. Server-Timing 응답 헤더:

Server-Timing: auth;dur=55.5, db;dur=220

Server-Timing 헤더의 값에는 여러 측정항목과 각각 다릅니다. 그런 다음 이 데이터는 현장에 있는 사용자로부터 수집할 수 있습니다. Navigation Timing API를 사용하고 이를 분석하여 사용자가 있습니다. 위의 코드 스니펫에서 응답 헤더에 두 개의 타이밍이 포함되어 있습니다.

• 사용자 인증 시간 (auth)으로 55.5밀리초가 소요되었습니다.
• 220밀리초가 소요된 데이터베이스 액세스 시간 (db)

또한 호스팅 인프라를 검토하고 충분한 리소스가 있어야 합니다. 공유됨 호스팅 제공업체는 높은 TTFB 및 전용 솔루션에 취약한 경우가 많습니다. 더 빠른 응답 시간을 제공하는 것이 더 많은 비용이 들 수 있습니다.

압축

HTML, JavaScript, CSS, SVG 이미지와 같은 텍스트 기반 응답은 네트워크를 통한 전송 크기를 줄이기 위해 압축된 형태로 다운로드할 수 있습니다. 가장 널리 사용되는 압축 알고리즘은 gzip 및 브로틀리입니다. Brotli 를 사용하면 gzip에 비해 파일 속도가 약 15~20% 개선됩니다.

압축은 보통 대부분의 웹 호스팅 업체에서 자동으로 설정하지만 Ad Exchange를 구성할 준비가 된 경우 고려해야 할 몇 가지 중요한 사항이 압축 설정을 직접 수정할 수도 있습니다.

1. 가능하면 Brotli를 사용합니다. 앞서 언급했듯이 Brotli는 gzip에 비해 현저히 개선되었으며 Brotli는 모든 주요 브라우저와 별개입니다. 가능하다면 Brotli를 사용하되 사용자 수를 늘리려면 gzip을 대체로 사용하고 압축이 전혀 없는 것보다 낫기 때문입니다.
2. 파일 크기가 중요합니다. 매우 작은 리소스(1KiB 미만)는 압축하지 않음 또는 때로는 전혀 압축하지 않습니다. 모든 유형의 효과 압축하는 방법은 데이터를 압축하는 데 필요한 더 압축 가능한 비트를 찾기 위해 압축 알고리즘이 작동할 수 있습니다. 학습합니다. 파일이 클수록 압축이 더 잘 작동하지만 더 많이 압축할 수 있다는 사실만으로도 효과적으로 사용할 수 있습니다 자바스크립트, CSS 같은 대규모 리소스는 브라우저 로드 완료 후 파싱 및 평가에 압축 해제되어 더 자주 변경될 수 있습니다. 약간 변경되어도 파일 해시가 달라집니다.
3. 동적 압축과 정적 압축의 차이를 이해합니다. 동적 및 정적 압축은 리소스가 배포되어야 하는 시점에 대한 다른 접근 방식입니다. 압축됩니다. 동적 압축은 리소스를 압축할 때 , 때로는 매번 요청되는 경우도 있습니다. 반면에 정적 압축은 파일을 미리 압축하므로 압축할 필요가 없습니다. 수행되어야 합니다. 정적 압축은 서버 응답에 추가될 수 있는 압축 자체와 관련된 지연 시간 시간을 단축할 수 있습니다. 정적 리소스(예: JavaScript, CSS, SVG 이미지는 정적으로 압축되어야 하는 반면, HTML은 정적으로 압축되어야 합니다. 리소스(특히 인증된 리소스)를 위해 동적으로 생성된 경우 동적으로 압축되어야 합니다.

자체적으로 압축하는 것은 어려우며, 압축이 가능한 상태로 두는 것이 콘텐츠 전송 네트워크 (CDN)에 대해서는 다음 섹션에서 다룰 예정입니다 자동으로 처리합니다 그러나 이러한 개념을 알면 호스팅 업체가 압축을 제대로 사용하고 있는지 확인합니다. 이러한 지식은 압축 설정을 개선하여 웹사이트에 최대의 이익을 안겨줄 수 있습니다.

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

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

학습한 내용 테스트

다음 단계: 핵심 경로 이해하기

이제 컨테이너와 관련된 성능 고려사항을 알아봤습니다. 웹사이트의 HTML을 사용하면 Google 게시자 태그를 가능한 한 빨리 가능하지만 이는 웹 학습의 시작에 불과합니다. 확인할 수 있습니다 다음으로, 주요 렌더링 경로의 이면에 있는 이론은 있습니다. 이 모듈에서는 렌더링 차단 및 차단과 같은 주요 개념을 설명합니다. 페이지의 초기 로드를 가져오는 데 있어 이들이 수행하는 역할에 대해 최대한 빠르게 렌더링해야 합니다.