Mengapa Situs WordPress Anda Sangat Lambat Dan Panduan Praktis Untuk Mempercepat Segalanya

Saya ingin memulai posting ini dengan memberi tahu Anda bahwa ini BUKAN hanya artikel umum "Cara Mempercepat WordPress".

Saya tidak akan memuntahkan apa pun yang sudah dapat ditemukan di web. Saya tidak akan memberitahu Anda bahwa Anda harus menginstal plugin caching, mengaktifkan kompresi, mengecilkan css/js Anda dll….

Lagi pula, Anda seharusnya sudah tahu bagaimana melakukan hal-hal ini. Dan jika tidak, Anda dapat menemukan informasi umum ini di ratusan blog lain.

Sebaliknya, artikel ini berisi semua kustom/semi-kustom yang telah saya terapkan dalam sebulan terakhir ini untuk mempercepat blog WordPress saya sendiri dan pada dasarnya mencegah akses jahat untuk menjatuhkan server saya.

Dan alasan "sedikit diketahui" adalah karena teknik yang akan saya jelaskan akan sangat spesifik untuk blog Anda sendiri tergantung pada pola lalu lintas yang Anda lihat.

Catatan: Jika Anda memiliki blog yang lambat dan Anda benar-benar tidak ingin berurusan dengan aspek teknis apa pun untuk mempercepat situs web, maka Anda mungkin harus mendaftar ke layanan seperti WP Engine .

Orang-orang ini berspesialisasi dalam hosting WordPress dan akan memastikan blog Anda berjalan secepat mungkin. Tapi tentu saja, ini ada harganya. Anda harus memeriksanya jika posting ini melampaui kepala Anda :)

Bagaimanapun, sebelum saya dapat menjelaskan kepada Anda bagaimana dan mengapa saya melakukan apa yang telah saya lakukan pada blog saya, Anda harus memahami beberapa konsep dasar tentang WordPress dan caching yang akan saya jelaskan di bawah.

Beberapa Fakta Menarik WordPress

Katakanlah Anda telah mengikuti semua panduan tentang cara mempercepat WordPress. Blog Anda terasa zippy. Webpagetest.org memberi tahu Anda bahwa blog Anda sangat cepat. Semuanya baik-baik saja kan? Belum tentu .

Saya dulu merasakan hal yang sama tentang blog saya. Lagi pula, saya mengikuti sebagian besar protokol percepatan standar. Saya menjalankan sangat sedikit plugin dan blog saya terasa cukup cepat dalam penggunaan normal dari sudut pandang pembaca manusia (Jaringan iklan yang memperlambat blog saya jadi saya memuat iklan terakhir).

Tapi kemudian saya mulai menganalisis grafik penggunaan CPU saya dan sering melihat periode beban server yang tinggi meskipun tingkat lalu lintas rendah hingga sedang. Kadang-kadang, server saya bahkan menjadi tidak dapat digunakan atau tidak responsif untuk waktu yang lama.

Catatan, satu-satunya alasan mengapa saya mulai memperhatikan statistik ini adalah karena beberapa waktu lalu saya menjalankan toko online saya di server yang sama dengan blog saya. Dan secara berkala saya akan memiliki pelanggan yang mengeluh bahwa toko itu sangat lambat. Ketika saya akhirnya melakukan penggalian, saya menemukan bahwa blog WordPress saya yang dioptimalkan dan di-cache sepenuhnya membuat server saya bertekuk lutut!

Pesan moral dalam cerita? Hanya karena tes kecepatan memberi tahu Anda bahwa blog Anda cepat tidak berarti semuanya baik-baik saja.

Berikut adalah beberapa fakta menarik tentang WordPress dan plugin caching seperti WP Super Cache dan W3 Total Cache yang harus Anda ketahui.

• Respons WordPress 404 lambat . Setiap kali blog Anda menerima akses ke halaman yang tidak ada, server Anda yang buruk harus memuat WordPress, menjalankan banyak kode php, melakukan banyak kueri MySQL dan kemudian mengeluarkan halaman WordPress 404 kustom Anda. Ini adalah tugas yang sangat intensif sumber daya dan caching tidak akan membantu.
• Plugin caching Anda tidak berfungsi dengan baik ketika ada parameter GET di URL. Misalnya, saya biasa memperhatikan bahwa blog saya akan lambat merangkak setiap kali saya mengirim ledakan ke daftar email saya. Secara teori dengan caching file statis, server saya harus hampir tak terkalahkan.

  Tetapi karena Aweber menyisipkan parameter pelacakan di URL, tidak ada file saya yang di-cache super. Akibatnya, WordPress harus membuat file cache baru (walaupun sudah ada), zip dan kirimkan setiap kali. Bagian terburuknya adalah file yang di-cache ini hanya digunakan sekali yang membuatnya membuang-buang sumber daya server

• Akses nakal lambat. Karena akses jahat mengharuskan WordPress memuat secara default, bot atau perayap buruk yang memutuskan untuk mengirim spam ke situs Anda dengan permintaan buruk dapat menghapus blog Anda dengan mudah.
• Plugin caching Anda mungkin memiliki bug atau ketidakcocokan dengan cara Anda menyiapkan blog . Misalnya, selama 3 tahun saya pikir WP Super Cache melakukan hal yang benar sampai saya mulai melihat log saya dan melihat bug dalam kode. Karena cara saya mengaturnya, saya memiliki masalah di mana WP Super Cache terlalu sering mem-flush cache saya.

Poin kunci yang saya coba sampaikan dengan poin-poin di atas adalah bahwa setiap kali akses non-standar terjadi di blog Anda, itu menggunakan banyak sumber daya server tidak peduli bagaimana Anda mengatur blog WordPress Anda. Dan jenis akses inilah yang akan membuat server Anda bertekuk lutut, bukan lalu lintas biasa.

Mendeteksi Akses Rogue

Kunci pertama untuk mengoptimalkan blog WordPress Anda adalah memahami pola lalu lintas yang diterima blog Anda. Saya berani bertaruh bahwa 99% pengguna WordPress tidak melakukan ini. Sebaliknya, mereka secara membabi buta mengikuti dan menginstal berbagai plugin dan menganggap semuanya berfungsi dengan baik. Jangan merasa buruk, saya juga begitu.

Jadi langkah pertama adalah mencari tahu apa yang sedang terjadi. Ada banyak cara untuk melakukan ini, tetapi cara termudah adalah menggunakan mode debug yang disediakan oleh plugin WP SuperCache. Apa yang dilakukan mode ini? Pada dasarnya, setiap kali akses ditangani langsung oleh WordPress (resource intensive), maka akan muncul di WP Super Cache log. Inilah cara Anda mengaktifkan mode ini.

Di bawah tab debug Plugin Super Cache WP Anda, cukup klik pada kotak centang "Debugging Enabled" dan Anda siap melakukannya!

Setelah logging diaktifkan, Anda dapat mengklik tautan "logfile" yang akan mengarahkan Anda ke file yang merinci lalu lintas WordPress Anda. Ini akan terlihat mirip dengan teks di bawah ini.

15:03:46 /?utm_source=fwisp.com supercache dir:
15:03:46 /?utm_source=fwisp.com No wp-cache file exists. Must generate a new one.
15:03:46 /?utm_source=fwisp.com In WP Cache Phase 2
15:03:46 /?utm_source=fwisp.com Setting up WordPress actions
15:03:46 /?utm_source=fwisp.com Supercache caching disabled. Only using wp-cache. Non empty GET request.
15:03:46 /?utm_source=fwisp.com USER AGENT (Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)) rejected. Not Caching

Hal penting yang perlu diperhatikan adalah setiap kali Anda melihat sesuatu di log ini, itu adalah hal yang buruk karena itu berarti WordPress harus bekerja. Dan karena WordPress adalah sumber daya, Anda ingin WordPress melakukan pekerjaan sesedikit mungkin.

Apa yang Harus Diperhatikan Dalam Log

Log WP Super Cache sangat bagus karena memberi tahu Anda semua yang sedang terjadi. Tetapi jumlah informasi yang banyak bisa sangat banyak kecuali Anda tahu apa yang harus dicari. Inilah yang harus Anda perhatikan dalam log ini.

