Скорость загрузки сайта — где ее проверить, что такое Google Pagespeed Insights и Core Web Vitals

Gzip сжатие для ускорения загрузки сайта

Существенный вклад в увеличение скорости внесло сжатие CSS через Page Speed, кэширование статических объектов (картинок, скриптов, CSS файлов) на стороне клиента (в браузерах посетителей), а так же очень эффективным оказалось включение Gzip сжатия на WEB сервере хостинга.

Но сразу хочу предупредить, что последнее действо имеет и негативную составляющую — увеличивается нагрузка вашего ресурса на сервер (где-то прибавилось, а где-то убавилось).

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

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

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

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

FileETag MTime Size
<ifmodule mod_expires.c>
<filesmatch ".(jpg|jpeg|gif|png|ico|css|js)$">
ExpiresActive on
ExpiresDefault "access plus 1 month"
</filesmatch>
</ifmodule>

Теперь в Page Speed в строке «Leverage browser caching» нет замечаний по поводу того, что кэширования скриптов в браузерах не происходит. Этот плагин ругается теперь только на скрипты Яндекса, на которые я, при всем желании, воздействовать не могу, ибо они подгружаются с серверов зеркала рунета вместе с объявлениями контекстной рекламы:

В общем, в плане Browser caching я сделал все, для того чтобы по максимуму увеличить скорость подгрузки страниц. Теперь пора переходить еще к одному очень эффективному и относительно простому способу ускорения — Gzip сжатию.

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

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

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

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

Ну, что поделать, за увеличение скорости загрузки приходится платить (возможно, что даже в прямом смысле — переходить на более дорого тариф хостинга). Хотя, одновременно с наращиванием скорости вы можете провести и ряд мероприятий, позволяющих существенно снизить нагрузку ресурса на сервер.

Я уже писал довольно подробно о некоторых способах оптимизации WordPress, для снижения его нагрузки:

1. Оптимизация темы (шаблона) WordPress, плагин WP Tuner и число запросов к БД
   
2. Hyper Cache — включаем плагин кэширования в Вордпресс
3. Плагин WPLANG Lite для подмены файла локализации

На моем хостинге был уже включен Gzip, но, к сожалению, не для всех объектов, которые хорошо поддаются сжатию, а включено было только для документов (html файлов). В то время, как CSS и скрипты передавались с web сервера в браузеры пользователей не сжатыми, хотя они очень эффективно архивируются (в несколько раз уменьшая свой вес).

Как проверить работу сжатия на лету в Page Speed

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

Работать с ними просто — введите Урл вашего проекта в приведенную форму и нажмите Enter.

Как видите, серверу nginx моего хостинга удалось с помощью Compressed (gzip) уменьшить размер основного загружаемого в браузеры пользователей документа (Html) в пять раз. Здорово, не правда ли? Это существенно способно увеличить общую скорость загрузки сайта.

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

Итак, активируем уже хорошо знакомый нам ускоритель Пейдж Спид, открываем в обозревателе любую страницу своего ресурса и переходим на вкладку «Resources»:

Здесь вы увидите список всех файлов, которые подгружаются в браузер с сервера с указанием их Урлов (самым первым идет Html). Вы, наверное, помните, что несмотря на то, что многие CMS (движки сайтов) работают на PHP, в браузер пользователей все равно отдается сгенерированная версия страницы в формате Html.

Но главное не это, а то, что расположено в этом окне справа от списка загружаемых с сервера объектов. Там, в двух последних столбцах под названием «File Size» (реальный размер на сервере) и «Transfer Size» (размер объекта, передаваемого в браузер), приведены веса этих загружаемых с сервера в браузер объектов.

Посмотрите на первую строку вкладки «Resources», напротив которой в столбце «Type» стоит «doc» (на приведенном ниже скриншоте выделено синим). Если в столбце «Transfer Size» для первой строчки (основного документа) размер будет меньше, чем в столбце «File Size», то значит Gzip на вашем вебсервере включено и успешно работает.

Обратите внимание, что размер сжатого объекта будет существенно меньше размера оригинала.

Но это еще не все. Ведь кроме основного документа в браузер посетителей подгружается еще куча объектов, некоторые из которых можно очень даже эффективно сжать. Я говорю про CSS и скрипты (JavaScript, jQuery). Найдите в столбце «Type» такие типы объектов и посмотрите, включен ли для них Gzip.

Если не включен для js и ccs, то размеры для них в столбцах «File Size» и «Transfer Size» будут одинаковы. Если включен, то в столбце «Transfer Size» размер файла будет существенно меньше. Ну, как вам, повезло? У меня размеры js и ccs были одинаковыми (приведенный выше скриншот был сделан уже после включения сжатия для них).

Как включить Gzip сжатие для Js, Html и Css через .htaccess

Поэтому мне пришлось еще раз вносить изменения в .htaccess для того, чтобы Gzip сжатие было включено для js и ccs объектов. Правда поначалу, используемый мною код позволил решить только половину проблемы — Gzip включилось для Css, но для скриптов сжатие по прежнему не применялось на сервере.

Вот вариант того кода:

<IfModule mod_deflate.c>
 AddOutputFilterByType DEFLATE application/javascript
 AddOutputFilterByType DEFLATE text/javascript
 AddOutputFilterByType DEFLATE text/css
 <IfModule mod_setenvif.c>
 BrowserMatch ^Mozilla/4 gzip-only-text/html
 BrowserMatch ^Mozilla/4\.0[678] no-gzip
 BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
 </IfModule>
</IfModule>

Кстати, если ваш хостер совсем не включил Gzip даже для основного файла документа, то в приведенный выше код вам нужно будет добивать еще одну строчку в середину:

AddOutputFilterByType DEFLATE text/html

У вас заработало? Если да, то поздравляю с существенным увеличением скорости загрузки сайта, а если нет, то попробуйте такой вариант, который помог мне добиться приведенной выше картинки в окне Page Speed:

<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/javascript text/css application/x-javascript
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4.0[678] no-gzip
BrowserMatch bMSIE !no-gzip !gzip-only-text/html
<ifmodule mod_gzip.c>
mod_gzip_on Yes
mod_gzip_item_include file \.js$
mod_gzip_item_include file \.css$ </ifmodule>
</IfModule>

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

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

Что дает скорость сайта

Во-первых, скорость положительно сказывается на числе успешных действий на сайте (конверсии). Есть очень много реальных историй на тему влияния ускорения на конверсию, в частности, Walmart (крупнейший ритейлер в США) повысил конверсию сайта только счет его ускорения на 20%.

Во-вторых, скорость (время ответа сервера) положительно сказывается на динамике индексации сайта (и количестве пользователей из поиска). Например, для сайта по организации праздников тренд показывает 30% увеличение числа пользователей после проведения ускорения.

В-третьих, скорость сайта является мощным фактором повышения доверия и лояльности посетителей. В частности, The Guardian (один из крупнейших новостных сайтов) сумел увеличить ежедневную посещаемость сайта на 35%, в том числе, за счет исключительной скорости на мобильных устройствах.

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

Например, снижение времени ответа всего на 0,15с способно поднять трафик из поисковиков на 20%. А регулярная недоступность сайта или значительное время ответа на зпросы поисковых роботов гарантированно закрывает выход сайта в топ10, а со временем и в топ20. Во всяком случае, на сайте, выпустившем книгу по ускорению сайтов (я как раз ее и упоминал в самом начале), приводится вот такое вот распределение скорости загрузки интернет-магазинов, входящих в Топ 50 самых крупных.

Как видно из графика — три четверти успешных бизнес-сайтов укладываются в эти самые пресловутые несколько секунд, которые «спокойно позволяют украсть из своей жизни» посетители вашего сайта до того момента, как их терпение начнет иссякать. Кроме того, при тормозах теряется лояльность (доверие) пользователя к вашему ресурсу, что приводит к снижению конверсии (звонков, заказов, продаж). И наоборот, ускорение открытия страниц приводит к росту лояльности и конверсии.

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

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

Однако, появился Айри.рф, как вариант крайне простого и практически не трудозатратного ускорения сайта. Но кроме скорости и отзывчивости он умеет и защищать ваш ресурс от злоумышленников, пытающихся его взломать или же создать ситуацию, когда он будет недоступен пользователям («уронить» с помощью Ддос атаки).

Что измерять

Не все измерения одинаково хороши, и для грамотной работы со скоростью сайта нужно понимать, в какой части сайта у него проблемы. Для начала, нужно измерить время ответа сервера (насколько шустро отвечает ваш хостинг). Это можно сделать при помощи сервисf Ping Admin. Если среднее время ответа по любому сервису больше 500 мс (0,5 секунд) — то потенциально возможны проблемы на стороне хостинга, и на их решение нужно выделить время.

