Скорость загрузки страниц сайта - один из тех случаев, когда мнение специалистов по продвижению и клиентов в целом совпадает. Быстрым сайтом удобнее пользоваться. Это улучшает поведенческий фактор сайта, у него, при прочих равных, лучше индексация. Многие специалисты считают скорость загрузки страницы фактором ранжирования. Практически каждый SEO-аудит содержит пункты, говорящие, что сайт нужно ускорить, но конкретные рекомендации дают очень редко. В данной статье я не буду рассуждать, почему так происходит, как вы поймете далее, ускорение сайта - обширная, и достаточно сложная тема.
Раз вы читаете статью, вероятно, тема эта как минимум интересна, и дальше убеждать вас в необходимости оптимизации скорости не имеет смысла. Лучше перейдем к сути.
Итак, нашей целью является передать контент страницы от сервера клиенту (браузеру, поисковой системе или даже парсеру) с наибольшей скоростью. Для этого нужно ответить на 4 вопроса, каждый из которых определяет отдельную сторону процесса загрузки страницы:
Xenu Link Sleuth можно просканировать сайт и собрать статистику с адресами, форматами и объемом изображений. Отобрать «тяжелые» изображения легко при помощи отчета Xenu, а скачать «оптом» можно, к примеру, утилитой wget.
Но важен не только объем изображений, но и их количество. Дело в том, что для каждого отдельного файла клиенту приходится отправлять на сервер запрос и дожидаться ответа. То есть, для ускорения загрузки страницы количество файлов также нужно минимизировать.
Конечно, не все файлы сайта загружаются последовательно, иначе все страницы открывались бы невероятно долго. Широко распространенный сейчас стандарт передачи данных HTTP1.1 (оригинал спецификации, для особо любопытных) позволяет загружать параллельно несколько файлов с одного домена. Но на современных сайтах количество файлов очень велико, и возможностей этого стандарта уже недостаточно.
Пожалуй, самым распространенным и эффективным решением проблемы большого количества изображений, является технология CSS-спрайтов. Несколько изображений (обычно, иконки или файлы шаблона) собираются в одно изображение, а отображение на сайте происходит изменением при помощи CSS отображаемой области этого большого файла.
Gzip, являющийся стандартными для всех Unix-систем.
Браузер обращается к серверу со списком поддерживаемых технологий сжатия (запросом Accept-Encoding), сервер возвращает заголовок Content-Encoding: gzip, что означает что контент страницы будет передан в сжатом gzip архиве. Сам метод сжатия близок с стандартным Zip-архивам.
Технология подходит для сжатия только текстовой информации (HTML, CSS, программного кода), но малополезна для передачи изображений и файлов сложных форматов.
Gzip-сжатие широко распространено и по умолчанию работает на большинстве сайтов. Проверить, отдает ли ваш сайт контент в сжатом таким образом виде можно практически любым из инструментов, проверяющих ответ сервера, например, «Проверка ответа сервера» в Яндекс.Вебмастере. Если сжатие включено, в отчете вы увидите вышеупомянутый Content-Encoding: gzip.
Если все же компрессия не работает, в большинстве случаев вы сможете самостоятельно активировать ее при помощи файла .htaccess. Для этого нужно добавить в него инструкции AddOutputFilterByType DEFLATE с типами данных, которые нужно сжимать. Например, для HTML, CSS и JavaScript инструкции будут выглядеть следующим образом:
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/javascript
В более сложных случаях, например, когда сжатие отключено на хостинге, потребуются настройки на уровне севера.
memcached позволяет сохранять кэш в оперативной памяти сервера, что позволяет генерировать страницы максимально оперативно. Однако из-за слишком объемного кэша оперативной памяти может стать недостаточно для нормального функционирования сайта, так что использование и само внедрение memcached следует доверить профессионалам.
С одной стороны, кэширование на жесткий диск способно ускорить сайт на не очень качественном хостинге, сервера которого перегружен. С другой – за актуальностью кэша следит не сервер, а скрипт, который этот кэш генерирует.
Использование кэша на жестком диске очень распространено, в данный момент для распространенных CMS можно найти большой выбор кэширующих плагинов.
HTTP/2 – новый протокол передачи данных, представленный общественности в 2014, и утвержденный 2015 году. По сравнению с HTTP1.1 для нас он имеет одно заметное преимущество – он не создает отдельно соединение для загрузки каждого файла, а загружает все их параллельно, одним потоком. Благодаря этому, нет необходимости в создании CSS-спрайтов, минификации JavaScript и переносе изображений на другие домены.
Кроме того, обмен заголовками здесь происходит в сжатом виде, а сервер, поддерживающий HTTP/2, может отправлять данные, которые еще не были запрошены клиентом, например, изображения из тела страницы еще до того, как полностью обработаны CSS-стили и JavaScript из раздела <head>. Вместе эти методы способны значительно ускорить загрузку Front-end составляющей страницы.
Проверить, поддерживает ли сайт HTTP/2 можно при помощи сервиса от KeyCDN. Если же вы хотите проверить поддержку протокола вашим браузером и наглядно оценить ускорение загрузки контентом, воспользуйтесь demo от Akami.
Но у HTTP/2 есть также и недостатки:
На начало 2017 года около 12% сайтов по всему миру поддерживают HTTP/2 и, учитывая все преимущества, в ближайшие годы можно ожидать значительный рост этого показателя.
Apache получил популярность благодаря производительности при обработке динамического контента, но в высоконагруженных системах он не всегда может обеспечить оперативную работу.
Nginx же способен обрабатывать только статичный контент, а динамический – отдавать другим обработчикам, например, тому же Apache. Тем не менее, Nginx может параллельно обрабатывать большое количество запросов. На самом деле, Apache также способен параллельно обрабатывать обращения, но его масштабируемость меньше. Это связано с различиями в механизме так называемых работников (воркеров), каждый из которых и обрабатывает обращения.
В наиболее распространенной сейчас архитектуре, Nginx + Apache, первый используется для сортировки запросов и передачи, второй - только тех из них, которые не способны обработать воркеры Nginx.
Если в конфигурации сервера все же нет Nginx, его следует непременно подключить.
Apache и Nginx имеют большое количество настроек, которые, в большинстве ситуаций, не требуется изменять. Тем не менее, вы можете уточнить оптимальные настройки у техподдержки, используемой на сайте CMS.
MySQL.
В работе базы данных можно выделить два важных параметра – скорость обработки запросов, количество и время блокировок (т.н. «локов»). Если происходит длительная блокировка, БД не может обрабатывать другие запросы, до завершения блокирующего, и может образоваться большая очередь.
Рассмотрим несколько проблем, которые замедляют работу базы данных вашего сайта.
1) Для таблицы неправильно выбрана система хранения данных (движок). Самые распространенные из них – MyISAM и InnoDB.
MyISAM хорошо обрабатывает запросы на выборку данных (SELECT) и подходит для таблиц, из которых осуществляются поиск, но не включаются новые записи. Попытка включить новые данные в такую таблицу наверняка вызовет долгую блокировку БД.
InnoDB гораздо лучше обрабатывает запросы на добавление данных, благодаря чему является стандартом для реализаций баз данных на сайтах. Тем не менее, если важен быстрый полнотекстовый поиск по таблице, стоит обратить внимание на MyISAM.
2) Отсутствие индексов. Индекс – специальная таблица, содержащая ссылки на отдельные важные элементы в таблице, для которой он создан. Индексная таблица специально упорядочена и оптимизирована, чтобы быстро проводить поиск. Условно, если представить таблицу БД как книгу, индексная таблица – ее алфавитный указатель.
3) Установлена стандартная СУБД MySQL. Если 10-15 лет назад стандартной сборки MySQL было достаточно даже для самых нагруженных сайтов, применяя стандартные решения сейчас, вы значительно теряете в производительности. Улучшить этот показатель может установка форков MariaDB или Percona Server. По сравнению с продукцией Oracle, эти решения более производительны и надежны, а Percona Server уже стал негласным стандартом для замещения стандартной MySQL.
4) Если после решения предыдущих 3-х задач, не удалось достигнуть повышения производительности, следует проверить настройки MySQL. Здесь, как и в предыдущих пунктах, я рекомендую обратиться к документации CMS. Но нужно иметь в виду, что главным образом, проблемы встречаются в следующих узких местах:
a) количество допустимых одновременных подключений (max_connections);
b) объем кэша запросов и его эффективность;
c) недостаток памяти на сервере (в процессе работы БД может занимать огромный объем физической памяти сервера);
d) большое количество временных таблиц, которые были созданы на жестком диске.
Как правило, значительное повышение производительности достигается после решения первых трех пунктов. В противном случае, велика вероятность, что запросы к базе данных очень плохо оптимизированы, они выполняются долго и вызывают долгие блокировки БД. Настроив на сервере логирование запросов, можно определить самые медленные из них, надолго блокирующие базу данных, а также те, выполнение которых происходит без участия индексов. Затем, вычислив запросы, реально определить, какие функции сайта нагружают БД больше всего.
Конечно, данная статья не является исчерпывающим руководством, так как не содержит конкретных рекомендаций по настройке технологий на сайте. Да и давать такие рекомендации можно только после детального изучения сайта. Тем не менее, мы рассмотрели эффективные оптимизацию на различных уровнях. И, я надеюсь, что помог вам составить представление об основных направлениях работ, которые помогут сделать сайты быстрыми и производительными.
data: URL - технология, которая позволяет встраивать файлы прямо в исходный код страницы, при этом для загрузки этих файлов браузеру не требуется создавать дополнительные подключения. При этом нужно указать тип файла, а также бинарный код файла, перекодированный в base_64.
2. Google AMP - ускоренные мобильные страницы, которые Google кэширует и отображает в некоторых собственных сервисах.
3. Varnish способен кэшировать запросы на сервере и работать как дополнительный маршрутизатор запросов. Он применяется на высоконагруженных контентных проектах, таких как Википедия и Facebook.
Источник: Seonews
Раз вы читаете статью, вероятно, тема эта как минимум интересна, и дальше убеждать вас в необходимости оптимизации скорости не имеет смысла. Лучше перейдем к сути.
Итак, нашей целью является передать контент страницы от сервера клиенту (браузеру, поисковой системе или даже парсеру) с наибольшей скоростью. Для этого нужно ответить на 4 вопроса, каждый из которых определяет отдельную сторону процесса загрузки страницы:
- Где находится сервер (или сервера) с которых загружается контент? Здесь подразумеваем географическое расстояние между сервером и клиентом.
- Какой контент передает сайт? HTML-код, изображения, CSS, JavaScript и прочее. Это так называемый Front-end сайта.
- Как идет передача контента страницы? Существует ряд распространенных методов ускорения передачи контента в сети Интернет, их мы также непременно рассмотрим.
- Каким способом этот контент генерируется? Время статичных сайтов, работающих на одних лишь HTML и CSS практически ушло. На современном сайте используется гораздо больше технологий - это, по крайней мере, базы данных и серверные языки программирования, такие как PHP и ASP. Эту область сайта называют Back-end’ом.Рассмотрим вкратце, как можно улучшить производительность по каждому из этих процессов.
Xenu Link Sleuth можно просканировать сайт и собрать статистику с адресами, форматами и объемом изображений. Отобрать «тяжелые» изображения легко при помощи отчета Xenu, а скачать «оптом» можно, к примеру, утилитой wget.
Но важен не только объем изображений, но и их количество. Дело в том, что для каждого отдельного файла клиенту приходится отправлять на сервер запрос и дожидаться ответа. То есть, для ускорения загрузки страницы количество файлов также нужно минимизировать.
Конечно, не все файлы сайта загружаются последовательно, иначе все страницы открывались бы невероятно долго. Широко распространенный сейчас стандарт передачи данных HTTP1.1 (оригинал спецификации, для особо любопытных) позволяет загружать параллельно несколько файлов с одного домена. Но на современных сайтах количество файлов очень велико, и возможностей этого стандарта уже недостаточно.
Пожалуй, самым распространенным и эффективным решением проблемы большого количества изображений, является технология CSS-спрайтов. Несколько изображений (обычно, иконки или файлы шаблона) собираются в одно изображение, а отображение на сайте происходит изменением при помощи CSS отображаемой области этого большого файла.
Gzip, являющийся стандартными для всех Unix-систем.
Браузер обращается к серверу со списком поддерживаемых технологий сжатия (запросом Accept-Encoding), сервер возвращает заголовок Content-Encoding: gzip, что означает что контент страницы будет передан в сжатом gzip архиве. Сам метод сжатия близок с стандартным Zip-архивам.
Технология подходит для сжатия только текстовой информации (HTML, CSS, программного кода), но малополезна для передачи изображений и файлов сложных форматов.
Gzip-сжатие широко распространено и по умолчанию работает на большинстве сайтов. Проверить, отдает ли ваш сайт контент в сжатом таким образом виде можно практически любым из инструментов, проверяющих ответ сервера, например, «Проверка ответа сервера» в Яндекс.Вебмастере. Если сжатие включено, в отчете вы увидите вышеупомянутый Content-Encoding: gzip.
Если все же компрессия не работает, в большинстве случаев вы сможете самостоятельно активировать ее при помощи файла .htaccess. Для этого нужно добавить в него инструкции AddOutputFilterByType DEFLATE с типами данных, которые нужно сжимать. Например, для HTML, CSS и JavaScript инструкции будут выглядеть следующим образом:
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/javascript
В более сложных случаях, например, когда сжатие отключено на хостинге, потребуются настройки на уровне севера.
memcached позволяет сохранять кэш в оперативной памяти сервера, что позволяет генерировать страницы максимально оперативно. Однако из-за слишком объемного кэша оперативной памяти может стать недостаточно для нормального функционирования сайта, так что использование и само внедрение memcached следует доверить профессионалам.
С одной стороны, кэширование на жесткий диск способно ускорить сайт на не очень качественном хостинге, сервера которого перегружен. С другой – за актуальностью кэша следит не сервер, а скрипт, который этот кэш генерирует.
Использование кэша на жестком диске очень распространено, в данный момент для распространенных CMS можно найти большой выбор кэширующих плагинов.
HTTP/2 – новый протокол передачи данных, представленный общественности в 2014, и утвержденный 2015 году. По сравнению с HTTP1.1 для нас он имеет одно заметное преимущество – он не создает отдельно соединение для загрузки каждого файла, а загружает все их параллельно, одним потоком. Благодаря этому, нет необходимости в создании CSS-спрайтов, минификации JavaScript и переносе изображений на другие домены.
Кроме того, обмен заголовками здесь происходит в сжатом виде, а сервер, поддерживающий HTTP/2, может отправлять данные, которые еще не были запрошены клиентом, например, изображения из тела страницы еще до того, как полностью обработаны CSS-стили и JavaScript из раздела <head>. Вместе эти методы способны значительно ускорить загрузку Front-end составляющей страницы.
Проверить, поддерживает ли сайт HTTP/2 можно при помощи сервиса от KeyCDN. Если же вы хотите проверить поддержку протокола вашим браузером и наглядно оценить ускорение загрузки контентом, воспользуйтесь demo от Akami.
Но у HTTP/2 есть также и недостатки:
- На данный момент поддержка осуществляется только поверх TLS. Это означает, что вы не сможете использовать преимущества протокола, если на сайте не установлен SSL-сертификат, и страницы не загружаются через HTTPS.
- Внедрение подразумевает серьезные изменения на сервере. К сожалению, не все конфигурации поддерживают необходимые технологии, может понадобится обновление ОС и другого программного обеспечения сервера. Соответственно, на виртуальном хостинге подобные изменения сделать вряд ли удастся.
На начало 2017 года около 12% сайтов по всему миру поддерживают HTTP/2 и, учитывая все преимущества, в ближайшие годы можно ожидать значительный рост этого показателя.
Apache получил популярность благодаря производительности при обработке динамического контента, но в высоконагруженных системах он не всегда может обеспечить оперативную работу.
Nginx же способен обрабатывать только статичный контент, а динамический – отдавать другим обработчикам, например, тому же Apache. Тем не менее, Nginx может параллельно обрабатывать большое количество запросов. На самом деле, Apache также способен параллельно обрабатывать обращения, но его масштабируемость меньше. Это связано с различиями в механизме так называемых работников (воркеров), каждый из которых и обрабатывает обращения.
В наиболее распространенной сейчас архитектуре, Nginx + Apache, первый используется для сортировки запросов и передачи, второй - только тех из них, которые не способны обработать воркеры Nginx.
Если в конфигурации сервера все же нет Nginx, его следует непременно подключить.
Apache и Nginx имеют большое количество настроек, которые, в большинстве ситуаций, не требуется изменять. Тем не менее, вы можете уточнить оптимальные настройки у техподдержки, используемой на сайте CMS.
MySQL.
В работе базы данных можно выделить два важных параметра – скорость обработки запросов, количество и время блокировок (т.н. «локов»). Если происходит длительная блокировка, БД не может обрабатывать другие запросы, до завершения блокирующего, и может образоваться большая очередь.
Рассмотрим несколько проблем, которые замедляют работу базы данных вашего сайта.
1) Для таблицы неправильно выбрана система хранения данных (движок). Самые распространенные из них – MyISAM и InnoDB.
MyISAM хорошо обрабатывает запросы на выборку данных (SELECT) и подходит для таблиц, из которых осуществляются поиск, но не включаются новые записи. Попытка включить новые данные в такую таблицу наверняка вызовет долгую блокировку БД.
InnoDB гораздо лучше обрабатывает запросы на добавление данных, благодаря чему является стандартом для реализаций баз данных на сайтах. Тем не менее, если важен быстрый полнотекстовый поиск по таблице, стоит обратить внимание на MyISAM.
2) Отсутствие индексов. Индекс – специальная таблица, содержащая ссылки на отдельные важные элементы в таблице, для которой он создан. Индексная таблица специально упорядочена и оптимизирована, чтобы быстро проводить поиск. Условно, если представить таблицу БД как книгу, индексная таблица – ее алфавитный указатель.
3) Установлена стандартная СУБД MySQL. Если 10-15 лет назад стандартной сборки MySQL было достаточно даже для самых нагруженных сайтов, применяя стандартные решения сейчас, вы значительно теряете в производительности. Улучшить этот показатель может установка форков MariaDB или Percona Server. По сравнению с продукцией Oracle, эти решения более производительны и надежны, а Percona Server уже стал негласным стандартом для замещения стандартной MySQL.
4) Если после решения предыдущих 3-х задач, не удалось достигнуть повышения производительности, следует проверить настройки MySQL. Здесь, как и в предыдущих пунктах, я рекомендую обратиться к документации CMS. Но нужно иметь в виду, что главным образом, проблемы встречаются в следующих узких местах:
a) количество допустимых одновременных подключений (max_connections);
b) объем кэша запросов и его эффективность;
c) недостаток памяти на сервере (в процессе работы БД может занимать огромный объем физической памяти сервера);
d) большое количество временных таблиц, которые были созданы на жестком диске.
Как правило, значительное повышение производительности достигается после решения первых трех пунктов. В противном случае, велика вероятность, что запросы к базе данных очень плохо оптимизированы, они выполняются долго и вызывают долгие блокировки БД. Настроив на сервере логирование запросов, можно определить самые медленные из них, надолго блокирующие базу данных, а также те, выполнение которых происходит без участия индексов. Затем, вычислив запросы, реально определить, какие функции сайта нагружают БД больше всего.
Конечно, данная статья не является исчерпывающим руководством, так как не содержит конкретных рекомендаций по настройке технологий на сайте. Да и давать такие рекомендации можно только после детального изучения сайта. Тем не менее, мы рассмотрели эффективные оптимизацию на различных уровнях. И, я надеюсь, что помог вам составить представление об основных направлениях работ, которые помогут сделать сайты быстрыми и производительными.
data: URL - технология, которая позволяет встраивать файлы прямо в исходный код страницы, при этом для загрузки этих файлов браузеру не требуется создавать дополнительные подключения. При этом нужно указать тип файла, а также бинарный код файла, перекодированный в base_64.
2. Google AMP - ускоренные мобильные страницы, которые Google кэширует и отображает в некоторых собственных сервисах.
3. Varnish способен кэшировать запросы на сервере и работать как дополнительный маршрутизатор запросов. Он применяется на высоконагруженных контентных проектах, таких как Википедия и Facebook.
Источник: Seonews
