Paano Pabilisin ang Iyong Website: Praktikal na Checklist

Para pabilisin ang website, sukatin muna ito gamit ang PageSpeed Insights, saka ayusin ang pinakamalaking sanhing itinuturo nito, na kadalasan ay sobrang laking larawan, sobrang JavaScript, mabibigat na font, o third-party script. Layunin ang "good" na target ng Core Web Vitals ng Google: nakikita ang pangunahing nilalaman sa loob ng 2.5 segundo, tumutugon sa tap sa loob ng 200 milisegundo, at halos walang paglundag ng layout. Karamihan ng site ay nakakarating doon sa iilang pagbabago, hindi sa muling pagsusulat.

Sukatin bago magbago ng kahit ano

Nasasayang ang oras sa paghula. Dalawang libreng tool ang sumasakop sa halos lahat:

• PageSpeed Insights (pagespeed.web.dev): idikit ang live na URL. Ipinapakita nito ang field data mula sa totoong gumagamit ng Chrome (kung sapat ang trapiko ng site mo) at lab data mula sa simulated na load, kasama ang listahan ng mga partikular na problema.
• Lighthouse sa Chrome DevTools: ang parehong lab test, na puwedeng patakbuhin sa anumang page na mabubuksan mo, kasama ang preview. Subukan sa mobile mode; sa mas mabagal na network sa phone lumalabas ang mga problema.

Ang mga numerong mahalaga ay ang Core Web Vitals ng Google. Pagsapit ng Setyembre 2026, nagbibigay ang dokumentasyon ng Google sa web.dev ng mga "good" na threshold na ito, na sinusukat sa ika-75 percentile ng mga page load:

Pinalitan ng INP ang mas lumang First Input Delay na sukatan noong 2024. Kung may tool pa ring nag-uulat ng FID, luma na ito.

Isulat ang iyong panimulang numero. Pagkatapos ng bawat ayos, subukan ulit para malaman mo kung ano ang nakatulong.

Saan napupunta ang oras: mga opsyon at trade-off

May ayos ang bawat karaniwang sanhi, at may kapalit ang bawat ayos. Magsimula sa mga nasa itaas; sila ang pinakamurang ayusin at pinakakaraniwan.

Mga larawan

Ang mga larawan ang pinakakaraniwang problema at pinakamadaling ayusin. Ang 4,000-pixel na larawang ipinapakitang 800 pixel ang lapad ay pinadadownload sa bawat bisita ng limang beses na mas malaki kaysa sa nakikita nila.

• Maghain ng mga larawang nasa laki ng pagpapakita, na may responsive na srcset na laki para sa phone at desktop.
• Gumamit ng modernong format (WebP o AVIF) at makatwirang compression.
• Lagyan ng width at height ang bawat larawan para mareserba ng browser ang espasyo. Ito lang ay halos nag-aayos na ng karamihan ng layout shift.
• I-lazy-load ang mga larawang nasa ibaba ng fold gamit ang loading="lazy".
• Huwag i-lazy-load ang pangunahing larawan sa itaas ng page. Matigas ang gabay ng Google sa LCP tungkol dito: ang lazy-loading sa LCP image ay laging nagpapabagal dito. Bigyan ito ng fetchpriority="high" sa halip.

JavaScript

Maraming site na gawa ng AI ay single-page app (SPA): dina-download ng browser ang JavaScript bundle at saka iginuguhit ang page. Kapag mas malaki ang bundle, mas matagal ang blankong screen. Mga ayos, ayon sa dami ng pagsisikap:

1. Alisin ang hindi mo ginagamit. Humingi ng listahan ng dependencies at tanggalin ang mga library na idinagdag minsan at nakalimutan na. Halimbawa, date library para sa iisang petsa, o buong icon pack para sa limang icon.
2. Hatiin kada route. I-load ang code ng admin dashboard kapag may nagbukas lang nito, hindi sa home page.
3. I-prerender ang mga pampublikong page. Ang marketing page na ipinapadala bilang totoong HTML ay lumalabas bago pa tumakbo ang anumang JavaScript. Nakakatulong din ito sa mga search engine; tingnan ang SEO para sa mga website na gawa ng AI.

Ang mabagal na INP ay kadalasang nangangahulugang iisang mahabang gawain ang humaharang sa page, gaya ng pag-filter ng napakalaking listahan sa bawat keystroke, o muling pag-render ng buong table kapag nagbago ang isang cell. Ipinapakita ng Performance panel ng Chrome DevTools kung alin.

Mga font

Bawat pamilya at timbang ng font ay isa pang file. Karaniwang sapat na ang dalawang pamilya at tatlo o apat na timbang. I-preload ang font na ginagamit sa itaas ng fold, gumamit ng font-display: swap para agad lumabas ang text, at i-self-host ang mga font kung mabagal ang external na font service para sa mga bisita mo.

Third-party scripts

Ang chat widget, analytics, heatmap, ad pixel, naka-embed na video, at social feed ay nagla-load ng code mula sa ibang server. Mukhang maliit ang bawat isa; kapag pinagsama, kadalasan sila ang pinakamabagal na bahagi ng page. Panatilihin ang mga tinitingnan mo talaga. I-load ang iba pagkatapos maging interactive ang page, at palitan ang mabibigat na embed (player ng YouTube, mapa) ng magaang preview na magla-load ng totoo kapag na-click.

Server response

