Большинство из нас ищет ответы на свои вопросы в Google или спрашивает у искусственного интеллекта. Но можем ли мы доверять найденной информации?
Поскольку одна из наших основных специализаций — работа над скоростью сайтов, мы решили посмотреть, что пишут об этом коллеги по отрасли. И были шокированы: среди первых результатов выдачи не нашлось ни одного сайта, который бы корректно отвечал на вопросы этой темы.
Это объясняет и то, почему искусственный интеллект на общие вопросы выдаёт похожую, часто ошибочную информацию — ведь он обучается именно на таких сайтах. Чтобы получить от ИИ более корректный ответ, ему нужно задавать достаточно специфичный вопрос — тот, который вряд ли сформулирует человек, который только начинает разбираться в теме.
Информация в тематических статьях в лучшем случае раскрыта неполно и требует уточнений. Например, когда в одном перечне «обязательных» рекомендаций рядом подают вещи, необходимые практически каждому сайту (как GZIP−сжатие), и вещи, нужные лишь в редких специфических условиях (как CDN) — так, будто всё перечисленное одинаково необходимо каждому сайту.
Но встречаются и утверждения, которые выходят далеко за рамки здравого смысла.
Вероятно, это связано с тем, что подобные статьи часто пишут копирайтеры, которые сами не разбираются в теме. Хотя, если честно, специалистов, которые действительно хорошо владеют вопросом скорости сайтов, тоже немного.
На подобных статьях учатся и разработчики — и впоследствии внедряют вещи, которых сами не понимают. Мы нередко сталкиваемся с этим в работе и даже ввели внутренний термин для сайтов, получивших проблемы из−за бездумного внедрения таких рекомендаций, — «жертва оптимизации».
Поэтому, чтобы таких жертв оптимизации становилось меньше, мы решили прокомментировать наиболее ошибочные тезисы из подобных статей, а также самые популярные утверждения, которые хоть и близки к истине, но требуют уточнения.
Какой должна быть скорость сайта?
Начнём с вопроса, за сколько секунд должен загружаться ваш сайт. На разных ресурсах эти цифры отличаются, но дело даже не в конкретных цифрах — дело в том, что предельного показателя как такового не существует. Нельзя сказать, что сайт, который загрузился за 2,9 секунды, — это хорошо, а за 3,1 секунды — уже плохо. Скорость — это параметр, который имеет смысл только в сравнении. Вопрос в том, с чем именно сравнивать.
Можно сравнивать со скоростью конкурентов — если есть риск, что клиент уйдёт к ним из−за более медленного сайта. Можно сравнивать со средней скоростью сайтов в своей нише — чтобы понимать, чего вообще ожидает типичный пользователь. Можно сравнивать с нормой для конкретного технологического стека или движка сайта. А можно — с теоретическим идеалом. Каждый из этих подходов по−своему полезен и вместе даёт полную картину. Но ни разу среди них нет точки, после которой о скорости можно забыть раз и навсегда — ведь сама скорость нестабильна: завтра может вырасти нагрузка на сервер, и показатель, который ещё вчера был «нормальным», просядет.
И главное — нельзя подгонять все сайты под один критерий. Если мы измеряем скорость, нужно каждый раз уточнять: на каких устройствах, с какой скоростью сети, под нагрузкой или без, и о каком типе сайта вообще идёт речь. То, что будет отличным показателем для интернет−магазина с тысячами товаров, может оказаться совершенно неприемлемым для простого одностраничного лендинга.
Также в этом отрывке упоминается исследование 2012 года, которое якобы обнаружило, что люди замечают замедление сайта на 4 миллисекунды. На самом деле здесь ошибка: речь в оригинальном исследовании шла о 400 миллисекундах, а не о 4. Эту цифру часто упоминают в статьях о скорости, и на одном из сайтов даже стояла ссылка на первоисточник — что меня сначала приятно удивило. Но оказалось, что эта ссылка ведёт на журналистскую статью, а не на само исследование. И что особенно забавно: само исследование провели ещё в 2009 году, а в 2012−м вышла та самая журналистская статья — и именно на неё, судя по всему, все и ссылаются, когда пишут о «исследовании 2012 года».
Итак, я нашёл оригинал. Речь там идёт не о сайтах вообще, а конкретно о странице результатов поиска Google. К сожалению, исследователи не указали, какой была начальная скорость загрузки — они просто начали искусственно замедлять выдачу и смотреть на реакцию пользователей. Первые изменения в поведении зафиксировали уже при задержке в 100 мс, а максимальный эффект — при задержке в 400 мс (почему−то именно на этом исследование и остановилось). Так вот: при задержке в 400 мс поиском стали пользоваться меньше — всего на 0,59%. И эта цифра стала статистически заметной лишь благодаря миллиардным масштабам аудитории Google. Если бы подобный эксперимент проводили на количестве пользователей, которое у среднего интернет−магазина не наберётся даже суммарно за всю жизнь сайта, эффект вполне мог бы затеряться в обычном шуме данных и вообще никак не проявиться. Поэтому будьте осторожны с подобными манипуляциями цифрами — то, что статистически доказано на миллиардах, автоматически не означает применимость к вашему проекту.
Скорость действительно очень важна для первого впечатления. Но наш опыт показывает: когда у среднестатистического сайта случаются проблемы со скоростью, которые не превышают порог адекватности (условно 5−6 секунд), это почти незаметно сказывается на продажах. Конечно, для проектов с аудиторией уровня Розетки даже небольшое замедление будет ощутимым. Но не стоит забывать, что скорость — далеко не основной критерий выбора сайта. Если ваше предложение ничем не лучше конкурентов, а сайт при этом работает значительно медленнее — вы действительно рискуете. Но если у вас есть реальные преимущества, то эти самые 400 мс бизнес не сломают.
Что влияет на скорость загрузки сайта?
Нам предлагают перечень значимых факторов, влияющих на скорость сайта. Рассмотрим каждый из них.
«Чистота» HTML−кода и его объём
Под чистотой кода обычно подразумевают его аккуратность и отсутствие лишних элементов. Эта чистота никоим образом не влияет на скорость — так же, как и валидность кода, о которой тоже нередко пишут в подобном контексте. Лишние элементы действительно могут увеличить объём кода, и именно это уже отразится на скорости. Но хотя теоретически можно получить HTML−файл весом в несколько мегабайт, на практике мы никогда не видели, чтобы размер этого конкретного файла был хоть сколько-нибудь похож на реальную проблему. Так что непонятно, что этот пункт вообще делает в перечне значимых факторов.
Качество и формат изображений на странице
Качество и формат изображений даже опосредованно не обязательно на что−то указывают. Имеет значение именно вес этих изображений — а качество и формат лишь инструменты, которыми этот вес регулируют.
Наличие видео на сайте
Видео станет проблемой, только если загружать его вместе со страницей. Но существует несколько способов добавить видео на сайт без замедления загрузки.
Количество запросов от браузера
К сожалению, этот пункт довольно часто встречается даже в свежих статьях. Проблема количества HTTP−запросов была актуальна во времена протокола HTTP первой версии, когда браузер мог одновременно загружать с одного домена не более двух файлов. Сегодня количество запросов практически утратило актуальность.
Количество установленных плагинов
Хотя можно заметить, что на сайтах с большим количеством плагинов часто возникают проблемы со скоростью, само по себе количество плагинов не является причиной. Есть плагины, которые вообще не влияют на быстродействие сайта. Точнее будет сказать, что на скорость влияет количество некачественных (медленных) плагинов, задействованных в формировании фронтенда.
Что упущено в этом перечне
В нём не хватает нескольких очень важных факторов.
- Качество программного кода. Это один из самых значимых факторов, неразрывно связанный с мощностью сервера. Программный код ставит задачи на вычисление, а сервер предоставляет мощность для этих вычислений. Поэтому задачи должны быть сформулированы так, чтобы требовать как можно меньше вычислений, а мощностей должно хватать, чтобы обрабатывать больше задач одновременно.
- Качество и структурированность базы данных. Самое простое, что можно сказать о базе данных, — это индексы. Это что−то вроде алфавитного или хронологического указателя в библиотеке, который позволяет быстро находить нужное по определённым параметрам. Но работа с базами данных может быть значительно более специфичной, чем этот пример.
- Скорость интернета. Скорость сети неразрывно связана с весом файлов сайта. Чем быстрее сеть, тем быстрее передаются файлы.
- Количество свободных ресурсов на устройстве пользователя. Мы часто забываем, что половину работы выполняет сервер, а вторую половину — устройство пользователя. И если у пользователя мало свободных ресурсов, сайт будет тормозить даже при идеальной работе сервера.
О тезисе «нет ничего, что невозможно исправить»
Не хочется придираться к буквальной физической возможности на что−то повлиять — хотя, например, на скорость сети или устройство пользователя мы действительно не имеем влияния. Но даже если отбросить это, в реальности остаётся немало других ограничений.
Например, как разработчики мы не можем повлиять на расположение сервера, если заказчик решил во время войны держать его за границей. Есть и экономические факторы, влияющие на объём серверных ресурсов, — они не бесплатны, и могут стоить очень дорого. Так что ограничений хватает. Но даже с ними остаётся огромное количество инструментов для работы над скоростью.
Замена или оптимизация хостинга
Очень часто пишут о замене хостинга, но из−за неудачных формулировок это нередко приводит к недопониманию и лишним переездам.
Буквально, хостинг — это просто процесс размещения сайта на сервере. Но в нашей культуре хостингом обычно называют то, что в англоязычном мире известно как shared hosting — специфическое размещение многих сайтов на одном сервере, где они делят между собой вычислительные ресурсы.
Если сайт начал медленно работать на таком хостинге, скорее всего, дело именно в нехватке процессорных ресурсов. И на другом таком же shared−хостинге вы вряд ли найдёте их больше — ведь проблема не в конкретном провайдере, а в самой модели размещения. На этом этапе вам нужны уже гарантированные ресурсы, а значит — стоит планировать переезд на VPS, а не очередной переезд между shared−хостингами.
Сжатие изображений
В этом примере есть рекомендации, которые я бы назвал опасными.
Вы можете открыть сайт на смартфоне или на десктопном устройстве, и выглядеть он будет по−разному, но корректно (надеюсь). Это не случайность — это результат подготовки сайта, его вёрстки и контента к работе на разных устройствах с разным разрешением. При этом у каждого сайта всегда есть минимальная ширина, после которой может появиться горизонтальная прокрутка, и максимальная ширина, после которой появляются поля по краям. Так что вопрос в том, какая именно максимальная ширина у вашего сайта. Если вы хотите, чтобы она достигала 4K, то вам действительно могут понадобиться изображения в 4K для фонов или баннеров. Но они не должны загружаться при меньших разрешениях — и особенно на смартфонах. Другими словами, нужна грамотная работа с адаптивностью контента.
Нельзя говорить, что изображение товара должно иметь какой−то конкретный, заранее определённый размер в пикселях. Изображение не должно быть больше того размера, в котором оно максимально показывается на сайте — а это не всегда наибольший размер именно на десктопе. Например, на планшете количество товаров в ряду каталога часто уменьшается по сравнению с десктопом, и из−за этого само изображение товара может отображаться в большем физическом размере, чем на широком экране. Всё зависит от конкретной вёрстки конкретной страницы.
Так же нельзя ориентироваться на цифры веса файлов. О каких именно файлах тут вообще идёт речь? О баннерах или о фото товара? Очевидно, что они будут иметь разный размер по своей природе. И даже при одинаковом разрешении и одинаковых параметрах сжатия размер готового файла может сильно отличаться — в зависимости от сложности самого изображения.
Ну и вишенка на торте — GZIP. GZIP предназначен для сжатия текстовых файлов. Их он действительно может сжать в разы. А вот изображениям он не даст практически ничего, если это не текстовый формат вроде SVG.
Подробнее о работе с изображениями читайте в нашей статье «Какой формат изображений лучше для сайта: JPEG, PNG, WebP или AVIF?».
Сжатие GZIP
Как мы уже разобрали ранее, GZIP — это технология сжатия именно текстовых файлов. Она способна сделать эти файлы значительно легче, но никоим образом не уменьшает их количество — то есть никак не влияет на количество запросов к серверу (хотя, как мы уже говорили, актуальность самого показателя количества запросов давно утрачена). И GZIP не привязан исключительно к протоколу HTTP/1.1, хотя именно такое впечатление может сложиться из формулировки в оригинале — это технология сжатия данных, которая так же работает и в HTTP/2, и в HTTP/3.
Оптимизируйте CSS и JavaScript
Почти всегда советуют заниматься минификацией файлов — то есть удалять отступы, комментарии, переносы строк. Технически весь код можно записать в одну строку, и он так же будет работать. И да, такой файл будет занимать меньше места.
Для примера приведу одну из самых распространённых библиотек для сайтов — Bootstrap. В обычном состоянии этот файл весит 281 КБ, а в минифицированном — 233 КБ. Разница составляет 48 КБ, что не так уж и мало.
Библиотека — это файл с большим количеством готового кода, который упрощает внедрение определённого функционала. В данном случае речь идёт о библиотеке для вёрстки.
И тут важно разделять две разные категории файлов: те, с которыми непосредственно работает разработчик, и библиотеки (библиотеки разработчики обычно не редактируют, или редактируют минимально).
Файлы, с которыми постоянно работает разработчик, не стоит держать в минифицированном состоянии. С таким кодом очень тяжело и неприятно работать, а значит и сама работа обходится дороже. Комментарии в коде, как правило, очень полезны — разработчик оставляет их для себя на будущее или для коллег как пояснение логики. Они могут существенно упростить доработки. Так что минифицировать такие файлы смысла не имеет, в отличие от библиотек, с которыми напрямую никто не работает.
Но тут стоит помнить ещё одну вещь — мы же используем GZIP, который выполняет подобную оптимизацию «на лету».
Так вот: после сжатия тот же файл библиотеки в обычном состоянии весит 33,5 КБ, а в минифицированном — 30,9 КБ. Разница составляет всего 2,6 КБ. И это на большой библиотеке — на рабочих файлах проекта разница будет вообще незаметной.
О подключении CSS и JS в разных местах страницы
Если не настраивать отложенную или асинхронную загрузку, расположение файлов в коде само по себе не влияет на общую скорость полной загрузки страницы. Файлы CSS, которые отвечают за оформление, могут загрузиться, и сайт будет выглядеть корректно, тогда как файлы JS, которые отвечают за функциональность, ещё не успеют загрузиться. Это может привести к ситуации, когда посетитель пытается открыть мобильное меню, а оно ещё не работает. И тут возникает вопрос: поймёт ли он, что нужно просто подождать, или решит, что на сайте баг, и уйдёт?
В целом с загрузкой скриптов стоит быть осторожными. Часто советуют загружать их асинхронно, но при этом теряется контроль над порядком загрузки — а иногда этот порядок критически важен.
Лучшее, что можно посоветовать в отношении этих файлов, — не допускать аномального разрастания их количества. Если у вас от 2 до 10 файлов каждого типа, они вряд ли создадут какие−то проблемы. А вот если их 30−60, то, скорее всего, проблема уже не в самих файлах, а в том, как в целом построен сайт.
Оптимизация базы данных
Оптимизация базы данных — очень важный процесс, и одновременно довольно сложный и вариативный, чтобы описать его в нескольких предложениях. Но то, о чём идёт речь в этом отрывке, очень далеко от реальной оптимизации.
В базе данных хранится контент сайта и его настройки. Поэтому там обычно не бывает ненужной информации, тестовых данных или копий, которые постоянно накапливаются и якобы требуют регулярных чисток. А вот спам — например, в отзывах — вполне возможен и действительно может накапливаться.
Но само разрастание базы данных само по себе не приводит к замедлению сайта. Если у вас в базе много товаров, это может повлиять на скорость загрузки именно страниц с товарами, но никак не отразится на скорости других страниц, где товаров нет. И с проблемой «база переполнена товарами» удалением не справиться — товары ведь не спам, их не уберёшь просто так. Тут нужна уже реальная оптимизация структуры базы данных и оптимизация программного кода, который с ней работает.
Внедрение кеширования
Браузерное кеширование — очень полезная вещь, и тут могу только поддержать рекомендацию его использовать.
Серверное кеширование действительно может существенно сократить время ответа сервера, но тут есть свои побочные эффекты. Подробнее об этом читайте в нашей статье «Кеширование страниц сайта: подводные камни, о которых часто молчат».
Использование серверов Nginx и Apache для размещения информации
Эта рекомендация не имеет никакого смысла.
Существует два популярных веб−сервера — Nginx и Apache. Если у вас есть сайт, он работает на одном из них. То есть это обязательное условие для работы любого сайта, а не опция для ускорения. Альтернативы, конечно, существуют, но они настолько редкие и специфичные, что случайно на них вряд ли наткнётесь. Нет никаких оснований говорить, что один из этих серверов «быстрее», а другой «мощнее» (хотя вопросы скорости и мощности применительно к сайтам настолько тесно связаны, что фактически являются синонимами). И, конечно, сами по себе эти веб−серверы не делают ничего из того, что перечислено в оригинальном тексте.
Как видите, даже в топе поисковой выдачи по теме скорости сайтов материалы изобилуют ошибками — от безобидных упрощений до утверждений, которые противоречат самим основам того, как работает браузер или сервер.
Чтобы защитить себя от некомпетентных рекомендаций, стоит хоть немного разобраться в вопросе самостоятельно. Когда понятна общая логика, абсурдные утверждения становятся заметны сразу. Для этого рекомендуем ознакомиться с нашими статьями на эту тему:
