Jinsi ya Kufanya Tovuti Yako Iwe Haraka: Orodha ya Vitendo

Ili kufanya tovuti iwe haraka, ipime kwanza kwa PageSpeed Insights, kisha rekebisha sababu kubwa zaidi inayoonyesha, mara nyingi picha kubwa mno, JavaScript nyingi mno, fonti nzito au scripts za watu wa tatu. Lenga malengo ya "nzuri" ya Core Web Vitals za Google: maudhui makuu yaonekane ndani ya sekunde 2.5, majibu ya kugusa yawe ndani ya milisekunde 200, na karibu hakuna mpangilio unaoruka. Tovuti nyingi hufika hapo kwa mabadiliko machache, si kuandika upya.

Pima kabla ya kubadilisha chochote

Kubahatisha kunapoteza muda. Zana mbili za bure zinamfaa karibu kila mtu:

• PageSpeed Insights (pagespeed.web.dev): bandika URL hai. Inaonyesha field data kutoka kwa watumiaji halisi wa Chrome (ikiwa tovuti yako ina trafiki ya kutosha) na lab data kutoka upakiaji wa kuigiza, pamoja na orodha ya matatizo mahususi.
• Lighthouse kwenye Chrome DevTools: jaribio lilelile la lab, kwenye ukurasa wowote unaoweza kuufungua, ikiwemo preview. Jaribu kwa hali ya simu; matatizo yanaonekana zaidi kwenye simu za mitandao ya polepole.

Namba zinazojali ni Core Web Vitals za Google. Kufikia Septemba 2026, nyaraka za Google kwenye web.dev zinatoa vizingiti hivi vya "nzuri", vilivyopimwa kwenye asilimia 75 ya upakiaji wa kurasa:

INP ilichukua nafasi ya kipimo cha zamani cha First Input Delay mwaka 2024. Zana inayoendelea kuripoti FID imepitwa na wakati.

Andika namba zako za mwanzo. Baada ya kila marekebisho, jaribu tena ili ujue kilichosaidia.

Muda unapoenda: chaguzi na biashara zake

Kila sababu ya kawaida ina marekebisho, na kila marekebisho yana gharama yake. Anza na zilizo juu; ndizo za bei nafuu na za kawaida zaidi.

Picha

Picha ndilo tatizo la kawaida zaidi na rahisi zaidi kulirekebisha. Picha ya pikseli 4,000 inayoonyeshwa kwa pikseli 800 inamlazimisha kila mgeni kupakua mara tano zaidi ya anachokiona.

• Tuma picha kwa ukubwa unaoonyeshwa, pamoja na ukubwa wa srcset unaojibu kwa simu na kompyuta.
• Tumia miundo ya kisasa (WebP au AVIF) na ubanaji unaofaa.
• Weka width na height kwenye kila picha ili browser ihifadhi nafasi. Hili peke yake hurekebisha mabadiliko mengi ya mpangilio.
• Lazy-load picha zilizo chini ya mstari wa kwanza kwa loading="lazy".
• Usiwahi lazy-load picha kuu iliyo juu ya ukurasa. Mwongozo wa LCP wa Google ni wa wazi kuhusu hili: kuweka lazy picha ya LCP kunaichelewesha kila wakati. Badala yake, ipe fetchpriority="high".

JavaScript

Tovuti nyingi zilizojengwa na AI ni single-page apps (SPAs): browser inapakua bundle ya JavaScript kisha ndipo inachora ukurasa. Bundle kubwa zaidi, ndivyo skrini tupu inavyodumu. Marekebisho, kwa mpangilio wa juhudi:

1. Ondoa usichokitumia. Omba orodha ya dependencies na ukate maktaba zilizoongezwa mara moja kisha zikasahauliwa: maktaba ya tarehe kwa tarehe moja, pakiti kamili ya aikoni kwa aikoni tano.
2. Gawanya kwa route. Pakia code ya dashibodi ya admin tu mtu anapoifungua, si kwenye ukurasa wa nyumbani.
3. Prerender kurasa za umma. Ukurasa wa masoko unaotumwa kama HTML halisi unaonekana kabla JavaScript yoyote haijaendeshwa. Hili pia linasaidia injini za utafutaji; angalia SEO kwa tovuti zilizojengwa na AI.

INP ya polepole kwa kawaida inamaanisha kazi moja ndefu inayozuia ukurasa: kuchuja orodha kubwa kila herufi, au kuchora upya jedwali zima wakati seli moja inabadilika. Paneli ya Performance ya Chrome DevTools inaonyesha ipi.

Fonti

Kila familia na uzito wa fonti ni faili nyingine. Familia mbili na uzito tatu au nne kwa kawaida zinatosha. Preload fonti inayotumika juu ya mstari wa kwanza, tumia font-display: swap ili maandishi yaonekane mara moja, na jihudumie fonti mwenyewe (self-host) ikiwa huduma ya nje ya fonti ni polepole kwa wageni wako.

Scripts za watu wa tatu

Chat widgets, analytics, heatmaps, pixels za matangazo, video zilizopachikwa na mipasho ya mitandao ya kijamii vyote hupakia code kutoka seva nyingine. Kila moja linaonekana dogo; pamoja mara nyingi ndiyo sehemu polepole zaidi ya ukurasa. Weka zile unazozitazama kweli. Pakia zilizobaki baada ya ukurasa kuwa tayari kuingiliana, na badilisha embeds nzito (kicheza cha YouTube, ramani) kwa onyesho jepesi linalopakia kitu halisi likibofywa.

Majibu ya server

