Отговаря ли представянето на вашата уеб страница на днешните стандарти? Рендерирането е процес на преобразуване на отговора на сървъра в картината, която браузърът „рисува“, когато потребител посети уебсайт. Лошото представяне на визуализация може да се превърне в относително висока степен на отпадане.

Има различни отговори на сървъра, които определят дали дадена страница се изобразява или не. В тази статия ще се съсредоточим върху първоначалното изобразяване на уеб страницата, което започва с разбор на HTML (при условие, че браузърът успешно е получил HTML като отговор на сървъра). Ще проучим нещата, които могат да доведат до високи времена за изобразяване, и как да ги поправим.

Критичен път на изобразяване

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

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

Ако това е файл на таблица със стилове, браузърът ще трябва да го анализира напълно, преди да изобрази страницата и ето защо Казва се, че CSS блокира рендирането .

Ако това е скрипт, браузърът трябва: да спре да анализира, да изтегли скрипта и да го стартира. Едва след това може да продължи да анализира, тъй като програмите на JavaScript могат да променят съдържанието на уеб страница (по-специално HTML). И ето защо JS се нарича блокиране на парсер .

След като завърши цялото парсиране, браузърът изгражда обектния модел на документ (DOM) и обектния модел на каскадни таблици със стилове (CSSOM). Комбинирането им дава Render Tree. Непоказваните части на страницата не я правят в Render Tree, защото тя съдържа само данните, необходими за изчертаването на страницата.

Предпоследната стъпка е да преведете Render Tree в Layout. Този етап се нарича още Reflow. Именно там се изчислява всяка позиция на всеки възел на Render Tree, както и неговият размер.

И накрая, последната стъпка е Paint. Включва буквално оцветяване на пикселите според данните, които браузърът е изчислил през предходните етапи.

Заключения, свързани с оптимизацията

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

следните фактори са допринесли за влиянието на графичния дизайн, освен

• Количеството данни, които трябва да бъдат прехвърлени
• Броят на ресурсите, които браузърът трябва да изтегли (особено блокиращите)
• Дължината на CRP

Освен това ще се потопим в подробностите за това как се прави, но първо, има важно правило, което трябва да се спазва.

Как да се измери ефективността

Важно правило за оптимизация е: Първо измерете, оптимизирайте според нуждите . Инструментите за разработчици на повечето браузъри имат раздел, наречен производителност , и там се случват измерванията. Когато оптимизирате за най-бързо първоначално (първо) изобразяване, най-важното нещо, което трябва да се погледне, е времето на следните събития:

• Първа боя
• Първа съдържателна боя
• Първа смислена боя

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

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

Стратегии за оптимизиране на ефективността

Като се има предвид това, което научихме по-горе, има три основни стратегии за оптимизиране на ефективността на уебсайта:

1. Минимизиране на количеството данни, които трябва да бъдат прехвърлени по проводника,
2. Намаляване на общия брой ресурси, които трябва да бъдат прехвърлени по проводника, и
3. Съкращаване на критичния път на изобразяване

1. Минимизирайте количеството данни, които трябва да бъдат прехвърлени

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

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

След като това стане, това, което ни остава, може да бъде като текст. Това означава, че можем безопасно да приложим алгоритъм за компресиране като GZIP (който повечето браузъри разбират).

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

• Ако използвате CDN, уверете се, че кеширането се поддържа и правилно е настроено там.
• Вместо да чакате да дойде датата на изтичане на ресурсите, може да искате да имате начин да го актуализирате по-рано от ваша страна. Вградете „пръстовите отпечатъци“ на файловете в техните URL адреси, за да можете обезсилва локалния кеш .

Разбира се, политиките за кеширане трябва да бъдат дефинирани за всеки ресурс. Някои може рядко да се променят или изобщо никога да не се променят. Други се променят по-бързо. Някои съдържат чувствителна информация, други могат да се считат за обществени. Използвай „Частна“ директива за да предпазите CDN от кеширане на лични данни.

Може да се направи и оптимизиране на уеб изображения, въпреки че заявките за изображения не блокират нито анализирането, нито изобразяването.

2. Намалете общия брой критични ресурси

