WordPress 페이지 로드 시간을 개선하기 위해 TTFB를 줄이는 방법

WordPress 사이트의 전체 속도와 관련하여 우리는 페이지 로드 속도를 개선하기 위해 프런트 엔드 성능과 최적화에 집중하는 경우가 많습니다. 그러나 때로는 웹 사이트가 원래 로드를 시작하는 서버 측에서 보는 것이 좋습니다. 오늘 우리는 TTFB(첫 번째 바이트까지의 시간)가 귀하에게 미치는 영향에 대해 자세히 알아보고 이를 줄이는 방법에 대한 몇 가지 쉬운 방법에 대해 논의할 것입니다. TTFB는 일반적으로 간과되는 성능 요소이지만 사이트 속도를 테스트할 때 고려해야 합니다.

• TTFB는 무엇입니까?
• TTFB가 중요합니까?
• TTFB를 측정하는 방법
• WordPress 사이트에서 TTFB를 줄이는 4가지 방법

TTFB는 무엇입니까?

TTFB는 첫 번째 바이트까지의 시간을 나타냅니다. 간단히 말해서 브라우저가 서버에서 데이터의 첫 번째 바이트를 수신하기 전에 기다려야 하는 시간을 측정한 것입니다. 해당 데이터를 가져오는 데 시간이 오래 걸릴수록 페이지를 표시하는 데 더 오래 걸립니다. 일반적인 오해는 이것이 DNS 조회 시간 후에 계산된다는 것입니다. 그러나 네트워킹에서 TTFB의 원래 계산 에는 항상 네트워크 대기 시간이 포함됩니다 . 여기에는 3단계 프로세스가 포함되며 그 사이 어디에서나 지연과 지연이 발생할 수 있어 총 TTFB가 됩니다.

1. 서버에 요청

누군가 귀하의 웹사이트를 방문하면 가장 먼저 HTTP 요청이 클라이언트(브라우저)에서 서버로 전송됩니다. 이 단계에서는 지연을 유발할 수 있는 다양한 요인이 있습니다. 느린 DNS 조회 시간 으로 인해 요청 시간이 늘어날 수 있습니다. 서버가 지리적으로 멀리 떨어져 있는 경우 데이터가 이동해야 하는 거리에 대기 시간 이 발생할 수 있습니다. 또한 복잡한 방화벽 규칙이 있는 경우 라우팅 시간이 늘어날 수 있습니다. 그리고 클라이언트의 인터넷 속도를 잊지 마십시오.

2. 서버 처리

요청이 전송된 후 서버는 이제 이를 처리하고 응답을 생성해야 합니다. 이로 인해 느린 데이터베이스 호출 , 너무 많은 타사 스크립트, 첫 번째 응답을 캐싱하지 않음 , 잘못 최적화된 코드 또는 WordPress 테마, 디스크 I/O 또는 메모리와 같은 비효율적인 서버 리소스 와 같은 다양한 지연이 발생할 수 있습니다.

3. 고객 응대

서버가 요청을 처리한 후 클라이언트로 다시 보내야 합니다(또는 오히려 첫 번째 바이트를 다시 보내야 함). 이것은 서버와 클라이언트의 네트워크 속도에 크게 영향을 받습니다. 클라이언트가 Wi-Fi 핫스팟에서 인터넷 속도가 느린 경우 TTFB에 반영됩니다.

TTFB가 중요합니까?

TTFB(첫 번째 바이트까지의 시간)가 웹사이트 속도와 같지 않다는 것을 이해하는 것이 중요합니다. 이것은 실제로 응답성의 측정입니다. TTFB가 중요한지 아닌지에 대해 웹에서 많은 토론이 있습니다. 어떤 이는 의미가 없다고 말하고(Cloudflare, LittleBizzy) 다른 사람들은 중요하다고 말합니다(Ilya Grigorik, Google 웹 성능 엔지니어). 양측은 왜 또는 왜 그것이 중요하지 않은지에 대한 몇 가지 유효한 요점과 실제로 어떻게 계산되는지에 대한 몇 가지 질문을 제기합니다.

Moz는 검색 순위와 첫 번째 바이트까지의 시간 간의 상관 관계에 대해 심층 연구도 했습니다. 그러나 이것이 원인인지 또는 TTFB가 낮은 사이트가 단순히 일반적으로 더 빠르며 Google의 페이지 속도 순위 요소의 영향을 받을 수 있는지 알기 어렵습니다.

그러나 중요한지 여부에 대해 시간을 허비하기보다는 이 지표를 개선하기 위해 수행할 수 있는 최적화에 중점을 둡니다. 당신이 하는 모든 것이 워드프레스 사이트의 전체 속도에 기여할 수 있으며, 이는 차례로 TTFB에 영향을 미칩니다. 훨씬 더 큰 TTFB가 있는 테스트 사이트에서 단순히 로드하고 느리게 느껴집니다.

일반적으로 100ms 미만이면 훌륭하고 좋은 TTFB 입니다. Google PageSpeed ​​Insights는 서버 응답 시간을 200ms 미만으로 권장합니다. 300-500ms 범위에 있는 경우 이는 매우 표준적입니다. 그리고 600ms가 넘는다면 서버에 잘못된 구성이 있거나 더 나은 웹 스택으로 업그레이드해야 할 때일 수 있습니다. 또는 TTFB를 줄이는 방법에 대한 아래 권장 사항을 따르십시오. SSL/TLS 협상도 요인이 될 수 있음을 기억하십시오.

TTFB를 측정하는 방법

TTFB를 테스트할 수 있는 다양한 방법이 있습니다. 아래에서 몇 가지를 살펴보겠습니다. 그러나 모든 도구는 약간 다른 결과를 제공하므로 단순히 하나를 사용하고 기준선으로 유지하는 것이 중요하다는 것을 기억하십시오.

Google Chrome DevTools로 TTFB 측정

DevTools를 실행하여 Chrome에서 TTFB를 측정할 수 있습니다. 그러나 컴퓨터에서 테스트하는 경우 TTFB가 네트워크 대기 시간과 인터넷 연결의 영향을 받는다는 점을 기억하십시오. 따라서 데이터 센터에서 테스트 중인 타사 도구(아래 추가 참조)를 사용하는 것이 더 효과적일 수 있습니다.

• Chrome 메뉴에서 추가 도구 > 개발자 도구를 선택합니다.
• 페이지 요소를 마우스 오른쪽 버튼으로 클릭하고 검사를 선택합니다.
• 키보드 단축키 Ctrl + Shift + I (Windows) 또는 Cmd + Opt + I (Mac) 사용

네트워크 창을 실행하고 사이트의 성능을 볼 수 있습니다.

Geekflare의 도구로 TTFB 측정

Geekflare에는 웹사이트에서 테스트하고 문제를 해결하는 데 사용할 수 있는 멋진 무료 도구 모음이 있습니다. Geekflare의 TTFB 도구는 간단하고 빠르며 전 세계 세 곳에서 첫 번째 바이트까지의 시간이 얼마나 빠른지(낮은) 확인할 수 있습니다.

WebPageTest로 TTFB 측정

WebPageTest로 TTFB를 측정할 수도 있습니다. 용어집에 따르면 목표 시간은 DNS, 소켓 및 SSL 협상에 필요한 시간 + 100ms입니다. 목표를 초과하는 100ms마다 단일 문자 등급이 차감됩니다. 아래 테스트에서 볼 수 있듯이 이 사이트는 0.256초 또는 256ms TTFB에서 측정되었습니다.

Pingdom으로 TTFB 측정

Chrome 및 WebPageTest에서는 이를 TTFB라고 합니다. 그러나 Pingdom을 사용하는 경우 실제로는 "대기" 시간이라고 합니다. Pingdom 사용 방법에 대한 심층 가이드도 확인하십시오.

GTmetrix로 TTFB 측정

GTmetrix에서는 Pingdom과 마찬가지로 TTFB를 대기 시간이라고 합니다. GTmetrix 사용 방법에 대한 심층 가이드도 확인하십시오.

KeyCDN의 도구로 TTFB 측정

KeyCDN에는 14개의 다른 위치에서 동시에 TTFB를 측정할 수 있는 훌륭한 웹 성능 테스트 도구가 있습니다. 아래 테스트에서 볼 수 있듯이 TTFB는 미국에서 낮고 해외에서는 훨씬 높습니다. 이는 우리 서버가 물리적으로 미국에 있기 때문입니다. 이것은 대기 시간과 거리가 TTFB에 영향을 미친다는 증거입니다.

