+7 (925) 507-98-19
к.э.н. Лавлинский Н. Е., технический директор ООО «Метод Лаб»
Метод Лаб несколько лет плотно занимается вопросами веб-производительности и ускорением сайтов. При этом у нас есть собственный опыт веб-разработки и проекты. Когда мы берём очередной проект на ускорение, невольно начинаешь задумываться о том, как сделать максимум возможного. Хочется сделать сайт по-настоящему быстрым, доступным для пользования даже при медленном мобильном соединении. Однако, часто мы упираемся в предел, дальше которого ускорить сайт не удаётся. Почему так происходит и кто виноват? Попробуем разобраться в проблеме.
Для многих людей процесс ускорения загрузки сайта может показаться магией: внешне то же самое, но загружается и работает быстрее. На самом деле процесс ускорения часто стандартный и содержит несколько этапов, часть из которых ручные, а часть – автоматизированные. Набор методик для ускорения широкий, постоянно появляются новые технологии для ускорения. В целом все они направлены на то, чтобы передавать как можно меньше данных и как можно быстрее давать пользователю контент и функциональность веб-приложения. В последнее время также обращают внимание на плавность анимации и скроллинга, а также на отзывчивость (время реакции интерфейса).
Для дальнейшего повествования важно напомнить, чем определяется скорость загрузки сайта: это клиентская и серверная части. Серверная часть – время генерации HTML-документа (или другого ответа бекенда). Клиентская часть – совокупность стилей CSS и кода JavaScript, картинки и другие элементы интерфейса (как правило, это обычные файлы, поэтому мы называем их статикой).
Как же происходит ускорение сайта и где мы упираемся в предел? Для ответа на этот вопрос посмотрим отдельно на каждый из видов ускорения сайтов.
Это наиболее удобный способ ускорения сайта с точки зрения заказчика. Существуют различные предложения по облачному ускорению как в России (Айри.рф), так и за рубежом (Cloudflare, Akamai, Incapsula).
Серверная часть принципиально ускориться с помощью облака не может, так как запросы от пользователя к серверу просто пропускаются через дополнительные узлы сети CDN и время ответа сервера остаётся тем же, плюс задержки от сервера до узла CDN. Единственный вариант – кэширование страниц на стороне CDN. Далеко не всегда такое решение возможно, а если и возможно, то его легко реализовать на собственном сервере. Таким образом, серверная производительность становится ограничителем в процессе ускорения сайта.
Перейдём к клиентской части. Здесь облако предлагает там прежде всего сжатие текстовых документов (html, css, js) и оптимизацию картинок (как правило, без потери качества). Максимум, что возможно сделать в облаке – отложить исполнение и загрузку JS. Здесь мы утыкаемся во второй ограничитель: облако никак не сможет понять, какой код используется на странице, а какой просто увеличивает вес сайта и тормозит загрузку. Вообще, эта задача нетривиальна и требует тщательной ручной работы, однако может дать значительные результаты.
Что касается общей верстки шаблонов и внутреннего строения сайта: автоматика изменить ничего не сможет. Например, в шапке сайта слайдер с 10 картинками шириной 1920 пикселей. Можно оптимизировать картинки, сжать CSS и JS слайдера, но принципиально ускорить такую конструкцию невозможно.
Таким образом, простота подключения и быстрый результат оборачиваются ограничениями по оптимизации как с серверной стороны, так и с клиентской.
Этот процесс отличается от полностью автоматического участием профессионального специалиста по ускорению. Сначала проводится анализ проблем сайта, далее решаются наиболее важные из них, в порядке воздействия на скорость загрузки.
Если есть проблемы с серверной частью веб-приложения, есть несколько вариантов простого решения: тюнинг окружения (как правило СУБД, интерпретатор, веб-сервер) или смена хостинга. Эти решения не всегда дают нужный эффект (иногда сайт уже работает на мощном выделенном сервере и расти особенно некуда). В этом случае можно найти узкое место системы и исправить его (часто проблема в неудачном SQL-запросе). Для такой меры нужна работа разработчика и его компетенция в серверном языке программирования. Если ускорить серверную часть сайта простыми методами не удаётся, мы получаем ограничение скорости сайта, которое можно сгладить только кэшированием.
По клиентской части выбор методов оптимизации становится шире, чем при использовании автоматизации. Мы можем найти не спользуемый на сайте (или отдельном шаблоне) код (JS, CSS) и полностью избавиться от него (максимальный эффект ускорения – не грузить вообще). Остальные ресурсы клиентской части можно оптимизировать, исходя из логики сайта: некоторые ресурсы отправить в пост-загрузку, что-то отложить, что-то наоборот, загрузить как можно раньше. Это кропотливая работа, дающая значительный эффект для реального пользователя (ощущение скорости).
Как мы убедились, при любом способе ускорения сайтов рано или поздно наступает предел, дальше которого продвинуться не получается. Что, если вы хотите дойти до конкретного результата, установить жёсткий бюджет на время загрузки страниц? В этом случае требуется более глубокое вмешательство в программный код и дизайн сайта. Обратите внимание, что большинство кейсов крупных компаний, которые получали реальный экономический эффект от ускорения, связаны с глубоким рефакторингом их веб-приложений.
Такие изменения требуют владения кодом, то есть либо производятся самими разработчиками, либо совместно с ними. По сути, можно говорить о процессе разработки с целью повысить производительность.
Основные сложности будет вызывать аргументация такой переработки сайта, потому что внешних изменений (фич) в результате не будет, только увеличение скорости работы. При этом затраты на такой процесс будут значительными. Заранее оценить положительный эффект от ускорения крайне сложно – понятно, что будет лучше, но насколько никто не знает.
Получается, что ускорение медленных сайтов ограничено пределами способа (автоматическое или ручное) и может не достигнуть требуемых показателей скорости проекта. Чтобы преодолеть эти пределы, требуется значительная переработка кода сайта с привлечением полной команды разработчиков, что сложно оправдать экономически.
Как же получить действительно быстрый сайт самым прямым путём?
Ответ прост и сложен одновременно. Нужно внедрить стандарты веб-производительности в процесс разработки, на всех этапах – от концепции дизайна до эксплуатации. Только в этом случае возможна реализация паттернов от Google: PRPL, RAIL и любых других.
Учитывая вопросы скорости во время процесса разработки, получится сэкономить на отдельных процедурах ускорения и оптимизации. При этом, разработчики будут работать в текущем контексте, без необходимости разбирать старый код, написанный годы назад. За счет более прямолинейного процесса, накладные расходы на производительность могут быть невысоки. После накопления критической массы опыта, разработчики перейдут в режим «быстро по умолчанию», то есть будут выполнять требования по скорости приложения автоматически.
Далее наступает этап эксплуатации проекта. Вот здесь можно вспомнить оптимизирующие CDN, которые отлично подойдут для решения следующих задач:
Именно при комбинации процесса разработки «для скорости» и автоматической оптимизации на этапе эксплуатации можно добиться максимального эффекта и приблизиться к идеально быстрому сайту.
За профессиональным ускорением сайтов обращайтесь к нам.