Ang time to first byte (TTFB), kung gaano katagal bago magsimulang sumagot ang server, ang nasa ilalim ng bawat ibang sukatan. Mabilis halos saanman ang mga static na page na galing sa CDN (isang network ng server na malapit sa mga bisita mo; tingnan ang ano ang CDN). Ang mga page na binubuo ng server sa bawat request ay nakadepende sa server na iyon at sa database nito. Ang caching ng paulit-ulit na gawain at mga database index para sa mabagal na query ang karaniwang ayos.

Mga prompt na gumagana

Maging tiyak: pangalanan ang page, ang sukatan, at ang limitasyon. Idikit ang mga finding ng PageSpeed Insights kung mayroon ka.

Ipinapakita ng PageSpeed Insights na 4.8 s ang LCP sa mobile para sa home page, at ang LCP element ay ang hero image. I-resize at i-convert sa WebP ang hero image, maghain ng responsive na laki, itakda ang width at height, bigyan ito ng fetchpriority="high", at tiyaking hindi ito lazy-loaded. I-lazy-load ang bawat larawang nasa ibaba ng fold. Huwag baguhin ang disenyo.

I-audit ang mga dependency ng app na ito. Ilista ang bawat package, kung ano ang gumagamit nito, at tinatayang dagdag nito sa bundle. Alisin ang mga hindi ginagamit at hatiin ang mga route na /admin at /settings sa magkakahiwalay na chunk na nagla-load lang kapag binisita.

Parang mabagal ang search box sa /products. I-debounce ang filter, iwasang i-render muli ang buong listahan sa bawat keystroke, at i-paginate o i-virtualize ang listahan kung may mahigit 200 item.

Hakbang-hakbang

1. Subukan ang live na page sa PageSpeed Insights sa mobile. Itala ang LCP, INP, at CLS, at ang nangungunang tatlong problemang nakalista.
2. Unahin ang mga larawan: laki, format, dimensyon, lazy loading sa ibaba ng fold, at priority para sa hero.
3. Alisin ang third-party scripts na hindi mo ginagamit, at i-defer ang natitira.
4. Bawasan ang mga font sa kailangan ng disenyo.
5. Paliitin ang JavaScript: alisin ang hindi ginagamit na package, hatiin kada route.
6. I-prerender ang mga pampublikong page kung client-rendered pa rin ang mga ito at mabagal pa rin ang LCP.
7. Suriin ang server: caching, database index, static hosting para sa content na bihirang magbago.
8. I-publish ulit at subukan ulit. Unti-unting nag-a-update ang field data sa PageSpeed Insights habang dumarating ang totoong bisita sa mga sumunod na linggo, kaya hatulan ang mga unang resulta batay sa lab data.

Mga karaniwang pagkakamali

• Pagsubok lang sa mabilis na laptop. Ang mga bisita mo ay nasa katamtamang phone at mabagal o hindi pantay na mobile data. Subukan sa mobile mode.
• Paghabol sa perpektong 100. Gabay lang ang lab score. Kapag nasa good range na ang Core Web Vitals, mas mahalaga na ang nilalaman at kakayahang magamit kaysa sa ilang huling puntos.
• Paglazy-load ng lahat, kasama ang hero image. Lalo lang nitong pinalala ang LCP.
• Pagdaragdag ng speed plugin o library sa ibabaw ng lahat. Mas madalas na mas mainam ang pag-alis ng bigat kaysa magdagdag ng code para pamahalaan ito.
• Pag-optimize sa preview, hindi sa live na site. Gumagamit ang development preview ng hindi naka-optimize na build. Sukatin ang na-publish na URL.
• Isang beses lang inaayos ang bilis. Bawat bagong widget, larawan, at feature ay nagdaragdag ng bigat. Subukan ulit pagkatapos ng malalaking pagbabago.

Checklist ng bilis

• LCP ≤ 2.5 s, INP ≤ 200 ms, CLS ≤ 0.1 sa mobile
• Nire-resize, na-compress, modernong format ang mga larawan, may width at height
• Hindi lazy-loaded ang hero image; lazy-loaded ang mga larawan sa ibaba ng fold
• Walang hindi ginagamit na JavaScript library; nakahiwalay ang mabibigat na route
• Dalawang pamilya ng font o mas kaunti; naka-preload ang pangunahing font
• Ang third-party scripts na talagang ginagamit mo lang, at huli ang pag-load
• Naka-prerender o static ang mga pampublikong page kung posible
• Nasubukan ulit sa live na URL pagkatapos mag-publish

Magkaugnay ang bilis at layout sa mobile; tingnan ang paano gawing mobile responsive ang website. Para sa buong pagsusuri bago ilunsad, sakop ng paano dalhin ang AI prototype sa production ang natitira.

Bilis sa Mythex

Sa Mythex, ginagawa mo ang mga pagbabagong ito sa pamamagitan ng pagtatanong sa chat, o sa code editor sa Pro. Suriin ang na-publish na URL, hindi ang Preview, dahil nagpapatakbo ang Preview ng development server. Nagdi-deploy ang mga static na front end bilang static site kapag nag-publish ka (static websites), na angkop sa mga content page. Ang mga app na may server ay nag-i-scale sa zero: natutulog kapag walang gamit at nagigising sa susunod na bisita, kaya mas mabagal ang unang request pagkatapos ng tahimik na panahon, at natutulog ang nakakabit na database pagkatapos ng 5 minutong walang gamit (hosting limits). Kung mabagal lang ang isang pampublikong page sa unang bisita, iyon ang malamang na sanhi. Nakakatulong ang pagpapanatiling static ng mga marketing page. Pagkatapos ng mga pagbabago, mag-publish ulit at mag-hard-refresh.

Mga tanong