Безопасность сайта: базовые меры защиты
Взлом сайта почти никогда не выглядит как в кино. Чаще всего это тихое заражение, о котором владелец узнаёт от поисковой системы, от хостинга или от…
Медленный сайт теряет посетителей раньше, чем они успевают прочитать первый заголовок. Человек нажал на ссылку, подождал несколько секунд, увидел белый экран и вернулся в поисковую выдачу. Разбираем, из чего складывается скорость загрузки, какие причины тормозят сайты чаще всего и в каком порядке их лечить, чтобы получить заметный эффект без переписывания проекта с нуля.
Владельцы сайтов часто воспринимают скорость как техническую метрику для разработчиков: есть какой-то балл в тестере, он красный или зелёный, и на этом разговор заканчивается. На практике скорость напрямую связана с тремя вещами, которые видны в отчётах о продажах.
Отдельно стоит сказать про рекламу. Если вы платите за клик в контекстной рекламе, а страница открывается медленно, часть оплаченных переходов вы теряете ещё до того, как посетитель увидел предложение. Ускорение сайта в таком случае работает как скидка на рекламный бюджет.
Прежде чем что-то менять, нужно понять, с чем вы работаете. Одного замера главной страницы недостаточно, и вот почему.
Тестеры скорости, которыми пользуются все, показывают лабораторные данные: страница загружается в контролируемых условиях с заданной скоростью сети и мощностью устройства. Это удобно для сравнения «до и после», но не отражает того, что видят реальные люди. Реальные данные собираются от настоящих посетителей через браузер и показывают распределение: у кого-то сайт открывается быстро, у кого-то в несколько раз медленнее. Смотрите оба источника и ориентируйтесь на худшие сценарии, а не на средние.
Проверять нужно не только главную. Для интернет-магазина минимальный набор такой: главная, страница категории с фильтрами, карточка товара, корзина, оформление заказа, страница поиска. Для корпоративного сайта: главная, страница услуги, блог, контакты. Именно внутренние страницы чаще всего оказываются самыми тяжёлыми, потому что на них много изображений, фильтров и динамических блоков.
| Показатель | Что означает | Что обычно его портит |
|---|---|---|
| Время ответа сервера | Сколько проходит до первого байта страницы | Слабый хостинг, медленные запросы к базе, отсутствие кеша |
| Отрисовка главного блока | Когда на экране появляется основной контент | Тяжёлые изображения, блокирующие скрипты и стили |
| Стабильность вёрстки | Прыгает ли страница во время загрузки | Картинки без заданных размеров, баннеры, подгружаемые шрифты |
| Отзывчивость | Как быстро сайт реагирует на нажатие | Избыток скриптов, тяжёлые виджеты и счётчики |
За годы работы с проектами мы заметили закономерность: причины медленной загрузки повторяются от сайта к сайту. Ниже перечислены основные, в порядке частоты.
Это причина номер один. Менеджер загружает фотографию товара прямо с телефона или от поставщика, и в карточку попадает файл в несколько мегабайт, который на экране отображается в размере небольшого квадрата. На странице категории таких картинок двадцать-тридцать, и вес страницы достигает десятков мегабайт.
Что делать:
Со временем сайт обрастает счётчиками, пикселями, онлайн-консультантами, виджетами обратного звонка, подписками, всплывающими окнами. Каждый из них подгружает собственные файлы, часто с чужих серверов, и каждый может подтормаживать. Хуже всего, когда несколько сервисов делают одно и то же: два разных счётчика посещаемости или три всплывающих окна подряд.
Проведите ревизию: выпишите все подключённые сервисы и честно ответьте, кто и зачем ими пользуется. То, чем никто не пользуется, отключайте. То, что нужно, подключайте с задержкой, чтобы они не мешали показать основное содержимое.
Если сервер отвечает больше секунды, то никакая оптимизация картинок не спасёт. Причины бывают разные: тариф для небольшого сайта, на котором живёт магазин с тысячами товаров; соседи по общему серверу, которые забирают ресурсы; устаревшая версия языка программирования на сервере; отсутствие кеширования, из-за чего каждая страница собирается заново при каждом запросе.
Кеширование здесь ключевое. Страница каталога, которую открывают сотни раз в день и которая меняется раз в сутки, не должна пересчитываться при каждом посещении. Серверный кеш, кеш запросов к базе и кеш в браузере посетителя вместе дают самый значительный выигрыш при минимальных вложениях.
В интернет-магазине база данных разрастается: заказы, сессии, логи, остатки, история изменений, временные данные импорта. Если за ней не следить, запросы начинают выполняться дольше, особенно в каталоге с фильтрами и поиском. Регулярная очистка временных данных, проверка индексов и анализ медленных запросов часто сокращают время ответа в разы.
Подключение пяти начертаний двух разных шрифтов выглядит безобидно, но каждое начертание это отдельный файл. Если к этому добавить стили, которые блокируют отрисовку, и скрипты в начале страницы, браузер долго не может показать ничего. Оставляйте только те начертания, которые реально используются, и загружайте шрифты так, чтобы текст появлялся сразу системным шрифтом, а затем заменялся.
Сайты, которые несколько раз перерабатывали разные подрядчики, нередко содержат модули, которые давно не используются, но продолжают подключаться и выполнять запросы. Старые версии библиотек, дублирующиеся стили, остатки прежних дизайнов. Такой груз накапливается незаметно и убирается только аудитом кода.
Чтобы не потеряться в десятках возможных улучшений, мы действуем по одной схеме. Она подходит и для небольшого сайта-визитки, и для магазина с большим каталогом.
Проверяем ключевые страницы в лабораторных тестах и смотрим реальные данные посетителей. Сохраняем результаты, чтобы потом можно было честно сравнить.
Сжимаем, уменьшаем, переводим в современные форматы, включаем отложенную загрузку. Это самый быстрый и безопасный шаг с самым заметным эффектом.
Настраиваем серверный кеш, кеш браузера и кеширование тяжёлых блоков. Следим, чтобы корзина и личный кабинет не кешировались ошибочно.
Отключаем лишнее, откладываем загрузку второстепенного, объединяем и сжимаем файлы стилей и скриптов там, где это даёт эффект.
Проверяем версию окружения, лимиты, нагрузку, чистим базу, оптимизируем медленные запросы. При необходимости рекомендуем смену тарифа или переезд.
Сравниваем с исходными данными, проверяем, что ничего не сломалось, и настраиваем наблюдение, чтобы скорость не деградировала снова.
В магазине скорость сложнее, чем в сайте-визитке, потому что страницы динамические: цены, остатки, фильтры, корзина зависят от пользователя и от состояния каталога.
Страница категории с фильтрами по десяти характеристикам может выполнять сотни запросов к базе. Если фильтры собраны неаккуратно, каждое нажатие превращается в долгое ожидание. Здесь помогают индексы в базе, ограничение числа одновременно показываемых вариантов и вынос подсчёта количества товаров в отдельный кеш.
Выгрузка товаров и остатков из учётной системы, как правило, запускается по расписанию и сильно нагружает сервер. Если она совпадает с часами пиковых продаж, сайт замедляется именно тогда, когда нужен быстрее всего. Переносите тяжёлые обмены на ночь или дробите их на небольшие порции. Правильно настроенный обмен с учётной системой не должен мешать покупателям.
Эти страницы нельзя кешировать целиком, но можно ускорить их другими способами: убрать лишние скрипты, не подгружать на них рекламные виджеты, сократить число полей в форме, использовать подсказки адреса без тяжёлых сторонних библиотек.
Если вы не готовы углубляться в технику, пройдитесь хотя бы по этому списку и передайте результаты тому, кто поддерживает ваш сайт.
Погоня за максимальным баллом в тестере иногда приводит к обратному результату. Вот что мы видим чаще всего.
Ускорение сайта это не проект с датой окончания, а привычка. Несколько простых правил помогают не откатиться назад.
Единой цифры нет, но ориентир такой: основное содержимое страницы должно появляться в пределах пары секунд даже на среднем мобильном устройстве, а сайт должен реагировать на нажатия без заметных задержек. Сравнивайте себя прежде всего с конкурентами в вашей нише и со своими собственными прошлыми показателями.
Частично да: сжатие изображений, настройка кеша, отключение лишних сервисов и смена тарифа хостинга не требуют программирования. Но если проблема в самом шаблоне или в тяжёлых запросах к базе, без разработчика не обойтись.
Только если причина именно в сервере. Если страница весит двадцать мегабайт из-за картинок, самый дорогой тариф лишь слегка сгладит проблему. Сначала диагностика, потом решение о переезде.
После каждого крупного изменения на сайте и планово раз в квартал. Для активного магазина с постоянными обновлениями каталога удобнее настроить автоматический мониторинг.
Если вы чувствуете, что сайт работает медленнее, чем должен, но не понимаете, с чего начать, мы можем провести аудит скорости и составить список конкретных правок с оценкой эффекта. Напишите нам через страницу контактов, и мы подскажем следующий шаг.
Взлом сайта почти никогда не выглядит как в кино. Чаще всего это тихое заражение, о котором владелец узнаёт от поисковой системы, от хостинга или от…
Резервная копия сайта похожа на страховку: пока всё хорошо, о ней не вспоминают, а когда случается беда, выясняется, что копии нет, она устарела или…
Вопрос «обновляться или не трогать, пока работает» знаком каждому владельцу сайта. Одни откладывают обновления годами и однажды получают взломанный…