เพิ่มความเร็ว WordPress ด้วย Varnish Cache

เพิ่มความเร็ว WordPress ด้วย Varnish

เพิ่มความเร็ว ให้ WordPress ด้วย การ Enable Varnish Cache บน WordPress Server พร้อมการตั้งค่าเพื่อใช้งาน Varnish Cache บน W3 Total Cache

จากซีรี่ส์ เพิ่มความเร็ว WordPress ทั้งหมด 3 ตอน

  1. Redis: เพิ่มความเร็ว WordPress ด้วย Redis
  2. CDN: เพิ่มความเร็ว WordPress ด้วย CDN
  3. Database: เพิ่มความเร็ว WordPress ด้วย Database

ผมพบว่าทั้ง 3 ตอน ยังขาดเรื่องสำคัญเรื่องหนึ่งคือเรื่อง เพิ่มความเร็ว WordPress ด้วย Varnish Cache รวมทั้งการปรับแต่ง W3 Total Cache เพื่อการใช้งานจริง เช่น การปรับแต่ง Minify เพื่อลดเวลาในการโหลดเว็บหน้าแรก (Home page)

Varnish Cache

ต้องขอสารภาพว่า ถ้าวัดด้วยความรู้สึก ผมไม่รู้สึกถึงความต่าง ระหว่างก่อนทำ และหลังทำ Varnish Cache ผมเลยต้องใช้ตัววัดจาก loader.io และผลที่วัดออกมาสร้างความประหลาดใจพอสมควร

ถ้าต้องการวัดแบบ Real-time ขอแนะนำ cronitor.io

ผลจากการทำ Varnish Cache

ผมได้วัดค่าเก็บเอาไว้ ทั้งแบบก่อนทำ Varnish Cache และหลังทำ จะเห็นว่าก่อนทำ Varnish Cache มี Response Time ที่ค่อนข้างสูง 1486 ms ผมใช้บริการของ loader.io ในการจำลองสถานการณ์ว่า ถ้ามีผู้ใช้งานเว็บไซต์ 250 คน ใช้งานพร้อมกันในช่วง 30 วินาที จะส่งผลต่อ Response Time อย่างไร ดังรูปที่แสดง

ก่อนทำ Varnish Cache
Before Varnish Cache

เปรียบเทียบ Response Time หลังทำ Varnish Cache ลดลงจาก 1486 ms (millisecond) เหลือ 443 ms ซึ่งลดลงอย่างเป็นสาระสำคัญ

After Varnish Before Purge Cache
After Varnish Before Purge Cache

หลัง Purge ด้วย W3 Total Cache ความเร็วเพิ่มขึ้นเล็กน้อย ซึ่งอยู่ในเกณฑ์ที่ดีครับ

ให้สังเกตกราฟ ตรงเส้นสีฟ้าแสดงถึง Response Time เป็นเส้นตรง ความหมายคือ มันตอบสนองต่อผู้ใช้งานเว็บไซต์ในความเร็วที่เท่ากัน ไม่ว่าจะมีผู้ใช้งานเว็บไซต์มากหรือน้อยแค่ไหน

ตรงเส้นกราฟสีเขียวอ่อน แสดงให้เห็นว่าแต่ละช่วงเวลามีจำนวนผู้ใช้งานขึ้นลงไม่เท่ากัน แต่ Response Time กราฟเส้นสีฟ้า มันทำงานความเร็วเฉลี่ยเท่าเดิม

After Varnish After Purge
After Varnish After Purge

Enable Varnish

สภาพแวดล้อมในการทำงานจะเหมือนกับ ซีรี่ส์ เพิ่มความเร็ว WordPress ใน 3 ตอนแรกนะครับ คือ WordPress Instance จะอยู่บน Amazon Lightsail โดย Bitnami ซึ่งถ้าอ่านเอกสารบน docs.bitnami.com เขาแนะนำให้เช็คโครงสร้างไฟล์ก่อนว่าเป็นแบบ A หรือ B แต่ผมเข้าใจว่าถ้าเราติดตั้ง WordPress Instance ในวันนี้ โครงสร้างไฟล์จะเป็นแบบใหม่ทั้งหมด หรือแบบ B นั่นแหละครับ ซึ่ง Varnish scripts จะอยู่ที่

