Скорость загрузки сайта. Что нужно о ней знать и как ускорить сайт?

Некоторые аспекты в этой статье утратили актуальность, хотя общая суть остается актуальной. У нас есть более свежая статья на эту тему "Скорость сайта. От чего зависит скорость загрузки сайта и как не допускать замедления"

Меня зовут Андрей Даценко. Я – руководитель студии WEB ROOM и проекта Web Speed Agency.

Мы подготовили этот материал совместно с моим партнером Михаилом Графским. Миша – чемпион мира по программированию на языке PHP по версии Bench Games, автор самого быстрого движка в мире nekTech и первой и пока единственной универсальной методики оптимизации времени ответа сервера.

Как Вы поняли, ускорение сайтов – это один из основных профилей нашей работы. Потому мы периодически просматриваем публикации и видео на эту тему, смотрим как работают наши конкуренты и как работают со скоростью web-мастера.

К сожалению, большинство рекомендаций, которые дают в сети, либо ошибочны, либо правомерны далеко не в каждой ситуации.

Потому мы решили опубликовать эту статью и постараться копнуть глубже и внести больше ясности в вопрос скорости.

Ну и, поскольку большинство рекомендаций и смыслов крутится вокруг сервиса Google PageSpeed, то мы тоже по нему хорошенько проедемся.

Итак, давайте начнем сначала.

Для чего нам нужно ускорять сайт?

1. Улучшение позиций.
2. Снижение нагрузки на сервер.
3. Улучшение конверсии.

Прошу обратить внимание, что в этом списке нет пункта «получение высокой оценки от Google PageSpeed», поскольку сама по себе оценка сервиса абсолютно ни на что не влияет.

Для начала я бы разбил их на две группы:

Процессы, которые обрабатывает сервер и процессы, которые обрабатывает браузер.

К первым относится время ответа сервера, его также называют временем загрузки html. По сути, это время за которое сервер получает от браузера команду открыть определенную страницу, обрабатывает все программные команды, связанные с этой страницей и отдает браузеру html-страницу со списком файлов, которые необходимо загрузить для корректного отображения этой страницы.

Ко вторым относится загрузка файлов стилей, скриптов, изображений и шрифтов, а также выполнение скриптов.

Итак, что нужно ускорить, чтобы поднять позиции?

На американском seo-шном портале moz.com опубликованы результаты исследований на эту тему. В ходе исследования проверяли 100 000 страниц по 2 000 запросов.
Кстати, что примечательно – там выложены все исходные данные эксперимента, которые каждый может скачать и перепроверить.

В результате не было обнаружено никакой зависимости позиций сайта от времени загрузки всей страницы, но была выявлена зависимость позиций от времени ответа сервера. Мы считаем эти исследования весьма убедительными и, к тому же, подтверждали эту зависимость личным опытом.

Так, при уменьшении времени ответа сервера на 400 миллисекунд мы наблюдали рост видимости сайта на 500-800%. Для тех, кто не знает, уточню, что в одной секунде 1000 мс, так что 400 миллисекунд – это 0,4 секунды.

Основываясь на этом, мы можем сделать вывод, что для поднятия позиций нам нужно улучшить время ответа сервера.

Перед тем как думать над тем, что можно сделать для улучшения, нужно понять, как замерять этот параметр и что можно считать удовлетворительным параметром.

Для замера можно воспользоваться сервисом PageSpeed Insights. Он показывает время ответа сервера довольно точно и, в отличие от большинства других сервисов по измерению, показывает время без учета времени прохождения сигнала между сервером вашего сайта и серверами сервиса.

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

Если у вас сайт на хостинге, то из-за колебаний нагрузки на сервер показатель времени ответа сервера может значительно колебаться. Сделайте много замеров и осредните показатель. Обращаю внимание на то, что PageSpeed Insights кеширует (то есть, запоминает) результат на 30 секунд, потому делайте замеры с интервалом более 30 секунд.

