Быстро ли работает сайт на нейросети: что решает скорость

Скорость задаёт не тот, кто написал код, а то, что страница отдаёт браузеру. Сгенерированный лендинг это в основном текст, несколько изображений и немного скриптов, поэтому грузится он как любая небольшая страница. Медленным его делает ровно то же, что и собранный руками: тяжёлые фотографии, лишние шрифты и сторонние виджеты.

Поэтому у вопроса «быстрый ли код у нейросети» нет ответа в общем виде. Скорость это свойство результата, а результат это страница в браузере, которому всё равно, кто её написал. Ниже разберём, из чего складывается вес сборки, какие решения стоят вам секунд и как замерить собственную страницу вместо спора об инструментах.

Что вообще определяет скорость загрузки?

Три вещи, примерно в порядке влияния. Сколько байт браузер скачивает. Сколько отдельных запросов он для этого делает. Сколько работы процессор выполняет до момента, когда страницей можно пользоваться. Почти любой разговор о производительности это один из этих трёх пунктов в разной одежде.

На маркетинговых сайтах первый пункт почти всегда решают изображения. Фотография первого экрана, залитая прямо с камеры, может весить больше, чем вся остальная страница вместе взятая, и никакая аккуратная вёрстка этого не компенсирует. Сжать один файл обычно даёт больший выигрыш, чем все прочие оптимизации.

Третий пункт, работа процессора, это место, где живут сторонние скрипты: чаты, карты, счётчики, плееры. Каждый из них сначала запрос, потом разбор, потом исполнение, и всё это соревнуется с вашим содержанием за один и тот же поток. Отсюда эффект, когда визуально скромная страница ощущается тормозной на среднем телефоне.

Ни одному из трёх пунктов не важно, кто написал разметку. Сгенерированная и написанная руками страница с одинаковым набором файлов ведут себя одинаково, потому что браузер не знает разницы и не имеет причин её знать.

Медленнее ли сгенерированный код написанного руками?

Сам по себе нет, и в отрыве от конкретной страницы сравнение бессмысленно. Честная формулировка вопроса уже: отдаёт ли эта конкретная сборка больше, чем ей нужно? На это ответ есть, и получают его, посмотрев на страницу, а не порассуждав об инструменте.

Где генерация действительно может дать слабину, так это в избыточности. Попросите страницу с галереей, картой, виджетом чата и анимированным первым экраном, и вы получите все четыре вещи, каждую со своим весом. Генератор сделал ровно то, что просили. За его спиной не стоит человек, который спросит, заслуживает ли карта своего места.

Ручная разработка ошибается в том же месте, только медленнее. Сайты, которые делали люди, годами обрастают плагинами, метками и забытыми экспериментами. Разница в том, что сгенерированный проект начинается маленьким и растёт от ваших явных просьб, поэтому лишний вес легче связать с конкретным решением.

Что попадает в собранную страницу?

Работающий проект, проверенный до выдачи. Перед тем как отдать результат, сборка запускается в песочнице, и та, что не открылась, помечается как неудачная, а не приходит вам пустым экраном. Это снижает риск опубликовать сломанное. Это не отменяет риск полностью и ничего не говорит о весе.

Читать таблицу стоит как чек-лист, а не как приговор. Две строки, которые вы контролируете напрямую, изображения и шрифты, на большинстве простых сайтов и решают исход.

Какие решения делают страницу медленной?

Четыре, и они повторяются почти в каждом описании медленной страницы.

Несжатые изображения. Фотография в полном разрешении, поставленная фоном, это самая частая причина. Уменьшите её до того размера, в котором она реально показывается, ещё до загрузки.

Разрастание шрифтов. Каждое дополнительное семейство и начертание это ещё один файл и ещё один момент, когда текст может дёрнуться при загрузке. Двух начертаний одного семейства маркетинговой странице обычно достаточно.