:: โครงสร้างไฟล์แบบ B
/opt/bitnami/varnish/scripts/ctl.sh.disabled

*** Batch Script ก็มี Comment นะ อ่านวิธีใส่ Comment ใน Bash/Shell


คำเตือน ห้ามแก้ไขสิทธิ์ในการเข้าถึงไฟล์ ctl.sh หรือห้ามใช้คำสั่งนี้

sudo chmod 666 path/to/ctl.sh

ถ้าต้องการแก้ไขไฟล์นี้ ให้แก้ด้วยคำสั่ง

sudo nano path/to/ctl.sh

บน SSH Terminal Browser เท่านั้น จากประสบการณ์ของผม ดูเหมือนไฟล์นี้จะไม่ทำงาน ถ้าเราแก้สิทธิ์การเข้าถึงไฟล์


Varnish ถูกติดตั้งไว้บน Apache (Web Server) แล้วนะครับ เราจึงไม่ต้องติดตั้ง เพียงแต่มัน Disable เอาไว้ เราแค่เอาคำว่า disabled ออกไปมันก็ใช้งานได้แล้วครับ ดังนี้

sudo mv /opt/bitnami/varnish/scripts/ctl.sh.disabled /opt/bitnami/varnish/scripts/ctl.sh

*** ก่อนเริ่มขั้นตอนถัดไป แนะนำให้ทำ Snapshot (backup) WordPress Instance

Start Varnish

เมื่อเรา Enable Varnish ตอนนี้ Varnish Script ได้เข้าไปอยู่ใน control script หรือ ctlscript.sh เรียบร้อยแล้ว เราสามารถสั่งให้มันทำงานผ่าน ctlscript.sh ดังนี้ครับ

sudo /opt/bitnami/ctlscript.sh start varnish

Disable PageSpeed

ตามคำแนะของ Bitnami เมื่อเราเลือกใช้งาน Varnish เราต้องปิดการทำงานของ PageSpeed บน Apache ดังนี้ครับ

  1. เปิดไฟล์ httpd.conf ด้วย Nano โดยพิมพ์คำสั่ง
sudo nano /opt/bitnami/apache2/conf/httpd.conf
  1. กดปุ่ม control + W เพื่อมองหาคำว่า pagespeed เราจะเห็น 2 บรรทัดนี้ครับ
Include conf/pagespeed.conf
Include conf/pagespeed_libraries.conf

ใส่เครื่องหมาย # ไว้ข้างหน้า Include เพื่อ Comment out

#Include conf/pagespeed.conf
#Include conf/pagespeed_libraries.conf

แค่นี้ครับ ตอนนี้ PageSpeed ก็ถูก Disabled เรียบร้อย

Disabled PageSpeed
Disabled PageSpeed

ลบ PageSpeed Cache ทิ้งทั้งหมด

  1. สร้างไฟล์ cache.flush เพื่อล้าง PageSpeed Cache ออกจาก Apache
sudo touch /opt/bitnami/apache2/var/cache/mod_pagespeed/cache.flush
  1. เสร็จแล้วรีสตาร์ท Apache ครับ
sudo /opt/bitnami/ctlscript.sh restart apache

Disable Varnish

ถ้าต้องการ Disable Varnish ให้ใช้คำสั่ง Stop Varnish ก่อนครับ

sudo /opt/bitnami/ctlscript.sh stop varnish

แล้วเติมคำว่า disabled ต่อท้ายไฟล์ /opt/bitnami/varnish/scripts/ctl.sh ดังนี้ครับ

sudo mv /opt/bitnami/varnish/scripts/ctl.sh /opt/bitnami/varnish/scripts/ctl.sh.disabled

แล้วรีสตาร์ท Apache Server

sudo /opt/bitnami/ctlscript.sh restart apache

ใช้ Varnish ร่วมกับ HTTPS

ในขณะที่ Varnish กำลังทำงานอยู่ ให้เปิดไฟล์ bitnami.conf ด้วยคำสั่ง

sudo nano /opt/bitnami/apache2/conf/bitnami/bitnami.conf

เติมโค้ดนี้เข้าไปใต้บรรทัด </Directory>ครับ

#Enable HTTPS for Varnish
ProxyPreserveHost On
RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}
ProxyPass "/"  "http://127.0.0.1:81/"
ProxyPassReverse "/"  "http://127.0.0.1:81/"
#Finished HTTPS for Varnish

