Website Lambat: Punca dan Cara Nak Lajukan Website Business

Ada satu kedai servis aircond di Ipoh yang upload 40 gambar kerja siap ke website dia sebab nak tunjuk portfolio. Sebulan lepas tu, enquiry WhatsApp turun separuh. Website tak rosak, ranking pun tak jatuh. Cuma page tu jadi berat 18 megabait dan orang tak sempat nampak butang WhatsApp.

Ini masalah yang owner jarang perasan, sebab owner test website dia sendiri di pejabat, guna fibre, guna phone baru, dengan semua file dah tersimpan dalam cache browser. Nampak laju. Memang selalu nampak laju.

Website lambat makan enquiry dulu, ranking kemudian

Soalan pertama owner biasanya pasal ranking. Itu bahagian kecil jawapannya, dan ia datang perlahan.

Google sendiri terus terang pasal berat isyarat ni. Dokumentasi page experience dia tulis “there is no single signal” untuk page experience, dan Search “always seeks to show the most relevant content, even if the page experience is sub-par.” Maksudnya page laju tak akan angkat content nipis mengatasi pesaing yang jawab soalan dengan betul. Kalau page kau memang tak keluar langsung, masalahnya bukan kelajuan, mula dengan check indexing.

Kerugian enquiry pula datang serta-merta dan jumlahnya lebih besar. Setiap saat sebelum page kau muncul adalah satu saat orang boleh keluar, dan yang paling cepat keluar ialah orang yang line paling teruk: luar bandar, dalam basement mall, atau dalam LRT.

Cara murah nak test. Bandingkan conversion rate visitor mobile dengan desktop dalam GA4. Kalau mobile convert sepertiga desktop sedangkan design sama, berat page adalah suspek pertama.

Tiga metrik Core Web Vitals dan apa rasanya pada pengguna

Google terbitkan ambang tepat untuk ketiga-tiganya di web.dev, dikira pada persentil ke-75 lawatan sebenar. Tiga daripada empat lawatan kena bagus baru kau lulus.

Satu benda kena semak dalam mana-mana report yang agency hantar. Interaction to Next Paint jadi Core Web Vital pada 12 Mac 2024, ganti First Input Delay. FID kira lambat sebelum browser mula handle tap pertama sahaja, dan hampir semua site lulus. INP kira keseluruhan masa tunggu sampai skrin bertindak balas, jadi banyak site yang dulu lulus sekarang gagal.

Kalau report yang kau terima pada 2026 masih senarai FID, template report tu dah basi. Tanya apa lagi yang tak update.

Field data lebih penting dari skor lab, dan 100 bukan sasaran

PageSpeed Insights bagi dua blok yang nampak serupa tapi maksudnya lain. Blok atas ialah field data dari Chrome User Experience Report: pengguna Chrome sebenar, atas phone dan line sebenar, kutipan 28 hari ke belakang. Itu yang sistem Google nampak. Blok bawah ialah Lighthouse, satu simulasi atas peranti simulasi. Dokumentasi Google sendiri kata “having good lab data does not necessarily mean real-user experiences will also be good.”

1. Mula dari Search Console. Report Core Web Vitals dia kumpulkan URL, jadi kau nampak sama ada masalahnya satu template atau seluruh site.
2. Lepas tu PageSpeed Insights, page demi page. Test page yang ada traffic, bukan homepage kesayangan.
3. Guna Lighthouse untuk cari punca, bukan untuk markah, dan tunggu 28 hari sebelum nilai kesan pembaikan.

Sekarang pasal nombor dalam bulatan berwarna tu. Ia campuran berwajaran metrik lab atas peranti yang diperlahankan, dan ia boleh naik turun lapan sepuluh mata antara test walaupun tak ada apa yang berubah pada site. Kejar dua puluh mata terakhir tu tempat duit terbakar, sebab untuk dapat mata tu developer akan buang live chat, booking calendar dan conversion tracking.

Sasaran yang lebih membosankan tapi betul: tiga-tiga vital hijau pada field data mobile, lepas tu berhenti. Banyak site kecil di Malaysia langsung tak ada field data sebab Chrome tak kumpul cukup lawatan, dan masa tu diagnostik lab dengan phone kau sendiri je yang ada.

Kualiti hosting dan lokasi server tentukan siling kau

