Рендеринг в інтернеті (Rendering on the Web)
Last updated
Last updated
Одне з основних рішень, які мають прийняти веб-розробники, – це де реалізувати логіку та рендеринг у своїх додатках. Це може бути складно, оскільки існує кілька різних способів створення сайту.
Термінологія
SSR : рендеринг на стороні сервера - рендеринг клієнтської або універсальної програми в HTML на сервері;
CSR : рендеринг на стороні клієнта - рендеринг програми у браузері, зазвичай з використанням DOM;
Регідратація ( Rehydration ): «завантаження» уявлень JavaScript на клієнта так, щоб вони повторно використовували дерево DOM та дані HTML, представлені сервером;
Попередній рендеринг ( Prerendering ): запуск програми на стороні клієнта під час складання для захоплення його вихідного стану у вигляді статичного HTML;
TTFB : час до першого байта - розглядається як час між натисканням на посилання і першим контентом, що надходить;
FP : First Paint - перший раз, коли будь-який піксель стає видимим для користувача;
FCP : First Contentful Paint - час, коли запитуваний контент (тіло статті і т. д.) стає видимим;
TTI : Time To Interactive - час, коли сторінка стає інтерактивною (події підключені тощо. буд.).
Серверний рендеринг
Серверний рендеринг генерує повний HTML для сторінки сервера у відповідь навігацію. Це дозволяє уникнути додаткових циклів обробки даних та шаблонів на клієнті, оскільки вони обробляються до того, як браузер отримує відповідь.
Серверний рендеринг зазвичай робить швидку First Paint та First Contentful Paint. Виконання логіки сторінки та рендерингу на сервері дозволяє уникнути надсилання великої кількості JavaScript клієнту, що допомагає швидко досягти Time to Interactive. Це має сенс, оскільки при серверному рендерингу ви просто надсилаєте текст та посилання в браузер користувача. Цей підхід може добре працювати для широкого спектру пристроїв та умов мережі, і відкриває цікаві оптимізації браузера, такі як потоковий аналіз документів.
При використанні серверного рендерингу користувачі навряд чи будуть чекати, поки обробиться JavaScript, перш ніж вони зможуть використовувати ваш сайт. Навіть коли не можна уникнути стороннього JS, використання серверного рендерингу для скорочення власних витрат на JS може дати вам більше бюджету на все інше. Однак цей підхід має один головний недолік: генерація сторінок на сервері вимагає часу, що часто може призвести до більш довгого часу до першого байта.
Чи достатньо серверного рендерингу для вашої програми, багато в чому залежить від нього самого. Існує давня дискусія щодо правильного застосування серверного рендерингу в порівнянні з рендерингом на стороні клієнта, але важливо пам'ятати, що ви можете використовувати серверний рендеринг для одних сторінок, а не для інших немає. Деякі сайти успішно застосовують гібридні методи рендерингу. Сервер Netflix відображає свої відносно статичні цільові сторінки, попередньо вибираючи JS для сторінок з інтенсивною взаємодією, надаючи цим важчим сторінкам, що відображається клієнтом, більш високу ймовірність швидкого завантаження.
Багато сучасних фреймворків, бібліотек та архітектур дозволяють відображати один і той же додаток як на клієнті, так і на сервері. Ці методи можуть використовуватися для серверного рендерингу, проте важливо відзначити, що архітектури, в яких рендеринг відбувається як на сервері, так і на клієнті, є власним класом рішень з дуже різними характеристиками продуктивності та компромісами. Користувачі React можуть використовувати renderToString() або рішення, побудовані на його основі, такі як Next.js для серверного рендерингу. Користувачі Vue можуть подивитися на посібник із серверного рендерингу Vue або Nuxt. Angular має Universal. У більшості популярних рішень використовується деяка форма гідратації, тому перед вибором інструменту ознайомтеся з застосовуваним підходом.
Статичний рендеринг
Статичний рендеринг відбувається під час складання та пропонує швидкі First Paint, First Contentful Paint та Time To Interactive – за умови, що кількість JS на стороні клієнта обмежена. На відміну від серверного рендерингу, йому також вдається досягти стабільно швидкого часу до першого байта, оскільки HTML-код для сторінки не потрібно генерувати на льоту. Як правило, статичний рендеринг означає створення окремого HTML-файлу для кожної URL-адреси заздалегідь. Оскільки HTML-відповіді генеруються заздалегідь, статичні рендери можуть бути розгорнуті на кількох CDN, щоб скористатися перевагою прикордонного кешування (edge-caching).
Рішення для статичного рендерингу бувають всіх форм та розмірів. Такі інструменти як Gatsby спроектовані так, щоб розробники відчули, що їхні програми рендеруються динамічно швидше, ніж генеруються на етапі складання. Інші, як Jekyll і Metalsmith приймають їхню статичну природу, забезпечуючи більш шаблонний підхід.
Одним із недоліків статичного рендерингу є те, що окремі HTML-файли повинні створюватися для кожного можливого URL. Це може бути складно або навіть неможливо, якщо ви не можете передбачити, які будуть ці URL-адреси раніше, або для сайтів з великою кількістю унікальних сторінок.
Користувачі React можуть бути знайомі з Gatsby , статичним експортом Next.js або Navi - це робить його зручним для автора з використанням компонентів. Тим не менш, важливо розуміти різницю між статичним рендерингом та попереднім рендерингом: статичні рендеринг сторінок є інтерактивними без необхідності виконання великої кількості JS на стороні клієнта, тоді як попередній рендеринг покращує First Paint або First Contentful Paint односторінкової програми (SPA), яку необхідно завантажити клієнт щоб сторінки були по-справжньому інтерактивними.
Якщо ви не впевнені, чи це рішення є статичним або попереднім рендерингом, спробуйте цей тест: відключіть JavaScript і завантажте створені веб-сторінки. Для статично візуалізованих сторінок більша частина функціональності, як і раніше, існуватиме без увімкненого JavaScript. Для попередньо оброблених сторінок можуть існувати деякі основні функції, такі як посилання, але більша частина сторінки буде інертною.
Ще один корисний тест – уповільнення роботи мережі за допомогою Chrome DevTools та спостереження за завантаженням JavaScript до того, як сторінка стане інтерактивною. Для попереднього рендерингу зазвичай потрібно більше JavaScript, щоб стати інтерактивним, і цей JavaScript має тенденцію бути більш складним, ніж підхід прогресивного покращення, який використовується під час статичного рендерингу.
Серверний Рендеринг проти Статичного Рендерингу
Серверний Рендеринг не є срібною кулею – його динамічна природа може супроводжуватись значними обчислювальними накладними витратами. Багато рішень для рендерингу серверів не скидаються рано, можуть затримати TTFB або подвоїти надсилання даних (наприклад, вбудований стан JS на клієнті). У React, функція renderToString() може бути повільною, оскільки вона є синхронною та однопоточною. Отримання серверним рендерингом «права» може включати знаходження або створення рішення для компонентів кешування, управління споживанням пам'яті, застосування технік мемоізації, і багато інших проблем. Зазвичай ви обробляєте / перебудовуєте один і той же додаток кілька разів – один раз на клієнті та один раз на сервері. Той факт, що при рендерингу з сервера може з'явитися щось раніше, не означає,
Серверний рендеринг генерує HTML на вимогу для кожного URL, але може бути повільнішим, ніж просто обслуговування статичного рендерингу контенту. Якщо можна додати додаткову роботу, серверний рендеринг + кешування HTML може значно скоротити час серверного рендерингу. Перевагою рендерингу на сервері є можливість отримувати більше «живих» даних та відповідати на повніший набір запитів, ніж це можливо при статичному рендерингу. Сторінки, що вимагають персоналізації, є конкретним прикладом типу запиту, який не буде добре працювати під час статичного рендерингу.
Рендеринг на стороні клієнта (CSR)
Рендеринг на стороні клієнта (CSR) означає рендеринг сторінок безпосередньо у браузері за допомогою JavaScript. Вся логіка, вибірка даних, шаблони та маршрутизація обробляються на клієнті, а не на сервері.
Рендеринг на стороні клієнта може бути важко отримати та швидко зберегти для мобільних пристроїв. Він може наблизитись до продуктивності суто серверного рендерингу, якщо виконує мінімальну роботу, зберігаючи жорсткий бюджет JavaScript і надаючи цінність у мінімально можливій кількості RTTs. Критичні сценарії та дані можуть бути доставлені швидше за допомогою HTTP/2 Server Push або <link rel=preload>, що змушує парсер працювати на вас швидше. Шаблони, такі як PRPL, варто оцінити, щоб забезпечити миттєву початкову та наступну навігацію.
Основним недоліком рендерингу на стороні клієнта є те, що кількість необхідного JavaScript має тенденцію до зростання в міру зростання програми. Це стає особливо важким з додаванням нових бібліотек JavaScript, поліфілів та стороннього коду, які конкурують за обчислювальну потужність і часто повинні оброблятись до того, як вміст сторінки може бути відображено. Досвід роботи з CSR, заснований на великих пакетах JavaScript, повинен враховувати агресивний поділ коду та обов'язково завантажувати JavaScript - «обслуговуйте тільки те, що вам потрібно, коли це потрібно». Для випадків, коли інтерактивність незначна чи відсутня, рендеринг сервера може бути більш масштабоване вирішення цих проблем.
Для людей, які створюють односторінкову програму, ідентифікація основних частин інтерфейсу користувача, що використовуються більшістю сторінок, означає, що ви можете застосувати техніку кешування Application Shell . У поєднанні з сервіс-воркерами це може значно покращити продуктивність, що сприймається, при повторних відвідуваннях.
Об'єднання серверного рендерингу та CSR через регідратацію
Цей підхід часто називається універсальним рендерингом або просто «SSR». Цей підхід намагається згладити кути між рендерингом на стороні клієнта та рендерингом сервера, виконуючи обидві дії. Запити навігації, такі як повне завантаження або перезавантаження сторінки, обробляються сервером, який відображає програму HTML, потім JavaScript і дані, що використовуються для візуалізації, вбудовуються в підсумковий документ. При акуратній реалізації це забезпечує швидку First Contentful Paint точно так, як серверний рендеринг, а потім «підхоплює», знову виконуючи рендеринг на клієнті, використовуючи техніку, яка називається (ре)гідратація. Це нове рішення, але може мати деякі істотні недоліки продуктивності.
Основним недоліком SSR з регідратацією є те, що він може мати істотний негативний вплив на Time To Interactive, навіть якщо він покращить First Paint. Сторінки SSR часто виглядають оманливо завантаженими та інтерактивними, але насправді не можуть реагувати на введення, доки JS на стороні клієнта не буде виконано та обробники подій не приєднані. Це може тривати кілька секунд або навіть хвилин на мобільному телефоні.
Можливо, ви випробували це самі - протягом деякого часу після того, як сторінка, яка виглядає повністю завантаженою не реагує на кліки або натискання. Це швидко засмучує… «Чому нічого не відбувається? Чому я не можу прокрутити?
Проблема регідратації: один додаток за ціною двох
Проблеми регідратації часто можуть бути гіршими, ніж уповільнена інтерактивність через JS. Щоб клієнтський JavaScript міг точно «підхопити», де сервер зупинився, без необхідності повторного запиту всіх даних, які сервер використовував для візуалізації свого HTML, поточні рішення SSR зазвичай серіалізують відповідь від інтерфейсу користувача. залежності даних у документі як тегів скрипта. Отриманий HTML-документ містить високий рівень дублювання:
Як ви можете бачити, сервер повертає опис користувальницького інтерфейсу програми у відповідь на запит навігації, але він також повертає вихідні дані, використані для створення цього інтерфейсу користувача, і повну копію реалізації користувальницького інтерфейсу, яка потім завантажується на клієнта. Тільки після завершення завантаження та виконання bundle.js цей інтерфейс стає інтерактивним.
Метрики продуктивності, зібрані з реальних веб-сайтів із використанням регідратації SSR, вказують на те, що його використання не рекомендується. Зрештою, причина криється в досвіді користувача: зрештою вкрай просто залишити користувачів в «дивній долині».
Хоча є надія на SSR із регідратацією. У короткостроковій перспективі використання SSR для контенту з високим ступенем кешування може зменшити затримку TTFB, що дає результати, аналогічні попередньому рендерингу. Регідратація поступово, поступово чи частково може стати ключем до підвищення ефективності цього в майбутньому.
**Рендеринг потокового сервера та прогресивна регідратація**(Streaming server rendering and Progressive Rehydration)
За останні кілька років серверний рендеринг отримав низку розробок.
Рендеринг потокового сервера дозволяє відправляти HTML порціями, які браузер може візуалізувати з отриманням. Це може забезпечити швидку First Paint та First Contentful Paint, оскільки розмітка надходить до користувачів швидше. У React потоки, що є асинхронними в renderToNodeStream() - у порівнянні з синхронним renderToString - означають, що зворотний тиск добре обробляється.
Прогресивна регідратація також варта того, щоб за нею стежити, і те, що вивчав React. При такому підході окремі частини програми, що відображається на сервері, «завантажуються» з часом, а не за загальним поточним підходом - ініціалізації всієї програми відразу. Це може допомогти зменшити обсяг JavaScript, необхідний для того, щоб зробити сторінки інтерактивними, оскільки оновлення на стороні клієнта низькопріоритетних частин сторінки може бути відкладено для запобігання блокуванню основного потоку. Це також допоможе уникнути однієї з найпоширеніших помилок регідратації в SSR, коли дерево DOM, що відображається сервером, руйнується, а потім негайно перебудовується - найчастіше тому, що при початковій синхронній візуалізації на стороні клієнта потрібні не зовсім готові дані, можливо,
Часткова регідратація
Часткова регідратація виявилася важкою. Цей підхід є продовженням ідеї прогресивної регідратації, де аналізуються окремі частини (компоненти/види/дерева), які мають бути поступово регідратовані, та ідентифікуються ті, у яких мало інтерактивності чи ні реактивності. Для кожної з цих в основному статичних частин відповідний код JavaScript потім перетворюється на інертні посилання та декоративну функціональність, скорочуючи їх площу на стороні клієнта майже до нуля. Підхід часткової гідратації має свої проблеми та недоліки. Це створює деякі цікаві проблеми для кешування, і навігація на стороні клієнта означає, що ми не можемо припускати, що серверний HTML-код для інертних частин програми буде доступний без завантаження сторінки.
Трисоморфний рендеринг (Trisomorphic Rendering)
Якщо сервіс-воркери є підходящим варіантом для вас, «трисоморфний» рендеринг також може становити інтерес. Це метод, при якому ви можете використовувати потоковий рендеринг сервера для початкової/не-JS-навігації, а потім попросити сервіс-воркер на себе HTML-рендеринг для навігації після його встановлення. Це може підтримувати кешовані компоненти та шаблони в актуальному стані та забезпечує навігацію у стилі SPA для відображення нових уявлень в одному сеансі. Цей підхід працює найкраще, коли ви можете спільно використовувати один і той же код шаблонів і маршрутизації між сервером, сторінкою клієнта і сервіс-воркером.
SEO міркування
Команди часто враховують вплив SEO при виборі стратегії рендерингу у мережі. Рендеринг сервера часто вибирається для забезпечення повного вигляду, який сканери можуть легко інтерпретувати. Сканери можуть розуміти JavaScript, але часто є обмеження, про які варто знати, як вони рендер. Рендеринг на стороні клієнта може працювати, але часто без додаткового тестування та роботи. Останнім часом динамічний рендеринг також став варіантом, що заслуговує на увагу, якщо ваша архітектура сильно залежить від клієнтського JavaScript.
У випадку сумнівів, інструмент Mobile Friendly Test неоціненний для перевірки того, що вибраний вами підхід робить те, на що ви сподіваєтеся. Він показує візуальний перегляд того, як будь-яка сторінка відображається сканеру Google, знайдений серіалізований контент HTML (після виконання JavaScript) і будь-які помилки, виявлені під час рендерингу.
Як працює рендеринг у браузері
З одержаного від сервера HTML-документа формується DOM (Document Object Model).
Завантажуються та розпізнаються стилі, формується CSSOM (CSS Object Model).
На основі DOM та CSSOM формується дерево рендерингу, або render tree - набір об'єктів рендерингу (Webkit використовує термін "renderer", або "render object", а Gecko - "frame"). Render tree дублює структуру DOM, але сюди не потрапляють невидимі елементи (наприклад <head>, або елементи зі стилем display:none;). Також, кожен рядок тексту представлений у дереві рендерингу як окремий renderer. Кожен об'єкт рендерингу містить відповідний об'єкт DOM (або блок тексту), і розрахований для цього об'єкта стиль. Простіше кажучи, render tree описує візуальну виставу DOM.
Для кожного елемента render tree розраховується положення на сторінці – відбувається layout. Браузери використовують потоковий метод (flow), у якому найчастіше досить одного проходу розміщувати всіх елементів (для таблиць проходів потрібно більше).
Нарешті відбувається малювання всього цього добра в браузері - painting.
У процесі взаємодії користувача зі сторінкою, а також виконання скриптів вона змінюється, що вимагає повторного виконання деяких з вищеперелічених операцій.
Адаптивний та чуйний веб-дизайн (Adaptive vs. Responsive)
Щоб онлайн ресурс коректно відображався на комп'ютері та мобільних пристроях, під час створення сайту чи інтернет-магазину рекомендується використовувати адаптивний дизайн. Такий тип верстки дозволяє варіювати розміри та відображення інтерфейсу ресурсу залежно від типу пристрою, за допомогою якого користувач зайшов до Інтернету.
Responsive Design (RWD) – чуйний дизайн – проектування сайту з певними значеннями властивостей, наприклад, гнучка сітка макета, які дозволяють одному макету працювати на різних пристроях;
Крім своєї структури, що змінюється, у респонсив дизайну є кілька інших переваг:
Однаковий зовнішній вигляд ресурсу в різних браузерах і на різних платформах Наявність у сайту однакової URL, що сприяє SEO-оптимізації Розробникам необхідно обслуговувати лише один сайт, що дозволяє скоротити час, що витрачається на дизайн та контент
І хоча позитивні сторони респонсивного дизайну очевидні, цей метод має низку недоліків. Найбільшим з них є швидкість завантаження, яка значно знижується через високу роздільну здатність зображень та інших візуальних елементів, необхідних для оформлення зовнішнього вигляду ресурсу.
Adaptive Design (AWD) - адаптивний дизайн, або динамічний показ - проектування сайту з умовами, що змінюються в залежності від пристрою, базуючись на кількох макетах фіксованої ширини.
Для створення чутливих макетів використовуються медіазапити та відносні розміри елементів сітки, задані за допомогою %. В адаптивному дизайні серверні скрипти спочатку визначають тип пристрою, за допомогою якого користувач намагається отримати доступ до сайту (настільний ПК, телефон або планшет), потім завантажує ту версію сторінки, яка найбільш оптимізована для нього. Для елементів сітки задаються фіксовані пікселі (px) розміри.
Джерела:
Дод. матеріал:
Серверний рендеринг також може представляти цікаві рішення при побудові . Краще використовувати повносторінкове сервіс-воркер ( ) кешування або просто рендерувати окремі частини контенту на сервері?
, що показує спектр сервер-клієнт:
