Як браўзеры загружаюць старонкі, як гэта ўплывае на прадукцыйнасць і як палепшыць CWV

Ключавой прычынай, па якой я вырашыў дапамагчы Overfuel, было тое, што каманда распрацоўшчыкаў разумела важнасць хуткасці загрузкі старонкі для ўсіх аспектаў бачнасці ў пошукавых сістэмах і карыстальніцкага досведу. Яны стварылі самы хуткі сайт аўтадылера платформа на планеце… і ўсе вынікі кліентаў значна пераўзышлі чаканні. Майце на ўвазе, што хуткасны сайт не толькі вырашае праблемы арганічнай выдачы; ён таксама павышае эфектыўнасць платнага пошуку, узаемадзеянне ў сацыяльных сетках і любы іншы сродак або канал, праз які вы прыцягваеце наведвальнікаў на свой сайт. Самае лепшае, што хуткі і добра распрацаваны сайт спрыяе канверсіям.

Як браўзеры загружаюць старонкі?

Для забеспячэння хуткай і адаптыўнай працы вэб-сайта неабходна разумець кожны этап загрузкі і адлюстроўвання старонкі ў браўзеры, правілы сеткі, якімі ён кіруецца, і стратэгіі, якія можна выкарыстоўваць для аптымізацыі кожнага этапу для павышэння хуткасці, эфектыўнасці і... Асноўныя вэб-жыццёвыя (CWV). Тое, што адбываецца паміж момантам націскання карыстальнікам на спасылку і момантам з'яўлення вашага кантэнту, не з'яўляецца загадкай — гэта складаная серыя ўзаемадзеянняў паміж браўзерам, сеткай і вашым серверам. Кожная мілісекунда ў гэтым працэсе можа паўплываць на тое, ці застанецца наведвальнік зацікаўленым, ці сыдзе.

З пункту гледжання бачнасці ў пошуку гэтыя веды вельмі важныя. Пошукавыя сістэмы, такія як Google, цяпер улічваюць хуткасць загрузкі старонкі і паказчыкі карыстальніцкага досведу непасрэдна ў сваіх алгарытмах ранжыравання. Сайты, якія павольныя або дрэнна аптымізаваныя, не толькі раздражняюць карыстальнікаў, але і рызыкуюць апусціцца ніжэй за больш хуткіх і лепшых канкурэнтаў у выніках пошуку. Асноўныя паказчыкі вэб-сайта — гэта вымерныя сігналы, якія адлюстроўваюць, наколькі хутка і плаўна загружаецца ваш сайт і становіцца інтэрактыўным. Разуменне працэсу прыняцця рашэнняў браўзерам падчас загрузкі з'яўляецца асновай для паляпшэння гэтых паказчыкаў і забеспячэння большай арганічнай бачнасці.

З боку карыстальніцкага досведу аптымізацыя прадукцыйнасці браўзера накіравана на ліквідацыю трэння. Карыстальнікі чакаюць імгненнай рэакцыі — ваганні або бачныя змены макета парушаюць адчуванне патоку і даверу. Авалодаўшы тым, як браўзеры атрымліваюць, аналізуюць і адлюстроўваюць кантэнт, а таксама ведаючы, як працуюць абмежаванні падключэнняў, паводзіны пратаколаў і стратэгіі дастаўкі рэсурсаў, вы можаце рабіць абдуманы і абгрунтаваны выбар, які забяспечыць лёгкія старонкі, хуткія ўзаемадзеянні і бесперабойны вопыт на розных прыладах і ў розных сеткавых умовах. У канкурэнтным лічбавым асяроддзі гэта не проста тэхнічная дапрацоўка; гэта асноўная перавага бізнесу.

Гэта кіраўніцтва служыць вычарпальным даведнікам для разумення працэсу загрузкі старонак у браўзеры, правілаў сеткі і пратаколаў, якія ім кіруюць, а таксама метадаў аптымізацыі, якія могуць значна палепшыць прадукцыйнасць. У ім падрабязна апісаны кожны этап загрузкі — ад першага DNS пошук да канчатковай карціны — адначасова супастаўляючы гэтыя дзеянні з Core Web Vitals і сучаснымі абмежаваннямі падключэння. Вы таксама знойдзеце рэкамендацыі па CDN стратэгія, аптымізацыя рэсурсаў, мініфікацыя і сцісканне, а таксама спіс эфектыўных мер для паляпшэння бачнасці ў пошуку і зручнасці выкарыстання (UX).