Time to First Byte ialah berapa lama server ambil masa nak hantar bait pertama. Panduan Google di web.dev letak TTFB bagus pada 0.8 saat ke bawah, dan teruk kalau lebih 1.8 saat. Ia bukan Core Web Vital, tapi ia duduk bawah LCP sebagai lantai keras.

Kiraannya tak boleh tipu. Kalau server ambil 1.5 saat baru jawab, tinggal satu saat untuk download dan paint semua benda sebelum kau terlepas sasaran LCP 2.5 saat. Compress gambar tak boleh beli balik masa tu, sebab itu hosting duduk paling atas dalam senarai.

Lokasi server pun sama sebabnya. Plan shared murah yang servernya di Arizona atau Frankfurt tambah masa perjalanan fizikal untuk setiap request dari visitor KL, dan masa tu dicaj berulang untuk setiap asset. Untuk audience Malaysia, server di Malaysia atau Singapura adalah default yang munasabah. Minta host tulis lokasi data centre secara bertulis.

Pasal harga, hosting shared bajet duduk sekitar puluhan ringgit sebulan, manakala plan cloud atau managed WordPress yang elok beberapa kali ganda. Yang gerakkan angka tu ialah jumlah traffic, sama ada kau perlu staging, dan siapa yang patch server. Kalau kau masih pilih platform, perbandingan builder ada terangkan siapa uruskan hosting.

Gambar hampir selalu benda paling berat dalam page

Punca paling biasa website WordPress Malaysia jadi lambat ialah gambar kamera 4,000 piksel lebar yang di-upload terus dari phone, lepas tu dipapar dalam kotak 400 piksel. Browser download semua sekali.

Resize dulu sebelum upload. Hero penuh jarang perlu lebih 1,600 hingga 2,000 piksel lebar, gambar dalam artikel jarang perlu lebih 1,200. Kerja ni owner boleh buat sendiri guna tool percuma dalam browser, atau plugin optimisasi gambar dalam WordPress. Lepas tu tukar format. Dokumentasi WebP Google sendiri kata gambar WebP lossy 25 hingga 34 peratus lebih kecil dari JPEG setara, dan WebP lossless 26 peratus lebih kecil dari PNG.

Dua perkara yang selalu terlepas pandang. Lazy loading elok untuk gambar bawah skrin tapi teruk untuk gambar hero, dan beberapa plugin popular lazy load semua benda secara default, jadi tambah satu saat pada LCP untuk gambar yang Google tengah kira. Kedua, setiap gambar perlu atribut width dan height supaya browser tempah ruang awal. Dimensi yang hilang adalah punca paling biasa skor CLS gagal.

Jumlah plugin cuma simptom, markup page builder itu bilnya

Tiga puluh plugin bukan automatik teruk. Dua belas plugin yang ditulis buruk boleh lagi berat dari tiga puluh yang kemas. Yang penting berapa banyak CSS dan JavaScript setiap plugin load atas page yang tak guna pun. Kes klasik: plugin booking yang dipakai satu page je, tapi load stylesheet dan script dia atas semua empat puluh page.

1. Clone site ke staging. Jangan sekali audit atas site live, dan backup dulu.
2. Rekod baseline. Run PageSpeed Insights atas tiga page sebenar dan catat nombornya.
3. Deactivate satu plugin, test balik, activate semula. Satu-satu, supaya kau tahu siapa punya kos.
4. Padam yang tak guna. Plugin deactivate pun masih perlu update dan masih bawa risiko.
5. Hadkan yang tinggal. Kebanyakan plugin cache boleh halang script load di page yang tak perlukan.

Page builder macam Elementor, Divi dan WPBakery tambah lapisan sendiri. Dia hasilkan markup bersarang dalam dan hantar framework CSS serta JavaScript atas setiap page, tak kira page tu guna widget tu atau tidak. Kos tu memang wujud, tapi masih boleh tahan. Betulkan hosting, gambar dan conditional loading dulu, baru timbang sama ada bakinya berbaloi untuk rebuild.

Script yang block render, font, cache dan CDN mengikut urutan

Render-blocking maksudnya file yang browser wajib proses sebelum boleh paint apa-apa. Stylesheet dalam head memang begitu reka bentuknya. Script pula begitu melainkan kau suruh dia tangguh, dan penyumbang paling teruk selalunya pihak ketiga: chat widget, heatmap recorder, pixel iklan, embed review. Load chat lepas visitor scroll sahaja.

