Panduan Tingkat Lanjut untuk Mengoptimalkan Kinerja WordPress

Saat ini, WordPress menguasai lebih dari 30% Internet. Sangat mudah digunakan, sangat populer, dan tidak akan kemana-mana dalam waktu dekat.

Tapi WordPress bisa lambat. Lalu bagaimana cara mengoptimalkannya?

Ada banyak artikel tentang cara menyetel dan mengoptimalkan WordPress. Faktanya, WordPress sendiri menyediakan panduan yang kuat tentang optimasi WordPress.

Untuk sebagian besar, artikel dan tutorial ini mencakup konsep yang cukup mendasar namun bermanfaat, seperti menggunakan plugin cache, berintegrasi dengan jaringan pengiriman konten (CDN), dan meminimalkan permintaan. Meskipun tips ini sangat efektif dan bahkan perlu, pada akhirnya, tips ini tidak mengatasi masalah mendasar: Sebagian besar situs WordPress yang lambat adalah akibat dari kode yang buruk atau tidak efisien.

Oleh karena itu, artikel ini terutama ditujukan untuk memberikan beberapa panduan kepada pengembang dan perusahaan pengembang WordPress yang dapat membantu mereka mengatasi penyebab mendasar dari banyak masalah kinerja WordPress.

WordPress menyediakan banyak fitur berorientasi kinerja yang sering diabaikan oleh pengembang. Kode yang tidak memanfaatkan fitur ini dapat memperlambat tugas paling sederhana , seperti mengambil kiriman. Artikel ini merinci empat kemungkinan solusi, yang mengatasi beberapa masalah mendasar di balik kinerja WordPress yang lambat.

Mengambil Postingan

WordPress menawarkan kemungkinan mengambil segala jenis posting dari database. Ada tiga cara dasar untuk melakukannya:

• Menggunakan fungsi query_posts() : Ini adalah pendekatan yang sangat langsung, tetapi masalahnya adalah bahwa itu menimpa kueri utama, yang dapat menyebabkan ketidaknyamanan. Misalnya, ini bisa menjadi masalah jika kita ingin menentukan, di beberapa titik setelah mengambil posting (seperti di dalam footer.php ), halaman seperti apa yang kita hadapi. Faktanya, dokumentasi resmi memiliki catatan yang merekomendasikan penggunaan fungsi ini karena Anda perlu memanggil fungsi tambahan untuk mengembalikan kueri asli. Selain itu, mengganti kueri utama akan berdampak negatif pada waktu pemuatan halaman.

• Menggunakan fungsi get_posts() : Ini bekerja hampir seperti query_posts() , tetapi tidak mengubah kueri utama. Di sisi lain, get_posts() secara default melakukan kueri dengan parameter suppress_filters disetel ke true . Hal ini dapat menyebabkan inkonsistensi, terutama jika kami menggunakan filter terkait kueri dalam kode kami, karena postingan yang tidak Anda harapkan di halaman dapat dikembalikan oleh fungsi ini.

• Menggunakan kelas WP_Query : Menurut pendapat saya, ini adalah cara terbaik untuk mengambil posting dari database. Itu tidak mengubah kueri utama, dan dijalankan dengan cara standarnya, sama seperti kueri WordPress lainnya.

Tetapi metode apa pun yang kita gunakan untuk berinteraksi dengan database, ada hal lain yang perlu kita pertimbangkan.

Membatasi Permintaan

Kita harus selalu menentukan berapa banyak posting yang harus diambil oleh kueri kita.

Untuk mencapai itu, kami menggunakan parameter posts_per_page .

WordPress memungkinkan kami menunjukkan -1 sebagai nilai yang mungkin untuk parameter itu, dalam hal ini sistem akan mencoba mengambil semua posting yang memenuhi kondisi yang ditentukan.

Ini bukan praktik yang baik, bahkan jika kami yakin bahwa kami hanya akan mendapatkan beberapa hasil sebagai tanggapan.

