Як саме інструменти для веб-майстрів Google вимірюють ефективність сайту?

Я вже два місяці працюю над вдосконаленням часу реагування (в основному на стороні сервера) на новому форумі (абсолютно новий продукт з технічної точки зору), який ми запустили в Німеччині кілька місяців тому, і я дуже здивований отриманими результатами. Я стежу за часом нашої реакції, використовуючи журнали Apache та власну реалізацію маяка Boomerang .

Використовуючи мою статистику, я бачу, що наш новий продукт відповідає приблизно за 680 мс, коли наш старий продукт відповідав приблизно 1050 мс. З іншого боку, Інструмент Google для веб-майстрів повідомляє нам, що сьогодні на наших сторінках середній час відгуку становить близько 1500 мс, де було 700 місяців тому з нашим старим продуктом.

Я зрозумів, що GWT враховує показники на стороні клієнта, тому я додав деякі заходи щодо нашого маяка Boomerang, і все виглядає просто чудово. Я також провів кілька випадкових сторінок на ySlow та Google Speed ​​Page, і все виглядає краще, ніж було раніше. У нас на інструменті «Швидкість сторінки Google» 82%, що досить цікаво для сайту, в якому розміщено рекламу :)

Останнім часом ми підписали угоду з Akamai про використання двох своїх продуктів: CDN для наших статичних файлів (раніше ми використовували інший CDN, але це було не дуже ефективно) та RMA для поліпшення маршрутів мереж. Ми також запровадили новий агресивний механізм кешування, щоб гарантувати, що більшість сторінок, які обслуговуються сканерам, кешуються нашою сіткою пам'яті. Перевіривши мої показники, здається, що ці зміни покращилися з 650 до приблизно 500 мс, що добре (все-таки не велике, але це, безумовно, поліпшення). Але інструменти для веб-майстрів продовжують повідомляти про збільшення середнього часу відгуку, коли ми бачимо, що він зменшується за той же час.

Чи були у вас колись подібні дивні поведінки на ваших сайтах, роблячи підвищення ефективності? Чи маєте ви якесь уявлення, як слідкувати за тим самим, що робить Google із ефективністю сайту в Інструментах Google для веб-майстрів, щоб ми могли покращувати наш сайт і постійно перевіряти, чи це те, чого хоче Google?

Редагувати 26.07.2011 : Дякую за відповіді, хлопці! Тим не менш, я був недостатньо точним. Основна проблема у нас - це не сторінка ефективності сайту, а наразі статистика сканування. Ми, мабуть, знайшли проблему на своїй стороні з дуже повільними сторінками (близько 3000 мс !!), і ми намагаємося їх виправити. Я буду тримати вас у курсі, як тільки у мене з’являться відомості. Знову дякую !

За офіційними рекомендаціями

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

Ефективність сайту - це експериментальна функція «Лабораторії інструментів веб-майстрів», яка показує інформацію про затримку щодо вашого сайту. (Щоб побачити дані про ефективність сайту, потрібно додати та підтвердити свій сайт в Інструментах для веб-майстрів.)

Час завантаження сторінки - це загальний час від моменту, коли користувач натискає посилання на вашу сторінку до моменту завантаження та відображення всієї сторінки у веб-переглядачі. Він збирається безпосередньо від користувачів, які встановили панель інструментів Google і ввімкнули додаткову функцію PageRank.

Оскільки користувачі часто можуть взаємодіяти з веб-сторінками до їх повного завантаження, це дуже сувора інтерпретація швидкості веб-сайту . Але доцільно бути дуже суворим щодо цього заходу, тому що якщо на сторінці є багато динамічних JavaScript та динамічно завантажених оголошень, це, можливо, правильніше, щоб користувач бачив, що сторінка повільно завантажується.

Тому спосіб їх вимірювання здійснюється за допомогою вкладки «Мережа» в інструментах Google Chrome aka ctrl+ shift+ I.

Дві відповідні події - це DOMContent Event Fired(синя лінія) та Load event fired(червона лінія). На випадковій сторінці на цьому веб-сайті це означає, що цифри становлять приблизно 600 мс і 1,1 сек відповідно. Це набагато набагато більше, ніж час завантаження сторінки з командного рядка, wget- і чітко відображає час, який витрачає браузер клієнта , щоб відобразити вміст, який він завантажує через HTTP.

(Мені це також здається несправедливим, оскільки веб-сайт зі всіма статичними сторінками матиме величезну перевагу перед однією, яка динамічно налаштовує кожну сторінку для конкретного користувача, але я здогадуюсь, що це перерви!)