Laman awak lambat? Urutan diagnosis yang saya guna (ukur dahulu, jangan teka)
Kebanyakan laman lambat bukan kerana bahasa pengaturcaraan. Ia kerana pertanyaan pangkalan data dijalankan dalam gelung, imej yang terlalu besar, cache yang tidak digunakan, dan skrip pihak ketiga yang berlebihan. Urutan yang betul ialah ukur dahulu, betulkan yang paling besar kesannya, kemudian ukur semula.
"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.