Сторонние встройки. Чат, карта в рамке, лента соцсети, видеоплеер это целые приложения, загруженные внутрь вашей страницы. По отдельности каждое решение разумно, а четыре вместе никто сознательно не принимал.

Всё на одной странице. Одна страница, которая тянет магазин, ленту блога и форму записи, грузит все три вещи посетителю, которому нужна была одна. Разделить их на многостраничную платформу стоит 12 кредитов за первые три страницы и по 3 за каждую следующую, и это часто дешевле трафика, который вы теряете.

Как это замерить, а не угадать?

Прогнать страницу через инструмент, который считает те же метрики, что смотрят поисковики, и сделать это с устройства, похожего на то, что держит ваш посетитель.

Пороговые значения по этим метрикам публикует Google и время от времени их пересматривает, поэтому актуальные цифры берите из его документации, а не из статьи в блоге, включая эту. Важнее точной планки направление: замерьте один раз до изменений и второй раз после.

Не мерьте превью на быстром ноутбуке по офисному вайфаю и не считайте это репрезентативным. Проверяйте на телефоне, на мобильном интернете, по опубликованному адресу. Как это выглядит на маленьком экране, разобрано отдельно в материале про мобильную версию собранного сайта, а если рядом нужны данные о трафике, подключение аналитики занимает несколько минут.

Что чинится правкой, а что требует кода?

Большая часть чинится правкой. Попросите меньше шрифтов, более лёгкий первый экран, убранную встройку или галерею, вынесенную на отдельную страницу, и сборка изменится. Одна правка стоит 3 кредита, поэтому круг подрезки достаточно дешёвый, чтобы делать его на пробу. В режиме Hi-Fi та же правка стоит 6 кредитов, и это стоит учитывать, если вы гоняете много мелких итераций.

Чего правка не сделает, так это не сожмёт фотографию, которую вы загрузили. Это происходит до билдера, в любом графическом редакторе, который у вас уже есть, и делать это стоит аккуратно: правильный размер и формат обычно снимают больше веса, чем все изменения вёрстки вместе.

Более глубокая работа живёт в коде. Выгрузите проект в GitHub, снимите профиль загрузки и меняйте то, на что профиль указывает. Этот путь описан в статье про выгрузку исходников, и с него же начал бы разработчик.

Влияет ли на скорость хостинг?

Влияет, и это одна из немногих частей, о которых на старте можно не думать. Опубликованный проект отдаётся с адреса вида <slug>.zugo.run, свой домен подключается поверх и на саму сборку не влияет.

Если вы хотите держать раздачу под собой, подключение Vercel разворачивает проект в ваш аккаунт, а после выгрузки в GitHub репозиторий разворачивается где угодно. Хостинг это решение, которое можно пересмотреть позже, чего нельзя сказать о странице, построенной вокруг шести шрифтов.

Что честно назвать границей этого ответа?

Три вещи, прямым текстом.

Мы не публикуем замер. Ни одно число в этой статье не утверждает, насколько быстрой будет ваша страница, потому что это зависит от ваших изображений, ваших интеграций и устройств ваших посетителей. Любое заявление о скорости от любого билдера, включая наш, стоит считать непроверенным, пока вы не замерили свою страницу.

Проверка в песочнице это про загрузку, а не про производительность. Она подтверждает, что сборка открывается. Она не оценивает вес и не предупредит, что фотография первого экрана огромная.

Тяжёлые приложения это другая задача. Панель, которая читает живые данные, или 2D-игра в браузере имеют профиль нагрузки, к которому советы про скорость страниц не применяются напрямую. Глубокая оптимизация сложного продукта это инженерная работа, и на ней Zugo не заменяет команду разработки.

Быстрее всего проверить всё это на своей сборке. Опишите одну страницу в Zugo, опубликуйте и прогоните опубликованный адрес через любой измеритель скорости ещё до того, как добавите первое изображение. Эта отправная точка скажет вам больше, чем любые общие утверждения о сайтах на нейросетях.