Храналогія загрузкі старонкі браўзера з Core Web Vitals

Храналогія загрузкі старонкі браўзера візуальна адлюстроўвае паслядоўнасць дзеянняў, якія браўзер выконвае для атрымання, рэндэрынгу і стварэння інтэрактыўнай вэб-старонкі. Разглядаючы гэтыя крокі ў залежнасці ад часу, вы можаце дакладна ўбачыць, дзе адбываюцца ключавыя этапы прадукцыйнасці.

Google выкарыстоўвае гэтыя паказчыкі для ацэнкі рэальнага карыстальніцкага досведу, і старонкі, якія не адпавядаюць патрабаванням, рызыкуюць страціць рэйтынг і знізіць узаемадзеянне.

Асноўныя вэб-жыццёвыя

Кожны маркер на часовай шкале адпавядае вымернай падзеі, якая адлюстроўвае альбо візуальную гатоўнасць, альбо інтэрактыўнасць.

• Першая фарба (FP): Пазначае момант, калі браўзер упершыню адлюстроўвае што-небудзь на экране, нават калі гэта проста колер фону. Хоць сам па сабе ён не з'яўляецца Core Web Vital, ён дае ранні сігнал аб візуальным прагрэсе.
• Першая афарбоўка зместу (FCP): Першы раз, калі з'яўляецца тэкст, выява або іншы значны кантэнт. Google разглядае гэта як паказчык таго, наколькі хутка карыстальнікі могуць успрыняць, што нешта адбываецца. Павольны FCP можа прывесці да таго, што старонка з самага пачатку не рэагуе.
• Самае вялікае афарбоўванне зместу (LCP)Час, неабходны для таго, каб найбольшы бачны элемент кантэнту — часта галоўны малюнак або асноўны загаловак — з'явіўся ў вобласці прагляду. LCP — адзін з трох афіцыйных асноўных паказчыкаў вэб-сайта, і Google рэкамендуе не перавышаць 2.5 секунды для добрага карыстальніцкага досведу.
• Затрымка першага ўваходу (У)Вымярае затрымку паміж першым узаемадзеяннем карыстальніка (клік, дотык, націсканне клавішы) і магчымасцю браўзера адказаць. Вялікія затрымкі тут часта ўзнікаюць, калі асноўны паток блакуецца інтэнсіўным выкананнем JavaScript. FID быў Core Web Vital, але з тых часоў быў заменены на INP.
• Кумулятыўны зрух макета (CLS)Нягледзячы на тое, што гэта не кропка на часовай шкале, CLS адсочвае нечаканыя візуальныя рухі падчас і пасля загрузкі. Нізкі CLS гарантуе, што элементы не будуць скакаць, памяншаючы расчараванне і выпадковыя клікі.
• Узаемадзеянне з наступнай фарбай (ІНП): Вымярае, колькі часу патрабуецца для візуальнай рэакцыі старонкі пасля любога значнага ўзаемадзеяння з карыстальнікам, а не толькі першага. INP фіксуе затрымку ўводу, апрацоўку падзей і момант адлюстравання наступнага кадра, што робіць яго значна больш поўнай мерай хуткасці рэагавання. Google лічыць INP менш за 200 мілісекунд плыўным і імгненным.

Разумеючы, калі і чаму адбываюцца гэтыя падзеі, вы можаце лепш накіраваць паляпшэнне прадукцыйнасці на тыя часткі паслядоўнасці загрузкі, якія найбольш важныя для бачнасці ў пошуку і задаволенасці карыстальнікаў. У раздзелах ніжэй храналогія падзелена на этапы — пачынаючы з навігацыі і налады падключэння — падрабязна тлумачачы кожны з іх і паказваючы, як менавіта аптымізаваць іх для больш хуткіх, стабільных і больш адаптыўных старонак.

