Если вы создаете веб-страницы для производственной среды, подумайте о том, чтобы разрабатывать и размещать их статически. Это может упростить вашу жизнь и одновременно принести пользу вашим клиентам и бизнесу. Преимущества заключаются в трех свойствах статических страниц:
- Высокая скорость и производительность.
- Возможность умеренной деградации.
- Простые, надежные и управляемые варианты хостинга.
Скорость: выгода для пользователя и бизнеса
Нельзя сказать, что это преимущество универсально, но в целом статические страницы быстрее загружаются, чем рендеринг на стороне сервера (SSR) или рендеринг на стороне клиента (CSR). Сокращенное время загрузки производит приятное впечатление на пользователя, а также, как было доказано, повышает коэффициент конверсии, что приводит к улучшению бизнес-показателей.
Сокращение времени загрузки связано с рендерингом — или его отсутствием. Для статического сайта HTML-файл формируется заранее, поэтому все, что требуется от сервера, — это предоставить пользователю обычный HTML-файл. В браузере пользователя может потребоваться некоторая гидратация, но если вы не блокируете всю страницу в ожидании этой гидратации, то, скорее всего, можете сразу же предоставить пользователю содержательную картину. Воспринимаемое время загрузки невелико.
Однако при использовании SSR HTML должен быть отрисован, когда запрос поступает на сервер. В зависимости от того, какой объем HTML отображается и какие данные извлекаются перед отображением, время отклика может быть довольно большим. В течение этого времени пользователи не увидят никакого контента, поскольку HTML не будет обработан до тех пор, пока сервер не ответит на запрос.
Кроме того, извлечение данных и рендеринг HTML могут требовать больших усилий от сервера, что приводит к его замедлению под нагрузкой. Если извлекаемые данные уникальны для каждого входящего запроса, замедление произойдет неизбежно. Но я часто видел, как инженеры используют SSR (или CSR) для извлечения данных, которые фактически не меняются от запроса к запросу, а это означает, что много времени тратится на выполнение вызовов и рендеринг HTML, когда это можно сделать один раз.
Наконец, CSR также должен отображать HTML, но все это происходит в браузере пользователя. Небольшой фрагмент HTML извлекается с сервера, дающего после этого браузеру пользователя команду извлечь определенный JavaScript, который затем извлекает все остальное и отображает страницу. Как правило, этот процесс медленнее, чем в случае с SSR, поскольку все данные теперь должны быть получены от географически удаленного пользователя, а не от сервера, который, вероятно, расположен в том же центре обработки данных. При этом пользователь все равно ничего не увидит в браузере, пока не завершатся все операции по извлечению и рендерингу. Воспринимаемое время загрузки становится намного больше.
Даже в случае статической страницы есть несколько правил, которых следует придерживаться для достижения оптимальной производительности. Прежде всего, старайтесь сократить время интерактивного взаимодействия. Как правило, оно не должно превышать 3 секунд. Если страница загружается долго, пользователи будут уходить с нее, а те, кто останутся, с меньшей вероятностью превратятся в постоянных клиентов. Поэтому скорость загрузки страницы должна быть выше.
Наиболее практичным способом достижения низкого времени загрузки является строгое соблюдение бюджета веса страницы. Чем меньше данных необходимо получить и обработать пользователю, тем быстрее будет происходить загрузка страницы. Чтобы достичь отметки в 3 секунды, оптимальный бюджет веса страницы — 800 кБ для всего: HTML, CSS, JS, изображений, шрифтов и т. д. Это потребует дисциплины, но, как показал мой собственный опыт, снижение времени загрузки страницы с 8 секунд до 3 секунд увеличивает конверсию на этой странице на 7 процентных пунктов. Такой результат стоит того, чтобы быть дисциплинированным.
Умеренная деградация
Мы убедились в том, что статические страницы обладают высокой производительностью, поскольку они предварительно рендеризуются. Это же свойство, как правило, обеспечивает процесс умеренной деградации статических страниц.
Умеренная деградация заключается в предоставлении пользователю как можно больше функциональности и информации, несмотря на ошибки. Например, если страница не может извлечь данные, она должна предоставить пользователю разумные значения по умолчанию, подтянуть резервные данные или показать подробное, понятное пользователю сообщение об ошибке. Или же при возникновении проблем с отправкой исходящего запроса страница должна повторить попытку, а затем показать понятное пользователю сообщение об ошибке с указанием шагов по ее устранению, если это применимо.
Теоретически любая веб-страница способна к умеренной деградации. Для этого просто необходима дисциплинированная обработка ошибок. Для меня, как разработчика, дисциплинированная обработка ошибок сводится к двум пунктам:
- упрощению задачи по выявлению и устранению режимов отказа;
- стремлению максимально сократить количество возможных режимов отказа.
Вот в чем статические веб-страницы действительно выигрывают: они позволяют легко определить режимы отказов и уменьшить количество потенциальных ошибок, с которыми может столкнуться страница.
Во-первых, статические страницы облегчают поиск ошибок. Это связано с тем, что, как и при компиляции кода, статические страницы должны быть созданы до того, как их можно будет обслуживать. Это предполагает, что вы используете фреймворк, а не пишете “ванильный” HTML/CSS/JS. Если сборка по какой-либо причине завершится сбоем, то артефактов для развертывания не будет. Таким образом, вам придется устранить все ошибки, способные помешать рендерингу страницы, до того, как она попадет в среду производства.
С другой стороны, рендеринг на стороне сервера или на стороне клиента выполняется во время выполнения. Если же у вас недостаточно тестового покрытия, некоторые проблемы с рендерингом могут не возникнуть до тех пор, пока пользователь не перейдет на определенную страницу. К тому времени будет уже слишком поздно. Пользователь увидит ваш баг.
Во-вторых, статические страницы уменьшают количество возможных режимов отказа. Поскольку в процессе сборки страницы будут гарантировано отображены, можно не беспокоиться о проблемах с рендерингом. Теперь проблемы во время выполнения будут в основном связаны с выполнением запросов на гидратацию страницы или исходящих запросов от взаимодействия с пользователем. Это гораздо меньший набор ошибок, для которых нужно писать код обработки!
Но преимущества на этом не заканчиваются: статические страницы могут также предотвратить целый ряд проблем, возникающих при обслуживании страницы.
В частности, при серверном рендеринге любая проблема с сервером становится проблемой для страниц. Если произошла ошибка при извлечении данных, то может возникнуть исключение, которое не позволит странице отобразиться. Если вы не обработали эту ошибку, клиент может просто получить ответ “500”.
Или, допустим, на ваш сервер в последнее время поступает много трафика. Поскольку рендеринг на стороне сервера может быть очень обременительным для серверов, вполне возможно, что запросы начнут проседать. В этом случае пользователи не получат страницу с умеренной деградацией — скорее всего, они получат белую страницу с надписью 504 Gateway Timeout!
Переходя на статическую страницу, вы уменьшаете объем работы, выполняемой серверами, что снижает вероятность возникновения ошибок и перегрузки серверов. Более того, вы получаете возможность воспользоваться некоторыми no-code решениями, полностью управляемыми и очень надежными, например обслуживанием страницы с помощью Amazon S3. Можно использовать CDN Cloudfront для кэширования ресурсов в географической близости от пользователей, что еще больше повышает производительность и надежность!
Установил и забыл
Из вышесказанного вытекает последнее преимущество — статические сайты очень просты в размещении и управлении.
При использовании SSR необходимо быть очень осторожным с серверами. Поскольку рендеринг может быть довольно требовательной операцией, есть вероятность перегрузить серверы. Это означает, что пользователи будут видеть пустую страницу в ожидании ответа или, что еще хуже, будут получать ошибки тайм-аута, что крайне неудобно для посетителя сайта. Чтобы избежать такого сценария, необходимо тщательно распределять ресурсы CPU и памяти на серверах, настраивать автомасштабирование, мониторинг и оповещения.
Однако если у вас есть статические артефакты, вы загружаете их в S3, а на стороне интерфейса используете Cloudfront, то обойдетесь без всего этого (можно также задействовать эквиваленты Google Cloud или Microsoft Azure, а также другие хостинговые или CDN-сервисы по своему усмотрению). При этом не требуется настройка CPU, памяти и автомасштабирования, а процессы мониторинга и оповещений упрощаются. Это объясняется тем, что S3 и Cloudfront управляются, поэтому вам не нужно заботиться о серверных нюансах. Можно просто отслеживать частоту 4XX и 5XX, количество запросов и количество попаданий/пропусков в кэш. Все это поможет понять, не выпущен ли случайно неработающий артефакт, не упущена ли возможность повышения производительности (например, кэширование определенных путей к файлам или кэширование в течение достаточно длительного периода времени). Но все проблемы, которые могли возникнуть при обслуживании страницы, при таком подходе решаются за вас.
Заключение
В целом, если вы используете SSR или CSR и рендерите страницы, которые практически не меняются или требуют лишь небольшой гидратации, стоит переключиться на обслуживание статических страниц. Это позволит сократить время загрузки для пользователей, повысить конверсию, отловить ошибки рендеринга до запуска в производство, а также сократить многие сложности, связанные с обслуживанием страниц. Ваши пользователи, ваш бизнес и ваши коллеги по команде будут вам благодарны!
Читайте также:
- Почему стоит избегать динамических ссылок
- Как перенести сайт с WordPress на GitHub Pages
- Основы создания сайтов
Читайте нас в Telegram, VK и Дзен
Перевод статьи Kraig McFadden: Why You Should Consider Building Static Sites