Untuk satu, kita jarang bisa yakin hanya mendapatkan beberapa hasil kembali. Dan bahkan jika kita bisa, menyetel tanpa batas akan membutuhkan mesin database untuk memindai seluruh database mencari kecocokan.

Sebaliknya, membatasi hasil seringkali memungkinkan mesin database hanya memindai sebagian data, yang berarti waktu pemrosesan yang lebih sedikit dan respons yang lebih cepat.

Hal lain yang dilakukan WordPress secara default, yang dapat berdampak buruk pada kinerja, adalah mencoba membawa posting yang lengket dan menghitung berapa banyak baris yang ditemukan pada kueri.

Namun, seringkali, kita tidak benar-benar membutuhkan informasi itu. Menambahkan dua parameter ini akan menonaktifkan fitur tersebut dan mempercepat kueri kami:

 $query = new WP_Query( array( 'ignore_sticky_posts' => true, 'no_found_rows' => true ) );

Tidak termasuk Postingan dari Query

Terkadang kami ingin mengecualikan postingan tertentu dari kueri. WordPress menawarkan cara yang cukup langsung untuk mencapainya: menggunakan parameter post__not_in . Sebagai contoh:

 $posts_to_exclude = array( 1, 2, 3 ); $posts_per_page = 10; $query = new WP_Query( array( 'posts_per_page' => $posts_per_page, 'post__not_in' => $posts_to_exclude ) ); for ( $i = 0; $i < count( $query->posts ); $i++ ) { //do stuff with $query->posts[ $i ] }

Tetapi meskipun ini cukup sederhana, itu tidak optimal karena secara internal menghasilkan subquery. Terutama di instalasi besar, ini dapat menyebabkan respons yang lambat. Lebih cepat membiarkan pemrosesan itu dilakukan oleh juru bahasa PHP dengan beberapa modifikasi sederhana:

 $posts_to_exclude = array( 1, 2, 3 ); $posts_per_page = 10; $query = new WP_Query( array( 'posts_per_page' => $posts_per_page + count( $posts_to_exclude ) ) ); for ( $i = 0; $i < count( $query->posts ) && $i < $posts_per_page; $i++ ) { if ( ! in_array( $query->posts[ $i ]->ID, $posts_to_exclude ) ) { //do stuff with $query->posts[ $i ] } }

Apa yang saya lakukan di sana?

Pada dasarnya, saya melepas beberapa pekerjaan dari mesin database dan menyerahkannya ke mesin PHP, yang melakukan hal yang sama tetapi di memori, yang jauh lebih cepat.

Bagaimana?

Pertama, saya menghapus parameter post__not_in dari kueri.

Karena kueri dapat memberi kita beberapa posting yang tidak kita inginkan sebagai hasilnya, saya meningkatkan parameter posts_per_page . Dengan cara itu saya memastikan bahwa, bahkan jika saya memiliki beberapa posting yang tidak diinginkan dalam tanggapan saya, saya akan memiliki setidaknya $posts_per_page posting yang diinginkan di sana.

Kemudian, ketika saya mengulang posting, saya hanya memproses yang tidak ada di dalam array $posts_to_exclude .

Menghindari Parameterisasi Kompleks

Semua metode kueri ini menawarkan berbagai kemungkinan untuk mengambil kiriman: menurut kategori, menurut kunci meta atau nilai, menurut tanggal, menurut penulis, dll.

Dan sementara fleksibilitas itu adalah fitur yang kuat, itu harus digunakan dengan hati-hati karena parametrisasi itu dapat diterjemahkan ke dalam penggabungan tabel yang kompleks dan operasi database yang mahal.

Di bagian berikutnya, kami akan menguraikan cara elegan untuk tetap mencapai fungsionalitas serupa tanpa mengorbankan kinerja.

Memaksakan Pilihan WordPress Secara Maksimal

WordPress Options API menyediakan serangkaian alat untuk memuat atau menyimpan data dengan mudah. Ini berguna untuk menangani informasi kecil, yang mekanisme lain yang ditawarkan WordPress (seperti posting atau taksonomi) terlalu rumit.

Misalnya, jika kita ingin menyimpan kunci autentikasi atau warna latar belakang header situs kita, opsi adalah yang kita cari.

WordPress tidak hanya memberi kita fungsi untuk menanganinya, tetapi juga memungkinkan kita melakukannya dengan cara yang paling efisien.

Beberapa opsi bahkan dimuat langsung saat sistem dimulai, sehingga memberi kami akses yang lebih cepat (saat membuat opsi baru, kami perlu mempertimbangkan apakah kami ingin memuatnya secara otomatis atau tidak).

Pertimbangkan, misalnya, sebuah situs tempat kami memiliki korsel yang menampilkan berita terkini yang ditentukan di bagian belakang. Naluri pertama kami adalah menggunakan kunci meta untuk itu sebagai berikut:

 // functions.php add_action( 'save_post', function ( $post_id ) { // For simplicity, we do not include all the required validation before saving // the meta key: checking nonces, checking post type and status, checking // it is not a revision or an autosaving, etc. update_post_meta( $post_id, 'is_breaking_news', ! empty ( $_POST['is_breaking_news'] ) ); } ); // front-page.php $query = new WP_Query( array( 'posts_per_page' => 1, 'meta_key' => 'is_breaking_news' ) ); $breaking_news = $query->posts[0] ?: NULL;

Seperti yang Anda lihat, pendekatan ini sangat sederhana, tetapi tidak optimal. Ini akan melakukan kueri basis data yang mencoba menemukan posting dengan kunci meta tertentu. Kami dapat menggunakan opsi untuk mencapai hasil yang serupa:

 // functions.php add_action( 'save_post', function ( $post_id ) { // Same comment for post validation if ( ! empty ( $_POST['is_breaking_news'] ) ) update_option( 'breaking_news_id', $post_id ); } ); // front-page.php if ( $breaking_news_id = get_option( 'breaking_news_id' ) ) $breaking_news = get_post( $breaking_news_id ); else $breaking_news = NULL;

Fungsionalitasnya sedikit berbeda dari satu contoh ke contoh lainnya.

Di bagian pertama kode, kami akan selalu mendapatkan berita terbaru, dalam hal tanggal publikasi posting.

Yang kedua, setiap kali posting baru ditetapkan sebagai berita terbaru, itu akan menimpa berita terbaru sebelumnya.

Tetapi karena kami mungkin ingin satu posting berita terkini pada satu waktu, itu seharusnya tidak menjadi masalah.

Dan, pada akhirnya, kami mengubah kueri basis data yang berat (menggunakan WP_Query dengan kunci meta) menjadi kueri sederhana dan langsung (memanggil get_post() ) yang merupakan pendekatan yang lebih baik dan berkinerja lebih baik.

Kami juga dapat membuat perubahan kecil, dan menggunakan transien alih-alih opsi.

Transien bekerja dengan cara yang sama tetapi memungkinkan kami untuk menentukan waktu kedaluwarsa.

Misalnya untuk berita terkini, pas seperti sarung tangan karena kita tidak ingin postingan lama sebagai berita terbaru, dan jika kita menyerahkan tugas mengubah atau menghilangkan berita terbaru itu kepada administrator, dia bisa lupa untuk melakukannya dia. Jadi, dengan dua perubahan sederhana, kami menambahkan tanggal kedaluwarsa:

 // functions.php add_action( 'save_post', function ( $post_id ) { // Same comment for post validation // Let's say we want that breaking news for one hour // (3600 = # of seconds in an hour). if ( ! empty ( $_POST['is_breaking_news'] ) ) set_transient( 'breaking_news_id', $post_id, 3600 ); } ); // front-page.php if ( $breaking_news_id = get_transient( 'breaking_news_id' ) ) $breaking_news = get_post( $breaking_news_id ); else $breaking_news = NULL;

Aktifkan Caching Persisten

WordPress secara native memiliki mekanisme caching objek.

Opsi, misalnya, di-cache menggunakan mekanisme itu.

Tapi, secara default, caching itu tidak persisten, artinya caching hanya hidup selama satu permintaan. Semua data di-cache dalam memori, untuk akses yang lebih cepat, tetapi hanya tersedia selama permintaan itu.

Mendukung caching persisten memerlukan penginstalan plugin cache persisten.

Beberapa plugin cache satu halaman penuh dilengkapi dengan plugin cache persisten yang disertakan (misalnya W3 Total Cache), tetapi yang lain tidak, dan kita perlu menginstalnya secara terpisah.

Itu akan tergantung pada arsitektur platform kami, apakah kami akan menggunakan file, Memcached atau mekanisme lain untuk menyimpan data yang di-cache, tetapi kami harus memanfaatkan fitur luar biasa ini.

Orang mungkin bertanya: “Jika ini adalah fitur yang hebat, mengapa WordPress tidak mengaktifkannya secara default”?

Alasan utamanya adalah, tergantung pada arsitektur platform kami, beberapa teknik cache akan berfungsi dan yang lainnya tidak.

Jika kami meng-host situs kami di server terdistribusi kami, misalnya, kami harus menggunakan sistem cache eksternal, (seperti server Memcached), tetapi jika situs web kami berada di satu server, kami dapat menghemat uang hanya dengan menggunakan sistem file untuk menyimpan.

Satu hal yang perlu kita perhitungkan adalah kedaluwarsa cache. Ini adalah jebakan paling umum dalam bekerja dengan caching persisten.

Jika kami tidak mengatasi masalah ini dengan benar, pengguna kami akan mengeluh bahwa mereka tidak akan melihat perubahan yang telah mereka buat atau bahwa perubahan mereka terlalu lama diterapkan.

Kadang-kadang kita akan menemukan diri kita membuat kompromi antara kinerja dan dinamisme, tetapi bahkan dengan hambatan itu, caching terus-menerus adalah sesuatu yang hampir setiap instalasi WordPress harus memanfaatkannya.

AJAX dengan Cara Tercepat

Jika kita perlu berkomunikasi melalui AJAX dengan situs web kita, WordPress menawarkan beberapa abstraksi pada saat memproses permintaan di sisi server.

Meskipun teknik tersebut dapat digunakan saat memprogram alat back-end atau pengiriman formulir dari front-end, teknik tersebut harus dihindari jika tidak benar-benar diperlukan.

Alasannya adalah untuk menggunakan mekanisme tersebut, kita diwajibkan untuk membuat permintaan posting ke beberapa file yang terletak di dalam folder wp-admin . Mayoritas (jika tidak semua) plugin caching halaman penuh WordPress tidak menyimpan permintaan posting cache atau panggilan ke file administrator.

Misalnya, jika kita secara dinamis memuat lebih banyak posting saat pengguna menggulir beranda kita, akan lebih baik untuk langsung memanggil beberapa halaman front-end lainnya, yang akan mendapatkan manfaat dari cache.

Kami kemudian dapat mengurai hasil melalui JavaScript di browser.

Ya, kami mengirim lebih banyak data daripada yang diperlukan, tetapi kami unggul dalam hal kecepatan pemrosesan dan waktu respons.

Hancurkan Gagasan Bahwa WordPress Hanya Lambat

Ini hanya beberapa saran yang harus dipertimbangkan pengembang saat membuat kode untuk WordPress.

Terkadang, kita lupa bahwa plugin atau tema kita mungkin perlu hidup bersama dengan plugin lain, atau bahwa situs kita mungkin dilayani oleh perusahaan hosting yang melayani ratusan atau ribuan situs lain dengan database yang sama.

Kami hanya fokus pada bagaimana plugin harus berfungsi dan bukan pada bagaimana ia menangani fungsi itu, atau bagaimana melakukannya dengan cara yang efisien.

Dari penjelasan di atas, jelas bahwa akar penyebab kinerja yang buruk di WordPress adalah kode yang buruk dan tidak efisien. Namun, WordPress menyediakan semua fungsi yang diperlukan melalui berbagai API-nya yang dapat membantu kami membangun lebih banyak plugin dan tema yang berkinerja lebih baik tanpa mengurangi kecepatan platform secara keseluruhan.