ตามที่แสดงในรูปนี้

Use Varnish with SSL
Use Varnish with SSL

กลับไปเช็คไฟล์ wp-config.php ว่ามีการกำหนดค่า Domain Name ไว้อย่างไร ถ้ามันแสดงโค้ดแบบนี้

define('WP_SITEURL', 'https://' . $_SERVER['HTTP_HOST'] . '/');
define('WP_HOME', 'https://' . $_SERVER['HTTP_HOST'] . '/');

ให้เปลี่ยนเป็น

define('WP_SITEURL', 'https://www.your-domain.com/');
define('WP_HOME', 'https://www.your-domain.com/');

ก็จะได้ตามภาพครับ

Domain Name on wp-config.php
Domain Name on wp-config.php

เสร็จแล้วก็สั่งรีสตาร์ท Apache อีกครั้งครับ

ปรับแต่ง Varnish

การปรับแต่ง Varnish จะใช้ไฟล์นามสกุล vcl ซึ่งสามารถดาวน์โหลดได้ที่ Bitnami

หรือจากลิงค์นี้ก็ได้ครับ

wordpress.vcl

เมื่อดาวน์โหลดไฟล์มาแล้ว ให้อัพโหลดไฟล์ไปไว้ที่ root ของ Bitnami ด้วย FileZilla

ก่อนอื่นให้แบ็คอัพไฟล์ default.vcl ไว้ก่อนครับ ด้วยคำสั่ง

sudo cp /opt/bitnami/varnish/etc/varnish/default.vcl /opt/bitnami/varnish/etc/varnish/default.vcl.backup

แล้วคัดลอกไฟล์ wordpress.vcl ไปแทนที่ default.vcl ด้วยคำสั่ง

sudo cp wordpress.vcl /opt/bitnami/varnish/etc/varnish/default.vcl

ตอนนี้ไฟล์ที่ดาวน์โหลดมาจาก Bitnami ทำหน้าที่เป็นไฟล์หลัก หรือ Default

ถ้าในอนาคตเรามีไฟล์อื่น ๆ เช่น varnish-w3-config.vcl เราสามารถคัดลอกไปไว้ที่เดียวกัน แต่ไม่ต้องเปลี่ยนชื่อไฟล์นะครับ ด้วยคำสั่ง

sudo cp varnish-w3-config.vcl /opt/bitnami/varnish/etc/varnish/

*** ถ้าเราทำงานบน VSCode โฟลเดอร์ varnish จะอยู่ที่ stack นะครับ ตามรูปประกอบ

Varnish Folder
Varnish Folder

ทั้งนี้ไฟล์ default.vcl เขากำหนดพอร์ตมาเป็น 8080 ให้เราแก้เป็นพอร์ต 80 ครับ โดยสามารถเปิดไฟล์เข้าไปเปลี่ยนเป็น 80 ก็ได้ครับ หรือใช้คำสั่ง

sudo sed -i 's/port\s*=\s*"[^"]*"/port = "80"/g' /opt/bitnami/varnish/etc/varnish/default.vcl

เมื่อแก้ไขไฟล์เสร็จแล้ว ให้รีสตาร์ทเซิร์ฟเวอร์ได้เลย

วิธีสลับ *.vcl file

ถ้าเรามีไฟล์ *.vcl มากกว่า 1 ไฟล์เราสามารถสลับไฟล์ไปมาได้ เพื่อทดลองว่าแบบไหนให้ผลดีที่สุด โดยเราระบุไฟล์ที่ต้องการใช้ใน Varnish Script File ซึ่งอยู่ที่ /opt/bitnami/varnish/scripts/ctl.sh

*** ผมเคยแก้ไฟล์นี้ใน VSCode แล้วมันไม่ยอม พอผมเปลี่ยนสิทธิ์การเข้าถึง เป็น 666 ผมพบว่าไฟล์นี้ไม่ทำงานไปซะงั้น ดังนั้นให้แก้ไฟล์นี้ที่ SSH Teminal Browser เท่านั้นครับ

varnish script file
varnish script file

โดยถ้าไม่ปรับแก้อะไรเลย มันจะใช้ไฟล์ default.vcl แต่ถ้าเราต้องการใช้ไฟล์อื่น เราก็แค่ใส่ชื่อไฟล์เข้าไปครับ โดยเปลี่ยนจาก

