IlmHamroh
JavaScript Full-stack/4-qism. HTML84/86-dars18 daqiqa
Mundarija (38)

Lighthouse va PageSpeed Insights: HTML sahifani audit qilish

Qisqacha: Lighthouse — Chrome'ga o'rnatilgan bepul vosita. U sahifani tezlik (Performance), qulaylik (Accessibility), zamonaviy amaliyotlar (Best Practices) va qidiruv (SEO) bo'yicha 0–100 ball bilan baholaydi va har kamchilikni aniq element bilan ko'rsatadi. PageSpeed Insights esa shu tahlilga haqiqiy foydalanuvchilarning 28 kunlik ma'lumotini qo'shadi. Ballarning katta qismi to'g'ri HTML'ga bog'liq: alt, lang, rasm o'lchamlari, meta description.

Bu darsda

  • DevTools'da Lighthouse auditini to'g'ri sharoitda ishga tushirasiz.
  • Hisobotdagi ballar, ranglar, metrikalar va tavsiyalarni o'qiy olasiz.
  • LCP, CLS va DOM hajmi muammolarining HTML'dagi sabablarini topib tuzatasiz.
  • PageSpeed Insights'dagi lab data va field data farqini tushuntirasiz.
  • Lighthouse'ni terminaldan ishga tushirasiz va avtomat audit nimani ko'rmasligini bilasiz.

Oldin bilishingiz kerak: Chrome DevTools II: Network, Application va Lighthouse, Rasm unumdorligi, Accessibility'ni tekshirish, HTML kod uslubi va konventsiyalar.

1. Nega bu kerak?

«Bahor» sayti deyarli tayyor. Jasur aka so'raydi: "Saytimiz yaxshimi?" Sardor "ha, zo'r" deydi. Malika "telefonda sekin ochildi" deydi. Kim haq?

"Yaxshi" — fikr. Fikr bilan bahslashish mumkin. Raqam bilan esa bahslashib bo'lmaydi. Kasalxonadagi tahlilni eslang: shifokor "o'zingizni qanday his qilyapsiz?" deb so'raydi, lekin qaror tahlil natijasiga qarab qabul qilinadi. Qon bosimi — 120/80, norma — shuncha. Raqam aniq, norma ham aniq.

Lighthouse — saytning shunday tahlil varag'i. U o'nlab tekshiruvni bir daqiqada o'tkazadi, har biriga baho qo'yadi va "nima qilish kerak" deb aniq aytadi. DevTools II darsida uni bir marta ishga tushirgansiz. Endi hisobotni o'qish va undagi HTML muammolarini tuzatishni o'rganamiz.

2. Lighthouse nima va qayerda ishlaydi

Lighthouse — Google'ning ochiq kodli audit vositasi. 2026-yilda uning 13-versiyasi ishlatiladi. U bitta, lekin uch joyda yashaydi:

Qayerda Qanday ochiladi Qachon qulay
Chrome DevTools F12 → Lighthouse paneli Ish paytida, localhost'da ham
PageSpeed Insights pagespeed.web.dev Internetdagi sayt uchun
Terminal (CLI) npx lighthouse Avtomatlashtirish uchun

Uchalasining ichida bir xil dvigatel. Farq — qayerda va qanday sharoitda ishga tushishida.

3. Birinchi audit: to'g'ri sharoit

3.1 Tayyorgarlik

Lighthouse sahifani sizning brauzeringizda o'lchaydi. Brauzerdagi hamma narsa natijaga ta'sir qiladi. Shuning uchun:

  1. Inkognito oynada oching (Ctrl + Shift + N). Brauzer kengaytmalari — tarjimon, reklama bloklovchi — o'z kodini sahifaga qo'shadi va ballni tushiradi. Inkognitoda ular odatda o'chiq.
  2. Boshqa og'ir dasturlarni yoping. Kompyuter band bo'lsa, sahifa ham sekin chiqadi.
  3. Sahifani Live Server orqali oching: http://127.0.0.1:5500. file:// manzilda ba'zi tekshiruvlar ishlamaydi.

3.2 Ishga tushirish