Time to first byte (TTFB), yaani muda ambao server inachukua kuanza kujibu, iko chini ya kila kipimo kingine. Kurasa tuli zinazotolewa kutoka CDN (mtandao wa servers karibu na wageni wako; angalia CDN ni nini) ni za haraka karibu kila mahali. Kurasa zinazojengwa na server kwa kila ombi zinategemea server hiyo na database yake. Caching ya kazi inayorudiwa na indexes za database kwa maswali ya polepole ni marekebisho ya kawaida.

Maombi yanayofanya kazi

Kuwa mahususi: taja ukurasa, kipimo na kikwazo. Bandika matokeo ya PageSpeed Insights ukiwa nayo.

PageSpeed Insights inaonyesha LCP ya sekunde 4.8 kwenye simu kwa ukurasa wa nyumbani, na kipengele cha LCP ni picha kuu. Punguza ukubwa na ubadilishe picha kuu kuwa WebP, tuma ukubwa unaojibu, weka width na height, mpe fetchpriority="high" na uhakikishe haijaorodheshwa kuwa lazy. Lazy-load kila picha iliyo chini ya mstari wa kwanza. Usibadilishe muundo.

Kagua dependencies za app hii. Orodhesha kila package, kinachoitumia na takriban kiasi inachoongeza kwenye bundle. Ondoa zisizotumika na ugawanye routes za /admin na /settings kuwa vipande tofauti vinavyopakia tu zinapotembelewa.

Sanduku la utafutaji kwenye /products linahisi lina kigugumizi. Weka debounce kwenye kichujio, usichore upya orodha nzima kila herufi, na gawanya orodha kwa kurasa au virtualise ikiwa ina vipengee zaidi ya 200.

Hatua kwa hatua

1. Jaribu ukurasa hai kwenye PageSpeed Insights kwa hali ya simu. Andika LCP, INP na CLS, pamoja na matatizo matatu ya juu yaliyoorodheshwa.
2. Rekebisha picha kwanza: ukubwa, miundo, vipimo, lazy loading chini ya mstari wa kwanza, kipaumbele kwa picha kuu.
3. Punguza scripts za watu wa tatu usizozitumia, na uahirishe zilizobaki.
4. Punguza fonti hadi kile muundo unachohitaji.
5. Punguza JavaScript: ondoa packages zisizotumika, gawanya kwa route.
6. Prerender kurasa za umma ikiwa bado zinachorwa upande wa mteja na LCP bado ni polepole.
7. Angalia server: caching, indexes za database, static hosting kwa maudhui yanayobadilika mara chache.
8. Chapisha tena na ujaribu tena. Field data kwenye PageSpeed Insights husasishwa kwa wiki zinazofuata ziara halisi zinapoingia, kwa hiyo hukumu matokeo ya mapema kwa data ya lab.

Makosa ya kawaida

• Kujaribu kwenye laptop ya haraka pekee. Wageni wako wako kwenye simu za kiwango cha kati na data ya mtandao isiyo thabiti. Jaribu kwa hali ya simu.
• Kufukuzia alama kamili ya 100. Alama ya lab ni mwongozo. Mara Core Web Vitals zikiwa katika kiwango kizuri, maudhui na urahisi wa kutumia vina umuhimu zaidi kuliko alama chache za mwisho.
• Ku-lazy-load kila kitu, ikiwemo picha kuu. Hilo linaifanya LCP kuwa mbaya zaidi.
• Kuongeza plugin au maktaba ya kasi juu ya kila kitu. Kuondoa uzito karibu kila mara ni bora kuliko kuongeza code ya kuudhibiti.
• Kuboresha preview badala ya tovuti hai. Previews za maendeleo huendesha builds zisizoboreshwa. Pima URL iliyochapishwa.
• Kurekebisha kasi mara moja tu. Kila widget, picha na kipengele kipya kinaongeza uzito. Jaribu tena baada ya mabadiliko makubwa.

Orodha ya kasi

• LCP ≤ sekunde 2.5, INP ≤ milisekunde 200, CLS ≤ 0.1 kwenye simu
• Picha zimepunguzwa ukubwa, zimebanwa, zina muundo wa kisasa, na zina width na height
• Picha kuu haijaorodheshwa kuwa lazy; picha zilizo chini ya mstari wa kwanza ni lazy
• Hakuna maktaba za JavaScript zisizotumika; routes nzito zimetenganishwa
• Familia mbili za fonti au chache; fonti kuu imepreload
• Scripts za watu wa tatu unazozitumia tu, zinapakia baadaye
• Kurasa za umma zimeprerender au ni tuli inapowezekana
• Imejaribiwa tena kwenye URL hai baada ya kuchapisha

Kasi na mpangilio wa simu vinaenda pamoja; angalia jinsi ya kufanya tovuti ijibu ukubwa wa simu. Kwa ukaguzi kamili kabla ya uzinduzi, jinsi ya kupeleka prototype ya AI hadi production inashughulikia yaliyobaki.

Kasi kwenye Mythex

Kwenye Mythex unafanya mabadiliko haya kwa kuomba kwenye chat, au kwenye kihariri cha code kwenye Pro. Kagua URL iliyochapishwa, si Preview, kwa sababu Preview huendesha server ya maendeleo. Front-end tuli huwekwa kama tovuti tuli unapochapisha (static websites), ambayo inafaa kwa kurasa za maudhui. Apps zenye server hupunguzwa hadi sifuri: hulala zikiwa hazitumiki na kuamka ombi linalofuata; kwa hiyo ombi la kwanza baada ya kipindi cha utulivu ni la polepole zaidi, na database iliyoambatishwa hulala baada ya dakika 5 bila matumizi (hosting limits). Ikiwa ukurasa wa umma ni polepole kwenye ziara ya kwanza pekee, hiyo ndiyo sababu inayowezekana. Kuweka kurasa za masoko tuli kunasaidia. Baada ya mabadiliko, chapisha tena kisha fanya hard-refresh.

Maswali