Si ta bësh website-in tënd më të shpejtë: një listë kontrolli praktike

Për ta bërë një website më të shpejtë, mate së pari me PageSpeed Insights, pastaj rregullo shkakun më të madh që tregon — zakonisht imazhe shumë të mëdha, shumë JavaScript, fonte të rënda ose skripte të palëve të treta. Synoni objektivat "të mira" të Core Web Vitals të Google: përmbajtja kryesore e dukshme brenda 2.5 sekondash, përgjigjet ndaj prekjeve brenda 200 milisekondash, dhe pothuajse asnjë lëvizje e layout-it gjatë ngarkimit. Shumica e faqeve arrijnë aty me një grusht ndryshimesh, jo me një rishkrim.

Mate para se të ndryshosh ndonjë gjë

Hamendësimi humbet kohë. Dy mjete falas mbulojnë pothuajse të gjithë:

• PageSpeed Insights (pagespeed.web.dev) — ngjit një URL live. Shfaq të dhëna në terren nga përdorues realë të Chrome (nëse faqja jote ka trafik të mjaftueshëm) dhe të dhëna laboratorike nga një ngarkim i simuluar, plus një listë problemesh specifike.
• Lighthouse në Chrome DevTools — i njëjti test laboratorik, i ekzekutuar në çdo faqe që mund ta hapësh, përfshirë një preview. Testo në modalitetin mobile; telefonat në rrjete më të ngadalta janë vendi ku dalin problemet.

Numrat që kanë rëndësi janë Core Web Vitals të Google. Që nga shtatori 2026, dokumentacioni i Google në web.dev jep këto pragje "të mira", të matura në përqindjen e 75-të të ngarkimeve të faqes:

INP zëvendësoi metrikën më të vjetër First Input Delay në 2024. Nëse një mjet ende raporton FID, është i vjetëruar.

Shkruaj numrat e tu fillestarë. Pas çdo rregullimi, testo përsëri që të dish çfarë ndihmoi.

Ku shkon koha: opsionet dhe kompromiset

Çdo shkak i zakonshëm ka një rregullim, dhe çdo rregullim ka një kosto. Nis me ato në krye — janë më të lirat dhe më të zakonshmet.

Imazhet

Imazhet janë problemi më i zakonshëm dhe më i lehti për t'u rregulluar. Një foto 4.000 pikselësh e shfaqur me 800 pikselë gjerësi e detyron çdo vizitor të shkarkojë pesë herë më shumë se ajo që sheh.

• Shërbe imazhet në madhësinë që shfaqen, me madhësi responsive srcset për telefonat dhe desktop-et.
• Përdor formate moderne (WebP ose AVIF) dhe komprimim të arsyeshëm.
• Vendos width dhe height te çdo imazh që shfletuesi të rezervojë hapësirën. Vetëm kjo rregullon shumicën e zhvendosjes së layout-it.
• Ngarko me lazy imazhet poshtë pjesës së dukshme me loading="lazy".
• Mos e ngarko kurrë me lazy imazhin kryesor në krye të faqes. Udhëzimi i Google për LCP është i drejtpërdrejtë: ngarkimi me lazy i imazhit LCP e vonon gjithmonë. Jepi fetchpriority="high" në vend të kësaj.

JavaScript

Shumë website të ndërtuara me AI janë aplikacione me një faqe (SPA): shfletuesi shkarkon një paketë JavaScript dhe pastaj e vizaton faqen. Sa më e madhe paketa, aq më i gjatë ekrani bosh. Rregullimet, sipas përpjekjes:

1. Hiq atë që nuk përdor. Kërko një listë të varësive dhe hiq bibliotekat që u shtuan një herë dhe u harruan — një bibliotekë datash për një datë, një paketë e plotë ikonash për pesë ikona.
2. Ndaje sipas rrugës. Ngarko kodin e dashboard-it të administratorit vetëm kur dikush e hap, jo në faqen kryesore.
3. Prerendero faqet publike. Një faqe marketingu që dërgohet si HTML i vërtetë shfaqet para se të ekzekutohet ndonjë JavaScript. Kjo ndihmon edhe motorët e kërkimit; shiko SEO për website-et e ndërtuara me AI.