VARNISH_CONFIG_FILE=/opt/bitnami/varnish/etc/varnish/default.vcl

เป็นชื่อไฟล์ที่ต้องการ ในที่นี้จะเป็น varnish-w3-config.vcl

VARNISH_CONFIG_FILE=/opt/bitnami/varnish/etc/varnish/varnish-w3-config.vcl

เมื่อแก้ไขไฟล์ Varnish Script เสร็จแล้ว ก็รีสตาร์ท Varnish และ Apache ครับ

sudo /opt/bitnami/ctlscript.sh restart varnish
sudo /opt/bitnami/ctlscript.sh restart apache

สรุป

การ เพิ่มความเร็ว WordPress ด้วย Varnish Cache มีขั้นตอนในการแก้ไขไฟล์ อยู่ 3 จุด

  1. Enable Varnish ให้ลบคำว่า disabled ที่ /opt/bitnami/varnish/scripts/ctl.sh.disabled
  2. Varnish with SSL ให้แก้ที่ไฟล์ /opt/bitnami/apache2/conf/bitnami/bitnami.conf
  3. ใช้ไฟล์ wordpress.vcl เพื่อปรับแต่ง Varnish ที่ /opt/bitnami/varnish/etc/varnish/default.vcl

ตามความเข้าใจของผม Proxy ควรมาอยู่ข้างหน้า WordPress Server แบบนี้ครับ

Users -> Proxy:80 -> WordPress:81 หรือ Port 8080

ดังนั้นเราต้องสลับพอร์ต โดยเอาพอร์ต 80 ให้ Varnish แล้ว WordPress เปลี่ยนไปใช้พอร์ต 81 หรือ 8080 แต่บทความนี้ไม่ได้ครอบคลุมถึงตรงนั้นนะครับ ขอติดค้างไว้ก่อน อย่างไรก็ตาม เมื่อวัดค่าด้วย loader.io มันก็เร็วขึ้นนะ

TODO: เขียนบทความเพิ่มเติมเรื่องการสลับพอร์ต


ปรับแต่ง W3 Total Cache

Varnish

ผมเข้าใจว่าการระบุ Reverse Proxy ใน W3 Total Cache ใช้ในกรณีที่เรานำ Proxy Server มาทำหน้าที่เป็น Web Server ด่านหน้า ตาม Flow นี้

Users -> Proxy Server :80 -> Web Server (WordPress):8080

ซึ่งเราต้องยก Port 80 ให้ Proxy แล้ว WordPress เปลี่ยนไปใช้ Port 8080 หรือ 81 แทน

หลักการทำงานของ Proxy

เมื่อมีผู้ใช้งานเว็บไซต์ จะเกิด Traffic ตรงไปที่ Proxy แล้ว Proxy จะไปดึงข้อมูลมาจาก WordPress Server เสร็จแล้วจะเก็บสำเนาไว้ เมื่อผู้ใช้งานเว็บไซต์ส่ง Traffic มาอีกครั้ง มันจะดูว่ามันมีสำเนามั๊ย ถ้ามีมันก็จะส่งสำเนากลับไปที่ผู้ใช้งานเว็บไซต์ แต่ถ้าไม่มี มันจะไปดึงข้อมูลมาจาก WordPress Server แล้วทำสำเนาทุกครั้ง พอนาน ๆ ไป มันจะมีข้อมูลครบ มันก็จะไปดึงข้อมูลจาก WordPress Server น้อยลง ทำให้ลดภาระงานของ WordPress เว็บไซต์จึงเร็วขึ้น

แต่บทความนี้ยังไปไม่ถึงตรงนั้นครับ ขอค้างไว้ก่อน

สำหรับกรณีของผม ผมยังใช้เว็บเซิร์ฟเวอร์จริง (WordPress) บน Port 80 และตั้งค่าให้มันทำ Varnish Caching บน Port 81 ผมจึงไม่ได้ระบุค่าใด ๆ ใน W3 Total Cache/Reverse Proxy

Users -> Web Server (WordPress):80 -> Proxy Server:81

ดังนั้นปล่อยว่างเอาไว้แบบนี้ครับ

Reverse Proxy Configuration
Reverse Proxy Configuration

Database Cache

