Laman awak lambat? Urutan diagnosis yang saya guna

"Laman saya lambat" ialah simptom, bukan diagnosis. Sebelum menukar apa-apa, saya kumpulkan lima ukuran. Tanpa nombor, pembetulan menjadi tekaan, dan tekaan selalunya menghasilkan kerja yang tidak mengubah apa-apa.

Lima ukuran asas

• ▸ Masa respons pelayan (TTFB): berapa lama pelayan berfikir sebelum menghantar bait pertama. Kalau ini tinggi, masalahnya di pelayan atau pangkalan data, bukan di pelayar pelawat.
• ▸ Bilangan dan tempoh pertanyaan pangkalan data bagi satu permintaan. Sepuluh pertanyaan kecil selalunya lebih baik daripada satu yang memanggil 10,000 rekod.
• ▸ Jumlah bait imej dan skrip. Satu gambar telefon yang tidak dimampatkan boleh lebih besar daripada seluruh halaman.
• ▸ Header cache untuk fail statik: CSS, JS dan imej sepatutnya diambil dari cache pelayar, bukan dimuat turun semula setiap lawatan.
• ▸ Skrip pihak ketiga: setiap penganalisis, widget sembang dan piksel pengiklanan menambah masa menunggu yang awak tidak kawal.

# Masa respons pelayan (ulang 3 kali, ambil yang sederhana)
for i in 1 2 3; do curl -s -o /dev/null -w "TTFB: %{time_starttransfer}s Jumlah: %{time_total}s\n" https://laman-anda.com/. Done # Saiz halaman dan header cache fail statik
curl -sI https://laman-anda.com/gambar-besar.jpg | grep -i -E "content-length|cache-control"

Puncak yang paling kerap saya jumpa

• ▸ Pertanyaan dalam gelung: satu pertanyaan diulang untuk setiap baris senarai, sehingga 100 baris bermakna 100 perjalanan ke pangkalan data.
• ▸ Imej asal dari telefon dimuatkan tanpa saiz: pelayar memuatkan fail penuh walaupun dipaparkan sekecil 300 piksel lebar.
• ▸ Tiada indeks pada lajur yang kerap dicari (slug, emel, tarikh), jadi setiap carian menyemak seluruh jadual.
• ▸ Skrip dalam <head> tanpa defer atau async, yang menghalang halaman daripada dipaparkan.
• ▸ Cache dinamik dimatikan: setiap kunjungan membina semula halaman yang sama.

Bila ia patut dibina semula

Pembinaan semula patut dipertimbangkan apabila kos mengekalkan melebihi kos membina baharu: struktur pangkalan data menghalang setiap ciri baharu, tiada sesiapa lagi memahami kod itu, atau peningkatan keselamatan tidak boleh dipasang. Kalau puncak masalah boleh disenaraikan dan dibetulkan satu per satu, memperbaiki hampir selalu lebih murah dan lebih cepat.

Apa yang saya betulkan dahulu

• ▸ Indeks dan pertanyaan pangkalan data, kesannya paling besar dan paling murah.
• ▸ Saiz imej dan caching statik, nampak jelas pada telefon.
• ▸ Bilangan skrip pihak ketiga, biasanya boleh dikurangkan tanpa kerugian.
• ▸ Barulah menyentuh struktur kod, jika masih perlu.

Maksud nombor TTFB

TTFB di bawah 200 milisaat boleh dianggap baik untuk laman yang ada pangkalan data. Antara 200 dan 500 milisaat masih boleh diterima, tetapi ada ruang untuk diperbaiki. Melebihi 800 milisaat, pelawat mula rasa halaman itu menggantung, terutama di telefon.

Bandingkan dengan masa perjalanan rangkaian sahaja. Dari Kuala Lumpur ke pusat data Singapura, perjalanan data bolak balik sekitar 20 hingga 40 milisaat. Ke Jerman atau Amerika Syarikat, 150 hingga 250 milisaat. Jadi TTFB 300 milisaat ke pelayan Singapura bermakna sekitar 260 milisaat itu masa pelayan berfikir, bukan masa kabel.

