Kenapa laman web lambat, dan cara memeriksanya sendiri dalam beberapa minit

Pelawat tidak menunggu. Kajian berulang kali menunjukkan bahawa apabila laman web mengambil masa lebih tiga saat untuk muncul, sebahagian besar pelawat sudah menekan butang kembali sebelum melihat apa-apa. Masalahnya, pemilik laman web biasanya tidak tahu laman mereka lambat, sebab di telefon mereka sendiri, dengan sambungan yang baik, ia terasa pantas.

Artikel ini menerangkan punca sebenar laman web lambat, cara memeriksanya sendiri dalam beberapa minit, dan perkara mana yang patut dibaiki dahulu. Semuanya menggunakan alat percuma yang sudah ada pada pelayar awak.

Mula dengan mengukur, bukan meneka

Jangan mula dengan memasang alat pengoptimuman. Mula dengan mengukur. Buka laman awak dalam pelayar, tekan F12 untuk membuka alat pembangun, dan pilih tab Network. Muat semula halaman dengan Ctrl+Shift+R supaya ia tidak menggunakan fail yang sudah disimpan pelayar.

Perhatikan tiga nombor di bahagian bawah: bilangan permintaan, jumlah saiz yang dipindahkan, dan masa sehingga halaman siap dimuatkan. Sebagai panduan: halaman biasa yang sihat biasanya di bawah dua saat, di bawah satu megabait, dan kurang daripada 50 permintaan. Jika awak melihat 3 megabait dan 120 permintaan, punca masalahnya sudah kelihatan di situ.

Punca satu: gambar yang tidak dikecilkan

Ini punca paling kerap, dan paling mudah dibaiki. Seseorang memuat naik gambar terus daripada telefon. Gambar itu bersaiz 4,000 piksel dan empat megabait. Laman web pula hanya memaparkannya pada saiz 800 piksel. Setiap pelawat memuat turun empat megabait untuk melihat gambar yang kelihatan sama seperti jika ia 200 kilobait.

Cara memeriksa: dalam tab Network, susun senarai mengikut saiz. Jika dua atau tiga fail di bahagian atas senarai itu imej, di situlah tempat terbaik untuk mula. Perkhidmatan percuma untuk mengecilkan imej ada di mana-mana sahaja, dan menukar format kepada WebP biasanya memotong saiz sekali lagi tanpa penurunan kualiti yang ketara.

Satu peraturan mudah: saiz fail gambar tidak sepatutnya melebihi 300 kilobait untuk gambar kandungan biasa, dan imej utama halaman tidak sepatutnya melebihi 500 kilobait.

Punca dua: pelayan yang lambat atau jauh

Setiap permintaan perlu pergi ke pelayan dan pulang. Jika pelayan awak berada di Amerika Syarikat dan pelawat awak di Malaysia, perjalanan itu sahaja mengambil masa. Sesetengah penyedia hosting yang murah meletakkan ribuan laman web dalam satu pelayan sehingga sumbernya berkongsi antara semua orang, dan laman awak menjadi perlahan pada waktu sibuk.

Ini tidak bermakna awak perlu berpindah ke pelayan yang mahal. Tetapi jika masa respons pelayan (bukan masa memuat turun gambar) melebihi satu saat, masalahnya bukan pada laman awak, masalahnya pada tempat awak menyimpannya. Ujian mudah: jalankan ini di terminal dan lihat baris terakhir.

curl -o /dev/null -s -w 'DNS %{time_namelookup}\nSambung %{time_connect}\nMula %{time_starttransfer}\nJumlah %{time_total}\n' https://laman-awak.com

Jika masa mula melebihi 0.6 saat, pelayan itu mengambil masa yang lama sebelum ia mula menghantar jawapan. Jika masa jumlah hampir sama, masalahnya bukan pada gambar atau fail, tetapi pada pelayan itu sendiri, atau pada cara laman itu menjana halamannya.

Punca tiga: tiada cache untuk fail yang tidak berubah

Fail seperti CSS, JavaScript, logo dan fon tidak berubah setiap kali orang melawat. Tanpa arahan cache, pelayar memuat turunnya semula pada setiap halaman yang dibuka. Sepuluh halaman bermakna sepuluh kali muat turun perkara yang sama.

Konsepnya mudah: fail yang jarang berubah boleh disimpan dalam pelayar untuk masa yang lama, sementara halaman yang sentiasa berubah tidak patut disimpan. Rahsia yang membolehkan kedua-duanya sekali gus ialah menanda versi pada nama fail atau pada URL, contohnya site.css?v=3. Apabila fail itu berubah, nombor itu berubah, dan pelayar memuatkan yang baharu.

Punca empat: terlalu banyak skrip, terutama yang tidak digunakan

