Все мы знаем, что на ранжирование результатов поиска Google влияет множество факторов. Как правило, эти факторы связаны с содержанием веб-страницы (текст, его URL-ы, заголовки, названия и т.п.) и с показателями подлинности сайта (возраст доменного имени, количество и качество входящих ссылок и т.д.). Однако в 2010 году Google совершил маленькую революцию в поисковых алгоритмах. Google объявил, что теперь скорость веб-сайта будет оказывать влияние на распределение результатов поиска. Иными словами, скорость тоже станет фактором ранжирования.
К сожалению, точного определения понятию «скорость сайта» ещё не найдено. Вопрос остаётся открытым для предположений и гипотез. В июне Мэтт Катс (MattCutts), известный SEO-специалист команды Google, добавил таинственности, заявив, что отныне медленно загружающиеся мобильные сайты будут наказываться понижением в выдаче.
Очевидно, что эти нововведения Google опираются на интуитивно понятный факт: плохо загружающиеся сайты приводят к «плохому» пользовательскому опыту. Сайты с плохим пользовательским опытом заслуживают меньшего поощрения в ранжировании. Но что именно измеряет Google? И какую роль это играет в ранжировании результатов поиска? Мэтт Питерс (MattPeters), специалист по данным из Moz, попросил Зумпфа (Zoompf) помочь найти ответы на эти вопросы.

Предупреждение

В то время как Google преднамеренно не объясняет, какие именно аспекты скорости сайта влияют на ранжирование, он предельно ясно заявляет, что релевантность содержимого страницы запросу остаётся доминирующим фактором. Иными словами, мы можем продемонстрировать корреляцию между частными показателями скорости веб-сайта и ранжированием поиска. Но доказать причинно-следственную связь между скоростью сайта и распределением результатов мы не можем, пока действуют другие неизмеряемые факторы. Тем не менее, мы выдвигаем предположение, что любые обнаруженные корреляции «скорость сайта — результаты выдачи» — это и есть «вероятное влияние» на ранжирование. Поэтому эти корреляции заслуживают внимания и анализа.

Методология

Перед началом работы мы с Мэттом создали список из 2 000 случайных поисковых запросов, взятых из «Исследования факторов ранжирования» 2013 года. Мы создали репрезентативную пробу поисковых запросов, в которую были включены запросы из одного ключевого слова (HDTV), пяти ключевых слов (город Оклахома аутлеты торговые центры) и запросы с промежуточным количеством ключевых слов. Затем мы выделили 50 лучших результатов поиска для каждого запроса и сформировали список из 10 000 страниц для последующей оценки
Затем мы создали 20 маленьких AMAZON EC2 — облаков, находящихся в облаке Северной Вирджинии. Наши облака мы «начинили» идентичными образцами, взятыми из общедоступного веб-инструмента WebPageTest. Этот инструмент использует те же самые версии браузера, что и большинство потребителей, и позволяет собрать более 40 различных показателей скорости загрузки веб-страниц. Для нашего теста мы выбрали Chrom. Чтобы получить последовательные результаты, мы запускали тестируемые страницы с пустым кэшем.
Если вы хотите проверить данные, вы можете загрузить полученные нами результаты отсюда.

Результаты

Мы собрали более 40 показателей для каждого исследуемого URL. Большинство этих показателей не оказало существенного влияния на результаты ранжирования. Этого следовало ожидать. Например, число связей, которые браузер использует для загрузки веб-страницы, скорее всего, не воздействует на позицию в выдаче. Для краткости мы сосредоточимся на самых примечательных результатах. Подчёркиваем: если вы хотите исследовать дополнительные факторы, используйте необработанные данные.

Время загрузки страницы.

Когда люди говорят о времени загрузки страницы, они обычно имеют ввидуодин из двух показателей: «время загрузки документа» или так называемое «полное время». Под “полным временем” подразумевается время, которое требуется, чтобы загрузить и показать все изображения, рекламу и аналитические инструменты. В общем, весь тот второстепенный материал, который вы видите, пока просматриваете страницу.
Так как Google не определил, что же такое «скорость загрузки страницы», мы исследовали, как оба показателя («время загрузки документа» и «полное время») влияют на ранжирование. Каково же было наше удивление, когда мы обнаружили, что никакой корреляции между этими ключевыми показателями и ранжированием не существует! Мы ожидали, что эти два показателя уж точно влияют на результаты выдачи. Однако, как вы сами видите на графике ниже, не существует корреляции «время загрузки документа или полное время — ранжирование»:

 

скорость загрузки сайта

 

