Критичний шлях рендерингу

Критичний шлях рендерингу – це послідовність кроків, які браузер повинен виконати між отриманням сторінки та відображенням будь-чого на екрані. Він включає розбір розмітки в структуру документа, розбір таблиць стилів у структуру стилів, об'єднання цих двох елементів у дерево рендерингу, обчислення макета та відображення результату. Розуміння цього пояснює, чому деякі ресурси затримують першу появу контенту, а інші – ні.

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

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

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

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

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

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

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