서버 응답 시간 외에 – 스매싱 잡지

귀하의 웹 사이트로드 HTML은 방문자 경험에 큰 영향을 미칩니다. 결국, HTML의 첫 번째 덩어리가로드 된 후에는 페이지 컨텐츠를 표시 할 수 없습니다. 그렇기 때문에 첫 바이트 (TTFB) 메트릭의 시간이 중요한 이유입니다. 탐색 후 얼마나 빨리 브라우저가 HTML 응답을 받기 시작하는지 측정합니다.

HTML 문서를 생성하면 TTFB 지연을 최소화하는 데 큰 역할을합니다. 그러나 실제로이 메트릭을 최적화하는 데 더 많은 것이 있습니다. 이 기사에서는 TTFB가 열악한 이유와이를 해결하기 위해 무엇을 할 수 있는지 살펴 보겠습니다.

어떤 구성 요소가 첫 바이트 메트릭에 시간을 차지합니까?

TTFB는 시간을 나타냅니다 에게 첫 바이트. 그러나 어디에서 측정합니까? ~에서?

다른 도구는 이것을 다르게 처리합니다. 일부는 HTTP 요청을 보내고 응답을받는 데 소요되는 시간 만 계산하여 리소스를로드하기 전에 먼저 발생하는 다른 모든 것을 무시합니다. 그러나 Google의 핵심 웹 생명을 살펴보면 TTFB는 사용자가 새 페이지로 탐색하기 시작하는 시점부터 시작합니다. 즉, TTFB는 다음을 포함합니다.

• 크로스 오리핀 리디렉션,
• 서버에 연결하는 데 소요되는 시간,
• 동일한 원산지 리디렉션 및
• HTML 문서의 실제 요청.

이 요청에서 폭포 시각화에서 이것의 예를 볼 수 있습니다.

여기서 서버 응답 시간은 183 밀리 초에 불과하거나 전체 TTFB 메트릭의 약 12%입니다. 시간의 절반은 대신 크로스 오리핀 리디렉션에 사용됩니다. 웹 사이트의 HTML 코드를 반환하는 요청을 만들기 전에 리디렉션 응답을 반환하는 별도의 HTTP 요청입니다. 그리고 우리가 그 요청을 할 때, 대부분의 시간은 서버 연결을 설정하는 데 소비됩니다.

웹에서 서버에 연결하는 것은 일반적으로 네트워크에서 3 번의 라운드 트립이 필요합니다.

1. DNS : 서버 IP 주소를 찾고 있습니다.
2. TCP : 서버에 대한 안정적인 연결을 설정합니다.
3. TLS : 안전한 암호화 된 연결을 만듭니다.

시간이 먼저 바이트에 맞는 네트워크 대기 시간이 의미합니다

위의 예에서 모든 네트워크 라운드 트립을 추가하겠습니다.

• 2 서버 연결 : 6 개의 라운드 트립.
• 2 HTTP 요청 : 2 라운드 트립.

그것은 우리가 우리 페이지의 첫 번째 응답 바이트를 얻기 전에 실제로 브라우저와 서버간에 데이터를 8 번 전송해야합니다!

이곳에서 네트워크 대기 시간이 들어오는 곳 또는 네트워크 왕복 시간 (RTT)이 서버로 보내고 브라우저에서 응답을받는 데 걸리는 시간을 보면 네트워크 왕복 시간 (RTT)입니다. 150 밀리 초의 RTT와의 높은 초기 연결에서 8 회의 여행을하는 데 1.2 초가 걸립니다. 따라서 서버가 항상 즉시 응답하더라도 해당 숫자보다 TTFB를 낮출 수 없습니다.

네트워크 대기 시간은 방문자의 장치와 브라우저가 연결하는 서버 사이의 지리적 거리에 크게 의존합니다. 웹 사이트에서 글로벌 TTFB 테스트를 실행하여 실제로 그 영향을 볼 수 있습니다. 여기서는 브라질에서 호스팅 된 웹 사이트를 테스트했습니다. 우리는 브라질과 미국 동해안에서 테스트 할 때 좋은 TTFB 점수를 얻습니다. 그러나 유럽, 아시아 또는 호주의 방문객들은 웹 사이트가로드 될 때까지 잠시 기다립니다.