Если с хостингом все ок, то двигаемся дальше — к времени отрисовки (DOMReady). Нужно понять, есть ли потенциальные проблемы с отрисовкой сайта на экране браузера, есть ли дополнительные задержки на стадии «белого экрана». Для этого воспользуемся сервисами Айри.рф или WebPageTest.

Каждый из них выдаст диаграмму загрузки сайта в браузере, на ней ищем фиолетовую вертикальную линию — это будет время окончания отрисовки сайта. Вторая вертикальная линия (синяя) будет означать время полной загрузки. Хорошо, если первая линия находится на 1-1,5 секундах загрузки сайта, а вторая — раньше 4 секунд. Тогда следующие абзацы можно прочитать «для справки». Если сайт загружается дольше 4 секунд — тогда смотрим ниже, как это исправлять.

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

Хорошим подспорьем в нахождении и решении проблем будет сервис Google PageSpeed Insights, который выдаст готовые рекомендации к применению (главное, не увлекаться дальше оценки 90, иначе толку будет нуль, а времени потрачено — уйма).

Как исправлять проблемы

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

1. Проблемы на стороне хостинга. Проверьте, установлен ли у вас веб-сервер nginx, подключено ли кэширование кода (OpCode кэш), установлены ли кэширующие плагины к движку сайта и оптимизированы ли таблицы базы данных (MySQL). Каждый из пунктов (а иногда — и все вместе) может приводить к задержкам на стороне сервера. Также нелишним бывает проверить время ответа с отключенными плагинами: может быть, какой-то плагин или модуль на вашем сайте создает неоправданно большую нагрузку.
2. Проблемы на уровне отрисовки страницы. Здесь вариантов решения может быть еще больше, и хорошо поможет уже упомянутый Google PageSpeed Insights. Он подскажет, есть ли проблемы с большим количеством стилей или скриптов. Если проблемы есть, то необходимо решение (модуль, плагин или сервис), который объединит все файлы в несколько. Также поможет отключение неиспользуемых модулей/плагинов (это вообще универсальное решение проблем скорости — отключить все).

   Дополнительно нужно проверить, оптимизированы ли шрифты на сайте. Если нет, то нужно исключить из них неиспользуемые символы (глифы).

   И наконец, просмотреть, какие коды (виджеты) используются на сайте. Часто недоступность сторонних сервисов кодов приводит к существенному замедлению загрузки сайта.

3. Проблемы с полным временем загрузки сайта. Если с предыдущими пунктами все более-менее здорово, то можно переходить к долгой загрузке сайта после отрисовки и до события onload. Здесь потенциальных проблем меньше (браузер уже разобрался с рендерингом), и они менее критичны для пользователя (страница уже есть на экране браузера, ее можно изучать). Если сторонние коды и(ли) виджеты вы еще не проверили — то самое время это сделать. Большое количество кодов статистики, кнопок и комментариев тормозят загрузку сайта. Может быть, какие-то из них можно отключить.

   Еще одной, не менее распространенной причиной «тормозов» и «тяжести», может быть большое количество (или неоптимизированные) изображения. Проверьте, что на хостинг вы залили оптимизированные версии файлов (в этом поможет Image Catalyst). Если на странице 100 и более картинок, то лучше будет установить плагин LazyLoad — чтобы изображения загружались в «ленивом» режиме. Также стоит проверить, что реальные размеры изображений совпадают с используемыми на сайте (иногда бывает, что очень большое изображение вставляют в маленьком масштабе: это «забивает» загрузку сайта неиспользуемым графиком).

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

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

В принципе, методы ускорения сайта своими силами можно обрисовать примерно так:

1. Постараться уменьшить число http-запросов, которые браузер посетителя отправляет вашему серверу (где хостится сайт), а также сторонним серверам (аналитика, реклама, кнопки и виджеты соцсетей). Например, каждое изображение используемое на странице (в html коде или в качестве фона в CSS) требует для загрузки отдельного запроса. Каждый файл CCS, Js и прочая статика тоже подгружается отдельным запросом. Значит для снижения числа запросов нужно: все фоновые изображения постараться объединить в спрайты, а также объединить все файлы CSS в один, равно как и файлы стилей JS. Про все это я писал отдельно на примере Вордпресса.
2. На скорость загрузки влияет не только число запросов, но и общий вес загружаемых файлов. Следовательно, следующим шагом будет:
   1. Максимальное сжатие (желательно без потери качества) и оптимизация (отказ от ненужных «погремушек» типа прозрачность и т.п.) всех имеющихся изображений. Способов реализации много (в том числе и онлайн сервисы по сжатию изображений), но я последнее время юзал бесплатную прогу ФайлОптимизер. Сжатие на лету возможно при подключении внешнего сервиса, но об этом чуть ниже.
   2. Сжимать html файлы страниц в Gzip (этот вид архивов браузеры умеют автоматом раскрывать), а так же CSS и JS. Все это, в принципе, можно делать на сервере (как загодя, так и на лету). Другое дело, что не всегда это можно сделать доступными способами (скорее всего потребуется привлекать фрилансера).
   3. Почистить непосредственно код, убрав лишнее и дублирующее содержание.
