Konfigurasi Cookieless, Subdomain Pengelola File Statis WordPress dengan Nginx

Prevalensi HTTP/2

Sebelum memulai, sedikit penjelasan mengenai prevalensi lalu lintas HTTP/2, teknik ini termasuk metode yang cukup kontroversial. Hal-hal berikut ini adalah yang perlu anda perhatikan tentang konfigurasi domain terpisah untuk file statis:

  • Metode Ini akan mengurangi muatan data yang dikirim ke server dalam koneksi HTTP/1, sehingga lalu lintas komunikasi web server akan meningkat
  • Pengunjung dengan akses jalur HTTP/2 akan mendominasi
  • Konfigurasi domain terpisah sebagai pengelola file statis akan menghasilkan pencarian DNS tambahan
  • Anda harus menggunakan sertifikat SSL tunggal (atau wildcard yang juga dapat digunakan untuk root domain) untuk subdomain pengelola file statis
  • Akses dengan jalur HTTP/2 memiliki fitur header kompresi dan sebenarnya tidak terlalu membutuhkan konfigurasi ini, tapi sebelum membatalkan rencana melakukan Konfigurasi Cookieless Subdomain Pengelola File Statis WordPress dengan Nginx, sebaiknya lanjutkan dulu membaca

Setiap situs web (khususnya yang berbasis php, seperti situs dengan penggunaan WordPress sebagai CMS) seharusnya menggunakan konfigurasi cookie-less/domain terpisah untuk pengelolaan file statis jika berencana menggunakan CDN atau jika telah menggunakan tapi:

  • CDN yang digunakan memperkenalkan kenaikan TTFB terlalu tinggi untuk halaman yang tidak di-cache. Ini berarti situs tidak dapat meletakkan CDN di root domain utama/halaman PHP.
  • CDN yang digunakan tidak memungkinkan untuk membuat rute akses file secara khusus untuk file statis. Contoh: Cloudflare dapat melayani segalanya melalui servernya, tetapi KeyCDN membutuhkan subdomain yang harus disiapkan.

Konsekuensi lainnya, metode ini menambah kebutuhan pencarian DNS dan mengurangi permintaan HTTP/2 multiplexing, jika pilihan penggabungan tidak tersedia. Pengurangan multiplexing akan berdampak:

  • Untuk browser Safari, Safari tidak meminta multiplexing di antara host yang berbeda
  • Penggunaan sertifikat SSL yang berbeda antara root domain dan domain statis (contoh: Saat menggunakan CDN atau kasus lain ketika sertifikat sama sekali tidak sama, akan ada notifikasi “DNS and certs do not agree”).

Konfigurasi Cookieless untuk file statis WordPress memastikan pengelolaan cache yang lebih baik dari situs web. Cara kerja dari konfigurasi ini antara lain ialah:

  • Situs web akan beroperasi di root domain www.example.com/example.com. WordPress akan menetapkan cookie pada level itu dan bukan untuk domain secara keseluruhan.
  • Folder untuk aset file (Javascript, gambar, file CSS) akan dihosting di subdomain statis.example.com. Dengan cara ini, cookie WordPress tidak akan berlaku untuk file-file itu.

Menggunakan domain tanpa cooki membuat file statis menjadi lebih baik di-cache oleh browser dan jaringan pengiriman konten. Persyaratan yang jelas adalah bahwa URL situs WordPress Anda harus dikonfigurasi dengan awalan www , yaitu: https://www.example.com akan menjadi URL Situs Anda.

Penambahan block server Nginx

Anda perlu mengonfigurasi blok server untuk subdomain statis situs web Anda. Kemudian cukup arahkan root dokumennya ke wp-content dari instalasi WordPress Anda. Konfigurasi boilerplate berikut adalah titik awal yang baik. Sesuaikan seperlunya:

server {

    listen 8080; 
    listen [::]:8080; 

    server_name static.example.com;

    root /var/www/html/blog/wp-content;

    # Disallow access to any PHP files. We only serve static files here
    location ~ \.php$ {
        return 403;
    }

    etag off;

    add_header Expires "Thu, 31 Dec 2037 23:55:55 GMT";
    add_header Cache-Control "public, max-age=315360000";

    # Allow WordPress to access fonts and other assets from the static subdomain
    location ~* \.(eot|otf|ttf|woff|woff2|cur|gif|ico|jpg|jpeg||png|svgz|webp)$ {
        add_header Access-Control-Allow-Origin "https://www.example.com";
        add_header Expires "Thu, 31 Dec 2037 23:55:55 GMT";
        add_header Cache-Control "public, max-age=315360000";   
    }
}