ผมได้ลอง Enable ทั้ง Database Cache (2) และ Object Cache (3) ผมพบ Error ในส่วนของ Object Cache เพราะมันทำงานซ้ำซ้อนกับปลั๊กอิน Redis Object Cache (ดู เพิ่มความเร็ว WordPress ด้วย Redis เพิ่มเติม)

Try Enable Both
Try Enable Both

มันฟ้องว่าทำงานซ้ำซ้อนกับไฟล์ object-cache.php

Object Cache Error
Object Cache Error

เมื่อไปเปิดดูไฟล์ object-cache.php ก็พบว่ามันถูกสร้างโดยปลั๊กอิน Redis Object Cache ดังนั้นก็ปล่อยให้มันทำงานไปครับ ไม่ต้อง Enable Object Cache บน W3 Total Cache ครับ

object-cache.php
object-cache.php

ตั้งค่า Database Cache

เมื่อเรา Enable Database Cache เราก็ต้องไปตั้งค่าที่ Database Cache Section

  1. ไปที่ Performance
  2. เลือกแถบ Database Cache
  3. ใส่ Redis servers ซึ่งสามารถใส่ได้หลาย Address นะครับ คั่นด้วยเครื่องหมาย comma เช่น 127.0.0.1:6379, redis.your-domain.local:6379, redis.your-domain.com:6379
  4. ลองกดปุ่ม Test ดูครับ

หมายเหตุ:

  • สำหรับคนที่ติดตั้ง Redis Server บน WordPress Server ก็ใช้ 127.0.0.1:6379
  • หรือคนที่สร้าง Redis บน Amazon Lightsail จะได้ redis.your-domain.local:6379
  • หากสร้างบน AWS ElastiCache ก็อาจจะได้เป็น redis.your-domain.com:6379

ในกรณีนี้ผมสร้าง Redis บน Lightsail จะได้ตามรูปครับ


Minify

General Settings (1)

จากการทดสอบคิดว่า การ Enable Minify ส่งผลให้เว็บไซต์ทำงานเร็วขึ้น ก่อนอื่นให้คลิ๊กตรง General Settings (1) ก่อนครับ

W3 Total Cache Menu
W3 Total Cache Menu

เมื่อเข้ามาที่หน้าจอ General Settings ให้ Scroll หา Minify

ติ๊กตรง Enable แล้วเลือก Minify mode เป็นแบบ Manual

ตรง Minify Cache Method: เขาแนะนำให้เลือก Disk ครับ นอกนั้นเลือก default ทั้งหมด

Enable Minify
Enable Minify

PageSpeed Insights

เมื่อ Enable เสร็จแล้วก็ให้ไปที่ PageSpeed Insights เพื่อทดสอบหา Blocking resources

ในขณะที่ผู้ใช้เว็บไซต์เข้ามาที่หน้าแรกของเว็บไซต์ หรือ Home Page มันจะมีไฟล์ JavaScript และ CSS ถูกโหลดมาด้วย แต่จริง ๆ แล้ว ณ ช่วงเวลานั้น ไฟล์พวกนี้ยังไม่มีความจำเป็น เราสามารถสั่ง Defer ไฟล์เหล่านี้ได้ ไฟล์เหล่านี้เรียกว่า Blocking resources

Blocking resources
Blocking resources

ให้คัดลอก URL ของไฟล์ JavaScript และ CSS ที่โชว์ภายใต้ Eleminate render-blocking resources นำมาใส่ที่ JS minify และ CSS minify ตามลำดับ

เลือกแถบ Minify (2)

W3 Total Cache
W3 Total Cache

ตรง JS file management: Theme: ให้เลือก Theme ที่เราใช้งานอยู่ครับ

JS minify
JS minify

เมื่อใส่ไฟล์ JavaScript เสร็จแล้ว Scroll หน้าจอลงมาด้านล่าง ใส่ไฟล์ CSS ต่อครับ

CSS minify
CSS minify

เสร็จแล้วกดปุ่ม Save Settings & Purge Caches

Save and Purge
Save and Purge

Multiple CDNs

เราสามารถใส่ CDN ได้มากกว่า 1 บรรทัด ครับ ตามรูปที่แสดง

Multi CDNs W3 Total Cache
Multi CDNs W3 Total Cache

Certificate