Ada satu perkara yang sering dilupakan. Pelawat di kawasan luar bandar Kelantan tidak guna fiber. Pada 4G dengan 5 Mbps, satu megabait mengambil masa kira kira 1.6 saat untuk turun. Itu sebabnya laman yang kelihatan pantas di pejabat boleh kelihatan lambat di telefon pelawat.

Contoh sebenar satu halaman

Ini contoh daripada satu halaman senarai produk yang saya periksa. Jumlah muat turun 1.4 MB, 38 pertanyaan pangkalan data bagi satu permintaan, TTFB 1.9 saat, dan masa muat penuh 4.2 saat pada telefon.

Selepas kerja pembetulan, jumlah muat turun turun ke 210 KB kerana gambar dikecilkan dan ditukar ke WebP. Pertanyaan pangkalan data turun dari 38 ke 4 kerana pertanyaan dalam gelung digantikan dengan satu pertanyaan dan indeks ditambah. Cache halaman 60 saat dipasang untuk pelawat yang tidak log masuk.

Keputusannya TTFB 220 milisaat dan masa muat penuh 1.1 saat. Kerja diambil masa 5 jam. Tiada satu baris kod logik aplikasi diubah. Semua perubahan berlaku pada gambar, pertanyaan dan lapisan cache.

Kos sebenar di Malaysia

Kadar kerja bebas untuk kerja prestasi di Malaysia sekitar RM 80 hingga RM 150 sejam. Pakej diagnosis dan pembetulan penuh untuk laman sederhana biasanya RM 600 hingga RM 1,500, bergantung kepada bilangan halaman dan keadaan kod.

VPS 4 teras dengan 8 GB RAM di Malaysia atau Singapura berharga sekitar RM 45 hingga RM 90 sebulan. CDN percuma sudah memadai untuk laman biasa. Jadi kos bulanan laman yang pantas bukan kos yang besar. Yang mahal ialah masa manusia.

Ada satu angka yang sering dipetik dalam tulisan pemasaran, iaitu setiap satu saat kelewatan mengurangkan penukaran sekitar 7 peratus. Angka itu datang daripada kajian lama sebuah syarikat teknologi besar dan kajian itu dilakukan untuk laman mereka sendiri. Ia berguna sebagai penunjuk arah, tetapi jangan jadikan ia janji untuk laman awak.

Alat yang boleh awak guna hari ini

PageSpeed Insights memberi dua set nombor. Satu datang daripada data pelawat sebenar yang dikumpul pelayar Chrome, satu lagi daripada ujian makmal. Data pelawat sebenar lebih penting kerana ia menunjukkan apa yang pelawat awak alami.

WebPageTest menghasilkan rakaman masa muat dan menunjukkan fail mana yang menyekat paparan. Kalau awak tidak pasti fail mana patut dibetulkan dahulu, ini alat yang paling cepat memberi jawapan.

Alat pembangun pelayar pada tab Network menunjukkan masa setiap permintaan. Susun mengikut saiz dan mengikut masa. Selalunya dua atau tiga permintaan sahaja menyumbang lebih separuh jumlah masa.

Untuk pangkalan data MySQL, hidupkan slow query log dan lihat pertanyaan yang melebihi 0.5 saat. Kemudian jalankan EXPLAIN pada pertanyaan itu untuk melihat sama ada indeks digunakan. Kerja ini percuma dan biasanya memberi pulangan paling besar.

Semua alat di atas tidak berbayar. Yang berbayar ialah masa orang yang membaca nombor itu dan memutuskan apa yang patut dibetulkan.

Empat kesilapan yang berulang

