Критичен път на рендиране

Критичният път на рендиране е поредицата от стъпки, които браузърът трябва да изпълни между получаването на страница и показването на каквото и да е на екрана. Той включва анализиране на маркировката в структура на документа, анализиране на стиловите таблици в структура на стила, комбиниране на двете в дърво на рендиране, изчисляване на оформлението и рисуване на резултата. Разбирането му обяснява защо някои ресурси забавят първата поява на съдържание, а други не.

Стиловите таблици блокират рендерирането по дизайн и това е умишлено, а не дефект. Браузър, който рисува преди стиловете да са станали достъпни, би показвал неоформено съдържание и след това би го преформулирал, което е по-лошо от кратко забавяне. Практическото следствие е, че всеки стилов лист, посочен в заглавката на документа, трябва да бъде изтеглен и обработен, преди да се появи каквото и да било, така че броят, размерът и скоростта на показване на стиловите таблици директно определят кога страницата става видима.

Скриптовете блокират парсера, освен ако не е отбелязано друго, което е другият основен източник на забавяне. Синхронен скрипт, открит по време на парсиране, спира изграждането на документа, докато не бъде изтеглен и изпълнен, защото може да го промени. Маркирането на скриптовете като отложени позволява парсирането да продължи и да ги изпълни след завършване на документа; маркирането им като асинхронни позволява изпълнението веднага щом пристигнат. Избирането на правилния атрибут за всеки скрипт е сред най-евтините налични подобрения.

Скъсяването на пътя включва намаляване както на броя на двупосочните операции, така и на работата, необходима на всеки етап. Вграждането на стиловете, необходими за първоначалния viewport, премахва блокиращата заявка изцяло, като останалата част се зарежда без блокиране. Отлагането на скриптове, които не са необходими за първото рендиране, минимизирането и компресирането на ресурсите и елиминирането на пренасочванията, които добавят пълни двупосочни операции, преди да започне каквото и да било, намаляват времето, изминало преди първото рисуване.

Подсказките за ресурси позволяват на браузъра да започне работа по-рано, отколкото откриването би позволило. Предварителното зареждане декларира, че ресурс, открит късно в документа, като например шрифт, цитиран от стилов лист, или изображение, приложено чрез CSS, ще бъде необходим, така че изтеглянето започва незабавно. Предварителното свързване установява връзки с източници от трети страни предварително, премахвайки разходите за свързване и договаряне от критичния момент. Използвани избирателно, те помагат; използвани безразборно, те се конкурират за честотна лента и влошават нещата.

Шрифтовете заслужават специално внимание, защото се намират в пътя и се откриват късно. Уеб шрифт, посочен от стилов лист, не може да започне да се изтегля, докато този стилов лист не бъде обработен, и в зависимост от стратегията за показване текстът може да е невидим, докато не пристигне. Предварителното зареждане на използваните шрифтове над гънката, изборът на стратегия за показване, която показва резервен текст незабавно, и съпоставянето на резервни показатели за намаляване на преформатирането - всичко това решава този проблем.

Рендирането от страна на клиента удължава пътя значително, поради което изисква целенасочено смекчаване. Когато първоначалният документ не съдържа съдържание и всичко трябва да бъде конструирано от JavaScript, пътят включва изтегляне, парсиране и изпълнение на пакета, а след това извличане на данни, преди да се появи каквото и да било. Рендирането от страна на сървъра или статичното генериране връща смислено съдържание към първоначалния път, което е структурна корекция, а не оптимизация.

Тъй като пътят се определя от това как е конструирана и доставена страницата, подобрението обикновено изисква промени в шаблона и компилацията, а не в конфигурацията. На практика този анализ се осъществява в рамките на уеб изпълнение работа, изпълнението се осъществява чрез разработване на продуктии когато подходът за рендиране на даден сайт е основното ограничение, дискусията се превръща в архитектурна тема за това как се създават страниците, а не в упражнение за настройване.