ให้ไปสร้าง Certificates ที่ AWS Certificates Manager เลือก Region เป็น us-east-1 หรือ US East (N. Virginia) โดยใส่ชื่อ Domain เข้าไป 4 ชื่อ โดยใช้ Certificate เดียวกันครับ

One Certificate for Multi Domain Name
One Certificate for Multi Domain Name

validate ให้เรียบร้อย

สร้าง S3 Bucket และ Cloudfront distribution ใหม่

รายละเอียดการสร้าง S3 Bucket และ Cloudfront สามารถอ่านบทความ เพิ่มความเร็ว WordPress ด้วย CDN

โดย Cloudfront distribution อันใหม่นี้ ตรง Alternate Domain Names ให้ใส่ Domain ทั้ง 4 เข้าไป 1 บรรทัด ต่อ 1 Domain ครับ ตรง SSL Certificate เลือก Custom SSL Certificate แล้วคลิ๊กเลือก Certificate ที่เราเพิ่งสร้างไป

Multi CNAMEs in Cloudfront
Multi CNAMEs in Cloudfront

หมายเหตุ: เราสามารถใส่ CNAMEs ได้ถึง 100 Domain names

100 CNAMEs for 1 Cloudfront
100 CNAMEs for 1 Cloudfront

เสร็จแล้วก็นำ Domain names ทั้ง 4 นี้ไปกรอกใน W3 Total Cache ครับ


Compatibility Check

ถ้าเรากดปุ่ม Compatibility Check ใน W3 Total Cache เราจะพบ Not detected หลายโมดูล ไม่ต้องตกใจนะครับ เขาบอกว่าเป็นเพราะเราใช้ php-fpm บน Apache แทนที่จะใช้ mod_php ซึ่งไม่ได้ผิดอะไร อ่านเพิ่มเติม

Compatibility Check
Compatibility Check

วิธีแก้ Error ชนิดต่าง ๆ

Unable to resolve hostname: your-domain.com

เมื่อคลิ๊กปุ่ม Test S3 upload & CloudFront distribution บางครั้งอาจพบ Error นี้

Unable to resolve hostname
Unable to resolve hostname

สาเหตุ: เพราะเราลืมใส่ your-domain.com ไว้ที่ Amazon Lightsail -> DNS ZONES

ต้องไม่ลืมว่า Domain Name เป็นแค่ชื่อชื่อหนึ่ง มันไม่ได้มีความหมายอะไรสำหรับคอมพิวเตอร์ คอมพิวเตอร์จะมองหา IP Address เท่านั้น การใส่ Domain Name ไว้ที่ DNS zone ก็เพื่อให้มันแปลงจาก IP Address เป็น Domain Name

เมื่อเราหยิบ Domain Name ไปใช้ คอมพิวเตอร์ก็จะแปลง Domain Name กลับไปเป็น IP Address อีกที แต่เมื่อมันแปลงแล้วไม่พบหมายเลข IP มันก็จะแจ้ง Error ว่าแปลง Domain Name ไม่ได้ หรือ Unable to resolve hostname

วิธีแก้:

  1. ไปที่ AWS Cloudfront เลือก Distribution ที่ต้องการแก้ไข
  2. คัดลอก Domain Name ก่อนคำว่า cloudfront.net อะครับ
Cloudfront
Cloudfront
  1. ไปที่ Amazon Lightsail เลือกแท็บ Networking แล้วเลือก DNS ZONES คลิ๊ก + Add record
  2. เลือก CNAME record
  3. Subdomain ให้ใส่ domain ที่มีปัญหา
  4. Maps to ให้วาง Domain Name ที่คัดลอกมาจาก Cloudfront
  5. กดลูกศรสีเขียว
DNS ZONES
DNS ZONES

ใส่ให้ครบทุกชื่อนะครับ ตามรูป

*** ขอให้สังเกตว่า Subdomain มีหลายชื่อ แต่ Maps to มีชื่อเดียวคือ xxxxxx.cloudfront.net

All CNAMEs
All CNAMEs

เมื่อกลับไปทดสอบอีกครั้งมันจะผ่านครับ

Test passed
Test passed

Use a Content Delivery Network (CDN)

