Почему сайт должен быть максимально быстрым?
Пользователи очень нетерпеливы. Настолько нетерпеливы, что даже доли секунды промедления достаточны, чтобы увеличилось количество тех, кто покинет сайт.
Нередко у вас есть лишь 1-5 секунд для того, чтобы успеть «зацепить взгляд» потенциального клиента. Особенно велико количество таких случаев со стороны аудитории, которая не спешит «уже сейчас заплатить» или имеет обширный выбор альтернатив.
Не успели даже показать сайт, – и потенциальный клиент потерян, и поисковая система записала «отказ». А это – одна из основных метрик, которая влияет на SEO в рамках учета поведения посетителей. Поэтому подобные случаи приносят долгосрочный ущерб.
Общая аудитория сайта тоже восприимчива к его скорости. Это очевидный вопрос удобства и отсутствия у людей бесконечного количества времени.
Такие предположения полностью подтверждает статистика различных интернет-магазинов, которые проводили замеры зависимости конверсии от скорости.
Из чего складывается время загрузки страницы?
-
Установка соединения между посетителем и сервером.
Особенно значимо, если посетитель далеко от хостинга или используется HTTPS.
Если аудитория сайта шире, чем 1 город, то улучшить можно только с помощью CDN. -
Генерация самой страницы в CMS.
Для большинства сайтов это самый медленный этап, который оптимизируется более быстрым хостингом, кешами и рядом других способов. -
Передача страницы посетителю.
Самое очевидное, – чем больше данных, тем дольше пересылать. Поэтому минификация и максимальное сжатие, – входят во все стандартные рекомендации.
Но размер почти любой страницы после сжатия крайне мал и на деле, куда большую роль тоже играет расстояние между посетителем и сервером. -
Передача стилей, скриптов, картинок и других сопутствующих файлов.
На это влияет как описанное в предыдущем пункте, так и дополнительные факторы:
– правильное использование картинок (форматы и размеры);
– минимизация количества файлов;
исключение повторной загрузки неизменных файлов (Expires-заголовки, т.е. кеш в браузере посетителя).
Также, при отсутствии CDN, обязательно нужен хостинг с SSD для исключения банальных задержек в начале передачи. -
Рендеринг.
Непосредственно отрисовка страницы в браузере пользователя обычно начинается раньше, чем завершается передача всех файлов.
Имеет значение правильность последовательности загрузки сопутствующих файлов. Причём, в зависимости от конкретного сайта, она может отличаться и даже противоречить тому, что рекомендуют различные сервисы (например, Google.PageSpeed).
Объёмная или неправильная javascript-обработка также замедляет процесс, но обычно исправление таких аспектов слишком трудоёмко.
Поэтому чаще всего намного проще и важнее, – максимально приблизить момент начала обработки, т.е. ускорить само получение файлов.
Что и как ускоряем?
Простым подключением к FireCDN-сети WSR, можно сразу улучшить почти все факторы:
-
Интеллектуально кешируется динамический контент.
Для большинства сайтов очень многие страницы отдаются посетителям моментально из кеша, а не зависят от скорости генерации в CMS. И для этого не требуется ничего устанавливать на сайт или сервер. -
Каждый посетитель получает данные с сервера, который расположен близко к нему.
Повышает и скорость соединения, и общую скорость доставки абсолютно всех кешированных данных.
А также и запросов, которые может начать выполнять FireCDN вместо вашего веб-сервера (например, различные редиректы; как обычные, связанные с HTTPS\WWW, так и более сложные на основе страны посетителя или других условий). -
Колоссально падает нагрузка на ваш хостинг.
Это обеспечивают кеширование, блокировка вредоносных и ненужных запросов файрволом, а также избавление от обработки HTTPS.
Снижение нагрузки может повысить скорость генерации страниц в CMS за счет освободившихся ресурсов, а также общую стабильность в пиковые моменты. -
Гарантируется идеальность сжатия и различных технических заголовков.
Даже в вопросах GZIP и Expires до сих пор можно встретить немалое количество неправильно работающих сайтов. А тонкие детали, как например, добавление Retry-After в случае ошибок, часто не имеет смысла реализовывать самостоятельно, но приятно получить автоматически.
Как подключить?
Система автоматической настройки склонирует вашу DNS-зону и подберёт основные базовые параметры. Поэтому после регистрации, в основном, достаточно просто указать домен и изменить DNS.
А ручное вмешательство требуется для сайтов с HTTPS, GeoIP, внутренними защитами и для некоторых других нечастых случаях. Такие ситуации рекомендую тестировать с помощью hosts-файла перед подключением (в справке есть подробная инструкция), также можно просто попросить техподдержку проверить корректность.
Если не прочитали описание сервиса, может удивить наличие этапа с указанием FTP-доступов. Его можно пропустить, но рекомендую указать. Тогда будет немного проще и одновременно подключится интегрированная система бэкапов с антивирусом, контролем изменений и возможностью быстрого восстановления напрямую на хостинг.
Как максимально оптимизировать скорость?
Любой сайт сразу в любом случае станет быстрее и получит экономию ресурсов сервера. При желании, можно ничего не настраивать и ограничиться стандартным эффектом или прямо в интерфейсе заказать индивидуальную настройку.
Основная оптимизация в том, что не для всех сайтов кеширование страниц сразу же окажется полным, а это даёт наибольшие преимущества. Благо, для большинства сайтов, где отсутствует бэкэнд-уникализация контента для общей аудитории (например, блоки ранее просмотренных страниц), достаточно активировать настройку «оптимизация куки для анонимных посетителей».
Это простое, универсальное и очень эффективное решение. Алгоритм работы состоит в том, что посетитель получает кешированные версии страниц до тех пор, пока не сделает какое-либо функциональное действие (авторизация, комментирование, добавление в корзину и т.д.). Таким образом, даже в сложных магазинах и сервисах кеш никак не мешает функционалу.
Ещё очень полезно ограничить список используемых в CDN стран и городов, а также активировать защиту админки, блокировку XML-RPC и другие параметры безопасности.
Перед дальнейшими действиями желательно день-другой проконтролировать раздел статистики, где стоит проверить адекватность количества сбросов кешей и их эффективности.
В «расширенном» режиме почти всегда можно и кеши, и защиту сделать ещё лучше. Это не столь тривиально, как базовые настройки. Но и эффективнее, и всё равно быстрее, чем самостоятельная реализация на уровне сайта или Varnish. Гибкость даже чуть выше и можно обработать любые самые сложные случаи (например, отдельные кеши для разных стран или разных пользовательских настроек: языков, валют и т.д.).
Итоги
Скорость загрузки стандартной страницы во многих городах РФ, СНГ и всего мира можно снизить до уровня 0.01-0.08сек.
Web Support Revolution по сути заменяет собой сочетание «Varnish+Cloudflare+хороший специалист», только с рядом ключевых преимуществ:
-
Несравнимо проще.
Хороший эффект удаётся в несколько кликов. А углублённая настройка во всех смыслах доступнее, чем альтернативы. -
Сайт работает быстрее.
Кеш на своём сервере это очень хорошо. Но не может быть ничего быстрее, чем кеш, который уже на момент запроса находится физически близко к посетителю, т.е. в самой CDN-сети. -
Ещё быстрее и надёжнее в РФ, СНГ, Прибалтике и ряде других регионов.
Благодаря более широкому охвату CDN. А также исключению возможности оказаться на IP-адресе, который заблокирован РКН, что стало случаться у CF. -
Дополнительный функционал повышает аптайм и делает жизнь вебмастера проще.
Помимо бэкапов с антивирусом и бесплатного SSL от Let’s Encrypt всем пригодится мониторинг с удобными уведомлениями, который работает в паре с эффективной системой поддержки аптайма при сломанном хостинге. Не для всех, но очень интересны возможности балансировки и отказоустойчивости с многосерверными системами, синхронизации данных и многое другое.