Вступ до веб-продуктивності та критичного шляху рендерингу

Більшість з нас щодня працюють з Інтернетом. Для нас стало нормальним отримувати всю необхідну інформацію майже миттєво. Але те, як ця веб-сторінка насправді складається та доставляється нам, є трохи загадкою.

Іноді веб-сторінки дивовижно швидкі, і іноді нам потрібно довго чекати, щоб побачити вміст - часто це призводить до того, що ми досить розчаровані і покидаємо сторінку. У наступній статті я спробую трохи прояснити ситуацію.

Застереження : Вся інформація, якою я ділюсь у цьому дописі, - це те, що я дізнався через безкоштовні курси, згадані внизу та узагальнені тут для всіх зацікавлених.

Критичний шлях відтворення

Перш за все, було б корисно зрозуміти кроки, які насправді проходить браузер. Він починається з простих файлів HTML, CSS та JavaScript, проходить рендеринг та фарбування сторінки, а в кінцевому підсумку стає тим, що бачить користувач.

Ці кроки від різних файлів HTML, CSS та JS до розфарбованої сторінки зазвичай називають критичним шляхом рендерингу (або коротше CRP).

Критичний шлях відтворення складається з п’яти різних етапів, які найкраще пояснюються на графіці.

Створення DOM та CSSOM

Більшість веб-сторінок складаються з HTML, CSS та JavaScript, які всі складають важливу частину CRP. Для того, щоб прочитати та обробити ваш HTML, браузер побудує об'єктну модель документа (DOM). Браузер переглядає HTML-теги (

,

,

і

і т. д.) у вашій розмітці та перетворює їх у маркери, які в свою чергу створюються у вузли паралельно. Обробляючи ці маркери StartTag та токени EndTag по порядку, та бачачи, які стають першими, браузер може встановити їх ієрархію та встановити батьків та дітей.

Однак нехай ця термінологія вас не лякає. Уявіть DOM як велике дерево з гілками, які представляють батьківські вузли, і які, в свою чергу, містять листя, дочірні вузли. Це дерево буде представляти залежності вузлів у нашому HTML і виглядає дещо подібним до цього:

На зображенні вище ми можемо побачити кореневий елемент, який охоплює всіх його дітей, які, в свою чергу, є батьками, які також містять дітей. Покладіть це догори дном, і воно буде виглядати майже як дерево!

Таким чином, DOM представляє нашу повну розмітку HTML. Як ви бачили, він створюється поступово, обробляючи маркери та перетворюючи їх у вузли. Насправді ми можемо використати це на свою користь, повернувши частковий HTML і давши користувачеві вказівку на те, що щось відбувається та відображається на сторінці.

Після побудови DOM ваш браузер обробить CSS і побудує CSS-об'єктну модель (CSSOM). Цей процес дуже схожий на побудову DOM. Але в цьому процесі, на відміну від раніше, дочірні вузли успадковують правила стилізації батьківських вузлів - звідси і назва Каскадні таблиці стилів (CSS).

На жаль, ми не можемо поступово обробляти часткові CSS, як це було б з DOM, оскільки це може легко призвести до застосування неправильних стилів, якщо переважний стиль з’явиться пізніше в процесі. Це є причиною того, чому CSS блокує візуалізацію, оскільки браузер повинен зупинити рендеринг, поки не отримає та не обробить весь CSS.

Наше дерево DOM та дерево CSSOM будуть містити всі вузли та залежності, які ми маємо на нашій сторінці.

Зібрання всього видимого вмісту - Дерево візуалізації

Браузер повинен знати, які вузли насправді візуально представляти на сторінці. Дерево візуалізації досягає саме цього і є поданням видимого вмісту DOM і CSSOM.

Ми починаємо будувати дерево візуалізації з ідентифікації кореневого вузла, а потім копіюємо всю видиму інформацію з DOM та CSSOM. Для цього ми також перевіряємо, чи шукаємо теги, які мають однаковий селектор. Метадані, посилання тощо не копіюються в дерево візуалізації. Те саме стосується CSS, який містить “display: none;” оскільки це також невидимий предмет.

Після того, як ми завершимо цей процес, ми отримаємо щось подібне до наведеного нижче (зауважте, як «веб-продуктивність» не копіюється).

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

Правильно підходить - Макет

Поки ми зараз знаємо щонам потрібно відобразити та відтворити на сторінці, важливо знати, як вона відображається. Щоб макет виглядав правильно, нам потрібно знати розмір браузера. Наш макет залежить від нього, щоб розрахувати правильні позиції та розміри для всіх наших елементів на сторінці.

Все це відбувається на етапі Layout. Врахування кроку розкладки особливо важливо для мобільних пристроїв, де наша точка зору може змінюватися, коли ми перемикаємося між альбомною та книжковою під час обертання наших телефонів. Це означає, що браузеру потрібно буде повторити крок розкладки кожного разу, коли ми перевертаємо телефон, що може бути досить вузьким місцем для продуктивності.

Розфарбуйте пікселі

Цей крок передбачає власне малювання пікселів на екрані, що визначається тим, що (Дерево візуалізації) і яким чином (Макет). Етап малювання включає власне малювання пікселів (наприклад, при зміні розміру зображення) на відміну від простого позиціонування. Це те, що ви в кінцевому підсумку побачите на екрані згодом.

Підведемо підсумок