Sucuri Performance Tool 및 ByteCheck와 같이 TTFB를 측정하는 다른 다양한 도구도 있습니다. 알고 계셨나요? Google Analytics에도 평균 응답 시간을 볼 수 있는 섹션이 있습니다. "행동 > 사이트 속도 > 개요"를 클릭하기만 하면 됩니다.

WordPress 사이트에서 TTFB를 줄이는 4가지 방법

이제 WordPress 사이트에서 TTFB를 줄이는 방법에 대해 알아보겠습니다.

1. 빠른 WordPress 호스트 활용

TTFB를 줄이는 첫 번째 방법은 빠른 WordPress 호스트를 사용하고 있는지 확인하는 것입니다. 타사 공유 호스트의 TTFB(애리조나주 피닉스에 위치)와 Kinsta의 TTFB(아이오와주 Council Bluffs에 위치)를 비교했습니다. 기본 Twenty Seventeen 테마가 실행되는 것과 똑같은 설정을 사용했습니다. Kinsta는 이제 29개의 Google Cloud Platform 위치를 모두 사용할 수 있으므로 WordPress 사이트를 방문자에게 더 가깝게 전략적으로 배치하는 것이 중요합니다.

Kinsta는 또한 모든 호스팅 계획에 Google Cloud Platform의 프리미엄 계층 네트워크 를 포함합니다. 다른 많은 호스팅 제공업체는 Google Cloud의 표준 계층 네트워크를 사용하므로 속도가 느려집니다.

공유 호스트 TTFB

모든 지역에서 평균 TTFB는 520ms였습니다 . 미국과 캐나다 전역에서 평균 TTFB는 240ms였습니다 .

킨스타 TTFB

모든 지역에서 평균 TTFB는 412ms였습니다 . 미국과 캐나다의 평균 TTFB는 164ms였습니다 . Kinsta로 호스팅하는 경우 유럽 또는 아시아에서 WordPress 사이트를 호스팅하도록 선택할 수도 있습니다. Google Cloud 데이터 센터 위치 목록을 참조하세요.

따라서 단순히 더 빠른 호스트를 사용함으로써 전 세계적으로 TTFB가 20% 감소 하는 것을 보았습니다. 미국과 캐나다 전역 에서 TTFB가 32% 감소했습니다 . 신중하게 고려한 아키텍처를 갖춘 우수한 WordPress 호스트를 보유하는 것은 TTFB를 낮추는 데 중요합니다. 이것은 또한 고객이 있는 지역에 물리적으로 위치한 장소를 신중하게 선택하는 좋은 사례가 됩니다. 대부분의 고객이 미국에 있는 경우 유럽에서 서버를 호스팅하지 마십시오(CDN이 그 중 일부를 무효화하는 데 도움이 될 수 있지만).

2. CDN 구현

TTFB를 줄이는 또 다른 쉬운 방법은 CDN(콘텐츠 전송 네트워크)을 활용하는 것입니다. 국가의 다른 지역 또는 전 세계에서 방문자에게 서비스를 제공하는 웹사이트가 있는 경우 TTFB를 크게 줄일 수 있습니다. 위에서 보았듯이 위치는 매우 중요합니다. 우리는 CDN 공급자인 KeyCDN과의 차이점을 보여주기 위해 약간의 테스트를 실행했습니다. 각 테스트는 5번 실행하고 평균을 취했습니다.

CDN 없는 TTFB

먼저 CDN을 비활성화한 상태에서 테스트를 실행했으며 총 로드 시간은 1.45초이고 자산의 평균 TTFB는 약 136ms였습니다.

CDN이 있는 TTFB

그런 다음 CDN을 활성화하고 테스트를 다시 실행했습니다. 보시다시피 총 로드 시간은 788ms로 떨어졌고 평균 TTFB는 이제 37ms입니다! CDN은 얼마나 큰 차이를 만들 수 있습니까? 주목해야 할 또 다른 중요한 점은 이 테스트를 수행하기 위해 스톡홀름 위치를 선택했다는 것입니다. 왜요? 물리적 거리를 줄임으로써 얻을 수 있는 진정한 향상을 보여주고 싶었기 때문입니다. 스톡홀름에 CDN POP이 있으므로 우리의 콘텐츠는 스톡홀름에서 제공됩니다.

