Google 웹 마스터 도구는 정확히 "사이트 성능"을 측정합니까?


27

몇 달 전에 독일에서 시작한 새로운 포럼 (기술적 인 관점에서 새로운 제품)에 대한 응답 시간 (주로 서버 측)을 개선하기 위해 2 개월 동안 노력하고 있습니다. 내가 얻은 결과에 많이 놀랐습니다. Apache 로그와 자체 Boomerang 비콘 구현을 사용하여 응답 시간을 모니터링합니다 .

내 통계를 사용하면 새 제품이 약 680ms 동안 반응하지만 이전 제품은 약 1050ms 안에 반응한다는 것을 알 수 있습니다. 반면에 Google 웹 마스터 도구는 3 개월 전에 이전 제품을 사용했을 때 현재 페이지의 평균 응답 시간이 약 1500ms 인 것으로 나타났습니다.

나는 GWT가 고객 측 메트릭을 고려하고 있다고 생각하여 Boomerang 비콘에 대한 측정을 추가했으며 모든 것이 잘 보입니다. 또한 ySlow 및 Google의 Page Speed에서 임의의 페이지를 실행했으며 모든 것이 이전보다 더 좋아 보입니다. Google의 페이지 속도 도구에 82 %의 이벤트가있어 일부 광고가 포함 된 사이트에는 매우 유용합니다. :)

최근 Akamai 와 정적 파일 (이전에 다른 CDN을 사용했지만 그다지 효과적이지 않음)을위한 CDN과 네트워크 경로를 개선하기위한 RMA라는 두 가지 제품을 사용하기 로 계약을 체결했습니다 . 또한 크롤러에 제공되는 대부분의 페이지가 memcache 그리드에 의해 캐시되도록하기 위해 새로운 공격적인 캐시 메커니즘을 도입했습니다. 내 측정 항목을 확인한 후이 변경 사항이 650ms에서 약 500ms로 개선 된 것 같습니다. 그러나 웹 마스터 도구는 계속해서 평균 응답 시간이 증가하는 것을보고합니다.

성능 향상을 수행하면서 사이트에서 동일한 종류의 이상한 동작을 경험 한 적이 있습니까? Google 웹 마스터 도구에서 Google의 사이트 실적과 동일한 기능을 모니터링하여 사이트를 개선하고 Google이 원하는 사이트인지 지속적으로 확인할 수있는 방법을 알고 있습니까?

2011/07/26 편집 : 답변 해 주셔서 감사합니다! 그럼에도 불구하고, 나는 충분히 정확하지 않았다. 현재 주요 문제는 사이트 실적 페이지가 아니라 크롤링 통계 관련 문제입니다. 우리는 아마도 매우 느린 페이지 (약 3000ms !!)와 관련하여 문제를 발견했으며 문제를 해결하려고합니다. 정보가 있으면 곧 게시하겠습니다. 다시 감사합니다!

답변:


17

공식 지침에 따라

http://www.google.com/support/webmasters/bin/answer.py?answer=158541

사이트 실적은 실험적인 웹 마스터 도구 실험실 기능으로 사이트에 대한 대기 시간 정보를 보여줍니다. 사이트 실적 데이터를 보려면 웹 마스터 도구에서 사이트를 추가하고 확인해야합니다.

페이지로드 시간은 사용자가 페이지에 대한 링크를 클릭 한 순간부터 전체 페이지가로드되어 브라우저에 표시 될 때까지의 총 시간입니다. Google 툴바를 설치하고 선택적 PageRank 기능을 활성화 한 사용자로부터 직접 수집됩니다.

사용자는 웹 페이지를 완전히 다운로드하기 전에 웹 페이지와 상호 작용할 수 있기 때문에 웹 사이트 속도를 매우 엄격하게 해석 합니다. 그러나 페이지에 많은 수의 동적 JavaScript 및 동적으로로드 된 광고가있는 경우 사용자가 페이지를 느리게로드하는 것으로 보는 것이 더 정확하기 때문에이 측정에 대해 매우 엄격한 것이 합리적입니다.

따라서이를 측정하는 방법은 Chrome 도구 (일명 ctrl+ shift+) 의 네트워크 탭을 사용하는 것 I입니다.

Chrome 도구의 네트워크 탭

두 가지 관련 이벤트는 DOMContent Event Fired(파란색 선)과 Load event fired(빨간색 선)입니다. 이 사이트의 임의 페이지에서 숫자는 각각 약 600ms와 1.1 초입니다. 이는 명령 줄에서 페이지를 다운로드하는 시간보다 훨씬 wget길며, 클라이언트 브라우저 가 HTTP를 통해 다운로드하는 콘텐츠를 렌더링하는 데 소비하는 시간을 분명히 반영합니다 .

(정적 페이지가 모두있는 웹 사이트는 특정 사용자에 대해 각 페이지를 동적으로 사용자 정의하는 웹 사이트보다 큰 이점을 얻을 것이기 때문에 나에게는 불공평 한 것처럼 보이지만 중단 점이라고 생각합니다!)


2
이 법안이 불공평하다는 데 동의합니다. 페이지의 고기가 거의 즉시로드 될 때 최신 Twitter 상태가 비동기식 및 눈에 띄게로드하는 데 얼마나 오래 걸리는지 Google에 잠재적으로 불이익을가합니다. 더 나쁜 것은, 모두가 싫어하는 복수 페이지 기사 형식을 장려하는 것 같습니다. 왜냐하면 거의 확실하게 더 빨리로드되기 때문입니다.
Dave Ward

1
Google이 광고를 판매하고 더 많은 페이지 요청이 더 많은 광고를 게재한다는 사실을 고려한다면 G $는 사이트가 여러 페이지 기사 형식을 사용하도록 장려하는 것이 좋습니다.
runxc1 Bret Ferrier

@dave Google은 사이트 실적이 실험적인 '실험실'기능이므로 분명히 순위 지정에 사용되는지 확실하지 않습니다.
Jeff Atwood

1
@Jeff, 나는 그들이 이후로 마음이 바뀌지 않는 한, 믿습니다 : googlewebmastercentral.blogspot.com/2010/04/…
Dave Ward

1
그렇다면 이것은 window.onload 이후에 실행되는 것이 페이지 로딩 시간에서 계산되지 않는다는 것을 의미합니까?
DisgruntledGoat
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.