Sekin sayt pulga tushadi: saytlarni qanday tezlashtiramiz

Bir kuni mijoz qayta ishlashga olib kelgan saytda brauzerning Network tabini ochdim va bosh sahifa 14 megabayt ekanini ko‘rdim. Shundan 11 tasi slayderdagi fotosuratlar. Beshta rasm, har biri kameradan chiqqan asl o‘lchamda, 2–3 MB dan.

Ofisdagi optik tolada bu sezilmaydi. Toshkentdagi 4G’da — bir-ikki soniya. Xorazm yoki Surxondaryodagi biror tumanda mobil internetda esa odam tabni yopgunicha oq ekranga qarab o‘tiradi.

Sayt tezligi texnik go‘zallik emas. Bu siz reklamaga to‘laydigan va birinchi ekranda yo‘qotadigan pul.

Nega soniyalar pulga aylanadi

Tasavvur qiling, reklama ishga tushiryapsiz. Har bir klik uchun to‘laysiz. Odam bosdi, sayt esa yuklanyapti. Har bir ortiqcha soniya sizga allaqachon pul turgan odamlarning bir qismini kesib tashlaydi. Google o‘z tadqiqotlarida ancha vaqtdan beri aytadi: yuklanish vaqti bir soniyadan uch soniyagacha oshganda chiqib ketish ehtimoli sezilarli o‘sadi, undan keyin esa yanada kuchliroq.

Ikkinchi ta’sir ham bor. Google reytingda Core Web Vitals’ni hisobga oladi. Bu uchta metrika:

• LCP — birinchi ekrandagi eng katta element qachon ko‘rindi (maqsad: 2,5 s gacha);
• INP — sahifa bosishlarga qanchalik tez javob beradi (maqsad: 200 ms gacha);
• CLS — yuklanishda maket qanchalik «sakraydi» (maqsad: 0,1 gacha).

Sekin sayt qidiruvda pastroq turadi va yomonroq konversiya qiladi. Ikki tomonlama zarba.

Rasmlar: deyarli har doim asosiy muammo

Auditlarimizga ko‘ra, sekin saytlarning ko‘pchiligida asosiy og‘irlik — rasmlar. JavaScript ham, shriftlar ham emas, «qanday bo‘lsa shunday» yuklangan fotolar.

Har bir loyihada rasmlar bilan nima qilamiz:

1. WebP formati. Xuddi shu sifatda u JPEG’dan taxminan 25–35% yengilroq, PNG skrinshotlarni esa bir necha barobar siqadi.
2. To‘g‘ri o‘lcham. Agar saytda foto 800 piksel kenglikda ko‘rsatilsa, 4000 piksellisini yuklash shart emas. Telefonlar uchun yanada kichigini beramiz.
3. Lazy loading. Birinchi ekrandan pastdagi rasmlar faqat odam ularga qadar aylantirib borganda yuklanadi.
4. Maketdagi o‘lchamlar. Har bir rasmning kengligi va balandligi ko‘rsatilgan, toki u yuklanganda sahifa sakramasin. Bu to‘g‘ridan-to‘g‘ri CLS’ga ta’sir qiladi.

Nuxt’da buning katta qismini @nuxt/image moduli bajaradi. Masalan, Japanese Garden saytida u shunday sozlangan:

// nuxt.config.ts
image: {
  format: ["webp"],
  screens: { sm: 640, md: 768, lg: 1080, xl: 1280 },
},

Keyin shablonda <img> o‘rniga loading="lazy" va sizes bilan <NuxtImg> yozamiz, server esa kerakli variantlarni o‘zi kesib beradi.

O‘z saytimiz

«Etikdo‘z etiksiz» degan gap biz haqimizda ham. idrok.group saytida admin panel orqali yuklangan rasmlar uzoq vaqt qanday yuklangan bo‘lsa, shunday saqlanib kelgan. Bir payt mijozlarga maslahat beradigan narsamizni o‘zimiz qildik: rasm yuklanayotganda avtomatik ravishda haqiqiy ko‘rsatish o‘lchamigacha kichraytiriladi va WebP’ga qayta kodlanadi, eski fayllar uchun esa ularni xuddi shu konveyerdan o‘tkazadigan buyruq yozdik.

Hech qanday redizayn, frontendda hech qanday yangi kod yo‘q. Faqat rasmlar.

Shriftlar va uchinchi tomon skriptlari

Ikkinchi tez-tez uchraydigan aybdor — shriftlar. CSS ichida @import orqali ulangan Google Fonts’dagi chiroyli shrift zanjirni anglatadi: CSS’ni yuklash, uni tahlil qilish, @import’ni topish, yana bitta CSS’ni yuklash va shundan keyingina shriftning o‘zi. Sekin ulanishda bu oq matnning ortiqcha yuzlab millisekundlari.