Кстати, если у Вас на хостинге большие колебания, то это первый сигнал к тому, что хостинг стоит менять. Вы можете взять бесплатный тестовый период на разных хостингах, скопировать туда свой сайт и мониторить их на протяжении нескольких дней: так Вы сможете понять, на какой хостинг лучше переезжать. По нашему опыту, плохо настроенные серверы хостера могут добавлять к времени ответа сервера 100-150 миллисекунд.
Иногда бывает гораздо больше, но это полный «караул».

Также время ответа сервера можно замерять инструментами браузера. Нажмите на клавиатуре Ctrl+Shift+I или откройте инструменты разработчика другим способом, перейдите во вкладку «Сеть» и обновите страницу с очисткой кэша браузера. Там Вы увидите время загрузки html файла.

Это такой пользовательский способ замера. Но он неприменим, если у Вас плохое интернет-соединение или если Вы находитесь слишком далеко от сервера. Я бы сказал, что удаленность не должна превышать 500 км. Но в идеале, вы должны находиться в одном городе с сервером.

Если Вы программист, то я рекомендую написать свой тест. Например, мы написали для себя тест, который может сразу сканировать много адресов по нескольку раз и выводить среднеарифметический показатель времени ответа сервера.

Полагаю, что с замером мы разобрались. Теперь давайте попробуем понять, какой показатель нас устраивает, а какой – нет.

Чтобы ответить на этот вопрос, нужно посмотреть на проблему с разных сторон.

Google говорит нам, что время ответа сервера не должно превышать 200 миллисекунд.

Опыт нам говорит о том, что позиции растут при уменьшении показателя времени ответа сервера вне зависимости от того, по какую сторону отметки в 200 миллисекунд находится Ваш сайт, а значит, мы должны уменьшить этот показатель насколько это возможно.

Основная загвоздка в том, что методики, которые позволяют существенно снизить время ответа сервера, довольно сложные и, соответственно, дорогие.

Если ваш бюджет не позволяет стремиться к минимальным показателям, то следует стремиться к норме для вашего сайта.

Что можно считать нормой?

У каждого движка свои особенности производительности. Одни быстрее, другие медленнее сами по себе. Но их показатели можно осреднить. Я лично проводил небольшое исследование. Я проверял время ответа сервера для сайтов в ТОП 100 выдачи Google более чем по 200 запросов.

Это позволило мне сделать вывод, что у сайтов, работающих на серийных движках, среднее время ответа сервера – 400-500 миллисекунд для обычных страниц и 600-800 для сложных страниц, как например, страница категории товаров в интернет-магазине. У сайтов, работающих на уникальных движках – 30-100 миллисекунд, практически без зависимости от типа страницы. Если Ваши показатели сильно превышают эти цифры, то эту проблему нужно срочно решать, и часто ускорение до средних показателей – процесс не супер-сложный.

Теперь перейдем к решению проблемы.

Давайте посмотрим, что нам рекомендует сделать PageSpeed по этому поводу.

Изучить данные производительности, найти и устранить проблемные места.

Согласитесь, очень абстрактные рекомендации.

Особенно меня забавляет предложение: «Если используется популярная веб-платформа или система управления контентом, советы по оптимизации вы найдете в документации». Трудно себе представить популярную платформу с проблемами производительности, у которой при этом в документации описано, как их решить.

Причин, по которым время ответа сервера может расти, очень много:

• Медленный сервер.
• Низкоквалифицированные front-end разработчики, которые не очень хорошо понимают, что делают и подключают к сайту кучу обширных библиотек, не имея способности написать простой код самостоятельно.
• Кривые руки программиста, который дорабатывал сайт.
• Неподходящая сайту структура базы данных (например, если Вы на серийный движок магазина зальете 1 млн товаров, то не стоит вообще ждать, что он сегодня загрузится).

Что из этого списка решить легко?