„Критично“ се отнася само до ресурси, необходими за правилното изобразяване на уеб страницата. Следователно можем да пропуснем всички стилове, които не са включени в процеса директно. И всички скриптове също.

Таблици със стилове

За да кажем на браузъра, че определени CSS файлове не са необходими, трябва да зададем media атрибути към всички връзки, отнасящи се до таблици със стилове. С този подход браузърът ще третира само ресурсите, които съответстват на текущите media (тип устройство, размер на екрана) според необходимостта, като същевременно намалява приоритета на всички останали таблици със стилове (те така или иначе ще бъдат обработени, но не като част от критичния път на изобразяване). Например, ако добавите media='print' атрибут на style таг, който препраща към стиловете за разпечатване на страницата, тези стилове няма да пречат на критичния ви път на рендиране, когато носителят не е print (т.е. при показване на страницата в браузър).

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

Скриптове

Както бе споменато по-горе, скриптовете блокират парсер, защото могат да променят DOM и CSSOM. Следователно, скриптовете, които го правят не не ги променяйте, не трябва да бъдат разбор на блокове, като по този начин ни спестявате време.

За да се приложи това, всички маркери на скриптове трябва да бъдат маркирани с атрибути - или async или defer.

Скриптове, отбелязани с async не блокирайте DOM конструкцията или CSSOM, тъй като те могат да бъдат изпълнени преди CSSOM да бъде изграден. Имайте предвид обаче, че вградените скриптове така или иначе ще блокират CSSOM, освен ако не ги поставите над CSS.

За разлика от тях, скриптове, маркирани с defer ще бъдат оценени в края на зареждането на страницата. Следователно те не трябва да засягат документа (в противен случай той ще задейства повторно изобразяване).

С други думи, с defer, скриптът не се изпълнява, докато не се задейства събитието за зареждане на страницата, докато async позволява на скрипта да работи във фонов режим, докато документът се анализира.

3. Съкратете дължината на критичния път на рендиране

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

Медийните заявки като атрибути за стиловите тагове ще намалят общия брой ресурси, които трябва да бъдат изтеглени. Атрибутите на маркера на скрипта defer и async ще попречи на съответните скриптове да блокират синтактичния анализ.

Минифицирането, компресирането и архивирането на ресурси с GZIP ще намали размера на прехвърлените данни (като по този начин ще намали и времето за пренос на данни).

Вграждането на някои стилове и скриптове може да намали броя на обиколките между браузъра и сървъра.

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

Заключение: Оптимизацията обхваща целия ви стек

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

Разработчиците на браузъри правят всичко възможно, за да оптимизират производителността на уебсайта за всяка страница, която посещавате, поради което браузърите обикновено прилагат така наречения „предварително зареждане“. Тази част от програмите сканира преди ресурс, който сте поискали в HTML, за да правите няколко заявки едновременно и да ги изпълнявате паралелно. Ето защо е по-добре да държите стиловите тагове близо един до друг в HTML (по ред), както и тагове на скриптове.

Освен това, опитайте се да изпращате актуализации на HTML, за да избегнете множество събития за оформление, които се задействат не само от промяна в DOM или CSSOM, но и от промяна на ориентацията на устройството и преоразмеряване на прозореца.

Полезни ресурси и допълнително четене:

• PageSpeed ​​Insights
• Контролен списък за кеширане
• Начин за тест ако GZIP е активиран за вашия уебсайт
• Високоефективна мрежа за браузър : Книга на Иля Григорик

Разбиране на основите

Какво представлява оптимизацията на уебсайта?

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

Как мога да проверя ефективността на уебсайта си?

Опитайте да използвате онлайн инструменти като PageSpeed ​​Insights на Google. Можете също така да използвате браузъра си в режим „Частно сърфиране“, за да заредите сайта, без да имате кеширани данни локално. Някои браузъри също ви позволяват да използвате дроселиране, което ви помага да симулирате бавна скорост на връзката.

Какво е скоростта на уебсайта?

Скоростта на уебсайта може да се определи като средното време за зареждане на уебсайт. Алтернативно, това може да означава неговата честота на кадрите в секунда, особено по време на тежки изчислителни операции.

Колко бързо трябва да се зареди уебсайт?

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

Каква е функцията на механизма за рендиране?

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

Какво е блокиране на визуализация?

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