Этап 1: Навігацыя і налада падключэння

Загрузка старонкі пачынаецца ў той момант, калі карыстальнік запускае навігацыю — няхай гэта будзе націсканне на спасылку, увод URL, або адпраўка формы. На гэтым этапе браўзер вызначае, адкуль атрымаць запытаны рэсурс, падрыхтоўвае сеткавыя злучэнні і забяспечвае бяспечны шлях для абмену дадзенымі. Аптымізацыя гэтага этапу памяншае затрымку запуску і стварае аснову для хуткай загрузкі.

1. Разбор URL-адрасоў і пошук у кэшы

Самы першы крок у працэсе загрузкі старонкі ў браўзеры пачынаецца ў той момант, калі карыстальнік уводзіць вэб-адрас, націскае на спасылку або запускае навігацыю любым спосабам. Браўзер аналізуе URL-адрас, каб вызначыць пратакол (HTTP or HTTPS), імя дамена, шлях і любыя параметры запыту.

Перш чым звязацца з сеткай, браўзер правярае, ці ёсць у яго кэшы свежая, дзеючая копія запытанага рэсурсу. Гэты ранні пошук, які ахоплівае кэш памяці, кэш дыска і кэш сэрвіс-воркера, часта дазваляе абыйсці неабходнасць DNS дазвол, TCP/TLS рукапацісканні і цалкам сеткавая перадача, забяспечваючы амаль імгненную загрузку старонак для паўторных наведванняў або часта выкарыстоўваных рэсурсаў.

• Праверкі кэш-памяць, кэш дыска, і кэш сэрвіснага воркера для свежай копіі.
  • Кэш-памяць:
    • Крамы нядаўна карысталіся рэсурсамі (HTML, CSS, JS, выявы) у браўзеры RAM.
    • Вельмі хуткае атрыманне, бо пазбягае доступу да дыска і сеткавых выклікаў.
    • Змест звычайна ачышчаецца пры закрыцці ўкладкі або акна браўзера, або калі для іншых працэсаў патрабуецца памяць.
  • Кэш дыска:
    • Захоўвае рэсурсы ў лакальным сховішчы карыстальніка, каб яны захоўваліся на працягу ўсіх сесій.
    • Доступ павольнейшы, чым кэш-памяць, але ўсё ж значна хутчэйшы, чым выбарка па сетцы.
    • Кантралюецца з дапамогай кэша HTTP загалоўкі (Cache-Control, Expires, ETag), які паведамляе браўзеру, як доўга ён можа паўторна выкарыстоўваць файл перад паўторнай праверкай на серверы.
  • Кэш сэрвіснага воркера:
    • Кіруецца зарэгістраваным на сайце скрыптом сэрвіс-воркера, што дазваляе цалкам кантраляваць тое, што кэшуецца і як гэта абнаўляецца.
    • Дазваляе выкарыстоўваць пашыраныя шаблоны, такія як доступ у аўтаномным рэжыме і фонавую сінхранізацыю.
    • У адрозненне ад стандартных кэшаў браўзера, ён праграмуемы, таму распрацоўшчыкі могуць кэшаваць пэўныя адказы API, версіі рэсурсаў і абнаўляць іх у фонавым рэжыме без умяшання карыстальніка.
• Калі параметр сапраўдны, браўзер можа імгненна абслугоўваць без доступу да сеткі.

2. Разрозненне DNS

Пасля таго, як браўзер вызначыць, што яму трэба атрымаць рэсурс з сеткі, першым крокам будзе пераўтварэнне даменнага імя ў IP-адрас праз сістэму даменных імёнаў (DNS). Браўзер спачатку правярае ўласны кэш DNS і, пры неабходнасці, кэш аперацыйнай сістэмы на наяўнасць нядаўніх пошукаў. Калі кэшаваны запіс не існуе, ён адпраўляе запыт да настроенага DNS-рэзолвера, які часта прадастаўляецца карыстальнікам. Інтэрнэт-правайдэр або дзяржаўную паслугу, напрыклад Cloudflare or Google Public DNSУ некаторых выпадках дазвол DNS можа выконвацца бяспечна з выкарыстаннем DNS праз HTTPS (DoH) або DNS праз TLS (DoT), шыфруючы запыт для абароны прыватнасці. Гэты працэс гарантуе, што браўзер дакладна ведае, куды адпраўляць наступны запыт на падключэнне.