Setiap rangka kerja, plugin dan widget menambah fail berasingan. Alat analitik daripada tiga penyedia, dua perisian sembang pelanggan, dan plugin yang sudah tidak digunakan tetapi masih menyala, semuanya berlumba untuk dimuatkan sebelum halaman muncul.

Cara memeriksa: lihat senarai permintaan dalam tab Network dan hitung berapa daripadanya datang daripada pihak ketiga. Jika lebih daripada lima, tanya satu persatu: adakah ia benar-benar mendatangkan hasil? Setiap satu yang dibuang adalah kelajuan yang percuma.

Punca lima: pertanyaan pangkalan data yang berlebihan

Ini biasanya berlaku pada laman yang dimuatkan daripada pangkalan data, laman berita, direktori dan kedai. Setiap pertanyaan mengambil masa yang sedikit, dan apabila laman perlu menjalankan ratusan pertanyaan untuk satu halaman, jumlahnya menjadi saat yang penuh.

Tandanya mudah dilihat: halaman muncul dengan pantas pada kali kedua dibuka, tetapi lambat pada kali pertama. Berita baiknya, penyelesaiannya tidak memerlukan menulis semula laman. Yang biasa digunakan ialah cache halaman, simpan hasil satu halaman yang sudah siap, dan hidangkan salinan itu kepada pelawat seterusnya.

Empat nombor yang menentukan penilaian

Kalau awak mahu penanda aras yang ringkas, gunakan nombor yang Google kumpulkan daripada lawatan sebenar pelawat, bukan daripada alat ujian. Nombor itu dipanggil Core Web Vitals, dan ada tiga yang utama.

Pertama, masa elemen terbesar muncul pada skrin. Baik jika bawah 2.5 saat, teruk jika melebihi 4 saat. Kedua, masa laman bertindak balas apabila diketuk atau ditaip. Baik jika bawah 200 milisaat, teruk jika melebihi 500 milisaat. Ketiga, jumlah susun atur yang bergerak semasa halaman memuat. Baik jika bawah 0.1, dan punca paling kerap ialah gambar yang tidak dinyatakan saiznya.

Untuk gambaran saiz, halaman median pada telefon pada 2026 berjumlah kira-kira 2.6 megabait dengan 71 permintaan. Sepuluh peratus halaman yang paling berat melebihi 11 megabait dan membuat lebih 200 permintaan. Kalau laman awak berada dalam kumpulan itu, punca utamanya hampir selalu dua benda, iaitu gambar dan skrip. Gambar sahaja menyumbang kira-kira 890 kilobait daripada 2,800 kilobait berat halaman median.

Contoh sebenar, dari 3.8 megabait kepada 180 kilobait

Ini kerja yang saya buat berulang kali. Satu gambar utama disimpan pada 4,000 piksel lebar dan berjumlah 3.8 megabait. Selepas dikecilkan kepada 1,200 piksel dan disimpan sebagai WebP pada kualiti 80, saiznya menjadi sekitar 180 kilobait. Pelawat tidak nampak bezanya pada telefon, tetapi setiap lawatan kini memuat turun 3.6 megabait yang lebih sedikit.

Satu halaman biasanya mempunyai lebih daripada satu gambar. Kalau laman awak memuatkan enam gambar besar, itu boleh menjadi lebih 20 megabait untuk satu lawatan. Pada data mudah alih, pelawat akan pergi sebelum gambar ketiga muncul. Peraturan yang saya guna begini. Jangan simpan gambar lebih besar daripada 1,600 piksel lebar untuk laman biasa, sasarkan bawah 300 kilobait untuk gambar kandungan, dan bawah 500 kilobait untuk gambar utama. Simpan dalam format WebP, dan sediakan versi kecil berasingan untuk halaman senarai supaya halaman senarai tidak memuatkan gambar besar yang tidak perlu.

Kos sebenar dan cara mengiranya

Kerja membetulkan kelajuan jarang memerlukan belanja besar. Mengecilkan gambar dan menukar format tidak berbelanja apa-apa selain masa. Menambah arahan cache untuk fail statik di Nginx atau .htaccess biasanya siap dalam masa kurang satu jam, dan kerja itu dibuat sekali sahaja.

Yang berbelanja ialah pelayan. Sebagai panduan kasar di pasaran Malaysia, hosting kongsi berada dalam lingkungan RM150 hingga RM400 setahun, VPS kecil sekitar RM30 hingga RM90 sebulan, dan pelayan terurus sekitar RM300 sebulan ke atas. Harga berubah mengikut penyedia, jadi minta sebut harga bertulis dan tanya tiga perkara. Berapa RAM, berapa banyak laman berkongsi pelayan yang sama, dan adakah sandaran harian termasuk.