อีกปัญหาหนึ่งที่อาจพบเมื่อทดสอบเว็บไซต์บน PageSpeed Insights หรือ GTmetrix คือ ไฟล์ทั้งหมดไม่ได้ถูกอัพโหลดไปไว้บน CDN เพราะ W3 Total Cache มองไม่เห็น บางครั้งเราต้องบอกมัน

  1. ให้ดู URL ที่อยู่หลัง your-domain.com ในที่นี้คือ wp-content/uploads/*
No CDN
No CDN

เนื่องจากโฟลเดอร์ wp-content/uploads/* เป็นโฟลเดอร์ที่ใช้เก็บ Media หรือ รูปภาพต่าง ๆ ที่ใช้เขียนบล็อก ผมไม่ได้อัพโหลดโฟลเดอร์นี้ขึ้นไปที่ CDN เพราะผมให้ปลั๊กอิน WP Offload Media Lite จัดการแทน

ถ้ามีไฟล์ JavaScript หรือ CSS มาอยู่ในโฟลเดอร์นี้ มันเลยตกสำรวจ ดังนั้นเราต้องระบุไฟล์เหล่านี้ให้ W3 Total Cache รับทราบ

  1. โดยไปที่ Performance -> CDN มองหา Custom file list:
Custom file list
Custom file list

เพิ่ม URL ที่ได้จากข้อ 1 เข้าไปทีละบรรทัด

Add file URLs
Add file URLs

*** URLs ในที่นี้ให้เป็น URL ในระดับไฟล์นะครับ ไม่ใช่ระดับโฟลเดอร์ เช่น

wp-content/uploads/elementor/css/post-354.css จะได้เป็น

{uploads_dir}/elementor/css/*

ไม่ใช่ {uploads_dir}/elementor/*


Distribution status is not Deployed, but “InProgress”.

เกิดจากเราเพิ่งสร้าง Cloudfront distribution หรือมีการแก้ไข มันจึงขึ้นสถานะกำลังทำงาน หรือ InProgress ให้รอจน Cloudfront ทำงานเสร็จ Error นี้จะหายไปเอง

Cloudfront In Progress
Cloufront In Progress
Error: InProgress
Error: InProgress

CORS

ถ้าเราพบว่าไอคอนต่าง ๆ หายไป ให้ลองคลิ๊กขวาบนเว็บไซต์ แล้วเลือก Inspect ไปที่แท็บ Network ลอง Refresh เว็บไซต์อีกครั้ง ถ้ามันขึ้นตัวแดง และแจ้งสถานะ CORS error แสดงว่ามันมีปัญหา Cross Origin สมมุติเว็บไซต์เรามีชื่อเป็น

www.your-domain.com และไฟล์ไอคอนเหล่านี้เก็บไว้ที่ cdn.your-domain.com อันนี้ถือว่า Cross Origin เพราะ www และ cdn คือคนละ Origin กัน

CORS error
CORS error

ปัญหานี้แก้ได้ไม่ยากครับ ไปที่ S3 Bucket ที่เก็บไฟล์ไอคอนเหล่านี้ แล้วไปที่แท็บ Permissions ลากหน้าจอลงมาจนสุด จะพบคำว่า Cross-origin resource sharing (CORS) ตามภาพ

CORS on S3 Bucket
CORS on S3 Bucket

ใส่โค้ดนี้เข้าไปครับ

[
    {
        "AllowedHeaders": [],
        "AllowedMethods": [
            "GET"
        ],
        "AllowedOrigins": [
            "*"
        ],
        "ExposeHeaders": []
    }
]

แล้วกดปุ่ม Save changes


403Forbidden

อาการ fonts หรือ icons หาย ยังมีอยู่แม้ Enable CORS ไปแล้ว แต่ครั้งนี้มันแสดงสถานะเป็น 403 ไม่ต้องตกใจครับ ทั้งนี้ปัญหา 403Forbidden เกิดจาก

  1. ไม่มีสิทธิ์เข้าถึงไฟล์
  2. ไม่พบไฟล์บนเซิร์ฟเวอร์

สาเหตุของ 403Forbidden:

1. ไม่มีสิทธิ์เข้าถึงไฟล์

2. ไม่พบไฟล์บนเซิร์ฟเวอร์

เมื่อเรา Enable CORS โดยอนุญาต Origin เป็นแบบ * ไปแล้ว ปัญหาที่เกิดจากสิทธิ์การเข้าถึงไฟล์จึงปัดตกไป เหลือแค่ สาเหตุข้อ 2 ซึ่งมีวิธีแก้ดังนี้ครับ

  1. ให้ตามไปดูไฟล์บนเซิร์ฟเวอร์ ว่าไฟล์ที่มีปัญหาอยู่บนเซิร์ฟเวอร์มั๊ย จากกรณีตัวอย่าง

ปลั๊กอิน Essential-Blocks เก็บไฟล์ fa-brands-400.woff2 ไว้บน S3 โฟลเดอร์ “/wp-content/plugins/essential-blocks/assets/fonts/”

***ผมใช้ Alias ของ S3 เป็น assets2.means-business.info

403Forbidden
403Forbidden

ผมจึงตามไปดูบน S3 ตามรูปข้างล่างนี้ จะเห็นว่าไม่มี โฟลเดอร์ fonts อยู่บนเซิร์ฟเวอร์

no fonts folder
no fonts folder
  1. ไปที่ Performance -> CDN มองหา Custom file list:
W3 Total Cache CDN Custom file list
Custom file list:

เติมโค้ดนี้เข้าไปครับ

{plugins_dir}/essential-blocks/assets/fonts/*
  1. คลิ๊กปุ่ม Upload custom files รอจนมันอัพโหลดเสร็จ
Upload custom files
Upload custom files

เมื่ออัพโหลดเสร็จ ลองไปตรวจดูที่ S3 จะพบโฟลเดอร์ และไฟล์ที่เราเพิ่งอัพโหลดขึ้นไป

Get fonts folder
Get fonts folder
font showing
font showing

ลอง Refresh เว็บบราวเซอร์ ตอนนี้สถานะเปลี่ยนเป็น 200

403Forbidden Solved
403Forbidden Solved

Cache TTL

ถ้าเราทดสอบเว็บไซต์ บน Chrome บ่อย ๆ และ Chrome มี Cache อยู่และยังไม่หมดอายุ เราอาจเจอปัญหาเว็บไซต์ทำงานลักลั่น เช่นไอคอนหาย แต่มันไม่ฟ้อง CORS error เหมือนข้างบน ก็ให้เดาว่าปัญหามาจาก Browser Cache

Chrome
Chrome

เราอาจแก้ด้วยการ Clear Cache บน Chrome หรือให้ลองไปเปิดเว็บไซต์ที่ Firefox ดูครับ เพราะ Firefox มันยังไม่มี Cache ถ้าเห็นว่าบน Firefox Browser มันแสดงไอคอนปกติ ก็ไม่ต้องทำอะไรครับ ปัญหา Cache TTL บน Chrome มันจะหายไปเอง เมื่อ Cache มัน Expired

Firefox
Firefox

ซีรี่ส์ เพิ่มความเร็ว WordPress


สมัครรับบทความ

ท่านจะได้รับบทความเกี่ยวกับเทคนิคในการเขียนโค้ด การสร้างเว็บไซต์ ความรู้ด้านบัญชี ภาษีอากร และอื่นๆ

0 0 votes
ให้คะแนนบทความ
Notify of
guest
0 ความเห็นทั้งหมด
Inline Feedbacks
ดูความเห็นทั้งหมด

บทความแนะนำ

Flask Python framework โดย สรุป

Flask Python framework + Emmet

สรุป วิธีสร้างเว็บไซต์ด้วยภาษา Python โดยใช้ Flask framework และ การตั้งค่า VSCode เพื่อให้สามารถใช้ Emmet ร่วมกับ Flask framework ได้

Redis บน Debian AWS EC2

Redis บน Debian AWS EC2

ติดตั้ง Redis แบบ Manual บน ระบบปฏิบัติการ Debian ที่อยู่บน EC2 ของ AWS Cloud จะช่วยให้การปรับแต่ง Redis เช่น การเพิ่มพอร์ต ทำได้ง่ายขึ้น

Colorize VIM

Developer Playground: Colorize VIM

ตกแต่ง VIM Editor ให้ดู Colorize ด้วย VIM Plug และมันยังมีประโยชน์ต่อการเขียนโค้ดด้วย เพราะมันจะแสดงข้อมูลที่สำคัญบริเวณขอบล่างของหน้าจอ

0
แสดงความเห็นได้นะx
()
x
Scroll to Top
Share on facebook
Share on twitter
Share on linkedin