Горизонтальная ось показывает позицию страницы в результатах поиска. Вертикальная ось показывает среднее время загрузки страниц для 2 000 поисковых запросов, которые мы использовали в эксперименте. То есть, мы вводили в поисковую строку Google 2 000 запросов один за одним и кликали напервый результат. Мы измерили время загрузки каждой страницы для каждого запроса, вычислили средний результат и отметили его на позиции 1. Затем повторили то же самое для второй страницы в выдаче, потом для третьей и т.д. Всего 50 раз. Мы ожидали, что полученный график продемонстрирует ясную и чёткую корреляцию, ведь исследуемые страницы наверняка имеют разное «время загрузки документа» и «полное время». Действительно, существует доказанная связь между временем загрузки страниц и удовлетворением пользователя, а также конверсией сайта (мы вернёмся к этому вопросу позже). Однако, к нашему удивлению, мы не нашли выраженной корреляции между скоростью сайта и ранжированием.

Время до «первого байта»

Обнаружив, что корреляция между ранжированием и тем, что обычно подразумевают под выражением «время загрузки страницы» отсутствует, мы расширили наше исследование до «времени до первого байта» (TTFB). Это величина, показывающая, сколько времени браузер тратит на то, чтобы получить первый байт ответа на ваш запрос. Иными словами, этот показатель измеряет время отсылки запроса на сервер, обработки запроса сервером, формирование ответа и время отсылки «первого байта» ответа на запрос с сервера на ваш браузер.Вот график TTFB для каждой позиции в выдаче:

скорость загрузки сайта

График ясно демонстрирует корреляцию «ранжирование – TTFB»: чем выше TTFB, тем ниже позиция сайта в выдаче. Сайты с низким TTFB отвечают быстрее и оказываются выше в выдаче, чем медленные сайты с высоким TTFB. Из чего мы делаем вывод, что TTFB-показатель, вероятно, имеет некоторое влияние на ранжирование.

Размер страницы

Ещё более удивительным был результат, полученный при сопоставлении размера страницы в байтах и её позицией в поисковой выдаче. Под «размером страницы» подразумеваются все те байты, которые нужно загрузить для полной демонстрации страницы, включая изображения, дополнения, виджеты и шрифты. Мы сделали график, показывающий размер страницы и её ранжирование. График демонстрирует парадоксальную корреляцию: чем меньше размер страницы, тем ниже ранжирование. Причем на первых 3 позициях обнаружен аномальный «провал»:

 

скорость загрузки сайта

Этот результат нас немного обескуражил. Мы совсем не ожидали обнаружить здесь прямую зависимость. Однако потом мы придумали следующую теорию: сайты с низким ранжированием принадлежат мелким компаниям с небольшими ресурсами. Следовательно, их сайты имеют меньший по размеру и менее сложный по содержанию контент. С увеличением и усложнением контента растёт и ранжирование сайта. Правило не касается «крутых парней» в топе, которые располагают дополнительными средствами, чтобы раскрутить свой сайт. Подумайте, например, как будут распределяться позиции в триаде «Amazon.com vs магазин SMB-электроники vs семейный магазин». Доказательств этой теории у нас нет, но она вполне соответствует полученным результатам и нашей интуиции.


Графический контент (изображения на сайте)

Поскольку анализ полного размера страниц нас сильно удивил, мы решили проверить, как средний размер всех изображений на странице (в байтах) соотносится с позицией сайта в ранжировании. При том, что результаты первых двух экспериментов были шокирующими, результат этого эксперимента оказался довольно скучным:

скорость загрузки сайта

 

Сильной зависимости здесь ожидать не следовало. Тем не менее, некоторая корреляция существует, так как сайты с большим количеством картинок и видео действительно загружаются медленнее. Так как этот показатель тесно связан с показателем «полного времени» загрузки сайта, результаты близки с полученными в первом эксперименте. Они доказывают, что время загрузки страницы в настоящее время не влияет на ранжирование.

Что это означает?

Полученные нами данные показывают, что не существует корреляции между временем загрузки страницы (будь то «время загрузки документа» или «полное время») и позицией сайта в выдаче Google. Это справедливо как для общих запросов (1 или 2 ключевых слова), так и для более точных (4-5 ключевых слова). Исследование не показало, что сайты с быстрой загрузкой имеют высокое ранжирование по сравнению с медленными сайтами. Даже если «время загрузки страницы» является фактором ранжирования, его влияние теряется в шуме других факторов. Мы надеялись обнаружить хоть какую-то корреляцию для общих запросов (1-2 ключевых слова). Наша надежда основывалась на том факте, что для общих запросов существует довольно острая конкуренция. Мы ожидали, что эта конкуренция позволит чётче проявиться менее значимым факторам ранжирования, таким как «время загрузки страницы». Однако этого не случилось.
Тем не менее, результаты показывают, что существует корреляция между низким показателем TTFB и высокой позицией сайта в выдаче. Ранжирование сайтов с серверами и высокопроизводительным backend-ом, способных быстро предоставить веб-контент, выше, чем у медленных ресурсов. Это означает что, вопреки расхожему мнению, именно backend, а не frontend влияет на позицию в выдаче. Осталось разобраться, почему?