INP i ngadaltë zakonisht do të thotë një detyrë e gjatë që bllokon faqen — filtrimi i një liste të madhe në çdo shkronjë, ose rirenderimi i një tabele të tërë kur ndryshon një qelizë. Paneli Performance i Chrome DevTools tregon cilën.

Fontet

Çdo familje fontesh dhe peshë është një skedar tjetër. Dy familje dhe tre ose katër pesha zakonisht mjaftojnë. Bëj preload fontin që përdoret mbi pjesën e dukshme, përdor font-display: swap që teksti të shfaqet menjëherë, dhe host-o vetë fontet nëse shërbimi i jashtëm i fonteve është i ngadaltë për vizitorët e tu.

Skriptet e palëve të treta

Widget-et e chat-it, analitika, heatmap-et, pikselat e reklamave, videot e integruara dhe feed-et sociale ngarkojnë kod nga serverë të tjerë. Secili duket i vogël; së bashku shpesh janë pjesa më e ngadaltë e faqes. Mbaj vetëm ato që vërtet shikon. Ngarko pjesën tjetër pasi faqja të jetë ndërvepruese, dhe zëvendëso embed-et e rënda (një player YouTube, një hartë) me një preview të lehtë që ngarkon materialin e vërtetë me klikim.

Përgjigja e serverit

Koha deri te bajti i parë (TTFB) — sa kohë i duhet serverit për të filluar të përgjigjet — qëndron nën çdo metrikë tjetër. Faqet statike të shërbyera nga një CDN (një rrjet serverësh afër vizitorëve tuaj; shiko çfarë është një CDN) janë të shpejta pothuajse kudo. Faqet e ndërtuara nga një server në çdo kërkesë varen nga ai server dhe baza e tij e të dhënave. Caching i punës së përsëritur dhe indekset e bazës së të dhënave për pyetjet e ngadalta janë rregullimet e zakonshme.

Prompt-e që funksionojnë

Jepu specifikë: emëro faqen, metrikën dhe kufizimin. Ngjit gjetjet e PageSpeed Insights nëse i ke.

PageSpeed Insights raporton LCP prej 4.8 s në mobile për faqen kryesore, dhe elementi LCP është imazhi kryesor. Ndrysho madhësinë dhe konverto imazhin kryesor në WebP, shërbe madhësi responsive, vendos width dhe height, jepi fetchpriority="high" dhe sigurohu që të mos ngarkohet me lazy. Ngarko me lazy çdo imazh poshtë pjesës së dukshme. Mos e ndrysho dizajnin.

Auditon varësitë e këtij aplikacioni. Listo çdo paketë, çfarë e përdor dhe sa shton përafërsisht në paketën e JavaScript. Hiq ato të pa përdorura dhe ndaj rrugët /admin dhe /settings në pjesë të veçanta që ngarkohen vetëm kur vizitohen.

Kutia e kërkimit në /products duket e ngadaltë. Vononi filtrimin, shmangni rirenderimin e të gjithë listës në çdo shkronjë, dhe ndaje listën në faqe ose virtualizoje nëse ka më shumë se 200 artikuj.

Hap pas hapi