컨텐츠 전달 네트워크가 시간이 먼저 바이트까지 의미하는 것

웹 사이트 속도를 높이는 한 가지 방법은 CDN (Content Delivery Network)을 사용하는 것입니다. 이 서비스는 전 세계적으로 분산 된 서버 위치 네트워크를 제공합니다. 웹 응용 프로그램이 호스팅되는 위치까지 각 왕복 여행 대신 브라우저는 근처의 CDN 서버 (에지 노드라고 함)에 연결합니다. 이는 서버 연결을 설정하는 데 소요되는 시간을 크게 줄여 전체 TTFB 메트릭을 향상시킵니다.

기본적으로 실제 HTML 요청은 여전히 ​​웹 앱으로 전송되어야합니다. 그러나 콘텐츠가 동적이지 않으면 CDN 에지 노드에서 응답을 캐시 할 수도 있습니다. 이렇게하면 요청은 전 세계적으로 이동하는 데이터 대신 CDN을 통해 전적으로 제공 될 수 있습니다.

CDN을 사용하는 웹 사이트에서 TTFB 테스트를 실행하면 각 서버 응답이 요청이있는 위치 근처의 지역 데이터 센터에서 나옵니다. 많은 경우에, 우리는 이미 에지 노드에서 캐시 된 응답 덕분에 200 밀리 초 미만의 TTFB를 얻습니다.

첫 바이트로의 시간을 개선하는 방법

웹 사이트의 TTFB 점수를 향상시키기 위해해야 ​​할 일은 가장 큰 기여 구성 요소가 무엇인지에 따라 다릅니다.

• 연결을 설정하는 데 많은 시간이 소요됩니다. 글로벌 CDN을 사용하십시오.
• 서버 응답은 느립니다. 응용 프로그램 코드를 최적화하십시오 또는 응답을 캐시하십시오
• 지연 TTFB를 리디렉션합니다. 체인 리디렉션을 피하십시오 그리고 서버를 최적화하십시오 리디렉션 응답을 반환합니다.

TTFB는 방문자가 웹 사이트에 액세스하는 방법에 따라 다릅니다. 예를 들어, 응용 프로그램에 로그인하면 캐시에서 페이지 컨텐츠를 제공 할 수 없습니다. 방문자가 클릭 추적 서버를 통해 리디렉션되므로 광고 캠페인을 실행할 때 TTFB의 스파이크가 표시 될 수도 있습니다.

실제 사용자 시간을 첫 바이트로 모니터링하십시오

웹 사이트의 다른 방문자에 대한 TTFB의 모습을 고장하려면 실제 사용자 모니터링이 필요합니다. 이렇게하면 방문자 위치, 로그인 상태 또는 참조 도메인이 실제 사용자 경험에 미치는 영향을 분류 할 수 있습니다.

DebugBear는 시간에 시간 동안 실제 사용자 지표를 수집하는 데 도움이 될 수 있습니다. TCP 지속 시간 또는 리디렉션 시간과 같은 개별 TTFB 구성 요소를 추적하고 국가, 광고 캠페인 등의 웹 사이트 성능을 분석 할 수 있습니다.

결론

웹 사이트의 첫 바이트를 방문자에게 제공하는 데 관련된 모든 것을 살펴보면 서버 응답 시간을 줄이는 것만으로는 충분하지 않으며 종종 웹 사이트에서 가장 영향력있는 변경 사항이 아님을 알았습니다.

웹 사이트가 한 위치에서 빠르다고해서 방문자가 귀하의 사이트에 액세스하는 위치에 따라 웹 사이트 속도가 다르기 때문에 모든 사람에게 빠르다는 의미는 아닙니다.

콘텐츠 전달 네트워크 TTFB를 개선하는 엄청나게 강력한 방법입니다. 고급 기능을 사용하지 않더라도 글로벌 서버 네트워크를 사용하면 서버 연결을 설정할 때 많은 시간이 절약됩니다.

(GG, YK)