F12 → yuqoridagi paneldan Lighthouse ni tanlang (ko'rinmasa, » belgisi ichida). Sozlamalar:

  • Mode (rejim) — Navigation (Default). Sahifani noldan yuklab o'lchaydi. Qolgan ikkitasi (Timespan va Snapshot) — maxsus holatlar uchun.
  • Device (qurilma) — Mobile. Mehmonlarning ko'pchiligi telefonda.
  • Categories (toifalar) — to'rttasini ham belgilang.

Analyze page load tugmasini bosing. Sahifa bir necha marta qayta yuklanadi, 20–60 soniyadan keyin hisobot chiqadi.

Maslahat: Mobile rejimida Lighthouse o'rtacha telefonni taqlid qiladi. U protsessorni 4 barobar sekinlashtiradi va sekin mobil internetni hisobga oladi. Shuning uchun kuchli kompyuterda ham "sekin" natija chiqishi mumkin — bu xato emas, mehmonning haqiqiy tajribasiga yaqin baho.

4. Hisobotni o'qish

4.1 Ballar va ranglar

Hisobot tepasida to'rtta doira turadi:

Toifa Nimani baholaydi
Performance Sahifa qanchalik tez ko'rinadi va barqaror turadi
Accessibility Ekran o'quvchi, klaviatura va boshqalar uchun qulaylik
Best Practices Xavfsizlik va zamonaviy amaliyotlar
SEO Qidiruv tizimi sahifani to'g'ri tushunishi

Rang har doim bir xil ma'noda:

  • 0–49 — qizil: jiddiy muammo.
  • 50–89 — to'q sariq: yaxshilash kerak.
  • 90–100 — yashil: yaxshi.

Ba'zi hisobotlarda beshinchi, eksperimental toifa ham chiqadi — Agentic Browsing. U sun'iy intellekt yordamchilari saytdan foydalana olishini tekshiradi. Hozircha unga e'tibor bermang.

4.2 Bitta audit ichida nima bor

Har toifa ostida ro'yxat bor. Qizil uchburchak — muvaffaqiyatsiz tekshiruv, yashil — o'tgani. Qatorni bossangiz, u ochiladi:

  • Nima muammo — bir-ikki gapda.
  • Learn more ("batafsil") — rasmiy tushuntirishga havola.
  • Aynan qaysi element — HTML parchasi bilan. Uning ustiga bossangiz, Elements panelida shu element ochiladi.

Pastroqda yana uch guruh bor:

  • Passed audits — o'tgan tekshiruvlar.
  • Not applicable — sahifaga tegishli emas (masalan, sahifada video yo'q).
  • Additional items to manually check — "qo'lda tekshiring". Vosita bu narsalarni o'zi tekshira olmaydi.

4.3 Performance ichidagi metrikalar

Performance bali beshta o'lchovdan (metrikadan) yig'iladi. Har birining vazni har xil:

Metrika Nimani o'lchaydi Vazni
FCP Birinchi matn yoki rasm qachon chiqdi 10%
Speed Index Sahifa qanchalik tez to'ldi 10%
LCP Eng katta element qachon chiqdi 25%
TBT JavaScript sahifani qancha "qotirdi" 30%
CLS Kontent qanchalik "sakradi" 25%

Ulardan ikkitasi to'g'ridan-to'g'ri HTML'ga bog'liq — LCP va CLS. TBT asosan JavaScript'dan keladi, uni JavaScript qismida ko'ramiz.

Metrikalar ostida Insights bo'limi turadi. Lighthouse 13 da tavsiyalar shu nomda: "LCP request discovery", "Layout shift culprits", "Improve image delivery". Har birida qancha vaqt yoki hajm tejash mumkinligi yozilgan.

Tekshirib ko'ring: Performance'da LCP va CLS birgalikda necha foiz vaznga ega? Bu HTML dasturchi uchun nimani anglatadi?

Javob

25% + 25% = 50%. Ya'ni Performance balining yarmi aynan HTML to'g'ri yozilganiga bog'liq: rasmlar o'lchami, asosiy rasm qanday yuklanishi. JavaScript yozmasdan ham ballni sezilarli ko'tarish mumkin.

5. Amaliyot: shoshilib yozilgan sahifa

5.1 Sahifa

Sardor «Bahor» bosh sahifasining yangi versiyasini bir kechada yozdi. Brauzerda hammasi joyida ko'rinadi.

Sardorning sahifasi (asosiy qismi):

html
<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <meta name="viewport"
        content="width=device-width, initial-scale=1">
  <title>Bahor</title>
</head>
<body>
  <header>
    <a href="/"><img src="logo.svg"></a>
    <nav><a href="menyu/">Menyu</a></nav>
  </header>
  <main>
    <h1>Choyxona «Bahor»</h1>
    <p>Toshkentdagi eng mazali osh.</p>
    <img src="osh.png" alt="Bir tarelka osh" loading="lazy">
    <h3>Bugungi menyu</h3>
    <p>Osh — 35 000 so'm. Batafsil <a href="menyu/">bu yerda</a>.</p>
    <button><img src="tel.svg" alt=""></button>
    <input type="text" name="ism" placeholder="Ismingiz">
  </main>
</body>
</html>

osh.png — telefondan to'g'ridan-to'g'ri olingan 2,8 MB li rasm.

5.2 Natija

Lighthouse (Mobile) shunday baholadi:

Toifa Ball
Performance 60
Accessibility 56
Best Practices 92
SEO 82

Muvaffaqiyatsiz tekshiruvlardan parcha (hisobotda aynan shunday inglizcha yoziladi):

text
Accessibility
  Buttons do not have an accessible name
  Heading elements are not in a sequentially-descending order
  `<html>` element does not have a `[lang]` attribute
  Image elements do not have `[alt]` attributes
  Links do not have a discernible name
Best Practices
  Browser errors were logged to the console
SEO
  Document does not have a meta description
Performance
  Largest Contentful Paint  15.0 s
  Cumulative Layout Shift   0.309
  Image elements do not have explicit `width` and `height`
  Improve image delivery — Est savings of 2,606 KiB

Endi har birini o'qib, sababini topamiz.

5.3 Accessibility xatolari

Audit Tarjimasi Sababi
Buttons do not have an accessible name Tugmaning nomi yo'q Tugmada faqat alt="" li rasm
Heading elements are not in a sequentially-descending order Sarlavhalar tartibi buzilgan h1 dan keyin darhol h3
<html> ... [lang] html da lang yo'q Ekran o'quvchi tilni bilmaydi
Image elements do not have [alt] Rasmda alt yo'q Logotip
Links do not have a discernible name Havolaning nomi yo'q Logotip havolasida matn ham, alt ham yo'q

Oxirgi ikki qator bitta xatodan chiqdi: logotip rasmida alt bo'lmagani uchun uni o'rab turgan havola ham nomsiz qoldi. Yaxshi alt matn darsidagi qoida: havoladagi rasmning alt i — havolaning manzilini aytadi. Masalan, "Choyxona «Bahor» bosh sahifasi".

Tugma uchun ham xuddi shunday: ichidagi rasmga ma'noli alt yoziladi yoki tugmaga matn qo'shiladi (ARIA asoslari darsida aria-label ni ham ko'rgansiz).

5.4 Best Practices va SEO

Browser errors were logged to the console — "konsolda brauzer xatolari bor". Hisobotda xatoning o'zi ham ko'rsatiladi:

text
Failed to load resource: the server responded with a status of 404 (Not Found)

"Resursni yuklab bo'lmadi: server 404 qaytardi". Sahifada bunday fayl yo'q-ku? Bor! Brauzer har bir sayt uchun o'zi favicon.ico ni so'raydi. Topmasa — 404. Yechim: Favicon darsidagidek ikonka qo'shish.

Document does not have a meta description — "hujjatda meta description yo'q". Google natijalarida sahifa ostidagi tavsif matni shundan olinadi (Qidiruv tizimlari uchun meta teglar).

5.5 Performance: LCP va CLS

LCP 15,0 soniya. Norma — 2,5 soniyagacha. Uch sabab bor, uchalasi ham HTML'da:

  1. Rasm juda og'ir: 2,8 MB. Sekin mobil internetda u uzoq yuklanadi. "Improve image delivery" tavsiyasi 2 606 KiB tejash mumkinligini aytyapti. Yechim — rasmni kichraytirish va zamonaviy formatga o'tkazish (Rasm formatlari, picture va source).
  2. Asosiy rasmda loading="lazy". Rasm unumdorligi darsidagi qoida: ekranning birinchi qismidagi rasm hech qachon lazy bo'lmaydi.
  3. Brauzerga "bu rasm muhim" deb aytilmagan. Buning uchun fetchpriority="high" bor.

Lighthouse 13 ning LCP request discovery tavsiyasi shu shartlarni ro'yxat qilib tekshiradi. Ro'yxatda uch qator bor:

  • "fetchpriority=high should be applied" — fetchpriority="high" qo'yilsin.
  • "Request is discoverable in initial document" — rasm HTML'ning o'zida darhol ko'rinsin.
  • "LCP resources should not use loading=lazy" — asosiy rasm lazy bo'lmasin.

CLS 0,309. Norma — 0,1 gacha. Sabab: rasmlarda width va height yo'q. Brauzer rasm yuklanguncha uning o'lchamini bilmaydi va joy ajratmaydi. Rasm kelganda matn pastga "sakraydi". Tuzatish img asoslari darsidan ma'lum: width va height yozish.

Diqqat: LCP elementi siz o'ylagan element bo'lmasligi mumkin. Telefon ekranida birinchi ko'rinadigan eng katta narsa ba'zan rasm emas, sarlavha yoki logotip bo'ladi. Hisobotdagi LCP tavsiyasini ochib, aynan qaysi element ekanini ko'ring — Lighthouse uni HTML parchasi bilan ko'rsatadi.

5.6 Tuzatilgan sahifa

Tuzatishlardan keyin:

html
<!DOCTYPE html>
<html lang="uz">
<head>
  <meta charset="utf-8">
  <meta name="viewport"
        content="width=device-width, initial-scale=1">
  <title>Choyxona «Bahor» — Chilonzor, Toshkent</title>
  <meta name="description"
        content="Osh, kabob va choy. Har kuni 7:00–23:00 ochiqmiz.">
  <link rel="icon" href="/favicon.svg" type="image/svg+xml">
</head>
<body>
  <header>
    <a href="/">
      <img src="logo.svg" alt="Choyxona «Bahor» bosh sahifasi"
           width="160" height="100">
    </a>
    <nav aria-label="Asosiy menyu">
      <a href="menyu/">Menyu</a>
    </nav>
  </header>
  <main>
    <h1>Choyxona «Bahor»</h1>
    <p>Toshkentdagi eng mazali osh.</p>
    <img src="osh.png" alt="Bir tarelka osh"
         width="600" height="400" fetchpriority="high">
    <h2>Bugungi menyu</h2>
    <p>Osh — 35 000 so'm. <a href="menyu/">To'liq menyu</a>.</p>
    <a href="tel:+998900000000">Qo'ng'iroq</a>
    <form action="/bron" method="post">
      <label for="ism">Ismingiz</label>
      <input id="ism" name="ism" type="text" autocomplete="name">
      <button type="submit">Band qilish</button>
    </form>
  </main>
</body>
</html>

osh.png o'rniga 600×400 o'lchamdagi, ancha yengil rasm qo'yildi. Natija:

Toifa Oldin Keyin
Performance 60 100
Accessibility 56 95
Best Practices 92 96
SEO 82 100

LCP 15,0 s dan 0,9 s ga, CLS 0,309 dan 0 ga tushdi. Bironta ham CSS yoki JavaScript qatori yozmadik — faqat HTML va rasm.

5.7 Qolgan ikki ogohlantirish

100 bo'lmagan ikki joy qoldi — ular ham foydali saboq:

  • Touch targets do not have sufficient size or spacing — "bosiladigan joylar juda kichik yoki bir-biriga juda yaqin". Telefonda barmoq bilan bosish uchun havolalar orasida joy kerak. Bu — CSS ishi, uni CSS qismida tuzatamiz.
  • Serves images with low resolution — "rasm sifati past". Telefon ekranida piksellar zich, 600 piksellik rasm xira ko'rinadi. Yechim — srcset bilan kattaroq nusxa berish (srcset va sizes).

Tekshirib ko'ring: Nega logotip rasmiga alt qo'shish bir vaqtning o'zida ikkita auditni tuzatdi?

Javob

Logotip havola ichida turibdi va havolada boshqa matn yo'q. Havolaning nomi uning ichidagi kontentdan olinadi — bu yerda rasmning alt idan. alt yo'q bo'lsa, rasm ham, havola ham nomsiz qoladi. alt qo'shilishi bilan ikkalasi ham nom oldi: "Image elements do not have [alt]" va "Links do not have a discernible name" birga yo'qoldi.

6. Lighthouse nimani ko'rmaydi

Accessibility'da 95 — bu "sahifa 95% qulay" degani emas. Accessibility'ni tekshirish darsida aytgan edik: avtomat vositalar muammolarning taxminan uchdan biridan yarmigacha qismini topadi. Sardorning sahifasida buni o'z ko'zimiz bilan ko'rdik:

  • placeholder label o'rnida. Sardorning input ida label yo'q edi, faqat placeholder. Lighthouse buni xato demadi — u placeholder ni ham nom deb qabul qiladi. Lekin label darsida ko'rdik: placeholder yozish boshlanishi bilan yo'qoladi va label o'rnini bosmaydi.
  • "bu yerda" havolasi. Lighthouse'da "Links have descriptive text" (havola matni ma'noli) degan audit bor. U "click here", "more" kabi inglizcha va boshqa ba'zi tillardagi iboralarni ushlaydi. O'zbekcha "bu yerda" ni esa tanimaydi va audit o'tib ketadi.
  • Ma'no. alt="rasm" — Lighthouse uchun to'g'ri, mehmon uchun foydasiz.

Shuning uchun Lighthouse — birinchi qadam, oxirgisi emas. Undan keyin klaviatura bilan yurib chiqish va kontent accessibility'si ro'yxati bo'yicha qo'lda tekshirish kerak.

7. DOM hajmi

DOM hajmi — sahifadagi elementlar soni. Har bir teg — DOM daraxtida bitta tugun. Elementlar juda ko'p bo'lsa, brauzer ularni joylash va chizishga ko'p vaqt sarflaydi, telefon xotirasi ko'proq band bo'ladi.

Lighthouse 13 da buning uchun Optimize DOM size tavsiyasi bor. Eski versiyalarda aniq chegara bor edi: taxminan 800 elementdan ogohlantirish, 1 400 dan ortig'ida xato. Bugun ham shu raqamlarni mo'ljal sifatida olsa bo'ladi.

Sahifangizda nechta element borligini bilish uchun DevTools'dagi Console'ga (DevTools I darsida ko'rgansiz) bitta qator yozing:

js
document.querySelectorAll("*").length

Bu JavaScript buyrug'i — "sahifadagi hamma elementlarni sanab ber". Hozircha uni nusxalab ishlatish yetarli, JavaScript'ni keyingi qismlarda o'rganamiz.

DOM hajmining HTML'dagi asosiy sababi — keraksiz o'ramlar ("div soup", Semantik HTML darsida ko'rgansiz):

html
<div class="karta">
  <div class="karta-ichi">
    <div class="sarlavha-quti">
      <div class="sarlavha">Osh</div>
    </div>
  </div>
</div>

To'rtta div o'rniga bitta semantik element yetadi:

html
<article class="karta">
  <h3>Osh</h3>
</article>

100 ta taom kartasi bo'lsa, farq — 400 ga qarshi 200 element. Kichik sayt uchun bu muhim emas, katta katalogda esa sezilarli.

8. PageSpeed Insights: lab va field data

8.1 Ikki xil ma'lumot

pagespeed.web.dev saytiga sahifa manzilini yozasiz va Analyze bosasiz. Natijada ikki bo'lim chiqadi:

  1. Discover what your real users are experiencing — "haqiqiy foydalanuvchilaringiz nimani boshdan kechiryapti". Bu — field data (dala ma'lumoti).
  2. Diagnose performance issues — "tezlik muammolarini aniqlash". Bu — lab data (laboratoriya ma'lumoti), ya'ni o'sha Lighthouse hisoboti.
Lab data Field data
Qayerdan Lighthouse bir marta yuklaydi Chrome foydalanuvchilaridan
Davr Hozir, bir marta Oxirgi 28 kun
Kimda Taqlid qilingan telefon Haqiqiy odamlar, haqiqiy telefonlar
Nimaga kerak Muammoni topish va tuzatish Natijani tasdiqlash

O'xshatish: lab data — mashinani sinov maydonchasida sinash. Field data — o'sha mashina bir oy davomida Toshkent tirbandligida qanday yurganining statistikasi.

8.2 Core Web Vitals

Field data'da uchta asosiy metrika ko'rsatiladi — Core Web Vitals (sahifa sifatining asosiy ko'rsatkichlari). Google ularni qidiruv natijalarini tartiblashda ham hisobga oladi.

Metrika Yaxshi Yomon
LCP — asosiy kontent chiqishi ≤ 2,5 s > 4 s
INP — bosishga javob tezligi ≤ 200 ms > 500 ms
CLS — sakrash ≤ 0,1 > 0,25

INP (Interaction to Next Paint) — mehmon tugmani bosgandan keyin ekran qancha vaqtda javob berishi. Uni faqat haqiqiy foydalanuvchilar o'lchaydi, chunki Lighthouse hech narsani bosmaydi. INP asosan JavaScript'ga bog'liq.

Baho 75-persentil bo'yicha qo'yiladi. Oddiy tilda: 4 mehmondan kamida 3 tasida metrika "yaxshi" bo'lishi kerak. Uchalasi ham shunday bo'lsa — Core Web Vitals Assessment: Passed ("o'tdi"), aks holda Failed ("o'tmadi").

8.3 "No data" — qo'rqmang

Yangi sayt uchun field data bo'limida ma'lumot yo'qligi haqida yozuv chiqadi. Bu xato emas. Google field data'ni faqat yetarlicha tashrif buyuruvchisi bor ommaviy sahifalar uchun yig'adi. «Bahor» saytiga oyiga bir necha ming odam kira boshlaganda, ma'lumot paydo bo'ladi. Unga qadar lab data bilan ishlaysiz.

PageSpeed Insights faqat internetdagi saytni tekshiradi — localhost'ni emas. Keyingi darsda saytni internetga chiqaramiz va uni birinchi marta shu yerda tekshiramiz.

Tekshirib ko'ring: Lighthouse Performance 98 berdi, PageSpeed Insights'dagi field data esa LCP'ni "Poor" (yomon) deb ko'rsatyapti. Qaysi biriga ishonasiz?

Javob

Field data'ga. U haqiqiy mehmonlarning 28 kunlik tajribasi. Lighthouse esa bitta taqlid qilingan yuklash, u sizning sharoitingizda o'lchangan. Farq katta bo'lsa, haqiqiy mehmonlar sekinroq telefon yoki internetdan foydalanyapti deb o'ylash mumkin. Lab data'dan esa aynan nimani tuzatish kerakligini topish uchun foydalanasiz.

9. Lighthouse terminalda

Lighthouse'ni terminaldan ham ishga tushirish mumkin. Buning uchun kompyuterda Google Chrome o'rnatilgan bo'lishi kerak. Live Server ishlab turganda:

bash
npx lighthouse http://127.0.0.1:5500/ --view

--view — tayyor hisobotni brauzerda ochish. Hisobot DevTools'dagi bilan bir xil ko'rinadi. Foydali qo'shimchalar:

bash
npx lighthouse http://127.0.0.1:5500/ --preset=desktop --view
npx lighthouse http://127.0.0.1:5500/ \
  --only-categories=accessibility,seo --view
  • --preset=desktop — kompyuter uchun o'lchash (standart holatda — mobil).
  • --only-categories — faqat kerakli toifalar, audit tezroq tugaydi.

Terminal versiyasining asosiy afzalligi — avtomatlashtirish. Katta loyihalarda Lighthouse har bir o'zgarishdan keyin o'zi ishga tushadi va ball tushib ketsa ogohlantiradi. Buni yuklanishni optimallashtirish darsida ko'rasiz.

10. Ballar nega har safar boshqacha

Auditni ikki marta ketma-ket ishga tushirsangiz, Performance bali 3–5 ball farq qilishi mumkin. Bu normal. Kompyuter band bo'lishi, tarmoq tezligi, fonda ishlayotgan dastur — hammasi ta'sir qiladi.

Qoidalar:

  • Muhim qaror oldidan auditni 3 marta ishga tushiring va o'rtadagi natijani oling.
  • Ballni emas, metrikani kuzating: "LCP 4 s dan 2 s ga tushdi" — aniq natija.
  • 100 ga intilmang. Performance 90+ va Accessibility 100 — kichik sayt uchun a'lo maqsad. Oxirgi 2–3 ball uchun ko'pincha foydasiz qurbonlar kerak bo'ladi.

11. Ko'p uchraydigan xatolar

11.1 Kengaytmalar bilan audit

Oddiy oynada 70, inkognitoda 95. Farq — kengaytmalar. Har doim inkognitoda o'lchang.

11.2 Faqat Desktop rejimida o'lchash

Kompyuterda 100 ball — telefonda 55 bo'lishi mumkin. Mehmonlaringiz qaysi qurilmadan kirishini eslang va birinchi navbatda Mobile'da o'lchang.

11.3 "Accessibility 100 — demak qulay"

6-bo'limda ko'rdik: placeholder va o'zbekcha "bu yerda" havolasi Lighthouse'dan o'tib ketdi. 100 ball — "avtomat topadigan xatolar yo'q" degani, xolos.

11.4 Localhost natijasini haqiqat deb bilish

Localhost'da server sizning kompyuteringizda, tarmoq kechikishi deyarli yo'q. Internetdagi sayt boshqacha ishlashi mumkin. Deploy'dan keyin saytni PageSpeed Insights'da qayta tekshiring.

12. Mashqlar

1-mashq (oson): Hisobotni tarjima qiling

Lighthouse shu tekshiruvlarni muvaffaqiyatsiz deb ko'rsatdi. Har biri uchun HTML'da nimani tuzatish kerakligini yozing:

  1. Document doesn't have a <title> element
  2. Form elements do not have associated labels
  3. Image elements do not have explicit width and height
Yechim
  1. "Hujjatda title elementi yo'q" — head ichiga ma'noli <title> qo'shiladi (Hujjat skeleti).
  2. "Forma maydonlarida bog'langan label yo'q" — har bir maydonga label for="..." va maydonga mos id (label darsi).
  3. "Rasmlarda aniq width va height yo'q" — har bir img ga haqiqiy o'lchamlar yoziladi. Bu CLS'ni kamaytiradi.

2-mashq (o'rta): O'z sahifangizni o'lchang

«Bahor» saytining bosh sahifasini inkognito oynada, Mobile rejimida audit qiling. Natijani jadvalga yozing: to'rt ball, LCP va CLS. Keyin eng ko'p ball "yeydigan" bitta Accessibility va bitta Performance muammosini tuzating va qayta o'lchang.

Yechim

Natijalar har kimda har xil bo'ladi. Namuna jadval:

O'lchov Oldin Keyin
Performance 78 94
Accessibility 87 100
LCP 3,8 s 1,6 s
CLS 0,21 0

Ko'p uchraydigan tuzatishlar:

  • Accessibility: logotip havolasiga alt, html ga lang="uz", sarlavhalar tartibi.
  • Performance: asosiy rasmdan loading="lazy" ni olib, fetchpriority="high" qo'shish; hamma img larga width va height.

Muhimi — auditni 3 marta ishga tushirib, o'rtacha natijani olish. Shunda o'zgarish haqiqatan sizning tuzatishingizdan ekaniga ishonch hosil qilasiz.

3-mashq (qiyin): Audit hisoboti yozing

Jasur aka sizdan saytning holati haqida qisqa hisobot so'radi. Tanishingizning saytini yoki istalgan ommaviy saytni (masalan, kun.uz) PageSpeed Insights'da tekshiring va Jasur akaga tushunarli tilda yozing:

  1. Core Web Vitals o'tdimi (field data bo'lsa)?
  2. Lab data'dagi to'rt ball.
  3. HTML bilan tuzatsa bo'ladigan 3 ta eng muhim muammo — har biri bitta gapda va qaysi element ekani bilan.
  4. Lighthouse tekshirmagan, lekin qo'lda tekshirish kerak bo'lgan 2 ta narsa.
Yechim

Namuna hisobot:

Sayt: example.com, 2026-yil 27-sentabr, mobil.

  1. Core Web Vitals: o'tmadi. LCP 3,4 s (norma 2,5 s gacha), INP va CLS — yaxshi.
  2. Lab: Performance 64, Accessibility 81, Best Practices 96, SEO 92.
  3. Muammolar:
    • Bosh sahifadagi katta banner rasmi lazy yuklanyapti — LCP'ni sekinlashtiradi. loading="lazy" ni olib tashlash kerak.
    • Yangiliklar ro'yxatidagi rasmlarda width va height yo'q — sahifa yuklanayotganda matn sakraydi.
    • Qidiruv maydonida label yo'q — ekran o'quvchi uni "tahrirlash maydoni" deb nomsiz o'qiydi.
  4. Qo'lda tekshirish: faqat klaviatura bilan hamma menyuga yetib borish mumkinmi; havola matnlari ("batafsil", "shu yerda") ma'noli ekanmi.

Yaxshi hisobotda ball emas, muammo → sababi → tuzatish zanjiri bo'ladi. Buyurtmachi raqamni emas, "nima qilish kerak"ni bilmoqchi.

13. Real ishda

  • Frilans buyurtmalar. "Saytimizni tezlashtirib bering" — keng tarqalgan buyurtma. Ish Lighthouse va PageSpeed Insights hisobotidan boshlanadi va "oldin/keyin" jadvali bilan tugaydi. Bu jadval — ishingizning isboti.
  • SEO. Core Web Vitals — Google qidiruv tartibiga ta'sir qiluvchi omillardan biri. SEO mutaxassislari har oy PageSpeed Insights va Google Search Console'dagi hisobotlarni kuzatadi.
  • Intervyuda so'raladi: "Core Web Vitals nima?", "LCP'ni qanday yaxshilaysiz?", "Lab va field data farqi?". Endi har biriga HTML misoli bilan javob bera olasiz.

Xulosa

  • Lighthouse — to'rt toifada 0–100 ball: Performance, Accessibility, Best Practices, SEO; qizil 0–49, to'q sariq 50–89, yashil 90–100.
  • Audit — inkognitoda, Mobile rejimida, 3 marta; ballni emas, metrikani kuzating.
  • Performance balining yarmi — LCP va CLS; ularning sababi ko'pincha HTML'da: lazy asosiy rasm, og'ir rasm, width/height yo'qligi.
  • Accessibility'dagi ko'p xato bitta sababdan: alt, lang, tugma va havola nomi, sarlavhalar tartibi.
  • PageSpeed Insights: lab data — Lighthouse; field data — haqiqiy mehmonlarning 28 kunlik ma'lumoti va Core Web Vitals (LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1).
  • Avtomat audit hamma narsani ko'rmaydi: placeholder, o'zbekcha havola matni va ma'noni qo'lda tekshiring.

Keyingi dars: Birinchi deploy: saytni GitHub Pages yoki Netlify'ga yuklash (git'siz) — «Bahor» saytini internetga chiqaramiz va havolasini do'stlarga yuboramiz.

Manbalar

  • Chrome for Developers: "Lighthouse overview", "Lighthouse performance scoring", "Lighthouse in DevTools" — developer.chrome.com/docs/lighthouse
  • Chrome for Developers: "Moving Lighthouse to insights" (Lighthouse 13) — developer.chrome.com
  • web.dev: "Web Vitals" — web.dev/articles/vitals
  • PageSpeed Insights haqida — developers.google.com/speed/docs/insights/v5/about
Ulashish:Telegram'da

Izohlar (0)

Izoh yozish uchun kiring.

  • Hozircha izoh yo'q. Birinchi bo'ling!
Lighthouse va PageSpeed Insights: HTML sahifani audit qilish — IlmHamroh