Kalau halaman publiknya cepat dan pengelolaannya lambat, biasanya Anda tidak sedang mengukur hal yang sama dua kali. Halaman publiknya disajikan dari singgahan; pengelolaannya menjalankan aplikasi Anda pada setiap klik. Kecepatan pengelolaan itulah kecepatan situs yang sebenarnya.
Pastikan singgahannya yang jadi selisihnya
curl -sSI https://yourdomain.com/ | grep -i x-cache
curl -sSI https://yourdomain.com/admin/ -H 'Cookie: session=...' | grep -i x-cache
HIT pada yang pertama dan BYPASS pada yang kedua - itulah seluruh penjelasannya. Lihat singgahan halaman, dan kapan ia berbohong kepada Anda.
Lalu cari tahu apa yang sebenarnya dikerjakan aplikasinya
- Kueri. Tampilan daftar di pengelolaan biasanya memuat jauh lebih banyak per baris daripada halaman publik. Lihat kueri N+1.
- Panggilan ke luar saat halaman dimuat - pemeriksaan lisensi, pemeriksaan pembaruan, sebuah umpan - yang membuat papan pantaunya menunggu server orang lain.
- Tabel catatan atau aktivitas yang sudah membesar dan kini dihitung di setiap halaman.
- Puluhan skrip khusus pengelolaan, dan itu masalah peramban, bukan masalah server.
Ukur pembagiannya
curl -sS -o /dev/null -w 'ttfb %{time_starttransfer} total %{time_total}\
' \
-H 'Cookie: session=...' https://yourdomain.com/admin/
Waktu ke bita pertama yang tinggi menunjuk server; yang rendah tapi totalnya lambat menunjuk peramban. Satu baris itu menentukan ke mana harus melihat, dan hanya makan sedetik.
Tersangka yang biasa
SELECT COUNT(*) FROM wp_options WHERE autoload = 'yes';
SELECT option_name, LENGTH(option_value) FROM wp_options
WHERE autoload = 'yes' ORDER BY 2 DESC LIMIT 10;
Apa pun yang dimuat otomatis dibaca pada setiap permintaan tanpa kecuali. Beberapa megabita darinya - sisa peninggalan pengaya yang sudah dicabut - memperlambat setiap halaman, dan ia terlihat lebih dulu di pengelolaan karena di sana tak ada yang disinggahkan.