• 404 Errors – Pada dasarnya ini adalah akses ke halaman yang tidak ada di blog Anda. Setiap akses 404 yang ditangani oleh WordPress membutuhkan banyak sumber daya server sehingga Anda ingin menghentikannya sejak awal jika memungkinkan
• One Time Accesses – Ini adalah permintaan yang menyebabkan server Anda men-cache dan mengompresi halaman yang hanya akan digunakan sekali (lebih lanjut tentang ini nanti)
• Serangan Lalu Lintas Aneh – Ini biasanya bot yang memalu blog Anda sekaligus
• Perilaku Caching yang Aneh – Apakah cache Anda di-flush saat seharusnya? Apakah semuanya di-cache dengan benar dalam semua keadaan?

Setelah mencatat lalu lintas blog saya selama 2 minggu, saya menemukan banyak ketidakefisienan yang akan saya jelaskan di bawah.

Bot Memalu Arsip Saya

Hal pertama yang saya lakukan adalah melihat log server saya untuk periode beban CPU yang tinggi. Kemudian, saya menganalisis log cache super saya selama periode yang sama persis ini untuk melihat apakah ada bisnis lucu yang terjadi. Ternyata setiap dua hari sekali, sekelompok bot akan datang dan memalu semua halaman arsip blog saya pada saat yang bersamaan!

Karena halaman arsip ini tidak di-cache secara default, banyak akses simultan sudah cukup untuk meningkatkan beban server saya dan membuat semuanya menjadi sangat lambat. Dan terkadang, itu bahkan menyebabkan server saya mogok.

Jadi saya melihat lebih dekat pada output HTML saya dan memperhatikan bahwa saya memiliki banyak tautan arsip sebagai bagian dari header WordPress saya. Oleh karena itu, bot dan perayap web lainnya akan datang dan mencoba menelusuri arsip.

Setelah googling besar-besaran, saya menemukan bahwa beberapa webmaster lain mengalami masalah serupa.

Ketika kami melihat masalah pemuatan dengan situs Anda berkali-kali, ada banyak klik untuk IP server proxy dan teorinya adalah bahwa proxy ini menyimpan cache situs Anda dan mengenai semua tautan arsip tersebut. Banyak IP yang kami lihat saat situs Anda menyebabkan masalah pemuatan adalah IP proxy perusahaan, pendidikan, dan Pemerintah/Militer yang tampaknya mengambil konten terlebih dahulu saat seseorang mengakses situs.

Solusi: Periksa untuk melihat apakah Anda memiliki pernyataan php "wp_get_archives" di kode header untuk blog Anda dan hapus. Setelah menghapus cuplikan kecil ini, semua akses arsip saya menghilang.

Bot Mengakses File yang Tidak Ada

Hal utama kedua yang saya perhatikan adalah ada banyak bot yang mengakses file di server saya yang tidak ada. Masalahnya adalah setiap kali akses file terjadi, server Anda harus memuat WordPress, mengeksekusi banyak kode PHP dan kemudian mengeluarkan halaman 404.

Solusi untuk masalah ini adalah mengedit file .htaccess (Google this jika Anda tidak tahu apa itu) dan tambahkan baris berikut.

Tulis Ulang %{REQUEST_FILENAME} !-f
Tulis Ulang %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !(robots\.txt|sitemap\.xml(\.gz)?)
Tulis Ulang %{REQUEST_FILENAME} \.(css|js|html|htm|rtf|rtx|svg
|svgz|txt|xsd|xsl|xml|asf|asx|wax|wmv|wmx|avi|bmp|class|divx|doc
|docx|exe|gif|gz|gzip|ico|jpg|jpeg|jpe|mdb|mid|midi|mov|qt|mp3|
m4a|mp4|m4v|mpeg|mpg|mpe|mpp|odb|odc|odf|odg|odp|ods|odt|ogg|pdf
|png|pot|pps|ppt|pptx|ra|ram|rar|swf|tar|tif|tiff|wav|wma|wri|
xla|xls|xlsx|xlt|xlw|zip)$ [NC]
Aturan Penulisan Ulang .* – [L]