Sebelum berbelanja, buat kiraan mudah dahulu. Katakan laman awak menerima 2,000 lawatan sebulan. Kalau seorang daripada sepuluh pelawat pergi kerana lambat, awak kehilangan 200 pelawat. Kalau seorang daripada 100 pelawat menjadi pelanggan, itu dua pelanggan yang hilang setiap bulan. Pada nilai RM150 bagi seorang pelanggan, kerugian itu RM300 sebulan. Dengan kiraan itu, naik taraf hosting RM80 sebulan berbaloi kalau ia mengembalikan seorang pelanggan sahaja. Tetapi jangan mula dari situ. Mula dari gambar dan arahan cache, kerana kedua-duanya percuma, dan ukur semula selepas itu.

Ujian dalam keadaan sebenar

Alat ujian berjalan pada pelayan yang pantas dengan sambungan yang pantas. Pelawat awak tidak. Di Malaysia, perbezaan paling besar kelihatan pada sambungan mudah alih, terutama di dalam bangunan, di kawasan luar bandar, dan pada waktu puncak.

Cara menguji tanpa membeli apa-apa. Buka laman awak pada telefon lama, gunakan data mudah alih, dan jauhkan telefon daripada router. Kalau boleh, turun ke tingkat bawah pusat beli belah atau duduk di dalam kereta di tempat letak kereta bawah tanah, kemudian buka semula laman itu dan catat berapa saat ia muncul. Kalau muncul dalam masa tiga saat, laman awak berada dalam keadaan yang lebih baik daripada kebanyakan laman. Kalau ia mengambil masa enam saat, awak sudah tahu masalahnya wujud dan boleh mengesannya dengan bukti, bukan dengan perasaan.

Satu tabiat yang saya syorkan. Catat masa sekarang pada sekeping kertas, buat satu pembaikan, ukur semula, dan tulis nombor baharu di sebelahnya. Tanpa catatan, awak tidak akan tahu sama ada kerja awak membantu, dan awak akan terus membetulkan perkara yang tidak pernah menjadi masalah.

Apa yang belum diketahui

Saya perlu jujur tentang had rencana ini. Saya tidak boleh memberitahu awak punca tepat laman awak lambat tanpa melihat data laman awak. Yang boleh saya beri ialah urutan siasatan yang biasanya betul.

Pada peringkat umum, ada perkara yang tidak diketahui sesiapa di luar Google. Google tidak menerbitkan berapa besar pengaruh Core Web Vitals berbanding faktor lain dalam kedudukan carian, seperti kaitan kandungan dan pautan masuk. Tiada siapa boleh memberi nombor itu dengan pasti.

Pada peringkat laman pula, perkara yang paling kerap tidak diketahui pemilik ialah apa yang berjalan di dalam pelayan mereka sendiri. Kalau awak menggunakan hosting kongsi, awak mungkin tidak boleh melihat log pertanyaan pangkalan data, dan awak mungkin tidak dibenarkan menetapkan cache sepenuhnya. Dalam keadaan itu, orang pertama yang patut awak tanya ialah penyedia hosting, bukan alat tambahan yang baru dipasang.

Akhir sekali, data lapangan berbeza daripada ujian. Dua pelawat pada hari yang sama boleh mendapat pengalaman yang berbeza kerana telefon, sambungan dan jarak mereka berbeza. Sebab itu satu angka sahaja tidak pernah cukup untuk membuat kesimpulan.

Apa yang patut dibaiki dahulu

• ▸ Gambar. Ia punca paling kerap, paling mudah dibaiki, dan kesannya paling besar.
• ▸ Arahan cache untuk fail statik. Kerja sekali, kesan berterusan.
• ▸ Buang skrip pihak ketiga yang tidak digunakan.
• ▸ Barulah lihat pelayan dan hosting, selalunya dengan kos tambahan sedikit atau tiada.
• ▸ Cache halaman untuk laman yang dimuatkan daripada pangkalan data.
• ▸ Pertimbangkan CDN, tetapi ingat ia menutup masalah dan bukannya menyelesaikannya.

Perkara yang tidak perlu dibimbangkan

Markah sempurna dalam alat ujian bukan matlamat. Markah mudah berubah dengan memasang dua fail, dan sering kali awak membelanjakan berjam-jam untuk dua mata terakhir yang tidak pernah terasa oleh pelawat.

Yang penting ialah sama ada pelawat awak merasakan laman itu pantas untuk kegunaan sebenar mereka, telefon lama, sambungan mudah alih yang tidak stabil, laman yang dibuka dalam bas. Uji dalam keadaan itu, bukan hanya pada komputer dan wifi pejabat.