Time to First Byte(첫 바이트까지의 시간) 측정항목에 맞게 최적화하는 방법을 알아보세요.
TTFB (Time to First Byte)는 콘텐츠가 포함된 첫 페인트 (FCP), 최대 콘텐츠 페인트 (LCP)와 같은 다른 모든 의미 있는 사용자 경험 측정항목보다 우선하는 기본적인 웹 성능 측정항목입니다. 즉, TTFB 값이 높으면 그 뒤에 오는 측정항목에 시간이 추가됩니다.
서버는 75번째 중앙값의 사용자가 '좋음' 기준점 내에서 FCP를 경험할 수 있을 만큼 충분히 빠르게 탐색 요청에 응답하는 것이 좋습니다. 대략적인 가이드라인으로 대부분의 사이트는 TTFB가 0.8초 이하이 되도록 노력해야 합니다.
TTFB 측정 방법
TTFB를 최적화하기 전에 TTFB가 웹사이트 사용자에게 어떤 영향을 미치는지 관찰해야 합니다. TTFB는 리디렉션의 영향을 받으므로 TTFB를 관찰하는 기본 소스로 현장 데이터를 사용해야 합니다. 실험실 기반 도구는 최종 URL을 사용하여 측정되는 경우가 많으므로 이 추가 지연이 누락됩니다.
PageSpeed Insights는 Chrome 사용자 환경 보고서에서 제공되는 공개 웹사이트의 필드 및 실험실 정보를 모두 얻을 수 있는 방법 중 하나입니다.
실제 사용자의 TTFB는 상단의 실제 사용자의 경험 확인하기 섹션에 표시됩니다.
TTFB의 하위 집합은 서버 응답 시간 감사에 표시됩니다.
현장과 실험실에서 TTFB를 측정하는 방법을 자세히 알아보려면 TTFB 측정항목 페이지를 참고하세요.
Server-Timing를 사용하여 필드에서 높은 TTFB 디버그
Server-Timing 응답 헤더는 애플리케이션 백엔드에서 지연 시간이 길어질 수 있는 고유한 백엔드 프로세스를 측정하는 데 사용할 수 있습니다. 헤더 값의 구조는 유연하며 최소한 개발자가 정의한 핸들을 허용합니다. 선택사항인 값에는 소요 시간 값 (dur 사용)과 사람이 읽을 수 있는 설명 (desc 사용)이 포함됩니다.
Serving-Timing는 여러 애플리케이션 백엔드 프로세스를 측정하는 데 사용할 수 있지만 다음과 같이 특별히 주의해야 할 프로세스도 있습니다.
- 데이터베이스 쿼리
- 서버 측 렌더링 시간(해당하는 경우)
- 디스크 탐색
- 에지 서버 캐시 적중/누락 (CDN 사용 시)
Server-Timing 항목의 모든 부분은 콜론으로 구분되며 여러 항목은 쉼표로 구분할 수 있습니다.
// Two metrics with descriptions and values
Server-Timing: db;desc="Database";dur=121.3, ssr;desc="Server-side Rendering";dur=212.2
헤더는 애플리케이션 백엔드의 선택한 언어를 사용하여 설정할 수 있습니다. 예를 들어 PHP에서는 다음과 같이 헤더를 설정할 수 있습니다.
<?php
// Get a high-resolution timestamp before
// the database query is performed:
$dbReadStartTime = hrtime(true);
// Perform a database query and get results...
// ...
// Get a high-resolution timestamp after
// the database query is performed:
$dbReadEndTime = hrtime(true);
// Get the total time, converting nanoseconds to
// milliseconds (or whatever granularity you need):
$dbReadTotalTime = ($dbReadEndTime - $dbReadStartTime) / 1e+6;
// Set the Server-Timing header:
header('Server-Timing: db;desc="Database";dur=' . $dbReadTotalTime);
?>
이 헤더가 설정되면 실험실과 현장 모두에서 사용할 수 있는 정보가 표시됩니다.
이 필드에서 Server-Timing 응답 헤더가 설정된 모든 페이지는 Navigation Timing API의 serverTiming 속성을 채웁니다.
// Get the serverTiming entry for the first navigation request:
performance.getEntries('navigation')[0].serverTiming.forEach(entry => {
// Log the server timing data:
console.log(entry.name, entry.description, entry.duration);
});
실험실에서는 Server-Timing 응답 헤더의 데이터가 Chrome DevTools의 네트워크 탭에 있는 타이밍 패널에 시각화됩니다.
Chrome DevTools의 네트워크 탭에 시각화된 Server-Timing 응답 헤더 여기서 Server-Timing는 리소스 요청이 CDN 캐시를 히트했는지 여부와 요청이 CDN의 에지 서버와 원본을 히트하는 데 걸리는 시간을 측정하는 데 사용됩니다.
사용 가능한 데이터를 분석하여 TTFB에 문제가 있다고 판단되면 문제를 해결할 수 있습니다.
TTFB 최적화 방법
TTFB 최적화에서 가장 어려운 점은 웹의 프런트엔드 스택은 항상 HTML, CSS, JavaScript이지만 백엔드 스택은 크게 다를 수 있다는 것입니다. 각각 고유한 최적화 기술을 사용하는 수많은 백엔드 스택과 데이터베이스 제품이 있습니다. 따라서 이 가이드에서는 스택별 안내만 제공하는 대신 대부분의 아키텍처에 적용되는 사항에 중점을 둡니다.
플랫폼별 안내
웹사이트에 사용하는 플랫폼은 TTFB에 큰 영향을 미칠 수 있습니다. 예를 들어 WordPress 성능은 플러그인의 수와 품질 또는 사용되는 테마에 영향을 받습니다. 플랫폼이 맞춤설정되면 다른 플랫폼에도 비슷한 영향을 미칩니다. 이 게시물의 일반적인 성능 조언을 보완하기 위해 공급업체별 조언을 확인하려면 플랫폼의 문서를 참고하세요. 서버 응답 시간 단축을 위한 Lighthouse 감사에는 제한된 스택별 안내도 포함되어 있습니다.
호스팅, 호스팅, 호스팅
다른 최적화 접근 방식을 고려하기 전에 먼저 호스팅을 고려해야 합니다. 여기에서 제공할 수 있는 구체적인 안내는 많지 않지만 일반적인 규칙은 웹사이트의 호스트가 전송하는 트래픽을 처리할 수 있는지 확인하는 것입니다.
공유 호스팅은 일반적으로 속도가 느립니다. 대부분 정적 파일을 제공하는 소규모 개인 웹사이트를 운영하는 경우에는 괜찮습니다. 다음에 설명하는 최적화 기법 중 일부를 사용하면 TTFB를 최대한 줄일 수 있습니다.
하지만 맞춤설정, 데이터베이스 쿼리, 기타 대규모 서버 측 작업이 포함된 대규모 애플리케이션을 많은 사용자와 함께 실행하는 경우 현장에서 TTFB를 낮추기 위해 호스팅을 선택하는 것이 중요합니다.
호스팅 업체를 선택할 때는 다음 사항에 유의하세요.
- 애플리케이션 인스턴스에 할당된 메모리는 얼마인가요? 애플리케이션의 메모리가 충분하지 않으면 최대한 빨리 페이지를 제공하기 위해 애쓰고 트래시가 발생합니다.
- 호스팅 제공업체가 백엔드 스택을 최신 상태로 유지하나요? 애플리케이션 백엔드 언어, HTTP 구현, 데이터베이스 소프트웨어의 새 버전이 출시되면 시간이 지남에 따라 해당 소프트웨어의 성능이 개선됩니다. 이러한 중요한 유지보수에 우선순위를 두는 호스팅 업체와 파트너십을 맺는 것이 중요합니다.
- 매우 구체적인 애플리케이션 요구사항이 있고 서버 구성 파일에 가장 낮은 수준의 액세스 권한을 원하는 경우 자체 애플리케이션 인스턴스의 백엔드를 맞춤설정하는 것이 적절한지 문의하세요.
이러한 문제를 처리해 주는 호스팅 업체가 많지만 전용 호스팅 업체에서도 TTFB 값이 길어지기 시작하면 최상의 사용자 환경을 제공할 수 있도록 현재 호스팅 업체의 기능을 재평가해야 할 수도 있다는 신호일 수 있습니다.
콘텐츠 전송 네트워크 (CDN) 사용
CDN 사용은 자주 언급되는 주제이지만 그럴 만한 이유가 있습니다. 애플리케이션 백엔드가 매우 최적화되어 있더라도 원본 서버에서 멀리 떨어진 사용자에게는 여전히 TTFB가 높을 수 있기 때문입니다.
CDN은 사용자와 물리적으로 더 가까운 서버에 리소스를 캐시하는 분산 서버 네트워크를 사용하여 사용자와 출처 서버의 근접성 문제를 해결합니다. 이러한 서버를 에지 서버라고 합니다.
CDN 제공업체는 에지 서버 외에도 다음과 같은 이점을 제공할 수 있습니다.
- CDN 제공업체는 일반적으로 매우 빠른 DNS 확인 시간을 제공합니다.
- CDN은 HTTP/2 또는 HTTP/3과 같은 최신 프로토콜을 사용하여 에지 서버에서 콘텐츠를 제공할 가능성이 높습니다.
- 특히 HTTP/3은 UDP 프로토콜을 사용하여 HTTP/2에서 사용하는 TCP에 있는 선두 차단 문제를 해결합니다.
- CDN은 최신 버전의 TLS도 제공할 수 있으므로 TLS 협상 시간과 관련된 지연 시간이 줄어듭니다. 특히 TLS 1.3은 TLS 협상을 최대한 짧게 유지하도록 설계되었습니다.
- 일부 CDN 제공업체는 Service Worker API와 유사한 API를 사용하여 요청을 가로채거나, 에지 캐시에서 응답을 프로그래매틱 방식으로 관리하거나, 응답을 완전히 재작성하는 '에지 워커'라고 하는 기능을 제공합니다.
- CDN 제공업체는 압축에 매우 능숙합니다. 압축은 직접 실행하기가 쉽지 않으며, 동적으로 생성된 마크업을 실시간으로 압축해야 하는 특정 경우에는 응답 속도가 느려질 수 있습니다.
- 또한 CDN 제공업체는 정적 리소스의 압축된 응답을 자동으로 캐시하므로 압축 비율과 응답 시간을 최적으로 조합할 수 있습니다.
CDN을 채택하는 데는 경미한 수준에서 상당한 수준에 이르기까지 다양한 노력이 필요하지만, 웹사이트에서 아직 CDN을 사용하고 있지 않다면 TTFB 최적화를 우선적으로 고려해야 합니다.
가능한 경우 캐시된 콘텐츠 사용
CDN을 사용하면 콘텐츠가 적절한 Cache-ControlHTTP 헤더로 구성된 경우 방문자에게 물리적으로 더 가까운 에지 서버에 콘텐츠를 캐시할 수 있습니다. 이는 맞춤설정된 콘텐츠에는 적합하지 않지만 출처까지 다시 이동해야 하므로 CDN의 가치가 대부분 상실될 수 있습니다.
콘텐츠를 자주 업데이트하는 사이트의 경우 캐시 시간이 짧아도 사이트가 붐비는 경우 눈에 띄게 성능이 향상될 수 있습니다. 이 기간 동안 첫 번째 방문자만 출처 서버로 돌아가는 전체 지연 시간을 경험하는 반면, 다른 모든 방문자는 에지 서버의 캐시된 리소스를 재사용할 수 있기 때문입니다. 일부 CDN에서는 사이트 출시 시 캐시 무효화를 허용하여 캐시 시간이 길지만 필요할 때 즉시 업데이트되는 등 두 가지 장점을 모두 누릴 수 있습니다.
캐싱이 올바르게 구성된 경우에도 애널리틱스 측정에 고유한 쿼리 문자열 매개변수를 사용하여 무시할 수 있습니다. 동일한 콘텐츠이지만 CDN에는 다른 콘텐츠로 보일 수 있으므로 캐시된 버전이 사용되지 않습니다.
오래되었거나 방문 빈도가 낮은 콘텐츠는 캐시되지 않을 수 있으며, 이로 인해 일부 페이지의 TTFB 값이 다른 페이지보다 높을 수 있습니다. 캐시 시간을 늘리면 이러한 영향을 줄일 수 있지만, 캐시 시간이 늘어날수록 오래된 콘텐츠가 게재될 가능성이 커집니다.
캐시된 콘텐츠의 영향은 CDN을 사용하는 사용자에게만 영향을 미치지 않습니다. 캐시된 콘텐츠를 재사용할 수 없는 경우 서버 인프라는 비용이 많이 드는 데이터베이스 조회로부터 콘텐츠를 생성해야 할 수 있습니다. 자주 액세스하는 데이터나 미리 캐시된 페이지는 실적이 더 우수할 수 있습니다.
페이지를 여러 차례 리디렉션하지 않기
TTFB가 높아지는 일반적인 원인 중 하나는 리디렉션입니다. 리디렉션은 문서의 탐색 요청이 브라우저에 리소스가 다른 위치에 있음을 알리는 응답을 수신할 때 발생합니다. 리디렉션 하나가 탐색 요청에 원치 않는 지연 시간을 추가할 수 있지만, 리디렉션이 다른 리소스를 가리켜 다른 리디렉션을 유발하는 경우 더욱 악화될 수 있습니다. 이는 측정 목적으로 분석 서비스를 통해 리디렉션되는 경우가 많으므로 광고 또는 뉴스레터에서 많은 방문자를 받는 사이트에 특히 영향을 미칠 수 있습니다. 직접 관리하는 리디렉션을 제거하면 TTFB를 개선하는 데 도움이 될 수 있습니다.
리디렉션에는 두 가지 유형이 있습니다.
- 동일 출처 리디렉션: 리디렉션이 웹사이트에서 완전히 발생합니다.
- 교차 출처 리디렉션: 리디렉션이 웹사이트에 도착하기 전에 소셜 미디어 URL 축소 서비스와 같이 다른 출처에서 처음 발생합니다.
동일 출처 리디렉션을 제거하는 데 중점을 두어야 합니다. 이 부분은 직접 제어할 수 있기 때문입니다. 이를 위해서는 웹사이트의 링크를 확인하여 302 또는 301 응답 코드가 발생하는지 확인해야 합니다. 이는 https:// 스키마를 포함하지 않았기 때문에 (따라서 브라우저가 기본적으로 http://로 설정되어 리디렉션됨) 또는 후행 슬래시가 URL에 적절하게 포함되거나 제외되지 않았기 때문에 발생할 수 있습니다.
교차 출처 리디렉션은 종종 관리할 수 없으므로 더 까다롭지만 가능하면 여러 리디렉션을 피하세요. 예를 들어 링크를 공유할 때 여러 링크 단축 도구를 사용하는 것이 좋습니다. 광고주 또는 뉴스레터에 제공된 URL이 올바른 최종 URL인지 확인하여 이러한 서비스에서 사용하는 리디렉션에 다른 리디렉션을 추가하지 않도록 합니다.
리디렉션 시간의 또 다른 중요한 원인은 HTTP-HTTPS 리디렉션일 수 있습니다. 이 문제를 해결하는 한 가지 방법은 Strict-Transport-Security 헤더 (HSTS)를 사용하는 것입니다. 이 헤더는 출처를 처음 방문할 때 HTTPS를 적용한 후 향후 방문 시 브라우저에 HTTPS 스킴을 통해 출처에 즉시 액세스하도록 지시합니다.
적절한 HSTS 정책을 마련한 후 사이트를 HSTS 미리 로드 목록에 추가하여 출처를 처음 방문할 때 속도를 높일 수 있습니다.
브라우저에 마크업 스트리밍
브라우저는 마크업이 스트리밍될 때 효율적으로 처리되도록 최적화되어 있습니다. 즉, 마크업은 서버에서 도착할 때 청크 단위로 처리됩니다. 이는 대용량 마크업 페이로드가 우려되는 경우 매우 중요합니다. 전체 응답이 도착하기를 기다렸다가 파싱을 시작하는 대신 브라우저가 마크업 청크를 점진적으로 파싱할 수 있기 때문입니다.
브라우저는 스트리밍 마크업을 처리하는 데 능숙하지만, 초기 마크업 비트가 최대한 빨리 전송되도록 스트림을 계속 전송하기 위해 최선을 다하는 것이 중요합니다. 백엔드에서 지연이 발생하면 문제가 있는 것입니다. 백엔드 스택은 다양하므로 모든 스택과 각 스택에서 발생할 수 있는 문제를 이 가이드에서 다루는 것은 불가능합니다.
예를 들어 React 및 서버에서 주문형으로 마크업을 렌더링할 수 있는 다른 프레임워크는 서버 측 렌더링에 동기식 접근 방식을 사용했습니다. 그러나 최신 버전의 React에서는 렌더링 중에 마크업 스트리밍을 위한 서버 메서드를 구현했습니다. 즉, React 서버 API 메서드가 전체 응답을 렌더링할 때까지 기다리지 않고 전송할 수 있습니다.
마크업이 브라우저로 빠르게 스트리밍되도록 하는 또 다른 방법은 빌드 시간에 HTML 파일을 생성하는 정적 렌더링을 사용하는 것입니다. 전체 파일을 즉시 사용할 수 있으므로 웹 서버는 파일 전송을 즉시 시작할 수 있으며 HTTP의 고유한 특성으로 인해 마크업을 스트리밍하게 됩니다. 이 접근 방식은 사용자 환경의 일부로 동적 응답이 필요한 페이지와 같이 모든 웹사이트의 모든 페이지에 적합하지는 않지만, 마크업을 특정 사용자에게 맞춤설정할 필요가 없는 페이지에는 유용할 수 있습니다.
서비스 워커 사용
Service Worker API는 문서와 문서에서 로드하는 리소스의 TTFB에 큰 영향을 미칠 수 있습니다. 이는 서비스 워커가 브라우저와 서버 간의 프록시 역할을 하기 때문입니다. 하지만 웹사이트의 TTFB에 영향을 미치는지 여부는 서비스 워커를 설정하는 방법과 설정이 애플리케이션 요구사항에 부합하는지에 따라 다릅니다.
- 애셋에 비활성 상태에서 재검증 전략을 사용합니다. 애셋이 서비스 워커 캐시에 있는 경우(문서 또는 문서에 필요한 리소스) 비활성 상태에서 재검증 전략은 먼저 캐시에서 해당 리소스를 제공한 다음 백그라운드에서 해당 애셋을 다운로드하고 향후 상호작용을 위해 캐시에서 제공합니다.
- 자주 변경되지 않는 문서 리소스가 있는 경우 비활성 상태에서 재검증 전략을 사용하면 페이지의 TTFB가 거의 즉시 실행될 수 있습니다. 하지만 웹사이트에서 동적으로 생성된 마크업(예: 사용자가 인증되었는지에 따라 변경되는 마크업)을 전송하는 경우에는 이 방법이 잘 작동하지 않습니다. 이러한 경우 문서가 최대한 최신 상태가 되도록 항상 먼저 네트워크를 호출해야 합니다.
- 문서에서 주기적으로 변경되지만 비중요 리소스를 로드하는 경우, 비중요 리소스를 가져와도 사용자 환경에 큰 영향을 미치지 않는 경우(예: 일부 이미지 또는 중요하지 않은 기타 리소스) 비활성 리소스 재검증 전략을 사용하여 이러한 리소스의 TTFB를 크게 줄일 수 있습니다.
- 클라이언트 렌더링 애플리케이션에는 앱 셸 모델을 사용합니다. 이 모델은 페이지의 '셸'이 서비스 워커 캐시에서 즉시 전송될 수 있고 페이지의 동적 콘텐츠가 페이지 수명 주기 후반에 채워지고 렌더링되는 SPA에 가장 적합합니다.
렌더링에 중요한 리소스에 103 Early Hints 사용
애플리케이션 백엔드가 얼마나 최적화되어 있든 관계없이 서버가 응답을 준비하기 위해 해야 할 작업이 상당할 수 있습니다. 여기에는 탐색 응답이 최대한 빨리 도착하지 못하도록 지연시키는 비용이 많이 들지만 필요한 데이터베이스 작업이 포함됩니다. 이로 인해 CSS 또는 경우에 따라 클라이언트에서 마크업을 렌더링하는 JavaScript와 같이 후속 렌더링에 중요한 일부 리소스가 지연될 수 있습니다.
103 Early Hints 헤더는 백엔드에서 마크업을 준비하는 동안 서버가 브라우저로 보낼 수 있는 초기 응답 코드입니다. 이 헤더는 마크업이 준비되는 동안 페이지에서 다운로드를 시작해야 하는 렌더링에 중요한 리소스가 있음을 브라우저에 힌트하는 데 사용할 수 있습니다. 지원되는 브라우저의 경우 문서 렌더링 (CSS)이 더 빨라지고 핵심 페이지 기능 (JavaScript)을 더 빨리 사용할 수 있습니다.
결론
백엔드 애플리케이션 스택의 조합이 너무 많기 때문에 웹사이트의 TTFB를 줄이기 위해 할 수 있는 모든 것을 요약한 도움말은 없습니다. 다음은 서버 측에서 작업을 조금 더 빠르게 처리하기 위해 살펴볼 수 있는 몇 가지 옵션입니다.
모든 측정항목을 최적화할 때와 마찬가지로 접근 방식은 대체로 비슷합니다. 현장에서 TTFB를 측정하고 실험실 도구를 사용하여 원인을 드릴다운한 후 가능한 경우 최적화를 적용합니다. 여기에 나와 있는 모든 기법이 상황에 적합한 것은 아니지만, 일부 기법은 적합할 수 있습니다. 항상 그렇듯이 현장 데이터를 면밀히 모니터링하고 필요에 따라 조정하여 최대한 빠른 사용자 환경을 제공해야 합니다.
Unsplash에서 제공한 테일러 빅의 히어로 이미지