Nima yordam beradi:

• <head>’da shrift serverlariga preconnect;
• @import o‘rniga to‘g‘ridan-to‘g‘ri <link>;
• matn darhol tizim shrifti bilan ko‘rinishi uchun font-display: swap;
• ikkitadan ko‘p bo‘lmagan oila va faqat kerakli qalinliklar. Poppins’ning 40 KB dan to‘rtta qalinligi — bu allaqachon 160 KB.

MY5’da aynan shu yo‘ldan bordik: shriftlar preconnect va to‘g‘ridan-to‘g‘ri havola orqali ulangan, birinchi ekranning muhim CSS’i esa sahifa barcha uslublarni kutmasdan chizilishi uchun to‘g‘ridan-to‘g‘ri HTML’ga joylanadi.

Alohida hikoya — uchinchi tomon skriptlari. Chat vidjeti, uchta analitika hisoblagichi, ijtimoiy tarmoq pikseli, xarita. Har biri o‘z JavaScript’ini tortadi va har biri «atigi ozgina» og‘irlikka ega. Birgalikda ular bir soniya qo‘shishi mumkin. Biz mijozdan har biri haqida so‘raymiz: undan kim foydalanadi va olib tashlasak nima bo‘ladi. «Bilmayman, uni oldingi marketolog qo‘ygan» degan javob istaganimizdan ko‘ra ko‘proq uchraydi.

SSR, SPA va viloyatlardagi telefon nimani ko‘radi

React yoki Vue’dagi saytni ikki usulda yig‘ish mumkin. SPA sifatida: brauzer deyarli bo‘sh sahifa oladi va JavaScript’ni bajarib, uni o‘zi quradi. Yoki server tomonida render (SSR) bilan: server darhol tayyor HTML beradi, JavaScript esa keyin uni «jonlantiradi».

Qidiruvda topilishi va arzon Android telefonli odamlarda ochilishi kerak bo‘lgan saytlar uchun deyarli har doim SSR’ni tanlaymiz. Masalan, MY5 va Japanese Garden server tomonida render bilan Nuxt 3’da qilingan.

9:41garden.redmedia.uz

Japanese Garden’da yanada uzoqroq bordik: sayt PWA qilib yasalgan. Birinchi tashrifdan keyin service worker sahifalarni keshlaydi va keyingi tashrif, hatto bog‘da aloqa yomon bo‘lsa ham, deyarli bir zumda ochiladi.

CDN va server

Auditoriya O‘zbekistonda, server esa Germaniyada bo‘lsa, har bir so‘rov minglab kilometr yo‘l bosadi. CDN statik fayllarni (rasmlar, skriptlar, uslublar) foydalanuvchiga eng yaqin tugundan tarqatadi. Bir necha mamlakatda auditoriyasi bor saytlar uchun bu sezilarli. Faqat Toshkentda ishlaydigan biznes uchun esa ba’zan O‘zbekistonda server ijaraga olib, CDN’siz ishlash oqilonaroq.

Backend tomonida ham brauzerda ko‘rinmaydigan sekinlashuvlar bo‘ladi: bazaga sekin so‘rovlar, sahifaga kerak bo‘lganidan o‘n barobar ko‘p ma’lumot beradigan API, kesh yo‘qligi. Bu endi backend dasturchilarning ishi va bizda Mirodil birinchi navbatda bitta sahifa bazaga nechta so‘rov yuborishini ko‘radi.

Sayt allaqachon sekin bo‘lsa, nimadan boshlash kerak

Saytni darhol qayta yozish shart emas. O‘ntadan to‘qqiz holatda samaraning katta qismini oddiy narsalar beradi:

1. PageSpeed Insights’ni oching va bosh sahifaning mobil versiyasini tekshiring.
2. Eng og‘ir rasmlarni toping va ularni kerakli o‘lchamdagi WebP’ga o‘tkazing.
3. Hech kim foydalanmaydigan uchinchi tomon skriptlarini olib tashlang.
4. Shriftlar qanday ulanganini tekshiring.

Shundan keyin ham sekin bo‘lsa, muammo, ehtimol, arxitekturada: server renderisiz SPA, o‘nlab plaginli og‘ir WordPress mavzusi, yuklamasi haddan oshgan server. Bu yerda dasturchilar bilan suhbat kerak va biz unga tayyormiz. Tezlik qidiruv bilan qanday bog‘liqligi haqida yangiliklar saytlari uchun SEO maqolamizni ham o‘qishni maslahat beraman: media’da bu muammolar eng keskin namoyon bo‘ladi.

Shaxsiy qoidam: har qanday loyihani topshirishdan oldin uni ofisdagi eng arzon Android’da, Wi-Fi o‘chirilgan holda ochaman. Agar o‘zimga kutish yoqimsiz bo‘lsa, uni mijozga ko‘rsatmayman.