20 мин на прочтение

Как ускорить загрузку сайта и не поругаться со своим программистом?

  • Как читать отчеты по скорости загрузки сайтов?
  • Почему не стоит смотреть на инструмент Google Page Speed (Pagespeed Insights)?
  • Что реально можно внедрить и увеличить скорость сайта, а что не стоит даже копировать в аудите разработчикам?
  • Как ускорить загрузку страниц сайта и не поругаться со своим программистом?
  • А заодно пару полезных и бесплатных плагинов для ускорения сайта на WordPress.

О чем рассказал

00:00:02 Как использовать сервисы для проверка скорости загрузки сайтов
00:00:29 Сервис GTmetrix
00:00:40 — Какие страницы анализировать
00:01:17 — Базовые настройки
00:03:49 — Отчет PageSpeed
00:16:21 — Отчет YSlow
00:20:28 — Вкладка Waterfall
00:20:48 — Вкладка Timings
00:22:01 — Вкладка Video
00:22:05 — Вкладка History
00:22:22 Google PageSpeed Insights
00:23:45 Pingdom Tools и web.dev
00:23:59 Резюме по сервису GTmetrix

Расшифровка видео «Как ускорить загрузку сайта и не поругаться со своим программистом?»

Привет. В рамках этого видео хочу рассказать, как использовать сервисы для проверки скорости загрузки сайтов и как правильно читать их отчёт.

Во-первых, наверное, ты сталкивался с несколькими сервисами — это Google PageSpeed Insights, Pingdom Tools, Google web.dev Measure, это тоже гугловский сервис, и GTmetrix.

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

Соответственно, первым делом нужно взять ту страницу, которую мы будем анализировать. По умолчанию обычно все берут главную страницу, но большая часть трафика приходится не на главную страницу, а на страницы конкретных товаров, категорий и, например, там, брендов. То есть надо взять несколько страниц, которые отражают основные шаблоны, куда приземляются пользователи. В случае с Roman.ua, это какая-нибудь большая длинная статья, например, про Facebook, где много анимации и всего остального, это главная и, например, страница категорий.

Что по настройкам?

По настройкам здесь крайне важно выбирать правильный сервер, потому что скорость будет очень сильно зависеть от того, откуда запрашивается сайт. Это будет из США, Китая или Лондон. В случае, если сайт работает, например, на европейскую аудиторию, то надо запрашивать с ближайшего сервера, в данном случае это Лондон.

И есть ещё тут такая настройка, собственно, ну, Chrome понятно, соединение не замедляется, видео не надо. Здесь есть еще такая настройка — Stop test onload. Она даёт возможность каким-нибудь внешним скриптам типа Яндекс.Метрики загрузиться. Если они, там, 2 секунды не грузятся или не отправляет какие-то дополнительные запросы, то проверка заканчивается. Поэтому если выбрать эту настройку, то скорость будет показываться быстрее и меньше будет обращать внимание на те сервисы, на которые мы не особо влияем, т.е. это, например, Яндекс.Метрика с Вебвизором или какой-нибудь чат. В общем, всё то, что долго грузится.

В общем-то, это всё, что надо здесь поставить.

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

Окей, давай сейчас перетестируем какую-то из существующих страниц и посмотрим отчёты, на что стоит обращать внимание.

А пока проходит тест, глобально, чем отличается этот инструмент от инструмента, например, PageSpeed Insights от Гугла. PageSpeed Insights от Гугла, он очень любит рекомендовать те вещи, которые визуально пользователю будут показывать страницу быстрее, часть из них можно применить, часть нет. Но в первую очередь есть смысл работать с GTmetrix.

А, здесь ещё, в настройках Roman.ua, я в куках прописал, что пользователь уже подписан, для того чтобы не вываливался отчёт формы подписки Sumo.com и соответственно правильней считалось скорость загрузки и не для новые пользователи, у которых ещё появляется форма Sumo.com, а для повторного посетителя.