3. На скорость загрузки еще влияет расстояние от вашего хостинга до компьютера посетителя. Если он с другого конца земного шара, то ждать ему придется существенно дольше чем тем, кто находится в том же городе (или хотя бы регионе). Выходом в этом случае может быть подключение сайта к CDN (сети доставки содержимого). Грубо говоря, копии файлов страниц вашего сайта будут храниться не в одном месте, а сразу на пуле распределенных по всему миру серверов. Каждому посетителю данные будут отдаваться с того сервера, который ближе к нему.
4. Также на скорость загрузки может влиять низкая скорость интернета у посетителя вашего сайта. В современных реалиях такая проблема возникает в основном у мобильных пользователей (не везде 3G ловится). Как я уже упоминал выше, в этом случае самым действенным вариантом (на данный момент) будет отложенная загрузка изображений и виджетов на мобильные устройства. Т.е сначала грузится Html и CSS (текст, разбивка и разметка), а картинки и прочие виджеты (функциональные блоки) подгружаются по мере прокрутки страницы. Как это реализовать самому я не знаю (внешние сервисы это позволяют реализовать).

И это только грубые мазки, ибо есть еще масса нюансов влияющих на скорость загрузки. Например, использование шрифтов не входящих в базовый набор любой ОС замедляет отображение страниц, если их не оптимизировать. Если сайт зарабатывает на показе рекламы, то различные внешние коды ее подгрузки могут конфликтовать и мешать друг другу. Желательно так же, чтобы сначала грузился основной контент (сверхбыстро), а затем все остальное. И об этом нужно думать, учитывать и отлаживать.

После обнаружения всех проблем скорости сайта фронт работ может быть внушительным. Можно сделать его самостоятельно, а можно воспользоваться одним из тарифов Айри для вебмастеров и применить оптимизацию скорости сайта за 25 рублей/день.

Как повысить скорость сайта с Айри.рф

Если взять определение с сайта разработчиков, то:

Айри — облачный SaaS сервис автоматического повышения доступности сайтов за счет применения технологий клиентской оптимизации, проактивной защиты и сети географических серверов, CDN нового поколения. Сайт, подключенный к Айри, получает самую высокую скорость, отказоустойчивость, защиту от атак и DDoS на всех уровнях, и максимальную эффективность работы на всех пользовательских устройствах (от настольных компьютеров до мобильных телефонов).

Кому нужен данный сервис и его услуги? Наверное, всем, кому есть что терять и кто хочет спать спокойно и не переживать за доступность и безопасность своего сайта в режиме 24 на 7. На самом деле это немало, особенно, если вашим основным занятием является ведение интернет-бизнеса, а не постоянная борьба с возникающими проблемами в работе сайта. В случае использования максимальной защиты и ускорения Айри.рф дает вам очень много — спокойствие и чувство «прикрытой спины». Но за это придется платить.

Много платить или мало? По-разному. У них есть тарифная сетка, предусматривающая шесть градаций: от 0 до 50 тысяч рублей в месяц. Сколько именно будете платить вы, зависит от того, какой трафик за месяц генерирует ваш сайт (учитывается только исходящий трафик). Счет выставляется по факту прошедшего через Айри.рф трафика с вашего сайта (отданных гигабайтах вебстраниц).

Давайте посмотрим на примере. Смотрите, если у вас нишевый интернет-магазин (у моего знакомого такой), куда вы привлекаете целевой трафик (например, с Директа или Адвордса), то трафик, скорее всего, большим не будет, а значит стоимость услуг от Айри.рф также высокой не будет. Но что вы получите взамен?

В идеальном случае вы получите:

1. Открывающиеся влет страницы сайта (карточки товаров, фильтры, корзина и т.п.) и связанный с этим некоторый рост конверсии приведет к росту эффективности контекстной рекламы, в которую вы вкладываете, наверняка, немалые средства.
2. Сайты ломают в 99.9% не по наводке, а «под общую гребенку» (например, собрав базу ресурсов на определенном движке). В случае использования Айри.рф этот процесс у злоумышленников вызовет массу непредвиденных затруднений, и они с большой долей вероятности «плюнут на вас» и пойдут искать счастья в другом месте.
3. В принципе, защиту от Ддоса ставить на маленький (нишевый интернет-магазин) не имеет смысла, но вот для крупного ресурса это практически необходимо сделать, ибо «ронять», скорее всего, будут (либо по заказу конкурентов, либо в целях шантажа). В этом случае Айри.рф опять же поможет. В своем блоге они заявляли об отражении Ддос атаки на популярный сайт. Мощность атаки доходила до 10 Гбит/с.
4. Какой бы у вас не был замечательный хостинг, но он все равно когда-нибудь, да бывает в состоянии оффлайна (когда ваш сайт не доступен). Вы можете пользоваться средствами мониторинга доступности сайта и, получив сигнал о проблеме, бежать писать или звонить хостеру, рвать волосы в период решения проблемы, терять нервные клетки и т.д. А можете использовать Айри.рф с соответствующими настройками, и ваши пользователи момент недоступности вообще не почувствуют.

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

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

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

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

Вторым важным фактором является использование большого числа географически распределенных оптимизирующих серверов и кэширующих ДНС серверов. Первые, грубо говоря, хранят копию вашего сайта со сжатыми статическими файлами и находятся во всех крупных городах России. Они позволяют сократить время передачи данных пользователям рунета, т.к. активируется обмен с ближайшим сервером. То же касается и ДНС-серверов, у которых, кроме всего прочего, очень хороший пинг (время ответа).

Теперь давайте чуть детальнее рассмотрим работу Айри.рф по ускорению сайта:

1. Используется CDN (Сеть доставки содержания), которая представляет из себя распределенную по нашей огромной стране (и Европе) сеть оптимизирующих серверов, где осуществляется сжатие всех статических данных сайта (стили, скрипты, изображения, служебные файлы и документы). Сеть позволяет передавать данные с того сервера, который находится географически ближе всего к пользователю, зашедшему на ваш сайт. Это позволяет быстрее получать требуемые данные.
   
2. Как я уже упомянул выше, все статические данные сжимаются и при этом используется прогрессивный алгоритм zopfli, что позволяет получить результаты существенно лучше, чем при использовании gzip. Правда, нагрузка на процессор при этом возрастает примерно в 100 раз по сравнению с gzip, зато декомпрессия в браузере осуществляется с той же скоростью. Ну, а так как нагрузку всю принимает на себя Айри.рф (его CDN сеть), то вы получаете от этого только выгоду, ибо сильнее сжатые файлы вебстраниц, стилей, скриптов и изображений будут передаваться пользователю быстрее.
3. При подключении вашего сайта к Айри.рф, все статические файлы сжимаются «на лету» на этих серверах (после чего хранятся в кэше серверов CDN) и отдаются пользователям гораздо быстрее из-за широких каналов связи, более близкого географического положения и, естественно, за счет в разы уменьшенного объема передаваемых данных. Сжимаются даже медиа-файлы (изображения, PDF, SWF и другие) без потери качества.
4. Объединяются все файлы, передаваемые при запросе страниц, которые можно объединить (делается это при помощи Page Speed, а для защищенных соединений используется SPDY), что позволяет уменьшить количество запросов к сайту, а значит сократить время ожидания при открытии его страниц. Такой метод ускорения загрузки сайта особенно заметен при просмотре сайта.
5. Для мобильных устройств используются отдельные алгоритмы, включая специальные изображения и облегченную верстку сайта.
6. Осуществляется «умное» кэширование динамических страниц, которое хорошо работает для блогов, корпоративных сайтов и интернет-магазинов. Снижение времени ответа сервера на большинство запросов приводит к значительному росту позиций в поиске (на 10-20%).

По поводу обеспечения безопасности сайта средствами Айри.рф. Для отражения хакерских атак используются алгоритмы, блокирующие подавляющее число нежелательных запросов к вашему сайту. В том числе и блокируется обращение непонятных ботов (которые не имеют отношения к поисковикам), что само по себе еще и дополнительно снимает излишнюю нагрузку на ваш хостинг (можно будет использовать более дешевый тариф).

