design

첫 바이트까지의 시간 : 그것이 무엇이며 중요한 이유

조회 482 (작성일 2019.08.20 21:13)
- 음성
- 목록

저는 현재 고객 프로젝트를 진행하고 있으며 전자 상거래 사이트이기 때문에 많은 관심을 가지고 있습니다. 로드 시간이 좋은 시작이며 렌더링을 시작하는 것이 중요합니다 정보를 빠르게 보고자 하는 고객 (힌트 : 그게 다)과 주요 제품 이미지가 얼마나 빨리 로드 되는지와 같은 클라이언트 별 메트릭? 모두 귀중한 통찰력을 제공 할 수 있습니다.

https://csswizardry.com/2019/08/time-to-first-byte-what-it-is-and-why-it-matters/

그러나 프론트 엔드 개발자가 너무 빨리 간과하는 한 가지 지표는 TTFB (Time to First Byte)입니다. 이것은 TTFB가 백엔드 영역으로 이동하기 시작한다고 생각할 때 이해할 수 있으며 거의 용서할 수 있지만 가능한 한 간결하게 문제를 요약한다면

좋은 TTFB가 반드시 빠른 웹 사이트를 갖게 된다는 의미는 아니지만 나쁜 TTFB는 확실히 느린 웹 사이트를 보장합니다.

프론트 엔드 개발자로서 TTFB를 직접 개선 할 수 있는 위치에 있지 않을 수도 있지만, TTFB가 높으면 문제가 발생할 수 있으며, 최적화를 위한 노력이 필요하다는 것을 알아야 합니다. 이미지, 중요 경로를 지우고 비동기식으로로드하는 웹 글꼴은 모두 캐치 업의 정신으로 만들어집니다. 더 많은 프론트 엔드 최적화는 잊어 버려야 하지만, 불행히도 말이 꺾인 후 안정된 문을 닫는 공기가 있습니다. TTFB 버그를 최대한 빨리 해결하려고 합니다.

TTFB 란 무엇입니까?

TTFB 타이밍 항목은 특히 통찰력이 없습니다. 전체 크기 / 품질보기 (375KB)

TTFB는 가장 불투명하게 불투명합니다. 그것은 우리가 종종 그저 광택을 내는 경향이 있다고 생각하는 많은 다른 것들로 구성되어 있습니다. 많은 사람들이 TTFB가 서버에서 보내는 시간 일 뿐이라고 생각하지만 이는 실제 범위의 작은 부분 일 뿐입니다.

사람들이 가장 먼저 배우고 싶은 가장 놀라운 점은 TTFB가 한 번의 전체 지연 시간을 계산한다는 것입니다. TTFB는 서버에서 보내는 시간 뿐만 아니라 장치에서 서버로 이동하여 다시 전송하는 데 걸리는 시간이기도 합니다 (즉, 데이터의 첫 바이트).

이러한 지식을 바탕으로 TTFB가 모바일에서 그토록 급격히 증가하는 이유를 곧 이해할 수 있습니다. 확실히, 당신은 이전에 서버가 모바일 장치를 사용하고 있다는 것을 전혀 알지 못했습니다. 어떻게 TTFB를 증가 시킬 수 있습니까?! 그 이유는 모바일 네트워크가 일반적으로 대기 시간이 길기 때문입니다. 휴대 전화에서 서버로 왕복 하는 왕복 시간 (RTT)이 예를 들어 250ms 인 경우 TTFB가 즉시 증가합니다.

이 게시물에서 관심을 가져야 할 핵심 사항이 있는 경우 TTFB가 대기 시간의 영향을 받는 것입니다.

그러나 TTFB는 무엇입니까? 자신을 결박; 다음은 특별한 순서 없이 제시된 목록입니다.

Latency : 위와 같이 서버로의 출장 및 귀국을 계산합니다. 런던의 장치에서 뉴욕의 서버로의 여행에는 이론적으로 광섬유보다 28ms의 최고 속도가 있지만 이는 매우 낙관적인 가정을 많이 합니다.

75ms에 더 가깝습니다.

이것이 CDN에서 컨텐츠를 제공하는 것이 매우 중요한 이유입니다. 인터넷 시대에도 고객과 지리적으로 더 가까운 것이 유리합니다.

