웹사이트 속도 테스트: 웹 호스팅 제공업체의 속도를 올바르게 측정

게시 됨: 2017-04-21

웹사이트의 속도는 여러 가지를 나타낼 수 있으며 측정에는 일반적으로 모호성과 해석 오류가 내포되어 있습니다. 이 기사에서는 웹사이트 속도 측정의 몇 가지 혼란스러운 측면을 정리할 것입니다. 그러면 속도 측정 보고서를 해독하는 데 도움이 됩니다. 마지막으로 웹 호스팅 제공업체의 속도를 측정할 때 고려해야 할 메트릭을 분석합니다.

예제에서는 Pingdom의 웹사이트 속도 테스트 도구를 사용할 것입니다. Daereboost 및 WebPageTest와 같은 유사한 도구가 많이 있으며 보다 균형 잡힌 결과를 얻으려면 모든 도구를 사용해 볼 것을 권장합니다. GTMetrix와 Google의 Page Speed Insights도 있습니다. Google을 사용하면 Google 도구가 가진 권한이 있습니다. 단점은 웹사이트의 실제 응답 시간(밀리초)에 대한 정보를 얻을 수 없다는 것입니다. 따라서 정량적 결과를 원하는 경우 다른 도구를 확인해야 합니다.

하지만 속도 측정이 조금 어려운 것이 사실입니다. 먼저 몇 가지를 정리하겠습니다.

웹사이트 속도 측정은 …복잡합니다

온라인 웹사이트 속도 측정 도구의 보고서는 일반적으로 웹사이트 속도와 관련하여 압도적인 양의 정보를 제공합니다. 이것은 특히 이전에 사용하지 않은 경우 이해하기 어렵습니다. 먼저, 염두에 두어야 할 몇 가지 사항이 있습니다.

웹사이트 속도 보고서는 다양한 측정항목을 함께 결합하여 총 속도 표시를 제공합니다. 이것은 웹사이트가 얼마나 "빠른지"에 대한 전반적인 근사치를 제공합니다. 하지만 웹호스팅 제공업체의 속도를 평가해야 하는 경우 결과를 자세히 살펴봐야 합니다.
웹 사이트 속도 테스트를 한 번만 실행하면 실제 보기가 제공되지 않습니다. 최소한 10가지 다른 테스트(동일한 도구를 사용하고 동일한 지역에서)를 실행한 다음 그에 따라 결과를 나누어 평균을 계산해야 합니다.
온라인 웹 페이지 속도 도구는 일반적으로 공급자 또는 웹 사이트에서 사용할 수 있는 모든 캐싱 메커니즘을 우회합니다. 예를 들어 요청의 요청 헤더를 검사하면 캐싱을 비활성화하는 두 개의 HTTP 헤더가 나타납니다. 이를 위해 테스트를 수행하는 동안 항상 캐싱을 염두에 두어야 합니다.

웹 공급자 속도는 응용 프로그램 속도와 다릅니다!

웹 사이트 속도 테스트 도구는 일반적으로 동일한 항목을 테스트하고 유사한 유형의 데이터를 표시합니다. 이전에 언급했듯이 모든 데이터가 실제로 공급자의 속도를 나타내는 것은 아닙니다. 예를 들어 Youtube와 같은 타사 서버에서 검색된 자산은 공급자의 속도에 대해 아무 것도 알려주지 않습니다. 이는 콘텐츠가 귀하의 서버가 아닌 다른 서버에 있기 때문입니다.

마찬가지로 Javascript 및 CSS 코드 메트릭은 웹 페이지가 브라우저에서 렌더링되는 속도만 보여줍니다.

그러나 공급자의 속도를 반영하는 몇 가지 메트릭이 있습니다. 이것은 DNS, 웹 브라우저가 웹 페이지에 연결하여 결과를 얻는 데 걸리는 시간 및 기타 여러 측정항목입니다. 하나씩 봅시다!

웹 호스팅 제공업체 속도 측정항목

DNS 응답 시간

이 측정항목은 PingDom 도구로 측정한 대로 웹사이트의 네임서버가 브라우저에 IP 주소를 반환하는 데 걸리는 시간을 측정합니다. 일반적으로 300ms 미만의 값은 정상으로 간주됩니다.

이 메트릭에서 높은 값이 관찰되면 그 이유에 대한 문제 해결을 시작해야 할 수 있습니다. 궁극적으로 DNS 공급자를 변경하도록 선택할 수 있습니다. 물론 웹 호스팅 제공업체에서 DNS 레코드를 유지 관리하는 경우 DNS 메트릭을 고려해야 합니다.

연결 응답 시간