• Перакладае імя хаста ў IP-адрас праз:
  • Лакальны кэш DNS
  • АС-рэзолвер
  • DNS-сервер (па жаданні праз DNS праз HTTPS/TLS)
• Аптымізацыявыкарыстанне Папярэдняя выбарка DNS для даменаў, якія, як вы ведаеце, будуць патрэбныя.

3. TCP-рукапацісканне

Маючы IP-адрас, браўзер ініцыюе падключэнне па пратаколе кіравання перадачай (TCP), каб усталяваць надзейнае злучэнне з серверам. Гэта трохэтапны абмен: браўзер адпраўляе серверу пакет SYN (сінхранізацыя), сервер адказвае SYN-ACK (пацверджанне сінхранізацыі), а браўзер адказвае ACK (пацверджанне) для пацверджання. Гэта падключэнне ўстанаўлівае правілы сувязі, у тым ліку нумары партоў і паслядоўнасць, гарантуючы, што абодва бакі гатовыя адпраўляць і атрымліваць дадзеныя ўпарадкаваным рэжыме з праверкай памылак.

• Усталёўвае злучэнне з дапамогай паслядоўнасці SYN → SYN-ACK → ACK.

4. Рукапацісканне SSL/TLS (HTTPS)

Калі падключэнне выкарыстоўвае HTTPS, браўзер выконвае падпіску SSL/TLS пасля ўстанаўлення TCP. На гэтым этапе браўзер і сервер узгадняюць версію пратакола шыфравання (напрыклад, TLS 1.3), выбіраюць сумяшчальныя наборы шыфраў і абменьваюцца ключамі для забеспячэння бяспечнай сувязі. Сервер таксама адпраўляе свой сертыфікат SSL/TLS, які браўзер правярае ў сваіх давераных цэнтрах сертыфікацыі. У некаторых выпадках браўзер можа выканаць праверку OCSP (Online Certificate Status Protocol) або выкарыстоўваць OCSP-стэплінг для пацверджання сапраўднасці сертыфіката. Гэты працэс гарантуе, што ўся наступная сувязь зашыфравана, а асоба сервера праверана.

• Узгадняе версію пратакола (TLS 1.2/1.3) і наборы шыфраў.
• Правярае сертыфікат сервера (можа праверыць праз OCSP/CRL).
• Абмяняецца ключамі шыфравання для бяспечнай сувязі.
• АптымізацыяУключыце TLS 1.3 для больш хуткага ўзаемадзеяння.

Этап 2: Пошук HTML і крытычны шлях

Пасля таго, як злучэнне гатовае, браўзер запытвае HTML-дакумент і рыхтуецца атрымаць усё неабходнае для адлюстравання старонкі. Гэта той момант, калі хуткасць сервера, стратэгія кэшавання і прыярытэтызацыя рэсурсаў аказваюць найбольшы ўплыў на час да першага байта і пачатку рэндэрынгу.

5. HTTP-запыт/адказ

Пасля ўстанаўлення бяспечнага канала браўзер адпраўляе HTTP-запыт на сервер. Гэты запыт уключае метад (звычайна GET для загрузкі старонкі), загалоўкі, якія апісваюць кліенцкае асяроддзе і налады, файлы cookie для падтрымання сесій і часам цела запыту для такіх метадаў, як POST. Сервер апрацоўвае запыт і вяртае HTTP-адказ, які змяшчае код стану (напрыклад, 200 OK, 301 Moved Permanently або 404 Not Found), загалоўкі (тып кантэнту, дырэктывы кэшавання, інфармацыя аб сцісканні) і цела HTML. Гэты HTML-код з'яўляецца адпраўной кропкай для браўзера, каб даведацца, якія іншыя рэсурсы ён павінен атрымаць для рэндэрынгу старонкі. Калі адказ з'яўляецца перанакіраваннем, браўзер паўтарае папярэднія крокі для новага URL-адраса.