Если вы выберите для себя дорогие тарифные планы в Айри.рф, то для фильтрации будут использоваться уже WAF-фильтры, которые практически стопроцентно защищают от подавляющего большинства возможных атак на ваш сайт (даже от массированных). Наверное, необходимость подключения такой «брони» будет возрастать пропорционально росту популярности вашего ресурса и увеличения рисков взлома «на заказ».

Также в Айри.рф осуществляется защита от Ддос (Ддос — это атака, направленная на создание ситуации, когда ваш сервер отказывает в доступе обычным пользователям из-за того, что на него ломится куча «зомби-компьютеров» из состава какого-нибудь ботнета). Срабатывает несколько уровней защиты:

1. Все запросы к сайту принимаются облаком из безупречно настроенных серверов, это гарантирует обслуживание (сейчас) порядка 50 000 запросов в секунду. Запросы предварительно фильтруются на валидность, это отсекает часть вредоносных атак.
2. При большой частоте запросов они начинают асинхронно отражаться через замедление ответа. Таким образом атаки типа slow-DDoS не проходят.
3. При большой плотности запросов с одного IP-адреса, он автоматически блокируется на уровне системы (iptables).
4. На уровне транспортных атак облако Айри надежно защищено инфраструктурой Ростелекома.

Защита в Айри.рф делится на три типа:

1. Базовая — отражение вредоносных запросов и предотвращение взлома сайта
2. Расширенная — все, что входит в базовую, плюс защита от Ддос атак
3. Максимальная — все, что входит в расширенную, плюс SSL-сертификат для сайта

Подытожить все выше сказанное можно скриншотом, снятым с самого сервиса:

Как ускорить сайт на WordPress с помощью плагина

Скорость – не единственная проблема, с которыми сталкиваются владельцы площадок на Вордпресс. Но плагин WP01 способен решить большинство из них:

1. Подробная техническая информация о сайте (версии CMS, PHP, MySQL).
2. Инструкции для создания резервных копий.
3. Инструменты и описания ручных методов ускорения сайта.
4. Средства и руководства по борьбе со спамом.
5. Информация по SEO-оптимизации.
6. Подбора плагинов.

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

Ускоряться придется каждому, кто заботится о ТОПе поисковой выдачи, ведь в середине июня текущего года стартует один из важных апдейтов – Core Web Vitals. Но популярные движки не готовы к предстоящему обновлению, о чем свидетельствуют данные ежегодного отчета HTTP Archive.

Core Web Vitals является комплексным фактором ранжирования, состоящим из трех показателей: LSP, FID и CLS. Все они связаны со скоростью работы ресурса. И по данным исследования, WordPress и другие движки соответствуют только одному эталонному показателю – FID (задержка после первого ввода). По остальным двух параметрам движки в пролете. Поэтому накануне запуска Core Web Vitals просто кровь из носа важно уметь и знать, как ускорить сайт на Вордпресс. Надеемся, что в этом нам поможет WP01…

Проверка в боевых условиях

Чтобы скачать расширения, перейдите на его страницу в официальном репозитории WordPress. После его установки в боковой панели административной панели движка появляется пункт «Улучшения от WP01».

*при клике по картинке она откроется в полный размер в новом окне

Функционал, входящий в состав инструмента для ускорения сайта на WordPress, можно использовать пошагово («1») или сразу перейти к нужному инструменту, кликнув по соответствующему пункту выпадающего списка («2»).

На первом шаге отображаются технические характеристики составляющих движка («3»):

1. Версию CMS.
2. PHP.
3. MySQL.
4. Доступный лимит оперативной памяти.
5. Путь к файлам движка на хостинге.

В Вордпресс эта информация разбросана по всей админке, а некоторых данных CMS и вовсе не предоставляет. Поэтому приведенные в разделе «Общая информация» сведения позволяют сэкономить время на их поиске.

В правом верхнем углу страницы указана ссылка на инструкцию по созданию резервных копий («4»). Особенно в ней нуждаются не искушенные опытом пользователи.

На втором шаге расширение предоставляет справочную информацию о резервировании данных площадки и базы данных MySQL.

*при клике по картинке она откроется в полный размер в новом окне

В первом блоке слева приводятся общие инструкции по созданию бэкапов с помощью специализированных расширений, скриптов, панели управления хостингом и т.д. («1»). Ниже размещен список руководств по резервированию данных через FTP и созданию копий MySQL («2»).