IlmHamroh
JavaScript Full-stack/6-qism. CSS: harakat, zamonaviy CSS va dizayn38/57-dars21 daqiqa
Mundarija (36)

CSS yuklash samaradorligi: render-blocking, critical CSS va media

Qisqacha: Brauzer head dagi har CSS fayl kelmaguncha sahifani chizmaydi — CSS render'ni bloklaydi. Shuning uchun CSS kichik, kam faylli va erta topiladigan bo'lsin. Har @import pog'onasi bitta kutish qo'shadi — bitta link yoki yig'ilgan fayl yaxshiroq. Hozir mos kelmaydigan fayl (<link media="print">) bloklamaydi va eng past navbatda yuklanadi. Katta saytlarda birinchi ekran uchun kerakli "kritik" CSS head ga yoziladi, qolgani keyin keladi. Ishlatilmagan CSS'ni olib tashlash, siqish (minify) va Brotli/gzip hajmni o'n baravargacha kamaytiradi.

Bu darsda

  • CSS nega render'ni bloklashini tushuntirasiz va buni Chrome'da o'lchaysiz (FCP, so'rov navbati).
  • @import zanjiri, preload va link ning media atributi sahifa tezligiga qanday ta'sir qilishini raqam bilan asoslaysiz.
  • Critical CSS nima ekanini, uni qaysi vosita yasashini va «Bahor» CSP'si bilan qanday to'qnashishini bilasiz.
  • Ishlatilmagan CSS'ni DevTools Coverage bilan topasiz, PurgeCSS, siqish va Brotli/gzip farqini raqamda ko'rasiz.
  • Lighthouse hisobotidagi CSS tavsiyalarini o'qiysiz va CSS hajmiga byudjet qo'yasiz.

Oldin bilishingiz kerak: Renderni nima to'xtatadi, Resurs maslahatlari, CSS metodologiyalari, PostCSS va Lightning CSS, Rendering pipeline.

1. Nega bu kerak?

Aziz avtobusda, telefonda «Bahor» menyusini ochdi. Internet sekin. Ekran oppoq — bir soniya, ikki soniya. U "sayt ishlamayapti" deb orqaga qaytdi. Holbuki HTML allaqachon kelgan edi: sarlavha, taomlar, narxlar — hammasi telefonda turibdi. Brauzer uni ko'rsatmayapti, chunki CSS kelishini kutyapti.

Renderni nima to'xtatadi darsidan eslang: CSS — render'ni bloklovchi (render-blocking) resurs. Brauzer head dagi CSS faylni topsa, u kelmaguncha birorta piksel chizmaydi. Sababi oddiy: CSS'siz chizsa, foydalanuvchi avval "yalang'och" sahifani ko'radi, keyin u birdan o'zgaradi. Bu chaqnash — FOUC (Qorong'i rejim darsida uni tema uchun ko'rgan edik).

Demak, CSS sahifaning birinchi ko'rinishini to'g'ridan-to'g'ri kechiktiradi. Ikki o'lchov shunga bog'liq:

  • FCP (First Contentful Paint) — ekranga birinchi matn yoki rasm chiqqan payt.
  • LCP (Largest Contentful Paint) — eng katta element (odatda sarlavha yoki asosiy rasm) chiqqan payt. Google'ning Core Web Vitals o'lchovlaridan biri: 2.5 soniyadan tez — "yaxshi".

Bugun biz taxmin qilmaymiz — o'lchaymiz. CSS metodologiyalari darsidagi @import o'lchovini davom ettiramiz va CSS yetkazishning har usulini Chrome'da sinaymiz. Xuddi osh damlashdagidek: qozon qizigandan keyin sabzi uchun bozorga yugursangiz, osh kechikadi (Resurs maslahatlari). CSS ham shunday: nima erta kerak, nima keyin — shuni to'g'ri tashkil qilish kerak.

2. O'lchov sharoiti

Kichik lokal server yasadik. U har faylni — HTML'ni ham, har CSS'ni ham — ataylab 300 millisekund ushlab turadi, sekin mobil internetdagidek (xuddi CSS metodologiyalari darsidagi kabi). Sahifa — «Bahor» menyusining bo'lagi: header, h1, uchta taom-karta, bron-havola. CSS — o'sha darsdagi olti fayl (tokenlar.css, reset.css, asos.css, layout.css, komponentlar.css, yordamchi.css), jami 1.2 KB.

Brauzer — Chrome 154, ekran eni 360 piksel, kesh o'chirilgan. Har variant uch marta ochildi. FCP — performance.getEntriesByName("first-contentful-paint") bilan, so'rovlar navbati — Chrome'ning o'z protokolidan olindi. Bu JavaScript — 09-qismda o'qiy olasiz, hozir raqamlarning o'zi muhim.

