Скорость загрузки сайта является фактором ранжирования?
- 10 сентября 2013
- Автор: Сергей Кузнецов
- Просмотров: 6306
Перевод статьи: Zoompf,
How Website Speed Actually Impacts Search Ranking
August 1st, 2013
Google использует множество факторов для ранжирования сайтов в поисковой выдаче (SERP). Как правило, это факторы, которые связаны с контентом веб страницы (текст, URL, содержимое title, заголовки и т.п.) и показатели аутентичности веб сайта (возраст, доменное имя, количество и качество входящих ссылок и т.п.). Тем не менее, в 2010 году, Google сделал что-то совершенно другое, отличное от этого. Google объявил о начале ранжирования ресурсов с учетом скорости загрузки сайта и теперь скорость представления контента сайта стала одним из факторов ранжирования.
К сожалению, точного определения термина "скорость сайта" до сих пор нет. Сия тайна (термина) стала более заманчивой, когда в июне Matt Cutts из Google заявил, что малопроизводительные сайты для мобильных устройств скоро будут подвергаться штрафным санкциям при поисковом ранжировании.
Очевидно, что Google все чаще говорит о том, что интуитивно вполне понятно: Сайты с плохой производительностью являются следствием малого опыта их владельцев и они заслуживают меньшего продвижения в результатах поиска. Но как же все это отразится на ранжировании в поисковых системах? Matt Peters из Moz попросил Zoompf помочь найти ответ.
Допущения
Пока в Google наводил туману на значимость скорости загрузки страницы в ранжировании, они все же заявили, что контент остается главным фактором ранжирования (с его множеством, весьма весомых факторов). По всей видимости, пока мы сможем только продемонстрировать корреляцию (или ее недостаток) между параметрами скорости и поисковым ранжированием. Но мы никогда не сможем доказать прямой причинно-следственной связи, т.к. другие факторы никуда не делись и все они продолжают участвовать в поисковом ранжировании. Тем не менее, в достаточно большом масштабе, мы можем предположить, что мы сможем обнаружить корреляцию и это заслуживает рассмотрения.
Методология
Начиная свое исследования мы потрудились с Matt над созданием списка 2,000 случайных поисковых запросов от 2013 Ranking Factors study. Мы выбрали репрезентативные примеры запросов, некоторые из которых состояли из одного ключевого слова ("hdtv"), а некоторых из пяти слов ("oklahoma city outlet mall stores") и целую куче между ними. Затем мы извлекли URL из ТОП 50 выборки по каждому запросу и создали список из 100,000 страниц для оценки.
Затем мы запустили 30 копий Amazon "small" EC2, работающих в облаке в Северной Вирджинии, и каждая копия с индивидуальными данными использовала Open Source пакет WebPageTest. Этот пакет использовал одинаковые версии веб браузеров и отслеживал около 40 различных параметров производительности при загрузке веб страниц. Мы использовали браузер Chrome для наших тестов и запускали каждую тестируемую страницу с пустым кешем, гарантируя этим сравнимые результаты.
Пока мы будем подводить итоги ниже, вы можете скачать все полученные данные здесь и покопаться в них самостоятельно.
Результаты
Пока мы снимали более 40 различных метрик для каждого URL, в большинстве случаев мы не заметили какого-либо существенного влияния на ранжирование. Во многом это, было ожидаемо - так, например, ожидали, что количество соединений, используемых веб браузером для загрузки страницы не должно влиять на ранжирование страницы. Для краткости, мы здесь просто выделим особо значимые, на наш взгляд, результаты исследования. Опять же, вы можете загрузить полные данные, если хотите исследовать их самостоятельно на наличие дополнительных факторов.
Время загрузки страницы
Когда люди говорят "время загрузки страницы", то обычно они подразумевают один из двух измеряемых вариантов:
- Время загрузки документа (Document Complete Time - это время, которое необходимо для загрузки страницы перед тем, как вы сможете с ней начать работать (что-то кликнуть или начать вводить данные). Весь контент еще не загружен (рисунки и т.п.), но вы уже можете взаимодействовать со страницей);
- Время полной отрисовки документа (Full Render Time - это время, необходимое для загрузки и отображения всего контента, включая рисунки, рекламу, счетчики и т.п.
Поскольку Google не раскрыл, что он подразумевает под скоростью, мы проверяли влияние на ранжирование оба варианта. Однако, для нас стало сюрпризом, что мы не обнаружили какой-либо значимой корреляции этих двух ключевых метрик, хотя мы ожидали, что это влияние будет заметно. Результат представлен на графике ниже:
На горизонтальной оси представлены позиции страницы в поисковой выдаче, а на вертикальной - среднее время фиксации всех 2000 различных времен запросов в исследовании. Другими словами, если мы подадим все 2000 запросов в Google один за другим и кликнем для получения результата каждого, мы измерим время загрузки каждой из этих страниц, а затем рассчитаем среднее и нанесем точку в позиции 1. Затем повторим действие для второй позиции, третьей, и так далее, пока не дойдем до 50.
Мы ожидали, что полученный график будет иметь тренд подъема с понижением позиции, т.к. вроде бы более высоко ранжируемые документы должны иметь меньшее время загрузки (Doc Complete Time или Full Render Time). Но мы не обнаружили такой прямой зависимости.
Время до первого байта
Не обнаружив корреляции между результатом ранжирования и традиционными трактовками "времени загрузки сайта" (см. выше), мы решили расширить исследование и посмотреть, нет ли зависимости ранжирования от так называемого "времени первого байта" (Time to First Byte - TTFB). Фактически, это время, которое требуется серверу на обработку запроса и генерацию ответа. При измерении фиксируется момент, когда первый байт ответа отдается вашему браузеру. Усредненный график ранжирования по TTFB представлен ниже:
Результат теста с TTFB принес сюрприз - была обнаружена корреляция между ухудшением позиции и увеличением времени первого байта. Сайты, имеющие низкий TTFB быстрее отзываются и имеют более высокий результат при ранжировании, чем медленные сайты с высоким TTFB. И это наблюдалось во всех данных, которые мы сняли во время эксперимента.
Размер страницы
Удивление вызвал и результат, показавший корреляцию ранжирования в зависимости от размера страницы. Под "размером страницы" мы понимали все байты, загруженные до полной отрисовки страницы (Full Render Page), включая все рисунки, рекламу, виджеты и шрифты. Когда граф зависимости среднего размера страницы для каждой позиции поискового запросы был построен, мы обнаружили корреляцию уменьшения размера страницы и с ухудшением позиции, с небольшой аномалией в ТОП 3.
Это результат нас сперва удивил. Мы не ожидали увидеть здесь какие-либо взаимосвязи! Но в дальнейшем, рассуждая, мы выдвинули теорию, что сайты с более низким рейтингом принадлежат боле мелким компаниям с небольшими ресурсами, и следовательно могут иметь меньше контента и меньшую сложность сайта. Ранжирование сайта растет с развитием сайта. Но здесь, похоже, есть исключения в виде "Big boys (больших мальчиков)", которые имеют супер большие бюджеты для супер оптимизации своих предложений (см. аномалия в ТОП 3). В качестве примера можно привести, например, Amazon.com. Мы не имеем реального подтверждения этой теории, но она подтверждается приведенными данными и согласуется с нашей интуицией.
Размер рисунков в контенте
Так, как наш анализ зависимости ранжирования от размера страницы нас удивил, мы решили посмотреть, нет ли зависимости рейтинга сайта от общего размера рисунков, которые грузятся на каждой странице. Особенно интересны резкие изменения в первых двух позициях рейтинга, за которыми идет уже малоинтересная пологая кривая.
Здесь мы не ожидали увидеть сильной корреляции, хотя некоторую корреляцию ждали, т.к. сайты более объемной графикой грузятся медленнее. Эта метрика очень связана с рассмотренной выше метрикой полной загрузки страницы (Full Render time) и плоский ее график скорее подтверждает мысль о том, что время загрузки страницы в настоящее время мало влияет на ранжирование.
Что все это означает?
Наши данные показывают отсутствие корреляции между временем загрузки страницы (загрузки документа или полной отрисовки документа) и ранжированием в поисковой выдаче Google. Это верно не только для ключевых фраз из 1...2 слов, но и для боле длинных ключевых фраз (4 или 5 слов). Мы не видели веб сайтов с более быстрой загрузкой страницы, которые бы ранжировались лучше, чем веб сайты с более низкой скоростью загрузки сайта. Если время загрузки страницы и является фактором ранжирования, то он теряется на фоне других факторов. Мы надеялись, что влияние скорости загрузки страницы проявится на коротких ключевых фраз (1...2 слова), т.к. на таких фразах велика конкуренция и этот фактор мог проявится, но не увидели этого.
Тем не менее, наши данные показали корреляцию между низким временем первого байта (TTFB) и более высоким ранжированием. Веб сайты с более быстрыми серверами и внутренней инфраструктурой могли бы иметь боле лучший рейтинг, чем более медленные сайты. Это означает, что не смотря на общее мнение, на ранжирование сайта влияет "бэк-офисная" производительность, а не "фронт-офисная". Возникает вопрос - почему так?
По видимому, для Google, TTFB это быстрая и простая метрика для ее фиксации. Различные боты (сканеры) Google приспособлены для снятия таких параметров, в то время как для фиксации времени полной загрузки документа или полной прорисовки страницы требуется функциональность более полноценного браузера. Кроме того, полная отрисовка явно зависит как от возможностей самого браузера, так и от структуры и дизайна страница. Использование TTFB для определения производительности или скорости, по-видимому, может быть объяснено и необходимостью увеличения времени и усилий, необходимых для сбора этих (полной загрузки и полной отрисовки) данных Google ботом. Однако, мы ожидаем, что со временем, время полной отрисовки страницы будет тоже использоваться в ранжировании из-за высокой важности этого параметра при взаимодействии пользователя с сайтом.
Ну а TTBF не только просто определяется, но еще и может служить вполне оправданной метрикой меры производительности сайта в целом. Так, TTFB показывает 3 фактора:
- Сетевые задержки между пользователем и сервером;
- Как тяжело нагружен сервер;
- Как быстро бэк-оффис сайта может генерить контент.
Веб сайт может снизить сетевые задержки используя Content Distribution Networks (CDNs). CDNs может быстро доставлять контент всем пользователям, зачастую, не зависимо от их географического расположения, значительно ускоряя процесс. Конечно, вполне резонно, что для лучшего ранжирования сайта требуется наличие производительных серверов, или использование CDNs, или оптимизации приложений или баз данных.
Так что же, неужели хвост виляет собакой?
Эти сайты имеют высокий рейтинг, потому что они имеют лучшую бэк-офисную инфраструктуру? Или они нуждаются в лучшей бэк-офисной инфраструктуре, что бы справиться с нагрузкой при уже более высоком рейтинге? Пока возможны оба варианта, делаем вывод, что сайты с более быстрым бэк-офисом получают более высокий ранг, а не наоборот.
Наши выводы основываются на том, что супер специфичные длинные запросы (4...5 слов) обычно не возвращаются веб сайтами с большим трафиком. Обычно длинные запросы используются небольшими компаниями в специфичных областях, которые не получают большого трафика. Однако, даже в таких условиях быстрые веб сайты с низким TTFB оцениваются лучше, чем сайты с более высоким TTFB.
Выводы
Бэк-офисная производительность веб сайта на прямую влияет на поисковое ранжирование сайта. Бэк-офис включает в себя веб сервер, сетевую инфраструктуру, возможно CDNs и бэк-офисное приложение и сервер базы данных. Владельцам веб сайтов следует искать пути улучшения своего TTBF. Это может быть решено за счет использования CDNs, оптимизации кода приложения, оптимизации запросов к базе данных, а так же использование более быстрого и шустро отвечающего веб сервера. Попробуйте посмотреть свой TTFB с помощью WebPageTest, затем исследуйте своих конкурентов, и посмотрите, нужно ли вам уменьшать TTFB.
И так, пока мы получили ситуацию, когда производительность фронтальной части (загрузка документа и полная отрисовка документа) не участвуют напрямую в ранжировании, но было бы ошибкой полагать, что они не важны, и что они не влияют на ранжирование каким-либо другим образом. Быстрые сайты способствуют более активному взаимодействию с пользователями, проявлению их активности и обмену информацией, что можно отнести уже к сфере юзабилити со всеми вытекающими последствиями. Ну а все это вместе может повышать или понижать рейтинг сайта. Если вы желаете увидеть, какие интерфейсные проблемы есть у вашего сайта, вы можете воспользоваться бесплатным сервисом Zoompf's free web performance report.