Setelah baris-baris ini dimasukkan ke dalam file .htaccess Anda, server web Anda akan terlebih dahulu memeriksa untuk melihat apakah ada file. Jika tidak, itu akan mengeluarkan respons 404 TANPA memuat WordPress.

Bot Mengakses URL yang Tidak Ada

Yang disayangkan dari cara penulisan WordPress adalah jika ada akses ke artikel yang tidak ada di database Anda, server Anda harus memuat WordPress, mengeksekusi sekumpulan kode PHP dan melakukan banyak pencarian MySQL sebelum mengeluarkan 404 tanggapan.

Jika Anda melihat log Anda dengan cermat, Anda mungkin akan melihat pola akses tertentu yang dapat Anda kecualikan sebelum mencapai WordPress.

Misalnya, saya perhatikan bahwa sekelompok bot mengakses situs saya dengan URL www.mywifequitherjob.com/some-article/www.facebook.com/like.php/… . Dan setiap kali, server saya akan memuat WordPress dan mengeluarkan respons 404.

Jadi alih-alih meminta WordPress menangani permintaan ini, saya menambahkan baris berikut ke file .htaccess saya

Tulis Ulang %{REQUEST_FILENAME} !-f
Tulis Ulang %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} www\.facebook\.com/plugins [NC]
Aturan Penulisan Ulang .* 404.html [L,R=404]

Pada baris di atas, saya meminta server web saya mencari "www.facebook.com/plugins" di URL dan segera mengeluarkan respons 404 tanpa memuat WordPress. Saat Anda membaca dengan teliti log Anda, Anda akan menemukan banyak akses nakal seperti yang saya jelaskan di atas. Tulis aturan .htaccess untuk masing-masing dan akses ini tidak akan lagi memuat server Anda.

Bot Memalu Tautan Komentar Saya

Ingat ketika saya memberi tahu Anda bahwa URL dengan parameter GET ditangani secara berbeda oleh plugin caching Anda? Saya menemukan bahwa ada banyak bot yang memalu artikel saya dengan set parameter "balas ke komentar".

Ketika ini terjadi (tergantung pada pengaturan caching Anda), wordpress dimuat dan file cache/zip disajikan meskipun mungkin tidak akan pernah diakses lagi. Ini adalah pemborosan sumber daya.

Contoh Diambil Dari Log Saya
12:01:11 /how-to-get-more-facebook-fans-with-a-facebook-reveal-tab-or-fan-gate/?replytocom=5972 No wp-cache file exists. Must generate a new one.
12:01:11 /how-to-get-more-facebook-fans-with-a-facebook-reveal-tab-or-fan-gate/?replytocom=5972 Gzipping buffer.

Solusinya adalah mengarahkan semua bot dan crawler dengan parameter GET ini ke halaman artikel utama. Berikut kode yang saya tambahkan ke file .htaccess saya.

RewriteCond %{QUERY_STRING} replytocom
RewriteCond %{HTTP_USER_AGENT} ^(.*)(bot|crawl|spider|slurp) [NC]
RewriteRule .* https://mywifequitherjob.com%{REQUEST_URI}? [L]

Kode ini mencari parameter GET “replytocom” dan kemudian menghapus parameter ini dari URL final sebelum menampilkan akses ke WordPress.

Crawler Mengakses Postingan Tanpa Garis Miring

Saya tidak yakin mengapa hal ini terjadi, tetapi saya melihat sekelompok webcrawler yang tampaknya secara sah mencoba mengakses artikel di blog saya tanpa garis miring di URL.

Seperti yang mungkin atau mungkin tidak Anda sadari, URL yang ditulis seperti http://bloganda.com/article/ berbeda dari URL yang ditulis seperti http://bloganda.com/artikel .

Akibatnya ketika URL tanpa garis miring ditemukan, WordPress harus masuk, menjalankan banyak kode PHP dan kemudian mengeluarkan 301 redirect ke artikel dengan garis miring. Untuk mengambil gambar WordPress, Anda cukup memasukkan aturan berikut di file .htaccess Anda.

# Tambahkan garis miring
Tulis Ulang %{REQUEST_FILENAME} !-f
Tulis Ulang %{REQUEST_URI} !(.*)/$
Tulis Ulang %{QUERY_STRING} !.*=.*
Aturan Penulisan Ulang ^(.*)$ $1/ [L,R=301]