Asosiy nuqta — CSS'siz sahifa: FCP 348–360 ms. HTML 300 ms kutildi, keyin darhol chizildi. Undan keyingi hamma raqamni shu bilan solishtiramiz.

3. Bloklash va zanjir

Olti faylni bitta hammasi.css ga qo'shdik va bitta link bilan uladik:

Variant FCP (3 marta)
CSS'siz 348–360 ms
Bitta link 644–736 ms

Nimaga qarang: ~300 ms qo'shildi — aynan CSS faylning kutish vaqti. Brauzer HTML'ni o'qib bo'ldi, lekin hammasi.css kelguncha (644-millisekund) kutdi. Chrome buni renderBlockingStatus: "blocking" deb belgiladi, so'rov navbati — VeryHigh (DevTools'ning Network panelida "Highest" deb ko'rinadi).

Bu — muqarrar narx. CSS'siz sahifa yaxshi emas; bitta tez fayl — normal holat. Muammo shundan keyin boshlanadi.

3.2 @import zanjiri

«Bahor»ning kirish fayli: asosiy.css ichida oltita @import.

Variant FCP Qachon so'raldi
Bitta link 644–736 ms hammasi.css — 332 ms
@import, 1 pog'ona 972–980 ms asosiy.css — 308, oltitasi — 628 ms
@import, 2 pog'ona 1288–1296 ms 314 → 625 → 951 ms

Nimaga qarang: har pog'ona bitta to'liq kutish qo'shadi. Birinchi pog'onada oltita fayl bir vaqtda so'raldi (628 ms) — CSS metodologiyalari darsidagi natija qayta tasdiqlandi. Ikki pog'onali zanjirda (zanjir.css → ichki-1.css → ichki-2.css) esa uchinchi fayl faqat 951-millisekundda so'raldi: brauzer uning borligini ikkinchi faylni o'qigandagina bildi.

flowchart LR
  H["HTML<br/>0–300 ms"] --> A["zanjir.css<br/>314–625"]
  A --> B["ichki-1.css<br/>626–950"]
  B --> C["ichki-2.css<br/>951–1260"]
  C --> F["Chizish<br/>~1290 ms"]

Nimaga qarang: to'rt kutish ketma-ket, hech biri parallel emas. Sekin 4G'da har kutish yarim soniyagacha bo'lishi mumkin (Resurs maslahatlari darsidagi ulanish narxi).

3.3 preload zanjirni uzadi

Zanjir fayllarini brauzerga oldindan aytsak-chi? Resurs maslahatlari darsidagi preload:

html
<link rel="preload" href="css/zanjir.css" as="style">
<link rel="preload" href="css/ichki-1.css" as="style">
<link rel="preload" href="css/ichki-2.css" as="style">
<link rel="stylesheet" href="css/zanjir.css">

Natija: uchala fayl bir vaqtda — 316-millisekundda so'raldi. FCP 652–672 ms — bitta link bilan deyarli bir xil. @import qoldi, lekin brauzer endi uni kutmaydi: fayllar allaqachon kelgan.

Bu — build vositasiz eng oddiy yechim. Kamchiligi: preload ro'yxatini qo'lda yangilab turish kerak. Fayl qo'shsangiz va preload ni unutsangiz — zanjir qaytadi.

Tekshirib ko'ring: «Bahor»ning asosiy.css i oltita faylni bitta pog'onada import qiladi. Mehmon sahifani ikkinchi marta ochdi — fayllar brauzer keshida. @import endi zarar qiladimi?

Javob

Deyarli yo'q. Kutish — tarmoq so'rovi uchun. Fayllar keshdan olinsa (HTTP kesh), zanjir millisekundlarda o'tadi. Shuning uchun @import zarari asosan birinchi tashrifda — lekin aynan birinchi tashrif mehmon sayt haqida fikr qiladigan payt. Google ham birinchi tashrif tezligini o'lchaydi.

4. media atributi: bloklamaydigan CSS

4.1 Chop etish fayli

«Bahor»ning yordamchi.css i — asosan chop etish uchun (Foydalanuvchi afzalliklari). Uni media atributi bilan alohida link qilsak:

html
<link rel="stylesheet" href="css/ekran.css">
<link rel="stylesheet" href="css/chop.css" media="print">
Variant chop.css navbati Bloklaydimi FCP
media siz VeryHigh ha 672–684 ms
media="print" VeryLow yo'q 656–680 ms