Нам довольно нетрудно протестировать разные хостинги и переехать. Немного сложнее, если у Вас выделенный сервер, но и тут вполне реально найти хорошего админа, который все хорошо настроит.

Часто несложно найти и устранить программные косяки.

Но все остальное требует серьезного вмешательства.

Из распространенных способов решения я бы рекомендовал переносить сайт на уникальный движок или сильно модифицированный, с архитектурой базы данных, заточенной под ваш проект.

Еще есть наша методика. Подробно описывать ее тут не будем, но общая суть заключается в том, что мы создаем гибридную систему.

Мы подсоединяем к любому движку нашу платформу nekTech и передаем ей функцию отображения front-end.

Суть быстрой работы nekTech заключается в полном разделении верстки и программирования, что позволяет загружать файлы шаблона из базы данных и, как результат, очень быстрый рендеринг сайта.

Чистый nekTech грузится за 2-5 мс, в составе гибрида время ответа сервера составляет в среднем 17-40 мс.

Основная загвоздка с нашей методикой состоит в том, что она требует немалой работы по разделению верстки и программного кода. В результате, ускорение одного шаблона страницы (категория товара или карточка товара) стоит от 500 до 1300 USD и занимает от 2 недель до 2 месяцев.

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

Перейдем к вопросу снижения нагрузки на сервер.

Так получилось, что мы об этом уже все рассказали.

Дело в том, что уменьшение времени ответа сервера пропорционально снижает нагрузку на сервер.

Так что, если Вы смотрели на вопрос снижения времени ответа сервера с точки зрения роста позиций, то для тех, кто платит за выделенный сервер или VPS есть ещё одна хорошая новость: Вы сможете вернуться на хостинг и начать отбивать деньги с первого дня. Только идите на хороший, проверенный Вами хостинг.

А если у Вас несколько серверов и Вы улучшите время ответа сервера, то сможете уменьшить их количество.

Идем дальше. Как скорость работы сайта влияет на конверсию?

На самом деле, мы не знаем. Знаем только то, что она влияет.

В сети вы можете найти много кейсов наших коллег, специализирующихся на ускорении сайтов, где они демонстрируют рост конверсии после ускорения.

Я встречал кейсы, в которых описывались случаи роста конверсии более чем на 200%, но поскольку на конверсию влияет огромное количество факторов, процент роста в Вашем случае предсказать невозможно.

Я изучал много таких кейсов и личный опыт и могу осреднить зависимость в такой показатель: конверсия увеличивается на 10% при ускорении загрузки сайта на 1 секунду. Осенью 2016 года я общался с представителем Google и он поделился своей официальной статистикой, которая говорит, что за каждую лишнюю секунду загрузки сайта Вы теряете 7% конверсии.

Как Вы понимаете, параметр «время ответа сервера» не сильно влияет на конверсию, если учесть, что в среднем, без глобального вмешательства, получается выиграть только 100-150 мс, то есть около 0,1 секунды.

Для значительного ускорения времени загрузки сайта мы будем работать с другими параметрами.

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

Более быстрая работа сайта улучшает поведенческий фактор, а он, в свою очередь, может влиять на позиции. Насколько эта зависимость сильна, без статистики вменяемого исследования сказать не могу.

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

Итак, что нам нужно, чтобы наш сайт быстро загрузился и отобразился пользователю?

На скорость загрузки файлов влияет размер файлов и скорость передачи. Поскольку мы не можем влиять на скорость передачи, то будем влиять на размер файлов. А для более быстрого отображения будем разбираться с версткой.

Разбирая эти проблемы, я бы хотел обращать Ваше внимание на замечания PageSpeed и на рекомендации, которые он дает.

Начнем с изображений, поскольку они занимают большую часть объема загружаемых файлов.

Будем рассматривать оценки на примере сайта, который недавно поступил к нам на обслуживание. На данный момент мы еще ничего с ним не делали.

Мы видим чудовищную оценку: 16/100