Собственно, на что надо смотреть? Здесь есть вот эти два отчета — PageSpeed и YSlow — это 2 методологии. Собственно, здесь есть какие-то проценты, скорость, время, объем страницы, но это не так важно, как конкретные рекомендации. Идем по рекомендациям сверху вниз и я комментирую каждую из них.

Leverage browser caching

Кэш. Важная рекомендация, которая говорит, что файлы на сервере не кэшируются, то есть браузер пользователя каждый раз их запрашивает с сервера. Соответственно, если здесь наши домены, мы что-то можем поменять, если здесь домен Sumo.com, Google Analytics, Facebook, API Google.com, то мы на эти сервера не влияем и поэтому, ну, здесь больше ничего вытащить нельзя. Если бы здесь было что-то с Roman.ua, то да, мы бы сказали: вот для таких-то файлов на Roman.ua добавьте кэширование и кэширование установите на какое-то конкретное время.

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

Minimize redirects

Дальше. Уменьшить количество редиректов. Здесь, опять же, пример с Яндекс.Метрикой и мы на это не влияем, поэтому ничего здесь делать не можем. Если у клиента загружаются картинки не с того сервера, например, Roma.net.ua, и потом перенаправляет на Roman.ua, то да, это можно обновить, изменить и получить лучше результат.

Serve resources from a consistent URL

Отдавать картинки с одинакового URL. Вот здесь в примере две картинки одинаковые отдаются с чуть-чуть разного адреса. Это можно поправить и тогда быстрее будет загружаться сайт.

Тут надо обращать внимание на то, сколько мы сэкономим. В данном случае это 22 КБ, на огромной странице не так, чтобы сильно критично. Всё, что больше 100 КБ, это критично. Всё, что, там, 7-20 КБ, это чаще всего не сэкономит большого времени на загрузке.

Avoid CSS @import

Дальше. Исключить импорт с помощью CSS. Если CSS очень маленький файл, то его можно не импортировать, а прям включить в HTML-код. И здесь он достаточно большой и тем более опять же он лежит на Sumo, поэтому здесь мы особо ничего не поменяем, он вызывается с помощью скриптов Sumo, Typekit и так далее.

Тут, кстати, еще есть приоритетность этих изменений, и порядок у тебя будет свой в зависимости от того, какие ошибки на конкретном сайте.

Defer parsing of JavaScript

Defer parsing of JavaScript. Вот это неплохая вещь, но тут надо работать напрямую с разработчиком, и для части скриптов, которые не влияют на отображение сайта, например, не ломают меню и так далее, можно сказать, чтобы они грузились только после того, как загрузится всё остальное. В случае с Roman.ua мы это не делали, потому что достаточно сложно вычленить что из этого есть смысл подгружать в самом конце, а что должно сразу же с загрузки страницы уже работать, чтобы пользователь не видел проблем. Но здесь 188 КБ, т.е. это точка роста в данном примере.

Specify a cache validator

Далее, cache validator. Опять же, нужно чтобы были хедеры Last-Modified или ETag. На Roman.ua они есть, их нету для вот этих третьих сторон. Соответственно, в данном случае мы здесь ничего поправить не можем.

Inline small JavaScript

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

Optimize the order of styles and scripts

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

Minify JavaScript

Уменьшить размер JavaScript, сжав его. Здесь потенциально экономия 7 КБ и большая часть скриптов лежит не на Roman.ua, а на других сайтах, т.е. здесь экономия максимум 47 байт, поэтому смысла особого нету.

Minify CSS

Уменьшить размер CSS файлов. Есть специальные скрипты. Например, на Roman.ua мы используем скрипт Autoptimize и соответственно обычно эти все сжатия происходят не руками, а с помощью специальных скриптов для той платформы, на которой работает клиент. На WordPress это, например, Autoptimize. Что еще? Есть гугловский mod_pagespeed, который тоже ставится на сервер и просто в 2-х строках конфигурации задаётся, чтобы что-то сжималось, что-то уменьшалось в размере, менялся порядок и так далее, но для этого надо это ставить на сервер и должен быть непросто хостинг, как у нас на Roman.ua, а прям сервер, на который можно установить это все, или хостинг должен быть с поддержкой этого всего.

Specify image dimensions