이 응답 시간은 브라우저가 웹사이트에 처음 연결하는 데 걸리는 시간을 측정합니다. 이것은 분명히 고려해야 할 지표입니다.

SSL

이전 스크린샷에서 HTTPS URL로의 리디렉션이 발생하는 것을 보았습니다(왼쪽 상단의 아이콘에서 볼 수 있음). Pingdom은 SSL 핸드셰이크가 발생하는 데 걸리는 시간을 측정합니다. SSL 핸드셰이크는 컴퓨팅 집약적인 작업입니다. 응답 시간은 일반적으로 사용되는 프로토콜, SSL 오프로딩과 같은 기술의 존재 여부 등과 같은 다양한 요인에 따라 달라집니다.

SSL 핸드셰이킹이 공급자에 의해 수행된 것이 확실한 경우에만 SSL 응답 시간을 고려해야 합니다. 확실하지 않은 경우 해당 측정항목을 생략하십시오.

Send 메트릭은 웹 브라우저가 서버에 요청을 보내는 데 걸리는 시간입니다. 이것은 방문자의 인터넷 연결에만 관련되며 귀하의 웹사이트나 호스팅 제공업체와는 관련이 없습니다. 따라서 해당 측정항목도 제외합니다.

대기/수신

이러한 응답 시간은 브라우저가 실제 웹 페이지를 수신하는 데 걸리는 시간을 나타냅니다. 대기 시간은 서버가 데이터 전송을 시작할 때까지 브라우저가 기다리는 시간입니다. 수신 시간은 서버가 실제로 해당 데이터를 브라우저로 보내는 데 걸리는 시간을 나타냅니다.

이 두 응답 시간은 모두 웹 서버와 관련이 있으므로 둘 다 고려해야 합니다.

정적 자산

웹 사이트에서 로컬로 제공되는 파일에 대한 응답 시간도 포함해야 합니다. 이를 정적 자산이라고 하며 일반적으로 이미지, CSS 파일 및 일반적으로 도메인에서 제공되는 모든 것입니다.

최신 웹 브라우저는 병렬 실행 스레드 및 기타 기술을 사용하여 리소스 다운로드를 가속화합니다. 예를 들어 100개의 요청이 있는 웹 사이트가 있는 경우 이 100개의 요청이 동시에 다운로드됩니다. Internet Explorer 10은 최대 8개의 병렬 연결을 사용하는 반면 Chrome은 6을 사용합니다. Firefox3 및 Safari 5도 6을 사용합니다. 이 값은 구성할 수 있지만 잘못 사용하면 컴퓨터가 쉽게 망가질 수 있으므로 그대로 두는 것이 좋습니다. 또한 HTTP/2는 이전 버전보다 더 우수한 패킷 스트리밍 관리 기능을 제공하기 때문에 다운로드 가속과 관련하여 상당한 도움이 됩니다.

마지막으로 Pingdom을 사용하면 지역 자산을 쉽게 식별할 수 있습니다. 필터 필드에 웹사이트 도메인을 입력하여 결과를 필터링하고 로컬 자산에 대한 요청을 표시할 수 있습니다.

로컬 자산(특히 이미지 및 비디오)을 가져올 때 상당한 지연이 있는 경우 CDN(콘텐츠 전송 네트워크) 사용을 고려하십시오.

Content Delivery Network를 사용하면 패킷 손실과 대기 시간을 최소화할 수 있습니다. CDN 서비스는 전 세계에 서버를 배치하여 콘텐츠를 방문자에게 최대한 가깝게 제공하여 대기 시간을 줄입니다.

닫는 중

웹사이트 속도 측정 도구는 측정하려는 대상에 따라 비판적으로 평가해야 하는 많은 정보를 제공합니다.

요약하면 웹 사이트 속도 테스트를 시작하기 전에 다음 사항을 염두에 두십시오.

웹 호스팅 속도와 측정 방식은 페이지 로드 속도와 완전히 다릅니다.
주목해야 할 주요 메트릭은 연결/대기/수신 응답 시간과 정적 자산의 메트릭입니다. DNS 및 SSL은 웹 호스팅 제공업체에서 관리하는 경우에만 고려됩니다.
Youtube와 같은 타사 서비스에서 가져온 콘텐츠와 관련된 모든 측정항목을 생략합니다.
테스트를 여러 번(최소 10회) 실행한 다음 결과를 테스트 수로 나누어 평균을 계산합니다.

응용 프로그램 및 페이지 렌더링 속도에 대한 주제는 또 다른 중요한 주제이므로 이에 대한 별도의 기사를 할애할 계획입니다. 또한 웹 호스팅 속도를 측정하는 것보다 훨씬 더 복잡합니다. 여러 요인에 따라 달라지고 꽤 많은 문제를 숨기기 때문입니다!