Pertama, memasang plugin cache tetapi membiarkan 38 pertanyaan pangkalan data. Cache menyembunyikan masalah untuk pelawat pertama, dan pelawat pertama itulah yang paling penting.

Kedua, menguji guna fiber 500 Mbps di rumah sendiri sedangkan sebahagian besar pelawat masuk guna telefon. Ujian perlu dibuat pada tetapan yang meniru telefon biasa.

Ketiga, mengubah tiga perkara sekali gus, kemudian tidak tahu mana satu yang berkesan. Satu perubahan, satu ukuran.

Keempat, membeli pelayan yang lebih besar sedangkan puncaknya satu pertanyaan tanpa indeks. Pelayan lebih besar hanya membeli sedikit masa. Ia tidak membetulkan kerja yang tidak cekap.

Soalan yang selalu ditanya

Perlukah saya tukar hosting? Tidak semestinya. Ukur dahulu. Kalau TTFB tinggi kerana pertanyaan pangkalan data perlahan, hosting baharu dengan masalah yang sama juga akan perlahan.

WordPress punca ke? Bukan nama sistemnya. WordPress dengan 45 plugin aktif memang berat, tetapi puncanya plugin, imej dan pertanyaan, bukan nama perisian itu.

Berapa lama kerja ini? Diagnosis biasanya setengah hari. Pembetulan satu hingga tiga hari bergantung kepada bilangan isu. Laman yang bersih boleh siap dalam beberapa jam.

Perlukah tukar bahasa pengaturcaraan supaya laju? Hampir tidak pernah. ColdFusion, PHP, Node atau Python semuanya boleh laju kalau pertanyaan dan cache betul. Menukar bahasa ialah projek berbulan bulan untuk masalah yang biasanya selesai dalam sehari.

Adakah CDN perlu? CDN membantu fail statik dan pelawat yang jauh dari pelayan. CDN tidak membetulkan pertanyaan perlahan. Kalau bajet terhad, betulkan pelayan dahulu.

Bila masalahnya bukan prestasi

Kadang laman nampak lambat kerana pelayan tidak sempat memproses permintaan serentak. Bilangan pekerja yang terhad bermakna permintaan ke 20 akan beratur menunggu. Ini masalah kapasiti, bukan masalah kod.

Kadang punca di luar pelayan. DNS yang perlahan menambah masa sebelum sambutan pertama. Sijil TLS yang tidak disimpan dalam cache memaksa jabat tangan berulang setiap kali pelawat datang.

Saya juga pernah jumpa cakera penuh kerana fail log yang tidak diputar. Bila cakera penuh, setiap tulisan ke pangkalan data menunggu, dan seluruh laman menjadi lambat. Semak ruang cakera sebelum membeli apa apa.

Apa yang belum diketahui

Satu ukuran pada satu masa bukan gambaran penuh. Trafik puncak, tugas sandaran yang berjalan pada 3 pagi dan proses carian enjin yang merangkak laman boleh mengubah keputusan. Ukuran perlu diambil pada waktu yang berbeza.

Skrip pihak ketiga boleh berubah tanpa pemberitahuan. Hari ini ia pantas, bulan depan pengeluar skrip menambah ciri baharu dan beratnya naik. Kerja prestasi bukan kerja sekali siap.

Jika laman bergantung kepada API pihak lain, tiada kerja di pelayan awak boleh memperbaiki masa tindak balas API itu. Yang boleh dibuat ialah menunjukkan keadaan memuatkan kepada pelawat supaya mereka tidak menekan butang dua kali.

Akhir sekali, urutan ini berdasarkan kerja yang saya lakukan pada laman biasa. Setiap laman berbeza. Nombor yang saya sebut di atas ialah contoh, bukan angka yang boleh dijangka untuk laman lain.

Urutannya mudah diingat. Ukur dahulu, senaraikan puncak mengikut susunan, betulkan yang paling besar kesannya, kemudian ukur semula. Setiap langkah mesti ada nombor sebelum dan selepas.