Тепер давайте знову складемо всю цю інформацію, щоб ми змогли побачити, що ми зрозуміли всі кроки, які ми повинні пройти, у Критичному шляху візуалізації (CRP).

  1. Браузер починається з побудови DOM, аналізуючи весь відповідний HTML.
  2. Потім він переглядає ресурси CSS та JavaScript і запитує їх, що зазвичай відбувається в голові, куди ми зазвичай розміщуємо наші зовнішні посилання.
  3. Потім браузер аналізує CSS і створює CSSOM з подальшим запуском JavaScript.
  4. Потім DOM і CSSOM об'єднуються разом у Дерево візуалізації.
  5. Потім ми запускаємо етап Layout and Painting, щоб представити сторінку користувачеві.

Добре, це добре знати - але чому це важливо?

Тепер це все чудово знати, і ми краще зрозуміли, що насправді робить браузер у фоновому режимі. Але чому це має значення? Чи всі ми повинні знати, що відбувається під капотом?

Так!

Якщо ми продовжуватимемо збільшувати розмір наших файлів і не звертатимемо уваги на те, що ми просимо браузер відтворити та розфарбувати на сторінці, браузеру знадобиться довше, щоб обробити всі ресурси. Зазвичай це призводить до більш повільного та менш приємного користувацького досвіду, а це означає, що сторінки не будуть придатними для використання та правильно відображатимуться, що призведе до розчарувань на стороні користувача.

Це особливо актуально, якщо ви запитуєте сторінку із сільської місцевості, де швидкий широкосмуговий зв’язок не обов’язково найкращий.

Але на щастя, є кілька способів обійти це, і ми можемо зробити наші сторінки швидшими!

Оптимізація продуктивності

Існує ряд стратегій, якими ми можемо скористатись, щоб зробити наші сторінки швидшими та кращими для використання для наших користувачів. Це особливо важливо для користувачів, які можуть знаходитись у віддалених місцях, де швидший Інтернет не є нормою, або де сторінки зазвичай отримують доступ через мобільний Інтернет.

Коли ми говоримо про стратегії оптимізації, у нас в розпорядженні приблизно три методи.

Зменшення, стиснення та кешування

Усі ці методи можна застосувати до наших HTML, CSS та JS. Потім, завдяки своєму меншому розміру, вони зменшать обсяг даних, які ми відправляємо туди-сюди між клієнтом і сервером. Чим менше байтів нам доведеться надіслати, тим швидше браузер отримає дані та почне обробку та візуалізацію сторінки.

Мінімізуйте використання ресурсів, що блокують візуалізацію (CSS)

Сам CSS блокує візуалізацію, як ми обговорювали вище, що означає, що браузер припинить рендерінг сторінки, поки CSS не завантажиться повністю і не буде оброблений.

Однак ми можемо зменшити великі файли CSS, розблокувавши візуалізацію для певних стилів та вікон. Ми робимо це, використовуючи правила друку в наших медіа-запитах, аналітиці та орієнтації пристрою (якщо ви хочете знати, як, я пропоную ознайомитися з наведеними нижче ресурсами). Крім того, ми можемо зменшити кількість ресурсів, які потрібно завантажити, включивши деякі наші CSS за певних обставин.

Мінімізуйте використання блокуючих парсер ресурсів (синтаксичний аналізатор документів JS)

Ми також можемо відкласти виконання нашого JavaScript і використовувати асинхронні атрибути на нашому сценарії для досягнення цього. Це означає, що решта сторінки може обробляти, і тим часом користувач бачить ознаки того, що щось відбувається на сторінці. Це також означає, що нам не потрібно чекати завантаження JavaScript.

Так загалом кажучи, це залишає нам три моделі оптимізації:

  1. Мінімізуйте кількість відправлених байтів
  2. Зменшіть кількість критичних ресурсів у критичному шляху візуалізації (аналітику, можливо, не доведеться завантажувати з самого початку, коли сторінка будується)
  3. Скоротіть критичну довжину шляху візуалізації (мається на увазі зменшення обсягу туди-сюди між вашим браузером та сервером, який нам потрібен для візуалізації сторінки)

Спробуйте самі

Якщо ви хочете спробувати спробувати розпочати оптимізацію, ви можете виміряти ефективність свого веб-сайту чи інших користувачів за допомогою ряду інструментів. Найпростішими є, мабуть, такі продукти Google, як PageSpeedInsights або Google Lighthouse, зручне маленьке розширення Google Chrome, яке можна легко встановити через Chrome App Store.

Просто натисніть розширення, а потім сформуйте звіт, і ви отримаєте звіт, який включає в себе наступне:

Потім ви можете порівняти свою ефективність із низкою показників, таких як First Pixel Painted to the Screen, First Interactive, Visual Completeness of your site та багато інших.

Інструменти розробника вашого улюбленого браузера - це також чудове місце, щоб розглянути терміни завантаження та вузькі місця у роботі. Забезпечення низького загального часу завантаження, безумовно, збільшить загальну швидкість обслуговування вашого сайту кінцевими користувачами.

Висновок

Сподіваємось, це пролило трохи світла на те, як ваш браузер відображає вам сторінку, та важку роботу, яку потрібно виконати у фоновому режимі, щоб переконатися, що ваші HTML, CSS та JavaScript перетворюються правильно.

Усвідомлення цих кроків допомагає нам зробити існуючі сторінки ефективнішими. Але це також дозволяє нам пам’ятати про те, як ми розробляємо додатки та веб-сайти, і розглядати, як наші сторінки шукають людей в інших регіонах світу.

Ресурси

Більшість своїх знань, якими я тут поділився, я отримав завдяки наступному:

  1. Оптимізація ефективності веб-сайтів на Udacity
  2. Чому ефективність має значення для розробників Google
  3. Високопродуктивна мережа браузерів Іллі Григоріка (//hpbn.co/)
  4. Високопродуктивні веб-сайти: основні знання для інженерів- розробників від Стіва Саудерса