• Браўзер адпраўляе загалоўкі запытаў (файлы cookie, кантроль кэша і г.д.).
• Сервер адказвае статусам, загалоўкамі і целам HTML-паведамлення.
• Перанакіраванне перазапускае некаторыя этапы падключэння.

6. Падказкі па рэсурсах

Сучасныя браўзеры могуць рэагаваць на падказкі па прадукцыйнасці, убудаваныя ў HTML або загалоўкі адказаў, каб аптымізаваць загрузку. Гэтыя падказкі, такія як preconnect, dns-prefetch, preload, і prefetch— дапамагаюць браўзеру прадбачыць і падрыхтавацца да будучых запытаў. Напрыклад, preconnect ініцыюе падпіску TCP/TLS з іншым паходжаннем, перш чым гэта спатрэбіцца, у той час як preload загадвае браўзеру неадкладна атрымаць крытычна важны рэсурс, напрыклад, табліцу стыляў або шрыфт. Правільнае выкарыстанне падказак рэсурсаў можа зрушыць усталяванне злучэння і атрыманне на больш ранні час на часовай шкале, скарачаючы затрымкі на крытычна важным шляху рэндэрынгу.

• Папярэдняе падключэннеРазагрэйце TCP/TLS да знешніх крыніц.
• Папярэдняя загрузкаНеадкладна атрымаць рэсурсы з высокім прыярытэтам (CSS, шрыфты, галоўныя выявы).
• Prefetch: Выбарка з нізкім прыярытэтам для верагодных будучых навігацый.
• Папярэдняя выбарка DNSВызначайце імёны загадзя.

Этап 3: Парсінг, блакаванне і рэндэрынг

Браўзер пачынае пераўтвараць неапрацаваны HTML у зручную для выкарыстання структуру, спыняючыся, калі сутыкаецца з рэсурсамі, якія блакуюць рэндэрынг, такімі як CSS або сінхронныя скрыпты. Менавіта тут добрыя практыкі ўпарадкавання і дастаўкі рэсурсаў могуць значна палепшыць хуткасць з'яўлення значнага кантэнту для карыстальніка.

7. Разбор HTML і пабудова DOM

Браўзер пачынае чытаць HTML зверху ўніз, пераўтвараючы яе ў дрэвападобную структуру пад назвай Мадэль аб'ектаў дакумента (ПАСТАНОВА). Падчас аналізу ён сустракае тэгі для тэксту, малюнкаў, скрыптоў і стыляў. CSS-файлы па змаўчанні блакуюць рэндэрынг, гэта значыць, браўзер не будзе адлюстроўваць кантэнт, пакуль стылі не будуць атрыманы і прааналізаваны, у той час як скрыпты таксама могуць блакіраваць аналіз, калі яны не пазначаны . async or deferЭфектыўнае ўпарадкаванне рэсурсаў, мінімізацыя блакуючых скрыптоў і ўбудаванне крытычна важнага CSS могуць значна палепшыць хуткасць з'яўлення бачнага кантэнту.

• Пераўтварае HTML у DOM.
• Сустрэчы рэсурсы, якія блакуюць рэндэрынг:
  • CSS-файлы: блакіраваць да загрузкі і аналізу.
  • JS-файлы:
    • Няма атрыбуту → блакуе разбор да выканання.
    • async → загружае паралельна, выконваецца адразу пасля гатоўнасці.
    • defer → загружае паралельна, выконваецца пасля завяршэння парсінгу.

8. CSSOM і дрэва рэндэрынгу

Калі браўзер атрымлівае CSS-файлы, ён пераўтварае іх у аб'ектную мадэль CSS (CSSOM), структураванае прадстаўленне ўсіх правілаў стылю. DOM і CSSOM затым аб'ядноўваюцца, каб сфармаваць дрэва рэндэрынгу, якое змяшчае толькі элементы і стылі, неабходныя для бачнага кантэнту. Гэты працэс выключае схаваныя элементы (напрыклад, тыя, што маюць display: none). Пабудова дрэва рэндэрынгу з'яўляецца абавязковай умовай для кампаноўкі і малявання, таму затрымкі ў дастаўцы або парсінгу CSS могуць непасрэдна паўплываць на найбольшую колькасць макетаў кантэнту (LCP).