Dengan menambahkan garis miring, Anda mengeluarkan 301 redirect ke URL yang benar sebelum membuatnya ke WordPress yang akan menghemat sumber daya CPU.

Saya Menemukan Bug Di WP Super Cache

Tidak seperti kebanyakan orang, saya tidak menginstal blog WordPress saya di root direktori public_html saya. Selain itu, halaman depan blog saya juga bukan halaman “postingan” saya. Ketika blog Anda dikonfigurasi dengan cara yang sama seperti yang saya lakukan, ada bug di WP Super Cache di mana semua file cache Anda bisa terhapus sebelum waktunya bahkan jika Anda memuat cache terlebih dahulu.

Saya tidak yakin apakah pembuat plugin mengetahui masalah ini, tetapi pada dasarnya saya menemukan bahwa setiap kali komentar spam dikeluarkan ke blog saya, seluruh cache saya akan salah dihapus. Karena saya mendapatkan komentar dan pelacakan spam sepanjang waktu, cache saya terus-menerus dikosongkan yang membuat cache menjadi kurang efisien.

Jadi saya menghabiskan akhir pekan untuk men-debug masalah ini dan akhirnya mengembangkan solusi. Jika ada di antara Anda yang mengalami masalah yang sama, beri tahu saya dan saya akan menunjukkan perbaikan saya. Moral dari cerita di sini adalah untuk tidak pernah berasumsi bahwa plugin caching Anda hanya berfungsi. Anda perlu melihat log!

Nonaktifkan Plugin Intensif CPU

Bahkan jika Anda telah mengikuti semua langkah saya di atas, tidak mungkin untuk menyaring semua akses nakal sebelum mereka mencapai blog WordPress Anda.

Oleh karena itu, Anda akan selalu menerima kunjungan ke situs Anda yang tidak ditangani secara efisien. Tidak ada jalan lain.

Tetapi yang penting untuk disadari adalah kemungkinan besar Anda tidak akan memiliki masalah bandwidth, Anda akan memiliki masalah CPU.

Akibatnya (dan ini mungkin berlawanan dengan intuisi), Anda sebenarnya tidak ingin melakukan apa pun yang intensif CPU seperti "memperkecil" atau "mengompresi" halaman Anda dengan cepat. Memperkecil dan kompresi membantu dengan bandwidth dengan mengorbankan penggunaan CPU.

Hal terakhir yang ingin Anda lakukan adalah mengecilkan dan menyimpan akses jahat. Bahkan, Anda mungkin harus mempertimbangkan untuk tidak mengecilkan atau mengompresi URL dengan parameter GET.

Yang terpenting, Anda tidak boleh menjalankan plugin intensif CPU di situs Anda. WP-Engine memiliki daftar besar plugin intensif CPU yang mungkin harus Anda coba hindari.

Saat saya membaca dengan teliti daftar plugin saya, saya perhatikan bahwa saya menggunakan plugin "pos serupa". Dan ketika saya melihat kode sumber, saya terkejut menemukan bahwa plugin melakukan perbandingan teks lengkap untuk menemukan artikel serupa yang merupakan penguras CPU utama dan tidak dapat diskalakan.

Segera setelah saya menemukan pengganti yang cocok, plugin ini pasti akan dibuang ke tempat sampah.

Pesan moral dalam cerita

Hanya karena tes kecepatan online memberi tahu Anda bahwa blog Anda cepat tidak terlalu berarti dalam skema besar.

Jangan salah paham. Kecepatan memuat halaman penting untuk mesin pencari dan untuk pelanggan reguler Anda, tetapi Anda juga harus memperhitungkan akses jahat yang dapat melewati cache Anda dan membuat server Anda bertekuk lutut.

Jadi jangan hanya menginstal caching dan plugin speedup lainnya secara membabi buta. Luangkan waktu untuk menganalisis lalu lintas Anda dan tulis aturan .htaccess sebanyak mungkin untuk meminimalkan pekerjaan yang harus dilakukan WordPress. Semoga beruntung!