И первое замечание: оптимизировать изображения. PageSpeed нам говорит, что после оптимизации изображений мы сократим их объем на 3,3 Мб.

Теперь давайте разберемся, что нам даст это по скорости.

Поскольку для нас важен мобильный траффик, предлагаю равняться на него.

Средняя скорость передачи нашего 3G – 30 Мб/с , 1 Мбит = 124 Кбайт.

Выходит, что за секунду на мобильное устройство может загрузиться 3750 Кбайт или 3,7 Мбайт.

Получается, что оптимизировав изображения, мы выиграем почти секунду. Очень хорошая экономия.

Как мы можем оптимизировать изображения?

PageSpeed предлагает скачать архив с уже оптимизированными изображениями. Но проблема в том, что изображения в архиве будут только для тестируемой страницы. Если у Вас не очень большой сайт, то Вы можете просканировать все страницы и заменить свои изображения на оптимизированные, но для объемных сайтов это вообще не вариант.

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

Мы в своей практике предпочитаем писать программу, которая автоматом обрабатывает изображения по размеру при первом открытии страницы и пересохраняет их на сервере. Этот путь замедляет первое открытие страницы сайта, поскольку оптимизация происходит в процессе загрузки страницы, но зато в дальнейшем проблем с картинками не будет.

Кстати, некоторые используют оптимизаторы на стороне сервера, которые также оптимизируют изображения на лету, при загрузке страницы, но они не перезаписывают файлы на сервере. Это конечно, улучшит оценку PageSpeed, но по факту даст постоянное существенное замедление сайта.

Также рекомендуем по возможности использовать для иконок и логотипов векторный формат SVG, но подключать их не файлом, а кодом. Это позволит сократить количество обращений к серверу при открытии страницы, поскольку все SVG-изображения будут загружаться в одном потоке, вместе с html-кодом самой страницы. Но не стоит увлекаться этим. В SVG можно перевести практически любое изображение, но чем сложнее изображение, тем больше кода в нем,и может быть ситуация, при которой файлом загружать картинку будет быстрее, чем читать ее код.

Некоторые наши коллеги рекомендуют убирать изображения с сайта для улучшения показателей скорости или значительно ухудшать их качество.

Мы не поддерживаем такой подход. Конечно, бывают случаи, когда картинки на сайте просто лишние и у них нет никакого назначения, и тогда их стоит убрать. Но в большинстве случаев картинки нужны и хорошее качество этих изображений может стимулировать рост продаж. Потому мы призываем сохранять здравый смысл. Скорость –скоростью, но если без картинок сайт не может продавать, то какой в этом всем смысл???

После любой оптимизации мы рекомендуем проверять показатели скорости инструментами браузера, чтобы убедиться, что Вы действительно что-то сделали.

Далее в PageSpeed мы видим рекомендацию использовать кэш браузера.

Для тех, кто не знает смысла этой рекомендации, поясню.

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

Но, чтобы снять замечание PageSpeed, кеширование не просто должно быть включено, срок кэширования должен быть не менее 30 дней (то есть, 2 592 000 секунд).

Однако, тут есть одна сложность. Если на Вашем сайте используются внешние сервисы, такие как аналитика поисковых систем, карты, мессенджеры и т.д. То Вы не можете влиять на параметры их кэша. Обычно кэширование у них установлено, но срок кэширования – несколько часов.

Это можно обойти, если Вы скачаете коды этих сервисов и будете их загружать со своего сервера, но тогда Вам нужно будет следить за выходом обновлений этих сервисов и обновлять их вручную.

Если Вы – ярый борец за скорость, можете проделать это и посмотреть, насколько реально ускорится Ваш сайт. Уверяю, разницу Вы не заметите.

Следующее замечание: Удалите код JavaScript и CSS, блокирующий отображение верхней части страницы.

Это замечание мы будем видеть всегда, когда мы будем подключать JavaScript и CSS в теге head, что, кстати, предусмотрено техническими требованиями html для корректного отображения страницы.