1. Testo faqen live në PageSpeed Insights në mobile. Shëno LCP, INP dhe CLS, dhe tre problemet kryesore të listuara.
2. Rregullo fillimisht imazhet: madhësitë, formatet, dimensionet, ngarkimin me lazy poshtë pjesës së dukshme, prioritetin për imazhin kryesor.
3. Hiq skriptet e palëve të treta që nuk përdor, dhe vono pjesën tjetër.
4. Zvogëlo fontet në atë që kërkon dizajni.
5. Thjeshto JavaScript-in: hiq paketat e pa përdorura, ndaj sipas rrugës.
6. Prerendero faqet publike nëse janë ende të renderuara në klient dhe LCP është ende i ngadaltë.
7. Kontrollo serverin: caching, indekset e bazës së të dhënave, hosting statik për përmbajtjen që ndryshon rrallë.
8. Publiko përsëri dhe ri-testo. Të dhënat në terren në PageSpeed Insights përditësohen gjatë javëve pasuese ndërsa vijnë vizita reale, ndaj gjykoji rezultatet e hershme sipas të dhënave laboratorike.

Gabimet e zakonshme

• Testimi vetëm në një laptop të shpejtë. Vizitorët e tu janë në telefona mesatarë dhe internet mobil të paqëndrueshëm. Testo në modalitetin mobile.
• Ndjekja e një 100 të përsosur. Rezultati laboratorik është një udhërrëfyes. Pasi Core Web Vitals janë në intervalin e mirë, përmbajtja dhe përdorshmëria kanë më shumë rëndësi sesa disa pikët e fundit.
• Ngarkimi me lazy i gjithçkaje, duke përfshirë imazhin kryesor. Kjo e përkeqëson LCP.
• Shtimi i një plugin-i ose biblioteke shpejtësie mbi të tjera. Heqja e peshës pothuajse gjithmonë është më e mirë sesa shtimi i kodit për ta menaxhuar.
• Optimizimi i preview-it, jo i faqes live. Preview-et e zhvillimit ekzekutojnë build-e të pa optimizuara. Mat URL-në e publikuar.
• Rregullimi i shpejtësisë vetëm një herë. Çdo widget, imazh dhe veçori e re shton peshë. Ri-testo pas ndryshimeve të mëdha.

Listë kontrolli e shpejtësisë

• LCP ≤ 2.5 s, INP ≤ 200 ms, CLS ≤ 0.1 në mobile
• Imazhet të ndryshuara në madhësi, të komprimuara, format modern, me width dhe height
• Imazhi kryesor jo i ngarkuar me lazy; imazhet poshtë pjesës së dukshme të ngarkuara me lazy
• Nuk ka biblioteka JavaScript të pa përdorura; rrugët e rënda të ndara
• Dy familje fontesh ose më pak, fonti kryesor i ngarkuar paraprakisht
• Vetëm skriptet e palëve të treta që përdor vërtet, të ngarkuara vonë
• Faqet publike të prerenduara ose statike aty ku është e mundur
• Ri-testuar në URL-në live pas publikimit

Shpejtësia dhe layout-i në telefon shkojnë bashkë; shiko si ta bësh një website të përgjegjshëm për telefonin. Për një kalim të plotë para lansimit, si ta çosh një prototip AI në prodhim mbulon pjesën tjetër.

Shpejtësia në Mythex

Në Mythex i bën këto ndryshime duke kërkuar në chat, ose në redaktorin e kodit në Pro. Kontrollo URL-në e publikuar, jo Preview-n, sepse Preview ekzekuton një server zhvillimi. Frontend-et statike vendosen si site statike kur publikon (website-et statike), që përshtatet për faqet e përmbajtjes. Aplikacionet me server zvogëlohen në zero: flenë kur janë në pritje dhe zgjohen me vizitën e radhës, kështu që kërkesa e parë pas një periudhe të qetë është më e ngadaltë, dhe një bazë të dhënash e bashkangjitur fle pas 5 minutash joaktivitet (kufijtë e hosting-ut). Nëse një faqe publike është e ngadaltë vetëm në vizitën e parë, kjo është shkaku i mundshëm. Mbajtja e faqeve të marketingut statike ndihmon. Pas ndryshimeve, publiko përsëri dhe bëj rifreskim të plotë.

Pyetje