Routing: CDN을 사용하고 있어야만 한다면! Leeds의 고객은 요청한 리소스가 해당 PoP의 캐시에 없는 것만 찾기 위해 MAN 데이터 센터로 라우팅 될 수 있습니다. 따라서 그들은 원래 서버로 다시 연결되어 서버에서 검색됩니다. 당신의 기원이 버지니아에 있다면, 그것은 TTFB의 크고 눈에 띄게 증가 할 것입니다.
Filesystem reads : 파일 시스템에서 이미지 나 sylesheet와 같은 정적 파일을 읽는 서버는 비용이 많이 듭니다. 모든 것이 TTFB에 추가됩니다.
Prioritisation: HTTP / 2에는 (재) 우선 순위 화 메커니즘이 있어 서버에서 우선 순위가 낮은 응답을 중단하고 우선 순위가 높은 응답을 유선으로 보낼 수 있습니다. H / 2가 원활하게 실행되는 경우에도 H / 2 우선 순위 문제는 제외하고 이러한 예상 지연은 TTFB에 영향을 줍니다.
Application runtime: 실제로는 분명하지만 실제 응용 프로그램 코드를 실행하는 데 걸리는 시간은 TTFB에 크게 기여할 것입니다.
Database queries : 데이터베이스에서 데이터가 필요한 페이지는 데이터베이스를 검색 할 때 비용이 발생합니다. 더 많은 TTFB.
API calls : 페이지를 채우기 위해 API (내부 또는 기타)를 호출해야 하는 경우 오버 헤드가 TTFB에서 계산됩니다.
Server-Side Rendering : 페이지를 서버 렌더링 하는 데 드는 비용은 사소 할 수 있지만 여전히 TTFB에 기여합니다.
Cheap hosting : 비용 대비 성능에 최적화 된 호스팅은 일반적으로 다른 웹 사이트와 서버를 공유한다는 것을 의미하므로 서버 성능이 저하되어 요청 수행 능력에 영향을 줄 수 있거나 단순히 하드웨어가 응용 프로그램을 실행하려고 할 수도 있습니다.
DDoS or heavy load : 이전 시점과 유사하게, 애플리케이션을 자동 확장하지 않고 로드를 늘리면 인프라의 한계를 조사하기 시작하는 성능이 저하됩니다.
WAFs and load balancers : 응용 프로그램 앞에 있는 웹 응용 프로그램 방화벽 또는 로드 밸런서와 같은 서비스도 TTFB에 기여합니다.
CDN features : CDN은 큰 순이익이지만, 특정 시나리오에서는 해당 기능으로 인해 추가 TTFB가 발생할 수 있습니다. 예를 들어, 요청 축소, 가장자리 포함 등).
Last-mile latency : 런던에 있는 컴퓨터가 뉴욕의 서버를 방문한다고 생각할 때, 우리는 그 여행을 상당히 단순화 시켜서 그 두 가지가 직접 연결되어 있다고 거의 상상합니다. 실제로는 자체 라우터에서 ISP에 이르기까지 훨씬 더 복잡한 중개자가 있습니다. 셀 타워에서 해저 케이블까지. 마지막 마일 대기 시간은 연결의 종단에 대한 불균형 한 복잡성을 처리합니다.

TMSB가 0ms 인 것은 불가능하므로 위의 목록에 반드시 TTFB가 나쁘거나 속도가 느려지는 것은 아닙니다. 오히려, TTFB는 위에 제시된 여러 항목을 나타냅니다. 여기서 목표는 스택의 특정 부분을 손가락으로 가리 키지 않고 TTFB가 정확히 수반 할 수 있는 것을 이해하도록 돕는 것입니다. TTFB 단계에서 잠재적으로 많은 일이 벌어지면서 웹 사이트가 전혀 로드 되지 않는 것은 거의 기적입니다!

TTFB 이해하기

고맙게도 더 이상 불분명하지는 않습니다! 서버 타이밍 API를 구현하는 데 약간의 추가 작업을 함으로써 복잡한 타이밍을 프런트 엔드에 측정하고 표시 할 수 있으므로 웹 개발자는 이전에 시야에서 가려 졌던 잠재적 병목 현상을 식별하고 디버깅 할 수 있습니다.

서버 타이밍 API를 통해 개발자는 응용 프로그램 자체에서 측정 한 타이밍 정보가 포함 된 추가 서버 타이밍 HTTP 헤더를 사용하여 응답을 보강 할 수 있습니다.

작년 BBC iPlayer에서 우리가 한 일입니다.