Font pula mahal secara senyap. Dua family dengan empat weight setiap satu bermakna lapan download, dan sebelum ia sampai browser mungkin tak papar apa-apa di tempat teks kau. Self-host file tu, potong character set kepada Latin, dan set font-display supaya font gantian keluar dulu. Kebanyakan website business cukup dengan dua weight satu family.

Page caching adalah tuas paling besar atas hosting shared. Ia tukar page yang PHP dan MySQL bina semula setiap kali request kepada file statik yang server boleh hulur terus, dan itu serang TTFB secara langsung.

CDN datang paling akhir untuk kebanyakan pembaca di sini. Kalau server kau dah di Malaysia atau Singapura dan customer kau orang Malaysia, faedahnya sederhana sahaja. Ia berbaloi bila kau hidang media berat, atau bila traffic sebenar datang dari luar rantau. Untuk semakan teknikal yang lebih luas, ikut checklist technical SEO selepas kerja kelajuan selesai.

Ujian sebenar ialah Android pertengahan atas 4G, bukan laptop atas fibre pejabat

Ini bahagian yang hampir semua owner langkau, dan ini juga yang ubah fikiran. Test guna iPhone baru atas wifi pejabat cuma bagitahu kau prestasi site untuk lebih kurang tiada sesiapa dalam senarai customer kau.

1. Pinjam Android umur tiga empat tahun. Peranti tu lebih dekat dengan visitor median kau berbanding apa-apa dalam bilik mesyuarat.
2. Tutup wifi. Data mobile sahaja, dari tempat yang signal sederhana, bukan atas bumbung.
3. Clear cache atau guna incognito. Salinan cache sembunyikan masalah yang kau nak uji.
4. Jalan laluan penuh. Hasil carian, landing page, page servis, sampai butang WhatsApp atau borang.

Kalau tak ada peranti sebenar, Chrome DevTools cukup hampir dan percuma: set network throttling ke slow 4G dan CPU throttling empat kali perlahan, lepas tu reload. Cuba juga waktu puncak petang, sebab masa tu tower mobile paling sesak dan pengalaman customer paling teruk.

Ini juga sebab skor mobile PageSpeed Insights sentiasa rendah dari desktop. Test mobile dia memang dah simulasi peranti pertengahan atas line yang sempit, dan nombor tu yang patut dibaiki. Ia paling penting atas page yang bawa offer kau, dan kos design website patut ambil kira kerja ni dari awal, bukan tampal kemudian.

Mana yang owner boleh buat sendiri, mana yang perlu developer

Garis pembahagi senang. Kalau perubahan tu boleh diundur dari dashboard WordPress dan kau ada backup yang jalan, buat sendiri. Kalau ia sentuh file theme, functions.php, server atau DNS, cari orang yang boleh baiki balik.

Turun ikut susunan dalam jadual tu. Tiga baris pertama murah dan selalunya cukup untuk gerakkan field data. Baris terakhir paling mahal dan patut jadi pilihan terakhir. Bila kau minta sebut harga untuk kerja developer, minta dia nyatakan metrik mana yang disasarkan dan berapa nombor sebelum dan selepas, bukan sekadar janji laju.

Soalan lazim pasal website lambat di Malaysia

Kesimpulan: betulkan lantai dulu, lepas tu berhenti

Kerja kelajuan ada urutan pulangan yang jelas untuk website WordPress di Malaysia. Hosting dan lokasi server tentukan siling, gambar bawa berat paling banyak yang boleh dibuang, plugin dan markup builder datang selepas tu, dan script, font serta caching kemas bakinya. Ukur guna field data 28 hari, test atas Android pertengahan guna data mobile, dan anggap skor lab sebagai alat diagnosis sahaja.

English version here: Website Speed in Malaysia: Core Web Vitals in Plain Language.

Kalau kau nak orang jalankan field data dan bagitahu jujur mana tiga fix yang berbaloi dibayar, hubungi kami.

Baca lagi

• Website vs Landing Page: What Does Your Business Actually Need
• Ecommerce Website Design in Malaysia: What a Proper Build Includes
• Digital Marketing Agency di Penang: Panduan Pilih & Kos

Sumber rasmi

• Meta Business Help Centre
• Google Business Profile