Что нужно сделать, чтобы сайт стал быстрее — Пособие для разработчика
У каждого, кто впервые узнает про скорость загрузки сайта, возникает одна и та же мысль: что нужно конкретно сделать, чтобы сайт был быстрее? Но сайты все разные: они все сделаны на разных движках, используются разные шаблоны и модули, и проблемы у всех отличаются. Универсального ответа на этот вопрос не существует. Но есть набор методик, которые помогут если не решить вопрос, то в долгосрочной перспективе снять его актуальность. Как и на какие проблемы нужно обратить внимание, чтобы получить 80% результата?
Первое, и основное, с чего действительно нужно начать ускорение сайта — это проверка его скорости и диаграмма его загрузки (например, для главной страницы). И первое, и второе можно получить при помощи расширений браузера для веб-разработчика, либо через сервисы Айри.рф илиWebPageTest. Вы вводите адрес вашего сайта — и через пару минут у вас красивая картинка наподобие этой — диаграмма загрузки сайта.
На диаграмме загрузки показаны характеристики загрузки всех объектов страницы сайта с указанием промежутков времени, за которые выполнялись определенные этапы этой загрузки — например, установление IP-адреса (DNS Lookup) или соединение с сервером.
Все, что вам для начала нужно знать про диаграмму загрузки, — это время ответа сервера на запрос HTML-страниц (первый запрос к сайту без учета редиректов), момент первичного отображения страницы (обычно это первая вертикальная, зеленая, линия) и момент окончательного отображения сайта (обычно это вторая вертикальная, синяя, линяя). Если вы нашли эти вещи на диаграмме загрузки — половина дела сделана, можно проводить дальнейший анализ.
5 главных вопросов по скорости сайта
Есть всего пять основных показателей, которые можно улучшить в загрузке сайта:
- Время загрузки первого объекта — HTML-документа
- Время начала отображения страницы
- Количество объектов и данных, которые загружаются между началом и окончанием отображения страницы
- Время полного отображения страницы
- Загрузка объектов после отображения страницы
Время загрузки HTML-документа
Проблемы с загрузкой самой страницы являются самыми критичными для удовлетворения пользовательским ожиданиям. Именно поэтому очень часто под ускорением сайта понимают ускорение сервера — чтобы он быстро отвечал. На установление IP-адрес сервера сайта уходит 50–300 мс, еще 20–100 мс обычно уходит на установление соединения с сервером. Даже если сервер идеально настроек, все равно пользователь не будет ждать слишком долго, и остается, максимум, 500 мс на то, чтобы отдать содержимое страницы. Из них еще 50–100 уйдут на получение данных по сети (да, скорость сигнала по проводам конечна, и быстрее скорости света передавать еще не научились).
Остается все ничего: 200–350 мс ожидания ответа от сервера (генерация страницы на стороне сервера). И если мы предполагаем худшее, то время ответа сервера никогда не должно превышать 200 мс для большинства запросов. Первое, на что нужно обратить внимание при анализе скорости сайта — как быстро пользователи получат HTML-страницу, сколько времени у них занимает этот процесс. Если больше 800 мс, то нужно исправлять ситуацию в этом месте — на стороне производительности или месторасположения сервера.
Время начала отображения страницы
Первое влияет на второе. Но сразу после оптимизации времени ответа сервера и максимального сокращения задержек на получение текста страницы, вопрос с ожиданием первоначального отображения страницы (стадия «белого экрана» в браузере) нужно решать. Хорошо, если возможно сократить эту стадию до 1–1,5 секунд (т.е. почти сразу после получение текста страницы ее можно отобразить в браузере со всеми стилями).
Если это не так, то нужно тщательно пересмотреть, что конкретно загружается до первичного отображения страницы, какие файлы и откуда они берутся. Большинство скриптов (JavaScript) можно убрать в подвал страницы, настроить асинхронную или отложенную загрузку. Возможно, часть файлов стилей не нужно загружать сразу при первом посещении сайта: какие-то используются не на всех страницах. Также все файлы можно отдавать в виде архивов с сервера и минимизировать их содержания. Все эти меры помогут сократить время «белого экрана» в разы. И это основная задача — ведь показатель отказов зависит, в основном, именно от этого показателя.
Количество данных до полной загрузки
После первых двух шагов можно взяться за «мясо»: основной процесс загрузки страницы. Здесь нас поджидают большие изображения, сторонние скрипты (те же счетчики и рекламные пиксели) и другая анимация. Все это делает сайт интересным, считает и измеряет эффективность посещения, помогает посетителю с правильным выбором. И одновременно мешает все это делать: каждый виджет отнимает у вас 2–3% конверсии.
Здесь можно начать с оптимизации изображений (используя любые пакетные или облачные решения) без потери качества, объединение небольших изображений в одну карту (спрайты), объединение и минимизация скриптов сайта (JavaScript-библиотек). Именно на этом этапе лучше всего работает CDN для сайта: объектов много, данных много, и сайт уже начал отображаться. Можно пожертвовать 50–100 мс на определение ближайшего адреса сервера, с которого загружаются статические файлы (например, изображения), но после этого очень быстро, экономя секунды на запросе и получении файлов, с него все загрузить.
Время полной загрузки
Произведя первичную оптимизацию скорости сайта, можно посмотреть на результат. Если сайт начал укладываться в 4 секунды — вы молодец, на этом можно остановиться. Но если сайт загружается все еще дольше 4 секунд, то необходимо применить комплекс дополнительных мер. В частности, нужно проанализировать все скрипты, которые загружаются на сайте (насколько они необходимы на конкретной странице, можно ли уменьшить их количество, возможно ли отложить их загрузку) и настроить «ленивую» загрузку изображений — когда загружаются только изображения на первом экране браузера, а загрузка остальных откладывается до полной загрузки страницы.
Все, что можно отложить за рамки первого взаимодействия с пользователем, нужно отложить. Ваш посетитель будет намного более счастлив получить хотя бы какой-то функционал (например, ссылки или картинки) сразу же. А чуть позже — остальные «фишки» сайта.
Жизнь после загрузки
После того как страница полностью загрузилась в браузере и готова к взаимодействию с пользователей (это должно происходить не более чем за 4 секунды), надо подумать, что делать с оставшимися данными (если они есть). В случае большого объема объектов необходимо выстроить последовательность загрузки, которая будет «разворачивать» функционал сайта с течением времени. Например, при чтении статьи намного более важно показать сначала все иллюстрации, а только потом — ссылки «Читать еще» и комментарии пользователей.
Указанные пять вопросов — отвечает ли сервер сайта до 0,2 секунд, отображаются ли страницы сайта до 1 секунды, сколько данных нужно для полного отображения страницы, полностью ли готовы страницы к взаимодействию через 4 секунды, и что происходит после загрузки страниц сайта — помогут вам быстро и грамотно определить, где основной потенциал ускорения сайта и что именно нужно делать для решения проблемы скорости сайта. А как это сделать, я расскажу ниже, рассмотрев основные технические проблемы скорости сайта и самые правильные шаги для их решения.
Проблема расстояния
Чтобы с головой окунуться в мир скорости, нам нужно понять некоторые технические детали. Предположим, что 1 изображение у вас на странице занимает 200 Кб (это кажется совсем чуть-чуть, ведь у нас на компьютере и на сервере десятки и сотни гигабайт свободного места). Но у обычного пользователя (со скоростью 20 Мбит/с) оно загрузится за 100 мс (0,1 секунды). Тоже вроде немного. Однако, у мобильного пользователя (на скорости 2 Мбит/с) — уже за 1 секунду. Если у вас на странице 10 таких изображений, то мобильному пользователю они «будут стоить» 10 секунд ожидания.
Но это ерунда, скажите вы. Возможно, у вас на страницах сайта нет такого большого объема изображений. Или у вас нет мобильных пользователей. Хорошо. Но кроме скорости передачи информации (которая ограничена скоростью света) есть еще и проблема расстояния для передачи информации. Независимо от скорости передачи информации, для того чтобы получить 1 объект, уходит 2 «времени расстояния» (технические специалисты называют это ping, пинг). Браузер должен сообщить на сервер, какой файл ему нужен, а сервер должен этот файл выдать. Процесс запроса файла как раз и требует 2 «времени расстояния».
Чтобы понять «время расстояния» лучше, представьте себе, что записываете большой список дел по междугороднему телефонному разговору. Связь плохая, и каждый пункт вы должны не только записать у себя, но и проговорить собеседнику, чтобы он был уверен, что вы записали в точности. Если пунктов много, то на запись уйдет приличное количество времени. А у современных сайтов таких пунктов хватает: обычно на странице загружаются 100–150 объектов. И каждый из них требует такой проверки.
Проблема размера
Средний размер страницы сайта — 2–3 Мб. Это означает, что даже при идеальном решении «проблемы расстояния» данные все равно будут «доходить» до пользователей, в лучшем случае, 2–3 секунды. И ваш сайт едва-едва уложится в нормативные 4 секунды ожидания. Про мобильных пользователей в таком случае можно забыть.
Самое правильное решение данной проблемы — оптимизация размера. Для текстовых файлов отлично подходит сжатие (достаточно просто проверить, что оно включено у вас на хостинге), для уменьшения размера графики подход сложнее, но ряд пакетных решений — например, Image Catalyst — позволит при загрузке обновлений на сайт (как дизайна, так и контента) не думать про экономию лишних байтов: оптимизация будет произведена лучшим способом. Если на страницах сайта выводится большое количество изображений (100 и более), то необходимо использовать плагины отложенной загрузки изображений (LazyLoad или unveil).
Также стоит отметить проблемы с размером шрифтов, используемых на сайте. Учтите, что каждый отдельный шрифт обычно «весит» как 10 картинок. И удаление неиспользуемых символов из шрифта позволяет уменьшить размер в 5–10 раз.
Проблема третьей стороны
Указанными двумя проблемами скорость сайта не ограничивается, но среди множества других причин медленной работы сайта стоит выделить виджеты. Или блоки кода, загружаемые со сторонних ресурсов (кнопки социальных сетей, голосования, комментирование, статистика, аналитика, рейтинги, персонализация и т.д.). Каждый такой блок добавляет DNS-запрос к своему домену и «время ожидания» к своему серверу. Также часто такие блоки добавляют задержки в браузере для отрисовки (рендеринга) части страницы, которая находится после этих блоков. И естественно, вносят задержки из-за загрузки дополнительных объемов данных, иногда 40–50% от общего размера страницы.
Из-за создаваемых задержек, каждый сторонний виджет «съедает» 2–3% конверсии сайта. И если такой виджет не приносит денег (не увеличивает конверсию сайта), то его нужно срочно удалять из кода страниц.
Организационные и технические решения
Google Page Speed Insights предлагает неплохой подход, генерируя инструкцию к применению на основании анализа сайта. Для исправления наиболее «тяжелых» проблем скорости загрузки сайта этого более чем достаточно (если вы можете просто передать разработчикам ссылку на сервис и задачу довести оценку до 90). Полная организационная последовательность действий описана ниже.
Грамотное управление скоростью сайта предполагает, что по каждой проблеме скорости у вас есть решение, оптимизирующее издержки на его внедрение и получаемый эффект. Для проблемы расстояния хорошим решением может стать перенос серверов максимально близко к пользователю (для российской аудитории — в Россию, для европейской — в Европу) и (или) использование CDN — сети кэширующих серверов — для выдачи статических файлов. Также грамотно будет использовать любое кэширующее и проксирующее решение, сокращающее сетевое расстояние. Например, Айри.рф.
Здесь нужно понимать, что сетевое расстояние от Москвы до Владивостока составляет 110–130 мс, а от Москвы до США или Канады — 120–150 мс. Поэтому создать быстрый сайт на мировую аудиторию — это очень сложная техническая задача. И она может выходить за рамки вашего бюджета. Но сделать быстрым сайт для одной отдельно взятой страны более чем реально.
Для второй проблемы — проблемы размера — нужна стратегия обновления сайта таким образом, чтобы размер данных каждый раз был минимальным. Это относится к таблицам стилей, скриптам, изображениям и документам. Каждый дополнительный байт данных может привести к задержке в 2 «времени расстояния», если не войдет в отправляемый сервером набор пакетов. Процесс обновления информации на сайте, подразумевающий использование самых передовых технологий сжатия и оптимизации файлов, позволит сократить важность этой проблемы. Возможно также использование любого автоматизирующего решения. Дополнительно нужно принять во внимание процесс загрузки страницы в браузере — и внедрить соответствующие решения (или плагины).
Для решения вопроса с виджетами необходимо составить подробный список, на каких страницах сайта какие виджеты используются. И если выгоды или необходимости использовать эти виджеты нет, то их нужно убрать.
Последовательный подход к ускорению сайта способен творить чудеса. Но важно понимать реальные проблемы пользователей, и решать именно их. Для отслеживания ситуации со временем загрузки сайта у реальных пользователей подойдет любой счетчик или сервис, который собирает данную информацию (Google Analytics, Яндекс.Метрика, Openstat, Pingdom или Айри.рф).
© vc.ru