Perhatikan bahwa kami telah menonaktifkan pembuatan ETag untuk file statis. Benar-benar tidak ada yang salah dengan ETag di nginx. Nginx tidak termasuk inode dalam nilai ETag, hanya ukuran file dan waktu mod, sehingga aman di lingkungan multi-server.

Namun, kami memilih untuk memvalidasi file statis dengan nilai tajuk yang Last-Modified .

Kami mengatur waktu kedaluwarsa ke maksimum. Di sana, kami juga telah membahas praktik terbaik tajuk Expires jauh di masa depan. Dan kami cukup mengurangi ukuran header HTTP kami dengan menghilangkan ETags dari respons.

Seseorang mungkin bertanya-tanya mengapa kita mengandalkan direktif add_header ketika kita bisa menggunakan expires max; . Kami melakukannya dengan cara ini untuk memastikan bahwa kata kunci publicdimasukkan ke header Cache-Control . Ini menandai file-file yang akan di-cache lebih baik oleh server proxy.

Kami juga mengulangi arahan add_header kami untuk menangani perangkap konfigurasi umum warisannya. 
Jika Anda peduli dengan browser lama yang hanya mampu HTTP / 1.0, maka Anda juga akan menyertakan add_header "Pragma" "public"; ke banyak orang.

Tapi itu tidak berakhir di sana. Mari kita tinjau beberapa langkah yang perlu.

Buat perubahan pada kode pelacakan Google Analytics

Kemungkinannya adalah, Anda menggunakan Google Analytics untuk melacak statistik pengunjung situs web Anda.Google Analytics secara default akan membuat cookie yang terikat ke domain Anda dan semua subdomainnya.Anda perlu menyesuaikan kode Javascript pelacakan Anda untuk memperbaikinya. Kami akan memberi tahu Google Analytics untuk menggunakan cookie yang hanya berlaku untuk domain www WordPress:

Ubah ga('create', 'UA-XXXXXXXX-X', 'auto'); to ga('create', 'UA-XXXXXXXX-X', 'static.example.com'); .

Terapkan SSL untuk domain statis

Subdomain statis membutuhkan SSL, sama dengan domain induk Anda. Kami merekomendasikan untuk menggunakan LetsEncrypt untuk pekerjaan itu. Setelah Anda memilikinya, mudah untuk menghasilkan sertifikat SSL dengan perintah satu baris. Anda dapat melangkah lebih jauh dan menghasilkan satu sertifikat yang berlaku untuk subdomain www dan statis :

certbot-auto certonly --webroot \
  -w /var/www/html/ -d example.com -d www.example.com \
  -w /var/www/html/wp-content/ -d static.example.com 

Ini menciptakan satu sertifikat SSL yang akan Anda gunakan pada www dan statis .

Kami sekarang akan menyesuaikan kedua blok server nginx untuk memasukkan konfigurasi SSL:

server {

    listen 443 ssl http2; 
    listen [::]:443 ssl http2; 
    ssl_certificate      /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key  /etc/letsencrypt/live/example.com/privkey.pem;
    ...
}

Penyesuaian domain cookiee WordPress

Buka wp-config.php dan letakkan di bawah membuka <?php tag:

define("COOKIE_DOMAIN", "www.example.com");

Ini memberi tahu WordPress bahwa kami tidak ingin cookie terikat ke semua subdomain, hanya ke www .

Sekarang saatnya membuat WordPress benar-benar menggunakan subdomain statis kami untuk tujuan yang baik. Kami ingin file statis, yaitu file javascript, gambar, dan seterusnya untuk ditautkan sebagai https://example.com/example.jpg alih-alih domain utama. Bagaimana kita mendekati ini? Ada lebih dari beberapa cara untuk mencapai ini. Pilih cara yang paling tepat untuk Anda.

Opsi #1. Cara default WordPress untuk perubahan tautan file statis