• CSS-файлы перапрацоўваюцца ў CSSOM.
• DOM + CSSOM = дрэва рэндэрынгу (бачныя вузлы і вылічаныя стылі).

Этап 4: Макет, маляванне і ўзаемадзеянне

Калі DOM і стылі гатовыя, браўзер вылічвае пазіцыі элементаў, афарбоўвае пікселі і збірае канчатковы візуальны вынік. Тут вырашальнае значэнне маюць старанная стабільнасць макета, эфектыўнае афарбоўванне і аптымізаваная кампазіцыя, каб пазбегнуць візуальных затрымак і зрухаў макета.

9. Макет (перапланіроўка)

Пасля завяршэння дрэва рэндэрынгу браўзер вылічвае становішча і памер кожнага бачнага элемента на старонцы. Гэты этап, вядомы як размяшчэнне або перапланіроўка, вызначае, дзе кожны фрагмент кантэнту змяшчаецца ў вобласці прагляду. Любыя змены, якія патрабуюць пераразліку пазіцый, такія як даданне новых элементаў над існуючым кантэнтам, могуць выклікаць дадатковыя перапланіроўкі, што можа значна паўплываць на прадукцыйнасць і прывесці да зрушэнняў макета, якія пагоршаць сукупны зрух макета (CLS) балы.

• Разлічвае геаметрыю і становішча элементаў.
• Познія змены макета тут спрыяюць CLS.

10. Фарба

Пасля таго, як макет завершаны, браўзер пераносіць пікселі кожнага элемента — тэкст, выявы, фоны, межы — на пласты. Ператварэнне — гэта працэс пераўтварэння абстрактных формаў і стыляў у візуальны вынік. Моцныя візуальныя эфекты, такія як цені, градыенты або складаныя SVG можа запаволіць маляванне, асабліва на прыладах з меншай магутнасцю. Аптымізацыя гэтых прылад можа скараціць час паміж макетаваннем і першым маляваннем змесціва (FCP).

• Запаўняе пікселі для тэксту, малюнкаў і фону.

11. Кампазіцыя

Канчатковая візуальная зборка адбываецца падчас кампазіцыі. Тут браўзер бярэ намаляваныя пласты і аб'ядноўвае іх у адзін малюнак для прагляду карыстальнікам. Пэўныя ўласцівасці CSS, такія як пераўтварэнні, змены непразрыстасці і анімацыя, могуць перамяшчаць элементы ў асобныя пласты, якія кампазітуюцца асобна. Хоць гэта можа палепшыць плаўнасць анімацыі, занадта шмат пластоў таксама можа дадаць накладныя выдаткі. Балансаванне выкарыстання пластоў з'яўляецца ключом да плаўнага рэндэрынгу.

• Слаі аб'ядноўваюцца ў канчатковую растравую выяву і адлюстроўваюцца.

Этап 5: Загрузка актываў і тыпы запытаў

Акрамя HTML і CSS, браўзер загружае выявы, шрыфты, медыяфайлы, скрыпты і ўбудаваныя элементы іншых вытворцаў — кожны з іх мае свае ўласныя патрабаванні да прадукцыйнасці. Тое, як гэтыя рэсурсы загружаюцца, сціскаюцца і прыярытэтызуюцца, можа істотна паўплываць на Core Web Vitals.

Тыповыя тыпы запытаў падчас загрузкі старонкі ўключаюць:

1. HTML дакумент
2. Табліцы стыляў CSS
3. JavaScript (сінхранізацыя, асінхроннасць, адтэрміноўка)
4. выявы (<img>, фон, srcset)
5. Шрыфты (WOFF2, ВОФ, TTF)
6. Відэа/аўдыё носьбіты інфармацыі
7. XHR / Выбраць API званкі
8. WebSocket-злучэнні
9. Запыты на працу з сэрвіснымі работнікамі
10. Папярэдняя выбарка DNS
11. Папярэдняе падключэнне
12. Папярэдняя загрузка
13. Prefetch
14. Выклікі API маякоў
15. Убудаваныя элементы іншых вытворцаў (iframe, рэклама, віджэты)
16. Пікселі аналітыкі/адсочвання

Этап 6: Дзейнасць пасля нагрузкі

Нават пасля таго, як старонка загрузілася, браўзер працягвае працаваць. Ініцыялізуюцца скрыпты, выконваюцца фонавыя задачы, а сэрвісныя работнікі могуць усталёўваць або абнаўляць. Кіраванне гэтым этапам гарантуе, што сайт застанецца адаптыўным, стабільным і гатовым да наступнага ўзаемадзеяння карыстальніка.

12. Выкананне JavaScript

Нават пасля першапачатковага рэндэрынгу JavaScript працягвае выконвацца. Падключаюцца слухачы падзей, ініцыялізуюцца аналітычныя скрыпты, а таксама запускаюцца адкладзеныя або асінхронныя скрыпты. Калі гэты код занадта цяжкі або манапалізуе асноўны паток, ён можа затрымаць узаемадзеянне з карыстальнікамі, уплываючы на затрымку першага ўводу (FID) або ўзаемадзеянне з наступным маляваннем (INP). Разбіццё вялікіх задач, выкарыстанне requestIdleCallback для нетэрміновай працы і перадача вылічэнняў вэб-воркерам могуць палепшыць хуткасць рэагавання.

• Слухачы падзей, аналітыка, адкладзены код.
• Цяжкія задачы тут уплываюць У/ІНП.

13. Бяздзейныя задачы

Падчас бяздзейнасці браўзер можа выконваць фонавыя задачы, такія як ачыстка памяці, папярэдняя загрузка рэсурсаў для верагодных наступных навігацый або ўстаноўка/абнаўленне сэрвісных воркераў. Гэта магчымасць для распрацоўшчыкаў планаваць задачы з нізкім прыярытэтам, не ўплываючы на інтэрактыўнасць. Аднак перагрузка перыядаў бяздзейнасці ўсё роўна можа прывесці да збояў у прадукцыйнасці, калі карыстальнік раптоўна ўзаемадзейнічае са старонкай.

• Папярэдняя загрузка будучых навігацый.
• Абслугоўванне кэша.
• Усталёўка сэрвіснага работніка.

Абмежаванні на адначасовыя падключэнні

Кожны браўзер усталёўвае абмежаванні на колькасць сеткавых падключэнняў, якія ён можа падтрымліваць адначасова, як для кожнага сайта, так і глабальна. Гэтыя абмежаванні прызначаны для балансавання прадукцыйнасці з нагрузкай на сервер, не дазваляючы асобнаму сайту манапалізаваць сеткавыя рэсурсы. Разуменне гэтых абмежаванняў — і таго, як яны адрозніваюцца паміж HTTP/1.1, HTTP/2 і HTTP/3 — мае важнае значэнне пры выбары спосабу абслугоўвання рэсурсаў, выкарыстання некалькіх даменаў або CDN, а таксама прыярытэзацыі запытаў для аптымальнай хуткасці загрузкі.

Стратэгія CDN: адзін і той жа дамен супраць асобнага дамена

Калі асобны CDN-дамен дапамагае (асабліва HTTP/1.1):

• Абыходзіць абмежаванні на колькасць падключэнняў для кожнага паходжання, дадаючы больш пулаў падключэнняў.
• Карысна для разгрузкі вялікіх, некрытычных рэсурсаў, каб яны не блакіравалі HTML/CSS/JS.

Калі варта пазбягаць асобных CDN-даменаў (асабліва HTTP/2/3):

• Дадае дадатковы час DNS і часу ўстанаўлення сувязі.
• Мультыплексаванне пазбаўляе большасці пераваг шардынгу дамена.
• Для рэсурсаў, важных для рэндэрынгу, пераважней інтэграваць CDN аднаго дамена.