Далее. Указать размеры картинок. Это достаточно просто сделать. Нужно, чтобы в HTML, именно в HTML, а не в CSS, были жестко заданы размеры картинок, тогда браузер будет быстрее отрисовывать страницу. Например, на Roman.ua, если глянуть вот эту картинку, посмотреть задан ли к ней жестко размер, то выяснится, что вот ширина задана, да, и, соответственно, если вот эта ширина задана в свойствах картинки, а не в CSS, браузер сразу понимает, какого размера эта картинка будет, и быстрее строит всю страницу из блоков, в том числе из этих картинок.

Minimize request size

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

Minify HTML

Уменьшить HTML. Тоже за это отвечает плагины, которые убирают из HTML лишние пробелы, комментарии и склеивает его воедино. Например, по-моему, на Roman.ua у нас уменьшенный HTML достаточно. Сейчас посмотрим. Да, здесь убраны лишние переводы строк и в принципе оно чуть-чуть склеено, у программиста там чуть больше переводов строк, пробелов и так далее.

Enable gzip compression

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

Optimize images

Оптимизировать графику. Обычно здесь самый большой зазор для роста. Мы просто подключили специальные плагины, которые сжимают эту графику и выводят в зависимости от разрешения пользователя, от его экрана разные картинки. Мы использовали такое решение как ShortPixel. Это специальное API, которое ставится тоже к WordPress и сжимает всю графику, при этом без визуального… визуально незаметно, что она сжата. То есть, например, вот эта картинка весила 207 КБ, стала 33 КБ. Вот решение, которое оптимизирует такую графику, обычно это чуть ли не самый большой зазор для роста, чтобы сайт начал весить меньше и грузился быстрее.

Specify a Vary: Accept-Encoding header

Accept-Encoding header. Та же история, что и ETag. Та же история, что gzip. Включается в настройках сервера и тоже надо смотреть, включена ли эта штука для… есть ли проблемы именно с твоим сервером.

Remove query strings from static resources

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

Avoid bad requests

Неправильные запросы. В нашем случае нету. Если есть, то надо править.

Avoid landing page redirects

Редиректы. Нету, всё отлично. Тоже, если есть, надо править.

Enable Keep-Alive

Keep-Alive, та же история. Туда же к gzip, к настройкам сервера, к Accept-Encoding header. В общем, если есть ошибка, то надо разбираться с ней.

Inline small CSS

Далее. Inline small CSS. Если есть какой-то маленький CSS и он вынесен в отдельный файл, например, там, 3 КБ, то иногда его проще задать прям в самом HTML-коде, чем отдельно сервер будет идти, брать ещё один файл, понимать, что он маленький, но тратить время. То есть одновременно браузер может качать, там, я не знаю, 4-10 файлов, и если он будет качать вот 3 КБ файл, он в это время не качает, например, какую-то картинку. Поэтому если файл маленький, его есть смысл вставлять прямо в содержимое страницы или в другой файл, который более большой CSS.

Put CSS in the document head

Указать CSS в хедере HTML-кода страницы. В принципе понятно.

Serve scaled images

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

Combine images using CSS sprites

Combine images using CSS sprites. Это правильная тема. Если очень много мелких картинок, то лучше их загрузить все одной, вместо того чтобы… одним спрайтом, вместо того чтобы загрузить каждую из них.

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

Это касается очень мелкой графики, которая используется, например, по всему сайту. То есть если, например, глянуть спрайты на «Розетке», то там будет очень много всего, той графики, которая используются сплошь и рядом…

Сейчас одну минуту.

Так, ну, логотип у них сейчас не в спрайте. Обычно это вот такая вот всякая графика, которая используется в куче мест, но сейчас они сделали по другой технологии, в SVG, в векторе, чтобы она менялась по размеру, в зависимости от разрешения пользователя, от того, с какого устройства он зашёл. Это тоже ещё один из вариантов. SVG файлы — это векторный файлы. Иногда используются спрайты. Когда вот эти вот все элементы, вот этот элемент, этот, этот, они вставляются в одну картинку по примеру спрайта.

Prefer asynchronous resources

Асинхронная загрузка. Да, достаточно важно, если есть возможность, поэтому, там, какие-то теги аналитики лучше всего размещать через Google Tag Manager, они получается асинхронными.

Specify a character set early

Вот эта рекомендация. Это, по-моему, задать кодировку. Редко она у кого-то не задана.

Avoid a character set in the meta tag

И не задавать ее в неправильном месте.

Это один из отчетов. Собственно, что здесь чаще всего реально влияет на скорость загрузки? Это оптимизированные картинки, с прописанным размером и загружающиеся в том размере, который выводится у пользователя. Это минифицированный CSS/JS. Есть специальные плагины, которые это автоматом минифицируют. Это включение кэшей. Это вот самые основные такие топ-3 рекомендации, как ускорить загрузку сайта.

Смотрим такой же отчёт от YSlow.

Add Expires header

Здесь добавить Expires headers. Такая же настройка сервера. Здесь нету Roman.ua. В общем, она говорит, что этот файл, проверь, не изменился ли он спустя какое-то время. Относится туда же к кэшированию.

Make fewer HTTP requests

Делать меньше запросов. Здесь, соответственно, если какие-то файлы можно объединить в один, их лучше объединять в один. Например, CSS и JS файлы очень часто можно пообъединять. Вместо того чтобы грузилась много разных, будет грузиться один большой. И это в целом обычно быстрее.

Use a Content Delivery Network (CDN)

Использование Content Delivery Network. Это специальная технология, благодаря которой картинки хранятся на каком-то отдельном сервере и которая отдаёт их максимально быстро. На Roman.ua мы ее не применяем. Обычно это используется для достаточно крупных проектов и далеко не всех.

Use cookie-free domains

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

Reduce DNS lookups

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

Avoid URL redirects

Убрать редиректы. Здесь опять же Яндекс.Метрика, ничего поменять мы не можем.

Reduce the number of DOM elements

Уменьшить количество DOM элементов. DOM элементом считается грубо, там, каждый квадратик, каждый элемент, который выводится в браузере.

Если у вас выводится это рекомендация, то чаще всего сильно ничего поменять не получится, потом что это надо переверстывать весь сайт, а сайт чаще всего сверстан так, чтобы он выводился и на компьютере, и на планшете, и на мобильном, и так далее. Особенно, если сайт очень-очень посещаемый, сложный, например, это сайт какой-нибудь «Розетки» или «Эльдорадо», то там просто верстка связана с тем, что используется эта верстка в куче мест, один и тот же блок может выводиться на десятке разных шаблонов и страниц, и особо уменьшить не получится количество DOM элементов. Поэтому клиенту это рекомендовать нет смысла.

Compress components with gzip

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

Minify JavaScript and CSS

Уменьшение JavaScript и CSS тоже обсуждали.

Make AJAX cacheable

Make AJAX cacheable. Не сталкивался, чтобы это сильно как-то, там, надо было применять.

Remove duplicate JavaScript and CSS

Убрать дублицирование JavaScript и CSS. Тоже редко бывает, чтобы грузилась два раза один и тот же JavaScript или CSS.

Avoid AlphaImageLoader filter

Avoid AlphaImageLoader filter. Крайне редко сталкивался с этой ошибкой.

Avoid HTTP 404 (Not Found) error

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

Use GET for AJAX requests

GET для AJAX requests. Не сталкивался.

Avoid CSS expressions

Избегать CSS Expression. Тоже сейчас не припоминаю.

Reduce cookie size

Уменьшить размер кук. Редко, когда мы можем использовать.

Make favicon small and cacheable

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

Configure entity tags (ETags)

ETags. Обсудили, достаточно важно.

Make JavaScript and CSS external

И складывать JavaScript и CSS во внешние файлы. Ну, внешние или внутренние, зависит от их размера и от того, в какой момент они должны грузиться.

В общем, основные рекомендации по этому отчету. Это опять же Expires. Это уменьшение JavaScript и CSS. Это если проект очень посещаемый, то использование CDN или cookie-free доменов. И в принципе основное вроде бы такое всё. Ну, и там, чтобы не было 404 ошибки.