참고: Cloudflare를 사용하는 경우 TTFB가 약간 높을 수 있습니다. 이는 전체 프록시 서비스를 실행하는 데 따른 추가 오버헤드와 복잡성 때문일 가능성이 큽니다. Cloudflare에는 일부 CDN 제공업체에 없는 추가 방화벽 및 기타 기능이 있습니다. 따라서 자신에게 더 도움이 될 수 있는 결정을 내려야 합니다. 전체 사이트가 제대로 최적화되지 않은 경우 약간 더 높은 TTFB에서 히트를 취하는 것이 절충의 가치가 있을 수 있습니다.

그러나 Cloudflare 페이지 캐싱을 사용하여 TTFB를 낮추는 방법에 대한 WP Bullet의 가이드를 확인하고 싶을 수도 있습니다. 이를 위해서는 몇 가지 추가 설정 및 테스트가 필요할 수 있습니다. 각 환경이 다르기 때문에 자체 테스트를 실행해야 합니다.

추천 자료: WordPress용 Cloudflare APO 설정 방법.

3. 워드프레스 캐싱

세 번째 방법이자 아마도 TTFB를 줄이는 가장 쉬운 방법 중 하나는 WordPress 사이트에서 캐싱을 활용하는 것입니다. 많은 사람들은 캐싱이 로드 시간을 줄이는 데 도움이 될 수 있다고 생각하지만 실제로는 서버 처리 시간을 줄이는 데 도움이 되므로 TTFB를 줄이는 데도 도움이 됩니다. 캐싱을 실행하거나 실행하지 않고 몇 가지 테스트를 다시 실행했습니다. 각 테스트는 5번 실행하고 평균을 취했습니다.

캐시 실행 없이

우리는 Pingdom을 통해 사이트를 실행했으며 캐시 실행 없이 사이트는 1.17초의 로드 시간과 560ms의 TTFB를 기록했습니다.

캐싱이 활성화된 경우

그런 다음 캐싱을 활성화하고 Pingdom을 통해 사이트를 다시 실행했습니다. 이번에 우리 사이트는 643ms의 로드 시간과 57ms의 TTFB를 기록했습니다.

따라서 캐싱을 활성화하여 TTFB를 무려 90%나 줄일 수 있었습니다! Kinsta의 캐싱에 대해 자세히 알아볼 수 있습니다. 캐싱 플러그인이 필요하지 않음을 의미하는 서버 수준에서 이 작업을 수행합니다. 관리형 WordPress 호스트를 사용하지 않는 경우 Cache Enabler와 같은 무료 캐싱 플러그인을 사용하는 것이 좋습니다.

4. 프리미엄 DNS 공급자 사용

마지막으로 DNS는 TTFB에서도 한 역할을 합니다. 얼마나 영향을 받았는지 정확히 계산하기는 어렵지만 전반적인 DNS 조회 시간을 볼 수 있으며 더 빠르고 느린 공급자가 있음을 알 수 있습니다. SolveDNS 속도 테스트 도구로 몇 가지 테스트를 실행했습니다. 다음은 NameCheap의 무료 DNS와 응답 시간을 사용하는 도메인의 예입니다.

무료 이름저렴한 DNS

그리고 아래는 Amazon Route 53의 프리미엄 DNS를 사용한 예시입니다. 일반적으로 볼 수 있듯이 DNS 조회 시간은 Amazon에서 훨씬 빠릅니다. 일반적으로 프리미엄 DNS 공급자는 더 나은 속도를 제공합니다. Cloudflare는 성능도 뛰어난 무료입니다.

아마존 루트 53 DNS

프리미엄 DNS 공급자를 사용해야 하는 이유에 대한 게시물을 확인하십시오. 여기 Kinsta에서 Amazon Route 53과 제휴했으며 모든 고객에게 무료로 제공됩니다.

요약

데이터베이스 캐싱, 디스크 IO, 스왑 사용량, RAM, PHP 설정, MySQL 설정, 네트워크 설정, TLS 오버헤드 등과 같이 TTFB를 줄이기 위해 최적화하거나 수정할 수 있는 다른 많은 것들이 있습니다. 그러나 위에서 언급한 것들은 상당히 구현하기 쉽고 가장 빠른 성능 향상을 제공합니다. 따라서 다음에 누군가 TTFB를 줄이는 방법을 묻는다면 빠른 WordPress 호스트, CDN, 캐싱 및 DNS가 모두 큰 역할을 한다는 것을 기억하십시오. 이러한 병목 현상을 수정하거나 개선하면 문제가 해결될 것입니다.

TTFB를 사용한 경험은 무엇입니까? 아래에서 이에 대해 듣고 싶습니다.