Kami dapat menginstruksikan WordPress untuk menautkan semua file statis dari wp-content menggunakan subdomain statis kami. Selain itu kami dapat “mempersingkat” URL kami sedikit dengan menyediakan URL direktori plugin.

Buka wp-config.php dan letakkan di bawah membuka <?php tag:

define("WP_CONTENT_URL", "https://static.example.com"); 
define("WP_PLUGIN_URL", "https://static.example.com/plugins");

Sesuaikan URL wp-content yang ada untuk ditautkan ke subdomain statis

Aku harus jujur ​​padamu. Saya tidak suka WordPress karena menyimpan URL absolut di seluruh basis datanya. Itu membuat mengubah URL menjadi tugas yang rumit untuk dihadapi. Tetapi kita dapat menggunakan alat baris perintah WP-CLI yang sangat baik untuk mengatasi kegagalan desain ini 🙂

wp search-replace 'https://www.example.com/wp-content/uploads/' 'https://static.example.com/uploads/'

Sekarang situs web Anda akan memiliki semua gambar dan aset plugin yang ditautkan dari static.example.com.

Opsi #2. Penggunaan Plugin

Anda mungkin memperhatikan bahwa kami mengubah URL hanya menjadi wp-content . Tetapi ada cukup banyak file yang biasanya ditautkan dari wp-includes . Itu masih akan ditautkan dari domain utama jika kita tetap pada opsi # 1.

Kami dapat memperbaiki tautan ulang sebanyak mungkin file statis (termasuk wp-content – wp-includes dan wp-includes ) dengan menggunakan plugin CDN Enabler . Ini akan menulis ulang setiap tautan ke file non-PHP ke nama domain tertentu, dan itu tidak terbatas pada wp-content . Jika Anda menggunakannya, Anda harus menyesuaikan root dokumen dari blok server nginx statis agar sesuai dengan domain utama.

Menggunakan plugin memerlukan sedikit lebih banyak memuat ke server Anda, karena harus buffer seluruh halaman dan mengganti konten dalam HTML.

Opsi #3. ngx_pagespeed

Secara pribadi, saya benci melihat tautan wp-content/uploads jadi saya mencoba menggabungkan beberapa pendekatan menjadi solusi terbaik.

Kami mengelola repositori CentOS untuk ngx_pagespeed plugin untuk nginx. Ini memiliki fitur untuk menulis ulang tautan aset yang ditemukan dalam HTML ke apa pun yang kita inginkan. Inilah cara kami mendekati ini:

pagespeed MapRewriteDomain https://static.example.com/ https://www.example.com/;

Sekarang buat tautan simbolik dari ./wp-content/wp-includes ke ./wp-includes (ingat, blok server statis memiliki root yang mengarah ke konten-wp).

Konfigurasi WordPress dari opsi # 1 sudah akan menampilkan semua tautan wp-content dari subdomain statis .

Sekarang ngx_pagespeed akan mengambil HTML yang dihasilkan dan memperbaiki semua aset wp-includesdengan menempatkannya di bawah subdomain statis kami juga.

Saya cukup senang dengan pendekatan ini karena memungkinkan untuk mempersingkat tautan WordPress dan masih memiliki sebagian besar file statis yang terhubung dengan benar untuk kedua direktori yang dimaksud.

Masalah yang umum ditemui pada konfigurasi cookieless, pengelolaan file statis WordPress dengan subdomain pada nginx server

  • Plugin yang memiliki akses terhadap pengelolaan file statis WordPress seperti, FIG (Featured Image Generator), Autoptimize, atau W3TC tidak tahu bagaimana menangani aset secara optimal dari konfigurasi subdomain untuk pengelolaan file statis
  • Penghapusan string kueri (hack functions.php ) mungkin berhenti bekerja untuk Anda. Deteksi kesalahan link file dengan cek inspect elemen, kemudian sesuaikan dengan penulisan link di file functions tema

Mau punya Tema WordPress unik ?, atau punya desain kesukaan yang ingin dibuat menjadi Tema WordPress ?

Pesan Jasa Desain Tema Wordpress Sekarang

Berikan tanggapan

This site uses Akismet to reduce spam. Learn how your comment data is processed.