Сайт на 90 КБ без единого фреймворка
Сайт, который вы сейчас читаете, — это один HTML-файл со стилями и скриптами внутри. Ни сборки, ни npm, ни внешних библиотек. Рассказываю, что это даёт на практике, чем приходится платить и в каких случаях так делать не надо.
В комментарии наверху исходного кода этого сайта написано: «Один файл: HTML + CSS + JS. Ноль фреймворков, ноль сборки, ноль трекеров. Так задумано: страница должна грузиться мгновенно и работать хоть через десять лет, без npm install и прочей магии». Это не поза — это инженерное решение с понятными плюсами и понятной ценой. Разберём и то, и другое.
Из чего складывается вес обычного сайта
Когда говорят «сайт тяжёлый», обычно представляют картинки. На деле в типичном сайте на популярной CMS вес распределяется примерно так:
| Что грузится | Откуда берётся | Можно ли убрать |
|---|---|---|
| Библиотеки и фреймворк | Тема оформления, конструктор страниц | Да, если верстать под задачу |
| Стили темы | Один файл на все страницы сайта сразу | Да, оставив нужное |
| Скрипты плагинов | Каждый плагин тянет своё, независимо от нужности | Частично |
| Шрифты | Часто 4–8 начертаний там, где нужны два | Да, почти всегда |
| Картинки | Загружены как есть, без сжатия и нужного размера | Да, и это даёт больше всего |
| Внешние сервисы | Чаты, аналитика, пиксели, виджеты | По одному, осознанно |
Ключевое здесь не мегабайты сами по себе, а количество отдельных запросов к разным серверам. Каждый — это установка соединения, ожидание, риск, что чужой сервис тормозит именно сегодня. Страница на сотню килобайт из одного файла открывается быстрее, чем «лёгкая» страница, которой нужно сходить в семь мест.
Что даёт подход «всё в одном файле»
- Один запрос — и страница готова. Стили не подгружаются отдельно, поэтому ничего не «прыгает» при отрисовке: пользователь сразу видит финальный вид.
- Нет чужих точек отказа. Сайт не зависит от того, работает ли сегодня CDN с библиотекой и не сменил ли кто-то версию пакета.
- Нечего взламывать. Нет админки, плагинов и базы — исчезает целый класс проблем безопасности, ради которых обычно и держат обновления.
- Работает без сборки. Открыл файл в редакторе, поправил, залил. Через пять лет — ровно так же, без археологии со старыми версиями инструментов.
- Понятная отладка. Всё, что происходит на странице, лежит в этом же файле. Не надо искать, какой из тридцати скриптов навесил обработчик.
Чем за это приходится платить
Честно, без рекламы собственного подхода. Минусы есть, и они не мелкие:
- Нет переиспользования. Шапка, футер и стили физически повторяются в каждом файле. Пока страниц три — незаметно. Когда их становится восемь, приходится либо заводить генератор, либо мириться с расхождениями.
- Нет админки. Текст правится в коде. Для сайта, который ведёт разработчик, это быстрее всего. Для клиента, который хочет сам менять цены, — неприемлемо.
- Всё руками. Ни готовых компонентов, ни маркетплейса решений: каждый элемент верстается и продумывается отдельно. Это время, и оно стоит денег.
- Плохо масштабируется. Каталог, фильтры, личный кабинет, сотни страниц — здесь нужна база и движок, а не файлы.
Момент, когда «руками» перестаёт работать
С блогом этого сайта я на такой момент и наткнулся. Пока страниц было две, инлайновый CSS в каждой — норма. На восьмой странице стало очевидно: восемь копий одного CSS рано или поздно разъедутся, и разница вылезет в самом неудобном месте.
Решение — маленький локальный сборщик: текст статей лежит отдельно, а шапка, футер, стили и разметка подставляются при сборке. На сайт по-прежнему уезжает обычный статический HTML, никакой сборки на сервере, но правится всё в одном месте. Инструмент разработки не обязан жить на продакшене — это разные вещи, и их полезно разделять.
Когда так делать не надо
Подход хорош для сайтов-визиток, лендингов, портфолио, документации, промо-страниц — там, где контент меняется редко, а скорость и надёжность важны. Он плохо подходит, если:
- контент правит не разработчик, а сотрудник компании;
- страниц много и они однотипные — каталог, база знаний, новости;
- нужны пользователи, корзина, личный кабинет, оплата;
- сайт живёт в связке с 1С, CRM и складом.
Во всех этих случаях нужен движок. Вопрос лишь, какой — готовая CMS или своя; про этот выбор есть отдельный разбор.
Что можно сделать со своим сайтом уже сегодня
Даже если переписывать сайт никто не собирается, три действия дают заметный эффект и не требуют разработчика:
- Сжать картинки. Обычно это половина веса страницы. Современный формат и правильный размер под макет — и мегабайты превращаются в сотни килобайт без видимой потери качества.
- Выкинуть лишние шрифты. Оставьте два начертания вместо шести. Разница в оформлении незаметна, разница в скорости — заметна.
- Пересмотреть внешние скрипты. Каждый чат, виджет и пиксель стоит времени загрузки. Если сервисом не пользуются полгода — его нет смысла держать.
Сайт грузится дольше трёх секунд?
Экспресс-проверка на главной покажет вес страницы, время ответа сервера, сжатие и то, что тянет загрузку вниз. Часто выясняется, что дело в паре несжатых картинок.
Если по итогам захочется не просто ускорить, а пересобрать сайт нормально — расскажите задачу. Скажу честно, стоит ли овчинка выделки: иногда дешевле починить существующий.