Вкладка Waterfall

Дальше можно посмотреть вкладки Waterfall, чтобы понять, какие файлы грузятся, какого размера и как долго, чтобы понять, что из этого грузится дольше всего, тормозит наш сервер или это Яндекс.Метрика, например, тормозит. И здесь видно вот какие файлы параллельно грузятся, какие последовательно.

Вкладка Timings

Вот эти цифры, они говорят о том, насколько хорошо работает сервер клиента.

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

— Собственно, First paint —  это уже первая прорисовка.

— Contentful paint — это прорисовка с контентом

— DOM построение вот этого DOM дерева.

— DOM загружен

— И финальная загрузка. Вот финальная загрузка, она зависит от количества всяких там маркетинговых скриптов и настроек, ставим ли мы в настройках, остановить тест, вот то, что я говорил вначале, или нет.

Соответственно, здесь кажется, что общее время загрузки 9.5 секунд — это много, но размер 17 МБ, там очень много графики грузится и DOM загружен за 1.2 секунды, что достаточно быстро по меркам интернета. Всё, что меньше 3 секунд, это достаточно быстро. Ну и, собственно, там, всё уже прогрузилось за 5 секунд. Это учитывая кучу GIF анимаций.

Вкладка Video

Можно сделать видео, чтобы замерялось, как это всё прорисовывается

Вкладка History

И можно отслеживать во времени, как менялись отчёты, да, там, растёт этот показатель, падает и как меняется размер страницы. Особенно, если клиент говорит: «Я что-то внедрил». И как меняется вот эти синтетические показатели PageSpeed и YSlow.

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

Но такой подход не всегда возможен, тем более здесь, например, в отчете у Google, тут большая часть вещей, мы вообще на них не влияем. Это Sumo, Google Analytics и так далее. И они говорят, что вот кэш 7 дней — это недостаточно… или 30 дней — это не достаточно хороший, кажется, кэш. То есть это просто вот как другая школа, которая требует, чтобы кэш был не 30 дней, а не знаю, сколько они хотят, год.

В общем, на Google PageSpeed Insights я не очень рекомендую смотреть и в первую очередь анализировать по GTmetrix.

Pingdom Tools в принципе неплохой, но, опять же, мне привычен GTmetrix и очень понятно, на что можно влиять.

Web.dev сделан плюс-минус по такому же принципу как Google PageSpeed Insights.

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

В принципе по вот этим вот отчетам видно, что показатель от 70 до 80 по PageSpeed — это обычно достаточно хорошо. А YSlow в свою очередь сильно меньше, потому что проекты не используют тот же CDN и некоторые ещё моменты, которые именно очень специфичные для крупных проектов, поэтому YSlow обычно здесь 50-60, максимум 70.

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

Читай также:

Кто делает подкасты о бизнесе на русском языке и сколько они приносят

11 октября 2017 Секрет Фирмы

Как делать подкасты — опыт Романа Рыбальченко c кейсом «Продуктивный Роман»

15 декабря 2017 AIN.ua

Роман Рыбальченко о 7 факторах стресса и как с ними бороться

27 июля 2017 Лайфхакер

Кейс читателя: Почему мы потеряли клиента, несмотря на успешное продвижение его интернет-магазина

19 мая 2015 vc.ru

Google убирает показатель «Средняя позиция»: рекомендации по работе с новыми метриками

25 сентября 2019 SEMANTICA
avatar
Вадим Ошкало
Руководитель intimo.com.ua

Cистемность — это «религия» Романа. Так что работая с Roman.ua Вам прийдется её принять и получить все вытекающие бонусы.

Все отзывы 82

Мы помогли более 200 Клиентам. Слово «Клиент» мы всегда пишем с большой буквы.

  • Macphun
  • Intimo
  • Prom.ua
  • Autoportal.com
  • Київстар
  • Kingston
  • SemRush
  • Dobovo
Работаем удаленно и в офисе в Киеве.

Любим путешествовать и увеличиваем продажи Клиентам по всему миру.