Начнем с JavaScript.

Что нам рекомендует PageSpeed?

Маленькие скрипты, необходимые для отображения верхней части страницы, встроить в html.

Рекомендация не лишена логики, однако большинство скриптов довольно объемные и встраивать их в html – неправильно. К тому же, хоть сколько-нибудь заметного ускорения это не даст.

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

Можно пойти другим путем: настроить асинхронную загрузку одного скрипта, который загрузит и запустит остальные скрипты в правильном порядке. Этот путь снимет замечание сервиса, однако по факту загрузку не ускорит, а может даже замедлить.

Потому, мы рекомендуем игнорировать это замечание.

Что касается загрузки CSS, то отложенная загрузка стилей приведет к тому, что пользователю сайт откроется некорректно. Будет черный текст на белом фоне и постепенно появятся изображения, фоны и контент распределится по нужным местам. Да, контент загрузится быстрее, но им в большинстве случаев будет невозможно пользоваться. А так как мы отложили загрузку стилей, то полная загрузка сайта до корректного состояния будет длиться дольше.

Рекомендация об использовании GZip-сжатия.

Что такое GZip и чем он может нам помочь?

Полагаю, Вы знаете, что такое архивация? GZip – это архивация файлов на лету, на стороне сервера, и распаковка их также на лету, на Вашей стороне, в браузере.

Эта архивация происходит очень быстро и она используется для сжатия текста: файлы html, css, js, которые по своей сути являются текстовыми, сжимаются в десять раз и более. Это позволяет скачать их заметно быстрее с небольшой нагрузкой на сервер.

К примеру, если Вы видите в замечаниях PageSpeed файл css или js размером 100 Кб, то передаваться, на самом деле, будет около 10 Кб.

Использование GZip на сайтах является стандартной общепринятой практикой.

Кстати, обращаю Ваше внимание, что лучше всего GZip сжимает пробелы, отступы и переносы строк. Это будет очень занятно, когда мы перейдём к следующему замечанию.

Рекомендации по сокращению JavaScript, css и html.

Что подразумевается под сокращением? Удаление лишних отступов, пробелов и переносов строк.

Самое интересное, что принимать решение о том, что лишнее, а что нет, будете не Вы, а PageSpeed.

Веб-мастерам работать с оптимизированным таким образом кодом будет довольно затруднительно и неприятно. Если же сайт никто не правит, то удаляйте на здоровье, только боюсь, что от этого ничего не изменится. Давайте подумаем, почему:

1. В нашем примере нам предлагают сократить JavaScritp и CSS. И если мы их сократим, то по объему файлов мы сэкономим 16,7 Кб. Теперь давайте прикинем, сколько это по времени загрузки. 16,7 – наш сэкономленный объем, разделим на 3750 Кб, которые могут загрузиться за одну секунду через 3G. Получим 0,004 секунды. И это мы ещё не учли сжатие. Это мало что изменит в жизни Вашего сайта и бизнеса.
2. Мы же подключаем Gzip-сжатие, которое делает эту оптимизацию на лету. Получается, что в этом нет смысла.

Также хочу добавить свою рекомендацию по этому поводу. Многие разработчики используют при создании сайта обширные библиотеки, например Bootstrap. Размер сокращенного css-файла этой библиотеки составляет 119 Кб. Также приведу в пример суммарный размер не сокращенных CSS-файлов интернет магазина, который мы делали – 56 Кб. Отсюда рекомендация – пишите код руками, это лучшая оптимизация.

Основной причиной аномально низкой скорости работы сайтов является подключение на сайте очень большого количества скриптов и стилей, большая часть которых на сайте даже не используется.

Так, если мы приводим в пример файл размером 100 Кб и говорим, что это – ерунда, то если у Вас таких файлов – 20, то это уже проблема.

Надеемся, что информация была для Вас полезной и интересной.