Един от най-често срещаните дебати, които виждам около модерните уеб технологии, се върти около изобразяването от страна на сървъра. Някои хора ще ви кажат, че е абсолютно критично, други ще кажат, че е хубаво да го имате, трети ще ви кажат, че е направо вредно. Кое е това? Е, и трите. Както всичко останало в програмирането и живота, зависи.

Когато седнете, за да вземете решение за архитектурата за вашето модерно, ефективно, прогресивно уеб приложение, ще трябва да решите дали да използвате или не изобразяване от страна на сървъра (оттук нататък SSR). Първо, трябва да избягвате SSR, ако не се нуждаете от него. Повечето съвременни уеб приложения изискват усъвършенствано взаимодействие с потребителския интерфейс, което трябва да се управлява от нетривиални количества JavaScript. Ако така или иначе трябва да напишете целия този JS и несе нуждаете от предимствата за зареждане на първата страница, които SSR ви дава, ще бъде по-добре просто да изградите статична обвивка на приложение и да избягвате главоболията от повторно използване на код клиент-сървър, повторно хидратиране на данни и обезсилване на кеша на динамично съдържание.

За да разберете дали имате нужда от SSR или не, просто отговорете на тези въпроси:

  1. Приложението ви изисква ли влизане, за да видите повечето съдържание (напр. GMail)?
     Ако е така, нямате нужда от SSR. Изградете статична обвивка на приложение, която изскача страницата за вход с възможно най-бързо Time-To-Interactive и заредете предварително всички активи и скриптове на приложението си, докато потребителят въвежда своите идентификационни данни. Използвайте service worker, за да кеширате обвивката на приложението си, така че последващите зареждания да останат супер бързи.
  2. Приложението ви ориентирано ли е повече към четене или правене (фокусирано върху съдържание срещу фокусирано върху взаимодействие)?
    Ако повечето потребители ще правят нещоскоро след като кацнете на страницата (напр. приложение за водене на бележки), нямате нужда от SSR. SSR може в някои случаи да постави приложението ви в състояние на „зловеща долина“, където можете да виждатестраницата, но не можете да взаимодействате с страницата. Това в крайна сметка се оказва по-лошо изживяване от спинера или екрана за зареждане, тъй като щракванията или докосванията просто ще спрат или ще направят нищо.
  3. Важно ли е SEO/социалното споделяне за вашето приложение (напр. електронна търговия)?
    Ако е така, имате нужда от (поне ограничено) SSR. Въпреки че някои търсачки вече изпълняват JavaScript и могат да анализират и индексират сайтове само с JS, всички роботи могат да четат съдържание, върнато от сървъра. В някои случаи (ако се интересувате само от социално споделяне на вашето съдържание, например), можете да се разминете с ограничен SSR, който инжектира само <meta> тагове в главата на вашия HTML, като действителното изобразяване на страницата все още се извършва в JavaScript. Свързани с това са технологии като AMP, които налагат съдържанието да бъде на страницата, за да се счита за валидно.
  4. Вероятно ли е потребителите, влизащи за първи път, да посетят чрез връзки за дълбоко съдържание? (напр. новинарски сайтове)
    Свързано, но не идентично с [3], ако е най-вероятно потребителите да стигнат до връзка с дълбоко съдържание (и четенето е по-важно от взаимодействието за вашето приложение), вероятно искате SSR. SSR винаги ще бъденай-бързият начин за получаване на първа боя, защото HTML се изпраща по кабела в първия отговор и не се блокира при анализ на JS или допълнителни заявки .

Това е! Тези четири основни правила няма да ви насочат правилно в 100% от ситуациите, но като цяло можете да мислите, че SSR е необходим за сайтове с голямо съдържание и дълбоки връзки при зареждане на първата страница . Ако все пак решите да добавите SSR към сайта си, не забравяйте да оптимизирате CSS за критичния път, да отложите всички JS и да накарате първото си изобразяване да деактивира по подходящ начин интерактивни битове, които няма да могат да се използват, докато не се заредят някои скриптове.

Успех и се надяваме, че това е било полезно!

Ако погледнете биографията ми, може да видите, че работя върху „Firebase“ и да се изненадате, че подкрепям SSR. Реалността е, че понякога имате нуждаот допълнителната производителност при зареждане на първата страница и в някои случаи SSR наистина е единственият начин това да се случи.

Още по-добре, може би не сте знаели, че можете да правите SSR с Firebase! Дейвид Ийст има нова видео поредица, която току-що започна, която ви показва как да направите рендиране от страна на сървъра на Firebase хостинг с облачни функции, можете да намерите повече там.

👋🏾 Запознайте се с хората и идеите, оформящи продуктите, които използваме всеки ден. Абонирайте се за Noteworthy — бюлетинът за продукти и дизайн, написан от екипа на Journal.