Оптимизация скорости работы вашего сайта может быть сложным вопросом, особенно для тех, кто не является разработчиком. Многочисленные статьи и руководства упрощают проведение оптимизации, предлагая различные советы, которые не являются универсальными и не могут применяться абсолютно к каждому сайту. Вот несколько советов, которые требуют детального разъяснения.
1. Ваша оценка производительности играет роль.
Если вы используете один из популярных инструментов тестирования скорости, такой как Google PageSpeed Insights, GTMetrix или Pingdom, вы получаете данные о производительности вашего сайта в виде оценки, которая дополнена некоторыми рекомендациями. Клиенты часто думают, что если у них имеется плагин кэширования, то они должны получить практически идеальные результаты. Естественно, такой подход не является правильным; более того, стремление достичь идеальной оценки – это просто пустая трата времени.
Суть в том, что оценка производительности вашего сайта не имеет значения! Единственная метрика, которая важна – это реальное время загрузки ваших страниц.
Почему оценка не имеет значения
Основные причины того, почему нам нужен более быстрый сайт:
- Чтобы улучшить SEO
- Чтобы улучшить опыт взаимодействия
- Чтобы поднять конверсию
Оценка производительности не влияет ни на что из этого.
Когда Google-бот посещает ваш сайт, он не знает вашу оценку производительности, которую показывают инструменты тестирования скорости. Он видит только то, как быстро загружается ваша страница.
Зачем нужна оценка производительности?
Оценка производительности и рекомендации могут быть полезны в качестве установившихся практик для разных руководств, а также для определения проблемных мест сайта. Факт в том, что более высокая оценка производительности не равна высокой скорости загрузки страниц. Я видел много сайтов с высокими оценками, но при этом с медленной скоростью работы.
К примеру, следующий сайт имеет время загрузки 30с – очень и очень много, но при этом оценка производительности Pingdom равна 96/100.
К тому же, каждый инструмент, который вы используете для оценки производительности, может давать разные результаты. И какой из них «правильный»? Поэтому не нужно переживать по поводу достижения каких-то оценок, лучше сосредоточьтесь на времени загрузки страниц.
Иногда предложения, которые даются сервисами, помогают поднять скорость загрузки, однако зачастую их сложно применить, чтобы извлечь для себя хоть какую-то пользу.
Классический пример этого – когда Google PageSpeed предлагает перенести CSS и JS файлы в футер. Некоторые JS-файлы могут быть перенесены в футер, в то время как перенос других может привести к поломке всего сайта. Аналогично, если вы загрузите свой сайт без CSS-стилей, он будет выглядеть сломанным, и будет предлагать ужасный опыт взаимодействия.
2. Вам нужны все типы кэширования.
Есть несколько разных доступных типов кэширования, и некоторые статьи предлагают реализовать их все – кэширование страниц, кэширование базы данных, Memcached и т.д.
На сайте без кэширования, когда пользователь переходит на страницу, сервер с помощью PHP должен получить из базы данных все компоненты страниц и контент, собрать их и передать обратно браузеру. Это требует некоторого времени.
В отличие от этого, кэширования страниц (которое делают разные плагины) генерирует статичные HTML файлы с вашим контентом, которые быстрее передаются вашим посетителям.
Это означает, что если у вас включено кэширование страниц и посетитель пришел на ваш сайт, ваша база данных даже не будет использоваться. Поэтому в большинстве ситуаций с кэшированием страниц вам не придется кэшировать также и базу данных. Это – истина для многих веб-сайтов.
Есть некоторые обстоятельства, при которых кэширование базы данных может оказаться необходимым, однако они не проявляют себя в случае со среднестатистическим сайтом. К примеру, если у вас имеется высокодинамичный сайт, для которого кэширование страниц попросту неосуществимо – в таком случае кэширование базы данных может оказаться полезным. Обычному блогеру про это думать не нужно.
Некоторые виды кэширования выполняются на уровне сервера, поэтому вы можете быть ограничены в плане своих решений – к примеру, если вы используете виртуальный или управляемый хостинг. В таком случае вы будете находиться во власти своего хостера. Однако кэширование страниц всегда может реализовать любой пользователь с помощью WordPress-плагина.
3. Можно положиться только на плагин кэширования.
Плагин кэширования – важный инструмент в вашем наборе инструментов для создания быстрого веб-сайта. Однако он не должен быть единственным. WordPress-сайт состоит из разных уровней, которые могут быть оптимизированы. Оптимизация одних является более простой для неспециалистов, в то время как оптимизация других — более сложной.
Плагин кэширования (когда настроек правильно) всегда окажет свою помощь, однако он представляет собой заключительный уровень для создания быстрого сайта. Если ваш сайт в целом неэффективен, то плагин кэширования будет выступать просто в роли лейкопластыря.
Другие уровни, которые надо рассмотреть:
Веб-хостинг
Хостинг – это фундамент для вашего сайта, поэтому не стоит на нем экономить. Если ваш хостинг слишком плохой, вы обречены, поскольку всегда будет иметься потолок того, как быстро ваш сайт может работать. Качественный веб-хостинг не всегда супер дорогой.
В иностранном сегменте есть несколько хостингов, которые мы рекомендуем использовать – к примеру, SiteGround и FastComet. Они не такие дорогие, но при этом очень эффективные. Есть и другие хостинги. Главное – не выбирать самый дешевый.
Ваша тема
Код вашего сайта несет в себе тема, поэтому неэффективно кодированная тема навредит вам. Это такая область, которую очень трудно исправить, особенно если вы не являетесь разработчиком. Поэтому в некоторых случаях вам придется нанять разработчика для того, чтобы провести оптимизацию скорости и улучшить производительность темы.
Обычно темы вида «все в одном», включающие в себя кучу возможностей, несут в себе дополнительный вес, который достигается при помощи загрузки разных ненужных вам скриптов и т.д. Если вы работаете с одной из таких тем, не активируйте все возможные настройки (к примеру, три разных слайдера), если вы их не используете.
Ваши плагины
В противовес популярному мнению, важно не количество плагинов, а их качество. Достаточно одного ужасно написанного плагина, чтобы ваш сайт начал тормозить. Конечно, надо разумно подбирать плагины и удалять те из них, которые вы не используете.
Итог
Если вы поместите реактивный двигатель на спортивный автомобиль и на танк, спортивный автомобиль все равно будет ехать быстрее, поскольку он оптимизирован и создан для достижения высокой скорости. То же самое применимо и к вашему сайту.
Кэширование не способно исправить плохой код, оно может только смягчить эффекты до некоторой степени. Чем качественнее все остальные компоненты вашего сайта, тем лучше и быстрее будет работать ваш сайт.
4. Меньше HTTP-запросов = более быстрый сайт.
Популярная рекомендация – вы должны сократить количество запросов, которое ваш сайт делает к серверу для формирования страницы. Обычно это верно – сокращение количества запросов является хорошей практикой. Однако, как и со всем остальным, здесь есть некоторые нюансы.
Нюансы связаны с минификацией. Большинство инструментов для минификации берут все ваши CSS-файлы и объединяют их в один большой файл (конкатенация). Таким образом, если у вас изначально было 8 CSS файлов на сайте, теперь у вас будет 1. Соответственно, будет произведен только 1 HTTP-запрос вместо 8. Лучше, не правда ли?
Может — да, может — нет. Современные браузеры в состоянии загружать многочисленные файлы за один раз параллельно. Таким образом, более эффективным подходом для вашего браузера может быть загрузка нескольких мелких файлов за один раз, нежели одного большого файла. Результаты могут варьироваться в зависимости от сайтов, поэтому вам нужно будет это протестировать.
Вот иллюстрация того, почему количество запросов не является лучшим индикатором эффективности.
На моем тестовом сайте выполняется 43 запроса, скорость загрузки – 639мс.
Загрузив всего лишь два больших, неоптимизированных изображения на страницу, я добавил только 2 лишних http-запроса, однако время загрузки удвоилось вследствие размера страницы:
Поэтому вы не должны фокусироваться только на одном индикаторе – важно придерживаться целостного подхода к оптимизации.
5. CDN – необходимость.
Это еще один достаточно популярный совет, который не стоит использовать бездумно.
Суть CDN состоит в том, что ваши ресурсы (изображения, CSS-файлы, JS-файлы) передаются вашему посетителю из ближайшей территориальной локации к нему, чтобы снизить задержку.
Задержка – время, которое требуется серверу для передачи контента браузеру пользователя. Чем дальше от сервера пользователь, тем дольше будут доставляться ресурсы.
С помощью CDN контент распределяется по разным серверам мира, чтобы он мог быть передан с самой ближней точки к пользователю, поэтому пользователь видит его быстрее.
Таким образом, CDN целесообразен только в том случае, если ваша аудитория распределена по миру, иначе это может стать бессмысленным и лишним расходом.
Вы должны также иметь в виду, что поскольку CDN – это внешний сервер, браузер должен выполнить просмотр DNS для достижения этого сервера, и каждый такой просмотр требует времени (примерно 200мс).
Таким образом, вы должны убедиться в том, что выигрыш в быстродействии, который вы получаете при использовании CDN, перевешивает минусы в виде времени просмотра и разрешения DNS.
Оптимизация скорости – это не какой-то универсальный процесс, применимый для всех. Методом проб и ошибок вы должны подобрать для себя лучшее решение. Все рекомендации, которые вы найдете в сети, должны быть тщательно протестированы в ваших определенных условиях, чтобы понять, помогут ли они вам или нет.
Источник