Одна из самых распространенных дискуссий, которые я вижу вокруг современных веб-технологий, вращается вокруг рендеринга на стороне сервера. Некоторые люди скажут вам, что это абсолютно критично, другие скажут, что это хорошо, а третьи все равно скажут вам, что это совершенно вредно. Так что это? Ну все три. Как и все остальное в программировании и жизни, зависит от обстоятельств.
Когда вы садитесь за стол, чтобы выбрать архитектуру для вашего современного производительного прогрессивного веб-приложения, вам нужно будет решить, использовать ли рендеринг на стороне сервера (далее SSR). Во-первых, вам следует избегать SSR, если он вам не нужен. Большинство современных веб-приложений требуют сложного взаимодействия с пользовательским интерфейсом, который должен управляться нетривиальным объемом JavaScript. Если вам все равно нужно написать весь этот JS, и вам не нужны преимущества загрузки первой страницы, которые дает SSR, вам будет лучше просто создать статическую оболочку приложения и избегать головные боли повторного использования кода клиент-сервер, регидратации данных и аннулирования кэша динамического содержимого.
Чтобы узнать, нужен ли вам SSR, просто ответьте на эти вопросы:
- Требуется ли в вашем приложении вход для просмотра большей части контента (например, GMail)?
Если да, SSR не нужен. Создайте статическую оболочку приложения, которая будет отображать страницу входа с максимально быстрым временем до начала взаимодействия и предварительно загружать все ресурсы и сценарии вашего приложения, пока пользователь вводит свои учетные данные. Используйте сервис-воркер для кэширования оболочки вашего приложения, чтобы последующие загрузки оставались сверхбыстрыми. - Ваше приложение больше ориентировано на чтение или выполнение действий (ориентированное на содержание или на взаимодействие)?
Если большинство пользователей собираются что-то делать вскоре после того, как приземлиться на странице (например, приложение для заметок), вам не нужен SSR. SSR может в некоторых случаях перевести ваше приложение в состояние «сверхъестественной долины», когда вы можете видеть страницу, но не можете взаимодействовать с страница. В конечном итоге это хуже, чем спиннер или экран загрузки, поскольку щелчки или нажатия просто останавливаются или ничего не делают. - Важны ли SEO / публикации в социальных сетях для вашего приложения (например, электронной коммерции)?
Если да, то вам нужен (хотя бы ограниченный) SSR. Хотя некоторые поисковые системы теперь выполняют JavaScript и могут анализировать и индексировать сайты, содержащие только JS, все сканеры могут читать контент, возвращаемый с сервера. В некоторых случаях (например, если вы заботитесь только о том, чтобы поделиться своим контентом в социальных сетях), вы можете обойтись ограниченным SSR, который только вставляет теги<meta>в заголовок вашего HTML, при этом фактический рендеринг страницы по-прежнему выполняется в JavaScript. С этим связаны такие технологии, как AMP, которые требуют, чтобы контент на странице считался действительным. - Вероятно ли, что впервые пользователи перейдут на сайт по ссылкам на глубокое содержание? (например, новостные сайты)
Связано, но не идентично [3], если пользователи, скорее всего, перейдут на ссылку на глубокий контент (а чтение важнее взаимодействия для вашего приложения), вы, вероятно, хотите SSR. SSR будет всегда самым быстрым способом получить первую отрисовку, потому что HTML-код отправляется по сети в первом ответе и не блокируется при синтаксическом анализе JS или дополнительных запросах. .
Вот и все! Эти четыре практических правила не помогут вам в 100% ситуаций, но в целом вы можете думать о SSR как о необходимом для сайтов с большим содержанием контента с глубокими ссылками в качестве первой загрузки страницы. . Если вы все же решили добавить SSR на свой сайт, обязательно оптимизируйте CSS критического пути, отложите все JS и сделайте свой первый рендеринг соответствующим образом отключив интерактивные биты, которые нельзя будет использовать, пока не загрузятся некоторые скрипты.
Удачи и надеюсь, что это было полезно!
Если вы посмотрите мою биографию, вы можете увидеть, что я работаю над Firebase, и удивитесь, что я защищаю SSR. Реальность такова, что иногда вам нужна дополнительная производительность при загрузке первой страницы, а в некоторых случаях SSR - единственный способ добиться этого.
А еще лучше, вы, возможно, не знали, что можете использовать SSR с Firebase! У Дэвида Иста есть только что начавшаяся новая серия видеороликов, в которых рассказывается, как выполнять рендеринг на стороне сервера на хостинге Firebase с помощью облачных функций. Здесь вы можете узнать больше.
👋🏾 Познакомьтесь с людьми и идеями, формирующими продукты, которые мы используем каждый день. Подпишитесь на примечательный - информационный бюллетень о продуктах и дизайне, подготовленный командой Journal.