TTFB — это самый быстрый и лёгкий показатель для Google. Поисковые роботы могут самостоятельно измерить TTFB. А вот измерение «времени загрузки документа» или «полного времени» требует ресурсов всего браузера. К тому же, «время загрузки документа» и «полное время» зависят от возможностей браузера так же, как они зависят от дизайна, структуры и контента веб-сайта. То, что TTFB определяет производительность или скорость, может быть объяснено так: для обработки данных, полученных от поискового робота, браузеру требуется больше времени и больше усилий. Мы подозреваем, что производительность страницы станет фактором ранжирования, поскольку этот показатель тесно связан с пользовательским опытом.

Мало того, что TTFB легко поддаётся вычислению. Вполне логично использовать TTFB для измерения производительности всего сайта. На TTFB влияют 3 фактора:

— время ожидания между запросом пользователя и ответом сервера;
— степень загруженности сервера;
— насколько быстро back-end сервера способен сгенерировать контент страницы.

Веб-сайты могут сократить время ожидания, используя CDN (ContentDistributionNetworks). CDN могут быстро доставить содержимое до пользователя независимо от его географического положения. Несомненно, причиной высокого ранжирования сайтов может быть наличие у них высокопроизводительных серверов, или использование CDN, или оптимизация дополнений и уровней базы данных.

Хвост виляет собакой?

Правда ли, что сайты с лучшей backend структурой имеют лучшее ранжирование? Или наоборот — УЖЕ находясь в топе, они обзаводятся производительным backend-ом, чтобы справиться с “тяготами” пребывания на верхушке? Несмотря на то, что оба предположения звучат правдоподобно, мы склоняемся к тому, что сайты с лучшим backend-ом имеют лучшее ранжирование, а не наоборот. Мы основываем это предположение на том факте, что на длинные запросы с 4-5 ключевыми словами поисковая система не выдаёт “сложносочинённых” сайтов с большим трафиком. Как правило, в выдачу попадают сайты мелких компаний со специфическим, небольшим по объёму контентом, который не требует большого траффика и, как следствие, дюжины серверов. Тем не менее, даже среди этих маленьких сайтов на первое место в выдаче попадают быстрые ресурсы с низким TTFB.

Выводы

Производительность backend-а напрямую влияет на ранжирование сайта. Backend включает в себя серверы, сетевые соединения, использование CDN и backend приложений и серверы баз данных. Владельцам сайтов следует повнимательнее изучить способы улучшения TTFB. Это может быть использование CDN, оптимизация кода дополнений и оптимизация баз данных. Сюда относится всё, что может сделать ваши сервера быстрыми и “отзывчивыми”. TTFB легко измерить с помощью общедоступных инструментов, например, WebPageTest. Если вы сравните ваш результат с результатами конкурентов, вы поймёте, насколько вам следует “разогнать” ваш сайт.
Несмотря на то, что мы обнаружили, что производительность frontend-а («время загрузки документа» и «полное время загрузки») напрямую не влияет на результаты ранжирования, было бы ошибкой считать, что она вообще неважна или не влияет на результаты выдачи косвенным путём. По сути, предназначение frontend — обеспечить пользователям позитивный (быстрый, отзывчивый, приятный) опыт. Буквально десятилетиями аналитики и юзабилити-специалисты исследовали влияние производительности сайта на качество пользовательского опыта. Быстрые веб-сайты имеют больше посетителей, которые посещают больше страниц, чаще возвращаются, а следовательно, чаще кликают по объявлениям или что-нибудь покупают. Короче говоря, быстрый веб-сайт делает пользователей счастливыми, а счастливые пользователи продвигают ваш сайт, лайкая его и рассказывая о нём друзьям. Всё это улучшает ранжирование вашего сайта. Если вы узнать, какие именно проблемы с производительностью frontend-а у вас есть, используйте бесплатный веб-отчёт Зумпфа.

Итак, производительность backend-а и TTFB непосредственно влияют на ранжирование. Производительность frontend-а и такие показатели как «время загрузки документа» и «полное время» не коррелируют с результатами ранжирования. Возможно, эффект корреляции настолько мал по сравнению с другими факторами, что его невозможно обнаружить. Однако, как мы уже показали, производительность frontend-а непосредственно влияет на пользовательский опыт. Позитивный опыт означает увеличение количества лайков и ссылок на ваш сайт, что, в конечном счёте, улучшает ранжирование. Если вы заботитесь о высоком ранжировании для вашего сайта и создании положительного опыта у пользователей, вам нужно улучшать производительность backend-а и frontend-а одновременно. В следующем посте мы обсудим простые способы как это сделать.
О Зумпфе: Марк присоединился к команде Зумпф в качестве СЕО-специалиста в январе 2013 года. Перед этим он 13 лет проработал в компании ChannelAdvisor. У Марка страсть находить простые, но мощные решения сложных производственных проблем. Сейчас Марк живёт в Атланте, штат Джоржия, вместе с женой, громадной собакой и прелестной трёхмесячной дочкой.