Nimaga qarang: chop etish fayli baribir yuklanadi (chop etish tugmasi bosilsa, u tayyor bo'lishi kerak), lekin eng past navbatda va sahifani to'xtatmaydi. Atributga istalgan media query yoziladi. media="(width >= 64rem)" ni 360 pikselli ekranda sinadik — natija xuddi shunday: VeryLow, bloklamadi. Ekran kattalashsa, brauzer uni darhol qo'llaydi.

Bu yerda FCP farqi kichik, chunki ikkala fayl ham bir xil 300 ms kutdi. Farqni ko'rish uchun chop etish faylini ataylab 1500 ms sekin qildik:

Variant FCP
<link media="print">, sekin fayl 676–692 ms
@import url("yordamchi.css") print;, sekin fayl 2192–2220 ms

Nimaga qarang: link dagi media sahifani sekin fayldan himoya qildi. Import qatoridagi print esa himoya qilmadi: Chrome faylni VeryHigh navbatda so'radi va blocking deb belgiladi — sahifa 2.2 soniya oppoq turdi. Media sharti bilan ham @import kirish faylining bir qismi bo'lib qoladi.

Qoida: katta va hozir kerak bo'lmaydigan CSS (chop etish, faqat katta ekran uchun og'ir bo'lak) — @import emas, media li alohida link.

4.2 Navbatni DevTools'da ko'rish

Resurs maslahatlari darsidagi usul: Network panelida ustunlar sarlavhasiga o'ng tugma → Priority. media="print" li CSS qatorida — Lowest, oddiy CSS'da — Highest. Throttling ro'yxatidan "Slow 4G" ni tanlang — farq ko'zga tashlanadi.

Tekshirib ko'ring: <link rel="stylesheet" href="katta-ekran.css" media="(width >= 64rem)"> qo'yildi. Telefondagi mehmon uni yuklab oladimi?

Javob

Ha, yuklaydi — lekin eng past navbatda va sahifa chizilishini to'xtatmasdan. Brauzer faylni tashlab ketmaydi: mehmon telefonni yotqizib qo'ysa yoki oyna kattalashsa, fayl tayyor bo'lishi kerak. Trafik tejalmaydi, lekin tezlik tejaladi.

5. Critical CSS

5.1 G'oya

Mehmon sahifani ochganda birinchi ekranni ko'radi — telefonda header, sarlavha va bir-ikki karta. Footer, bron formasi, chop etish qoidalari hali kerak emas. Critical CSS (kritik CSS) — faqat birinchi ekran uchun kerak bo'lgan qoidalar. Ular <style> ichida HTML'ning o'ziga yoziladi, to'liq CSS esa bloklamasdan keyin keladi. Natija: CSS uchun alohida kutish yo'q — sahifa HTML bilan birga chiziladi.

Kritik CSS'ni qo'lda ajratish — xatoga moyil. Buni vositalar qiladi: Beasties (Google'ning eskirgan Critters vositasining davomi, beasties 0.5.4), critical paketi, Vite va Next.js plaginlari. Beasties'ni bitta link li sahifamizga qo'lladik:

text
Inlined 938 bytes (79% of original 1.15 kB) of css/hammasi.css.

Tarjimasi: "hammasi.css dan 938 bayt (1.15 KB ning 79%) ichkariga yozildi." Kichik CSS'ning deyarli hammasi birinchi ekranda ishlatiladi — 79%. Vosita head ga <style> va <link rel="preload" as="style"> qo'ydi, asl link ni esa body oxiriga ko'chirdi. O'lchov: FCP 344–420 ms — CSS'siz sahifa bilan bir xil. hammasi.css — non-blocking.

Katta CSS'da manzara boshqacha. Xuddi shu menyuni Bootstrap bilan yozib (CSS freymvorklar), Beasties'dan o'tkazdik:

text
Inlined 9.58 kB (4% of original 226.67 kB) of bs/bootstrap.min.css.

Birinchi ekranga 227 KB dan atigi 4% — 9.6 KB kerak ekan. Critical CSS aynan shunday — katta CSS'li saytlarda — o'zini oqlaydi.

5.2 media="print" onload hiylasi

Kritik CSS yozilgach, to'liq faylni bloklamasdan qanday yuklash kerak? Internetda mashhur hiyla:

html
<link rel="stylesheet" href="css/hammasi.css"
      media="print" onload="this.media='all'">

O'qilishi: "faylni chop etish uchun deb yukla (bloklamaydi — «media atributi» bo'limidagi qoida), yuklangach media ni all ga almashtir". onload — JavaScript: "yuklab bo'lingach shu kodni bajar" (hodisalar, 09-qism).

Kritik CSS'siz faqat shu hiylani sinadik. FCP — 344–356 ms, eng tez natija. Lekin 480-millisekunddagi kadrni ko'ring:

html
<style>
  .ustun { display: flex; gap: 1rem; flex-wrap: wrap;
    font-family: system-ui, sans-serif; }
  .ustun > div { flex: 1 1 10rem; max-width: 12rem;
    border: 1px solid #c9d6cf; padding: 0.5rem; }
  .ustun > div > p:first-child { margin: 0 0 0.5rem;
    font-size: 0.8rem; color: #5b6660; }
  .yalangoch h1 { font-family: serif; margin: 0.3em 0; }
  .yalangoch h2 { font-family: serif; font-size: 1.2em;
    margin: 0.3em 0; }
  .yalangoch { font-family: serif; }
  .tayyor { background: #fffaf0; color: #1f2a24; }
  .tayyor h1, .tayyor h2 { color: #2f6b3a; margin: 0.3em 0; }
  .tayyor h2 { font-size: 1.2em; }
  .tayyor .taom-karta { background: white; padding: 0.5rem;
    border-radius: 0.5rem;
    box-shadow: 0 1px 2px rgb(0 0 0 / 12%); }
  .tayyor .narx { color: #b4461a; font-weight: bold; margin: 0; }
</style>
<div class="ustun">
  <div>
    <p>onload hiylasi, 480 ms</p>
    <div class="yalangoch">
      <h1>Menyu</h1>
      <h2>Osh</h2>
      <p>35 000 so'm</p>
    </div>
  </div>
  <div>
    <p>kritik CSS, 480 ms</p>
    <div class="tayyor">
      <h1>Menyu</h1>
      <article class="taom-karta">
        <h2>Osh</h2>
        <p class="narx">35 000 so'm</p>
      </article>
    </div>
  </div>
</div>

Nimaga qarang: bu — ikki sahifaning bir paytdagi (480 ms) holati, Chrome skrinshotlaridan qayta chizilgan. Chapda — brauzerning standart ko'rinishi: serif shrift, qora matn, oq fon. 150 ms dan keyin CSS keladi va sahifa birdan o'zgaradi — FOUC. O'ngda esa birinchi kadrdanoq «Bahor» ko'rinishi. Xulosa: onload hiylasi faqat kritik CSS bilan birga ishlatiladi. Aks holda "tez" FCP — tez chiqqan xunuk sahifa. Kech kelgan CSS elementlar o'lchamini ham o'zgartiradi — bu CLS (Cumulative Layout Shift, sahifaning "sakrashi") ni oshiradi.

5.3 «Bahor» va CSP

«Bahor»da qat'iy CSP bor: default-src 'self' (CSS nima). Hiylani shu CSP bilan sinadik. Konsolda:

text
Executing inline event handler violates the following Content Security Policy directive 'default-src 'self''. Either the 'unsafe-inline' keyword, a hash ('sha256-...'), or a nonce ('nonce-...') is required to enable inline execution. Note that hashes do not apply to event handlers, style attributes and javascript: navigations unless the 'unsafe-hashes' keyword is present. Note also that 'script-src' was not explicitly set, so 'default-src' is used as a fallback. The action has been blocked.

Tarjimasi: "HTML ichidagi hodisa ishlovchisini bajarish CSP'ning default-src 'self' qoidasini buzadi. Ruxsat uchun 'unsafe-inline', hash (kodning "barmoq izi") yoki nonce (bir martalik ruxsat so'zi) kerak. Hash'lar hodisa ishlovchilari, style atributlari va javascript: havolalariga 'unsafe-hashes' bo'lmasa qo'llanmaydi. script-src alohida yozilmagan, shuning uchun default-src ishlatildi. Amal bloklandi."

Oqibati — eng yomon holat: onload ishlamadi, media doim print qoldi, sahifa hech qachon bezalmadi (fon shaffof, media: print — tekshirdik). Kritik CSS'ning <style> tegi ham shu CSP'da to'siladi — CSS nima darsidagi xabar.

Yechim bor, lekin murakkab: CSP'ga <style> ning hash'ini qo'shish (style-src 'self' 'sha256-...') va onload o'rniga alohida skript fayl. «Bahor» uchun bunga ehtiyoj yo'q: uning CSS'i 1–2 KB, bitta tez link bilan FCP ~650 ms. Critical CSS — katta sayt vositasi.

Tekshirib ko'ring: Nega Beasties to'liq CSS link ini body ning oxiriga ko'chirdi, head da qoldirmadi?

Javob

head dagi link bloklaydi — kritik CSS'ning butun foydasi yo'qoladi. body oxiridagi link dan oldingi kontent esa CSS'ni kutmasdan chiziladi (o'lchovda non-blocking, FCP ~350 ms). Kritik CSS birinchi ekranni bezaydi, qolgan qoidalar keyin keladi. head dagi preload esa faylni erta so'rab qo'yadi — link ga navbat kelganda u tayyor.

6. Ishlatilmagan CSS

6.1 Coverage: qancha CSS ishlayapti?

Yuqoridagi Bootstrap'li menyuda qancha CSS haqiqatan ishlatiladi? DevTools'da buni Coverage paneli ko'rsatadi: Ctrl + Shift + P → "Show Coverage" → yozib olish tugmasi → sahifani yangilash. Xuddi shu o'lchovni Chrome'ning dasturiy interfeysi bilan qildik:

text
bootstrap.min.css jami 232108 ishlatilgan 8563 3.7%

96% qoidalar bu sahifada bekor yuklandi. Bu — freymvorkning narxi: u har qanday sahifa uchun hamma komponentni olib keladi. Lighthouse ham shuni aytdi: "Reduce unused CSS — Est savings of 218 KiB" ("Ishlatilmagan CSS'ni kamaytiring — taxminiy tejash 218 KiB").

Ehtiyot bo'ling: Coverage faqat shu sahifa, shu holat ni ko'radi. Hover, ochilgan menyu, xato xabari, boshqa sahifa, katta ekran — ularning CSS'i "ishlatilmagan" bo'lib chiqadi, lekin kerak.

6.2 PurgeCSS

PurgeCSS — HTML (va JS) fayllardagi so'zlarni o'qib, CSS'dan ularda uchramagan selektorlarni olib tashlaydigan vosita. Tekshirdik (purgecss 8.0.0):

bash
npx purgecss --css bs/bootstrap.min.css \
  --content bs-menyu.html --output tozalangan/

Natija: 232 111 bayt → 11 012 bayt. Yigirma baravar kichik.

Tuzoq xuddi Tailwind CSS 4 darsidagi bg-${rang} kabi: PurgeCSS kodni ishga tushirmaydi, faqat matnni o'qiydi. JavaScript keyin qo'shadigan class (masalan, ochilgan modal uchun show) HTML'da yo'q — PurgeCSS uni o'chiradi va modal ochilmay qoladi. Bunday class'lar safelist sozlamasiga yoziladi.

Tailwind'da bu ish ichida: u faqat fayllarda uchragan utilitalarni yasaydi (Tailwind CSS 1). Tailwind loyihasiga PurgeCSS kerak emas.

7. Hajm: siqish va kompressiya

7.1 Ikki bosqich

Bootstrap fayllarida o'lchadik (Node'ning zlib moduli bilan, gzip — 9-daraja):

Fayl Xom gzip Brotli
bootstrap.css 280 311 32 943 24 474
bootstrap.min.css 232 111 30 669 22 970
PurgeCSS natijasi 11 012 3 211 2 788

(baytlarda)

  • Minifikatsiya (minify) — bo'sh joy, izoh va ortiqcha belgilarni olib tashlash (PostCSS va Lightning CSS darsidagi cssnano va Lightning CSS). Bu yerda 17% kichraydi.
  • Kompressiya — server faylni uzatishdan oldin arxivlaydi, brauzer ochadi. gzip — eski va hamma joyda, Brotli — yangiroq, matnni yaxshiroq siqadi: bu yerda gzip'dan yana 25% kichik.

Nimaga qarang: kompressiya minifikatsiyadan ancha kuchli (280 KB → 24 KB). Lekin eng katta yutuq — keraksiz CSS'ni olib tashlash: 2.8 KB. Tartib: avval ortiqchasini olib tashlang, keyin siqing, keyin serverda kompressiya.

Kompressiyani odatda siz emas, server yoki hosting qiladi. Tekshirish: DevTools → Network → CSS faylni tanlang → Headers bo'limida content-encoding: br yoki gzip. Sarlavhalar haqida — HTTP sarlavhalari darsida.

Tekshirib ko'ring: Saytingiz CSS'i minifikatsiyadan keyin 200 KB, server kompressiya qilmaydi, sahifa esa CSS'ning 5% ini ishlatadi. Uchta ishdan qaysi biri eng katta yutuq beradi: yana minifikatsiya, Brotli yoqish yoki ishlatilmaganini olib tashlash?

Javob

Ishlatilmaganini olib tashlash: 200 KB → taxminan 10 KB, yigirma baravar (jadvaldagi PurgeCSS qatori kabi). Brotli ham kuchli — jadvalda taxminan o'n baravar. Ikkalasini birga qilsangiz, bir necha kilobayt qoladi. Yana minifikatsiya deyarli hech narsa bermaydi — fayl allaqachon siqilgan. Tartib shuning uchun: avval ortiqchasini olib tashlang, keyin kompressiya.

7.2 Byudjet

Kichik CSS — tez sahifa. Jamoalar CSS byudjeti qo'yadi: "kritik yo'ldagi CSS siqilgan holda 14 KB dan oshmasin" kabi. Bu son bejiz emas: yangi ulanishning birinchi "bo'lagida" server taxminan shuncha ma'lumot yubora oladi (TCP'ning boshlang'ich oynasi, web.dev tavsiyasi). Undan kattasi uchun qo'shimcha aylanma yo'l kerak bo'ladi.

«Bahor»ning butun CSS'i 1.2 KB — byudjetdan ancha pastda. Portfolio'ning yig'ilgan CSS'i izohlari bilan 13 390 bayt edi, siqilgani 7 541 bayt (PostCSS va Lightning CSS) — siqish va kompressiyadan keyin yana bir necha barobar kichik bo'ladi.

8. Kod bo'lish va keyingi sahifa

Kod bo'lish (code splitting) — CSS'ni sahifalarga bo'lish: bron formasining uslublari faqat bron/ sahifasida. Bosh sahifa ularni yuklamaydi. Resurs maslahatlari darsida aynan shunday misol bor edi: bron sahifasining CSS'ini prefetch bilan oldindan olib qo'yish.

Kichik saytda bu ortiqcha — bitta keshlangan fayl hamma sahifaga yetadi. Katta ilovada esa Vite (Vite I, 16-qism) buni o'zi qiladi: har sahifa (route) o'z CSS bo'lagini oladi.

Yana bir tomon — yuklashdan keyingi chizish. Rendering pipeline darsidagi content-visibility: auto ekrandan tashqaridagi bo'limlarni chizishni kechiktiradi. Bu yuklash tezligi emas, lekin uzun sahifaning birinchi chizilishini yengillashtiradi.

9. Lighthouse bilan tekshirish

Lighthouse va PageSpeed darsidagi Lighthouse CSS muammolarini alohida ko'rsatadi. Lighthouse 13.5.0 ni sahifalarimizga qo'lladik (Performance, mobil, sekin tarmoq simulyatsiyasi bilan):

Sahifa Ball FCP "Render-blocking requests"
Bitta link 100 1.4 s 400 ms tejash
@import, 1 pog'ona 98 2.0 s 1 050 ms
@import, 2 pog'ona 95 2.3 s 1 330 ms
Critical CSS 100 0.9 s yo'q
Bootstrap menyu 93 2.6 s 1 650 ms

Nimaga qarang: Lighthouse sekin telefon tarmog'ini simulyatsiya qiladi, shuning uchun soniyalar bizning 300 ms li o'lchovdan katta. Tartib esa bir xil. Hisobotning ikki bo'limi CSS uchun muhim:

  • Render-blocking requests — qaysi fayl chizishni qancha kechiktirdi. @import sahifasida olti import fayli alohida qatorlarda.
  • Network dependency tree — so'rovlar zanjiri daraxt ko'rinishida: v2-import.html → asosiy.css → oltita fayl. Zanjir qancha chuqur bo'lsa, shuncha yomon.

Ball 93–100 — hammasi "yashil". Lekin FCP 2.6 s va 0.9 s o'rtasidagi farqni sekin internetdagi Aziz sezadi. Ballga emas, o'lchovlarga qarang.

10. Ko'p uchraydigan xatolar

10.1 Chop etish CSS'ini @import bilan ulash

@import url("chop.css") print; — fayl baribir bloklaydi (o'lchovda 2.2 s). Tuzatish: <link rel="stylesheet" href="chop.css" media="print">.

10.2 onload hiylasi kritik CSS'siz

FCP tez, lekin sahifa avval yalang'och ko'rinadi. CSP bo'lsa — umuman bezalmaydi. Tuzatish: hiyla faqat kritik CSS bilan; qat'iy CSP'li kichik saytda — oddiy bitta link.

10.3 Hammasini preload qilish

Rasm, shrift, CSS, JS — hammasi preload. Ular bir-birining navbatini egallaydi (Resurs maslahatlari). Tuzatish: preload — faqat brauzer kech topadigan 1–3 fayl uchun.

10.4 PurgeCSS dinamik class'ni o'chirdi

Modal ochilmay qoldi — show class'i CSS'dan ketgan. Tuzatish: safelist, yoki class'lar fayl matnida to'liq yozilsin.

10.5 Faqat ballga qarash

"Lighthouse 98 — hammasi joyida". Tuzatish: FCP, LCP va Network zanjirini o'qing; "Slow 4G" da o'zingiz oching.

11. Mashqlar

Mashqlar kurs/mashqlar/06/tezlik/ da. Oddiy HTML va CSS fayllar, Live Server bilan.

1-mashq (oson): bloklaydimi?

Har link yoki qoida sahifa chizilishini bloklaydimi? Navbati qanday?

  1. <link rel="stylesheet" href="asosiy.css">
  2. <link rel="stylesheet" href="chop.css" media="print">
  3. <link rel="stylesheet" href="keng.css" media="(width >= 64rem)"> — 360 pikselli telefonda
  4. asosiy.css ichida @import url("chop.css") print;
  5. <link rel="preload" href="asosiy.css" as="style"> (yolg'iz, stylesheet siz)

Ishora: "media atributi" bo'limidagi ikki jadval va Resurs maslahatlari darsidagi "preload faqat yuklaydi".

Yechim
  1. Bloklaydi, Highest.
  2. Bloklamaydi, Lowest — baribir yuklanadi.
  3. Bloklamaydi, Lowest — ekran kattalashsa qo'llanadi.
  4. Bloklaydi, Highest — @import dagi media sharti himoya qilmaydi (o'lchovda 2.2 s).
  5. Bloklamaydi va qo'llanmaydi ham: preload faylni faqat yuklab qo'yadi. Uni ishlatish uchun rel="stylesheet" kerak.

2-mashq (o'rta): zanjirni o'lchang

  1. index.html → asosiy.css → @import url("qism.css") → @import url("ichki.css") zanjirini yasang (har faylda bitta-ikkita qoida).
  2. DevTools → Network: "Disable cache" va "Slow 4G". Sahifani yangilang. Waterfall'da uchta CSS qachon boshlanganini yozing.
  3. head ga ikkita preload qo'shing (qism.css, ichki.css) va qayta o'lchang.
  4. Lighthouse → Performance: "Network dependency tree" bo'limida zanjir qanday ko'rinadi?

Ishora: "preload zanjirni uzadi" bo'limi.

Yechim

Preload'siz waterfall'da uch CSS chizig'i zinapoya bo'lib turadi: har biri oldingisi tugagach boshlanadi. Slow 4G'da har pog'ona yuzlab millisekund. preload bilan uchala chiziq bir vaqtda boshlanadi — zinapoya yo'qoladi. Bizning o'lchovda (har fayl 300 ms) FCP 1290 ms dan 660 ms ga tushgan edi. Sizning raqamlaringiz tarmoq va kompyuterga bog'liq — lekin shakl bir xil bo'ladi.

Lighthouse'da preload'siz variantda "Network dependency tree" uch pog'onali daraxtni ko'rsatadi va bo'lim qizil/sariq belgi oladi.

3-mashq (qiyin): Bootstrap'ni ozdiring

  1. npm install bootstrap (npm — 16-qismda to'liq, hozir aynan takrorlang). node_modules/bootstrap/dist/css/bootstrap.min.css ni css/ ga nusxalang.
  2. Menyu sahifasini Bootstrap class'lari bilan yozing: container, row, col-sm-6, card, btn btn-success.
  3. DevTools Coverage bilan ishlatilgan ulushni o'lchang.
  4. npx purgecss --css css/bootstrap.min.css --content index.html --output tozalangan/ — hajmni solishtiring.
  5. Tozalangan faylni ulang va sahifani 360 va 1280 pikselda tekshiring. Nima buzildi?

Ishora: "Ishlatilmagan CSS" bo'limidagi ikki ogohlantirish — boshqa holatlar va JavaScript class'lari.

Yechim

Bizning sahifada: ishlatilgan ulush 3.7%, PurgeCSS 232 111 → 11 012 bayt. Sizda raqamlar yaqin bo'ladi (sahifadagi class'larga bog'liq).

5-savol: odatda ko'rinish buzilmaydi — HTML'dagi hamma class saqlanadi, @media ichidagi col-sm-6 ham. Buziladigani — JavaScript'li komponentlar: Bootstrap'ning navbar menyusi yoki modal'ini qo'shsangiz, ular ochilganda qo'shiladigan show, collapsing class'lari o'chib ketgan bo'ladi. PurgeCSS sozlamasida safelist: ["show", "collapsing"] kabi ro'yxat kerak.

4-mashq: Portfolio qadami — portfolio CSS'ini o'lchang va zanjirni olib tashlang

Portfolio'ning asosiy.css i oltita faylni @import ... layer() bilan chaqiradi (Kaskadni boshqarish). Bu — bir pog'onali zanjir.

  1. Portfolio'ni internetdagi manzilida (GitHub Pages) oching. DevTools → Network: "Disable cache", "Slow 4G". Yettita CSS fayl qachon boshlanganini yozing. Lighthouse → Performance: FCP va "Render-blocking requests".
  2. Coverage bilan bosh sahifada har CSS faylning ishlatilgan ulushini ko'ring. Qaysi fayl eng kam ishlatiladi va nega bu normal?
  3. Zanjirni olib tashlang — ikki yo'ldan birini tanlang:
    • A (build'siz): har sahifa head iga oltita <link rel="preload" as="style">;
    • B (yig'ish): Lightning CSS bilan hammasini bitta faylga yig'ing va HTML'da shu faylni ulang.
  4. 1-qadamni qayta o'lchang. FCP qanchaga o'zgardi?

Ishora: B yo'li uchun npx lightningcss --bundle --minify --targets "defaults" ... (PostCSS va Lightning CSS darsidagi CLI; --bundle — importlarni bitta faylga qo'shish). @import yo'llari asosiy.css ga nisbatan. 404.html dagi / bilan boshlangan yo'lni unutmang.

Yechim

2: eng kam ishlatiladigani — yordamchi.css: unda chop etish qoidalari va .korinmas. Ekranda chop etish qoidalari ishlamaydi — bu normal, ular kerakli paytda ishlaydi.

3A — masalan, bosh sahifada:

html
<link rel="preload" href="assets/css/tokenlar.css" as="style">
<link rel="preload" href="assets/css/reset.css" as="style">
<link rel="preload" href="assets/css/asos.css" as="style">
<link rel="preload" href="assets/css/layout.css" as="style">
<link rel="preload" href="assets/css/komponentlar.css" as="style">
<link rel="preload" href="assets/css/yordamchi.css" as="style">
<link rel="stylesheet" href="assets/css/asosiy.css">

Ichki sahifalarda yo'l ../assets/css/.... Kamchiligi: 6 sahifa × 6 qator, yangi fayl qo'shilsa — hammasini yangilash.

3B — portfolio papkasida:

bash
npm install --save-dev lightningcss-cli
npx lightningcss --bundle --minify --targets "defaults" \
  sayt/assets/css/asosiy.css -o sayt/assets/css/asosiy.min.css

«Bahor» tuzilmasidagi shunday yetti faylda (1 506 bayt) sinadik: natija — bitta 1 157 baytli fayl, har import o'z @layer bloki ichida (@layer tokenlar{...}@layer reset{...}) — qatlamlar tartibi saqlandi. Sahifalarda asosiy.min.css ulanadi. Kamchiligi: har CSS o'zgarishidan keyin buyruqni qayta ishga tushirish kerak, asosiy.min.css ni esa qo'lda tahrirlamang (PostCSS va Lightning CSS darsidagi dist/ qoidasi). Bu qadamni 07-qismda GitHub Actions avtomatik qiladi.

Hozircha A yo'li portfolio uchun yetarli: build yo'q, zanjir yo'q. 4-qadamda bitta pog'ona kutish (Slow 4G'da odatda bir necha yuz millisekund) FCP'dan yo'qoladi. Raqamlaringizni yozib qo'ying — Yakuniy loyiha: landing darsida landing'ni shu o'lchovlar bilan tekshirasiz.

12. Real ishda

  • Katta saytlar (yangiliklar, onlayn do'konlar) critical CSS'ni build paytida avtomatik yasaydi — Next.js, Astro, Vite plaginlari bilan. Birinchi ekran HTML bilan birga keladi.
  • Freymvorklar narxi. Bootstrap'ning 227 KB CSS'idan menyu sahifasi 4% ini ishlatdi. Tailwind'ning "faqat ishlatilganini yasash" g'oyasi aynan shu muammoga javob.
  • Core Web Vitals — Google qidiruvida sahifa tajribasi signallaridan biri. CSS yetkazish LCP va CLS ga bevosita ta'sir qiladi.
  • Intervyuda so'raladi: "Render-blocking CSS nima?", "Critical CSS qanday ishlaydi?", "@import nega sekin?", "media="print" li link yuklanadimi?", "Ishlatilmagan CSS'ni qanday topasiz?". Endi har biriga raqam bilan javob bera olasiz.

Xulosa

  • head dagi CSS render'ni bloklaydi: bitta tez link — normal narx (bizda +300 ms).
  • @import ning har pog'onasi bitta to'liq kutish qo'shadi; preload yoki bitta faylga yig'ish zanjirni uzadi.
  • link dagi media mos kelmasa — bloklamaydi va Lowest navbatda; @import dagi media sharti esa himoya qilmaydi.
  • Critical CSS birinchi ekranni HTML bilan birga chizadi; onload hiylasi faqat u bilan birga, qat'iy CSP'da esa ishlamaydi.
  • Ishlatilmagan CSS — Coverage va Lighthouse; olib tashlash (PurgeCSS, Tailwind) siqish va Brotli'dan ham kuchliroq.
  • Ballga emas, FCP/LCP va Network zanjiriga qarang; sekin tarmoqda o'zingiz oching.

Keyingi dars: Vizual ierarxiya va asosiy dizayn tamoyillari — CSS vositalaridan dizaynning o'ziga o'tamiz: ko'z avval nimani ko'rishini qanday boshqarish.

Manbalar

  • web.dev: "Render blocking CSS", "Extract critical CSS", "Defer non-critical CSS", "Largest Contentful Paint (LCP)" — web.dev
  • Chrome DevTools: "Coverage", "Network features reference" — developer.chrome.com/docs/devtools
  • MDN: "@import", ": media", "rel=preload", "Resource Timing: renderBlockingStatus" — developer.mozilla.org
  • Beasties — github.com/danielroe/beasties; PurgeCSS — purgecss.com; Lighthouse — developer.chrome.com/docs/lighthouse
Ulashish:Telegram'da

Izohlar (0)

Izoh yozish uchun kiring.

  • Hozircha izoh yo'q. Birinchi bo'ling!
CSS yuklash samaradorligi: render-blocking, critical CSS va media — IlmHamroh