วันนี้เราจะมาแฉ เอ๊ย มาแชร์วิธีการทำคะแนนใน Google PageSpeed Insights ให้ได้ 100 คะแนน หรือได้คะแนนสูงที่สุดเท่าที่จะทำได้ ต้องขอออกตัวก่อนว่า เตยไม่ได้เป็นผู้เชี่ยวชาญทางด้านโปรแกรมเมอร์ใดๆ นะคะ บางเรื่องอาจจะไม่สามารถอธิบายโดยละเอียดหรือถูกต้องได้ ท่านใดเห็นสมควรอย่างไรสามารถแนะนำกันในคอมเม้นท์ได้เลยค่ะ เราจะไม่มีมีการแก้ไขหรือพิมพ์โค้ดใดๆ เองใน How to นี้

wpthaiuser-google-100

(บทความนี้ค่อนข้างยาวและเนื้อหาเยอะพอสมควร ใครจะลองทำจริงๆ อาจจะต้องตั้งใจอ่านนิดนึง ขนาดเขียนเองก็ยังมึน เว็บที่ใช้ทดสอบจริงๆ ก็คือเว็บของเราเอง และอีกเว็บที่โคลนนิ่งไปแล้ว Deactivate ปลั๊กอินออก ก็คือ wpthaiuserexample.com ดังนั้นทุกอย่างในเว็บจึงเหมือนกัน ต่างแค่อีกตัวนั้นไม่ได้ใช้ Jetpack เท่านั้นเอง เพราะต้องทำการเชื่อมต่อบัญชี WordPress จุดประสงค์เราเพียงแค่ทำแล้วลบ เก็บภาพบางส่วนเท่านั้น)

Google PageSpeed Insights จำเป็นหรือไม่

การทดสอบเว็บด้วย Google PageSpeed Insights นั้น เป็นการวิเคราะห์ว่าเว็บไซต์ของเรานั้นมีความรวดเร็วในการเข้าชมมากแค่ไหน โดยจริงๆ แล้ว Google PageSpeed Insights นั้นไม่ได้วัดความเร็วเป็นแบบวินาทีเหมือนเว็บอื่นๆ แต่ให้คะแนนโดยวัดตามความเร็วของการแสดงผล โดยดูจากโครงสร้างต่างๆ ของเพจว่ามีส่วนไหนที่ทำให้เว็บโหลดช้า หรือแสดงผลช้ากว่าที่ควรจะเป็นหรือไม่ ดังนั้นเราจึงไม่ปฏิเสธหรือเพิกเฉยต่อการปรับแต่งเว็บให้รับกับนโยบายของ Google PageSpeed Insights แต่เราจะพยายามปรับให้ได้ดีที่สุดโดยไม่กระทบต่อการแสดงผลแทน

ปัญหาหลักๆ ของเว็บ WordPress ที่มักจะพบเมื่อทดสอบด้วย Google PageSpeed Insights

  1. Optimize Images ไฟล์ภาพที่มีขนาดไม่เหมาะหรือใหญ่จนเกินไป เว็บทั่วไปใครๆ ก็เจอค่ะ ปรับขนาดไหนก็ยังโดน ภาพที่ Google แนะนำบางทีก็ความละเอียดไม่โอเค อันนี้ไม่ต้องถึงกับเครียดนะคะ ปล่อยได้ปล่อยค่ะ
  2. Render-blocking JavaScript and CSS in above-the-fold content ปัญหาจากการรัน JS, CSS ที่ไปบล็อคการแสดงผลของเนื้อหาอื่นๆ เกณฑ์ในข้อนี้ถูกนำมาใช้เพื่อการปรับปรุงเว็บสำหรับ Mobile โดยเฉพาะ เพื่อไม่ให้ผู้ชมรอโหลดสคริปต์ต่างๆ
  3. Compression/Gzip/Leverage Browser Caching ถ้าเจอแนวๆ นี้คือเกี่ยวกับการแคช
  4. Minify JavaScript/CSS เกี่ยวกับการทำ Minify JavaScript และ CSS ให้มีขนาดเล็กลง
  5. User Experience ในส่วนนี้เป็นส่วนของ Design โดยเฉพาะค่ะ เช่น หากปุ่มบางปุ่มอยู่ใกล้กันเกินไป ก็จะโดนหักคะแนน คะแนนส่วนนี้จะแยกจาก Speed และมีเฉพาะบน Mobile เท่านั้น

page-speed-insights

จะเห็นว่าปัญหาส่วนใหญ่ที่เจอจะเกี่ยวกับการทำให้เว็บแสดงผลได้เร็วขึ้นทั้งนั้น ดังนั้นการทำตามคำแนะนำของ Google ก็เป็นเรื่องที่ดี ส่วนตัวมีความเชื่อที่ว่า หากเว็บที่ได้รับคะแนนในส่วนนี้เยอะ ก็อาจจะได้รับผลลัพธ์ที่ดีในผลการค้นหาด้วย ซึ่งไม่ได้มีการยืนยันนะคะ จะมีก็แต่ก่อนหน้านี้ที่ Google ยืนยันว่า เว็บที่รองรับการแสดงผลบน Mobile ได้ดีกว่า จะได้รับอันดับที่ดีกว่า (เป็นแค่ส่วนหนึ่งในการพิจารณาเท่านั้น)

ธีมและปลั๊กอินก็มีส่วนนะ

เพราะการแสดงผลของเว็บ WordPress นั้นขึ้นอยู่กับธีมเป็นส่วนใหญ่ และปลั๊กอินบ้างบางส่วน ดังนั้นธีมจึงเป็นตัวส่งผลหลักโดยตรง JavaScript และ CSS ส่วนใหญ่นั้นก็สร้างขึ้นจากธีมที่ เราสามารถอ่านรายละเอียดของธีมต่างๆ ได้ว่าให้ความสำคัญเกี่ยวกับ Speed มากน้อยแค่ไหน บางธีมกำหนดขนาดภาพมาอย่างละเอียด บางธีมเอาภาพใหญ่ไปใช้กับภาพขนาดเล็ก ทำให้เว็บโหลดเยอะโดยไม่จำเป็น

total-promote

เราใช้ธีม Total

เราต้องยอมรับว่าธีมหรือหน้าเว็บที่มีการใช้ลูกเล่นหรือเอฟเฟคมากๆ ที่ต้องใช้ JavaScript เยอะๆ ย่อมโหลดมากกว่าธีมที่มีรูปแบบเรียบๆ อยู่แล้ว โดยเฉพาะธีมที่ใช้ปลั๊กอิน Page Builder ทั้งหลาย การปรับแต่ง JS หรือ CSS ด้วยวิธีการที่เราจะนำเสนอต่อไปนี้ก็อาจจะกระทบกับบางเว็บ ทำให้ไม่สามารถที่จะแสดงผลอย่างที่ควรจะเป็นได้ หรืออาจจะปรับได้ไม่ถึงสูงเท่าเว็บที่ลักษณะเรียบกว่า นอกจากนี้ในส่วนของความ Responsive ของธีมยังกระทบโดยตรงกับ User Experience ของเว็บด้วย จะเห็นได้ว่า กับธีม Total นั้นเราไม่ต้องปรับอะไรก็ได้ 100/100 ค่ะ

ปลั๊กอินที่ใช้ :

  • WP Smush (Pro) บีบอัดภาพ
  • WP Fastest Cache สร้างแคช แก้ปัญหา Leverage Browser Cache, Gzip compression ฯลฯ
  • Autoptimize ปลั๊กอินเทพในการจัดการ บีบอัพ CSS, JS แก้ปัญหา Above The Fold CSS
  • AO CriticalCSS Powerup ให้คู่กับตัวบนสำหรับเว็บที่มีหน้าต่างกันเยอะๆ
  • Async JavaScript สำหรับทำ Defer JavaScript ลดปัญหา Render-Blocking JavaScript in Above the fold content
  • Jetpack ใช้ในส่วนของ Photon เพื่อใช้ CDN กับรูปภาพเพียงอย่างเดียว

Optimize Image

เราได้ทดลองใช้ปลั๊กอิน WP Smush – Image Optimization (Pro) สำหรับการปรับภาพไปเรียบร้อยแล้วนะคะ จึงไม่ได้มีภาพเปรียบเทียบ PageSpeed ระหว่างก่อนและหลังปรับภาพ ปลั๊กอินนี้ใช้ดีมากๆ รุ่น Pro นั้นจะปรับภาพได้เยอะกว่าตัวฟรี และสามารถสั่งให้ทำการบีบอัดทีเดียวทั้งเว็บได้เลย หากเป็นตัวฟรีก็จะต้องคลิกปรับได้แค่ทีละ 50 ภาพ เขามีแบบทดลองฟรี 14 วันนะคะ สามารถใช้ตัวนี้ลองปรับทั้งเว็บได้ ปลั๊กอินจะทำงานผ่านเซิฟเวอร์ของ WPMUDEV โดยตรง จะเห็นผลโดยตรงกับภาพ Thumnail ต่างๆ ซึ่งจะลดขนาดได้ถึงครึ่งเลยทีเดียว เพราะแม้ภาพต้นฉบับที่เราปรับจากคอมแล้ว แต่พวก Thumbnail นั้นเป็นการสร้างเองใน WordPress ทำให้ภาพเหล่านั้นไม่ได้โดนบีบอัดเท่าที่ควร

นอกจากนี้เรายังใช้ปลั๊กอิน Jetpack ช่วยอีกทางหนึ่งด้วย เพราะ Photon ของ Jetpack จะทำการเสริฟภาพตามขนาดที่ควรจะเป็นนั่นเอง ภาพบางภาพเลยติดว่าต้อง Optimize อยู่ เพราะขนาดที่เรากำหนดไว้นั้นจะใหญ่กว่าหน้าจอที่ Google กำหนด เว็บที่เราไม่ได้ใช้ Jetpack ก็จะแสดงภาพตามขนาดจริง ซึ่งเราทำภาพใหญ่ไว้เผื่อการแสดงผลบนหน้าจอขนาดที่ใหญ่กว่าด้วย ดังนั้น Google จะมองว่าเราเสริฟภาพไม่เหมาะสมกับขนาด นอกจากนี้ Photon ยังเสริฟภาพแบบ WebP สำหรับ Chorome browser ทำให้คนเข้าใช้จาก Chrome โหลดภาพได้เร็วยิ่งขึ้น

ปลั๊กอินบีบอัดภาพอื่นๆ

Cache

ปลั๊กอิน Cache นั้นมีส่วนช่วยในสำหรับเว็บ WordPress เป็นอย่างมาก เว็บ WordPress ทุกเว็บควรจะมีการติดตั้งแคช โดยเฉพาะหากเริ่มมีคนเข้าเว็บมากขึ้น เพราะจะช่วยลดการทำงานของเซิฟเวอร์ได้เยอะ และช่วยให้เว็บเราทำงานได้เร็วขึ้น โดยการทำงานของแคชนั่นก็คือการสร้างหน้าเว็บแบบ static แทนการดึงข้อมูลจากฐานข้อมูลทุกครั้งที่มีการเรียกดู จึงทำให้เว็บทำงานเร็วขึ้นนั่นเอง

pagecache1.png

ในที่นี้เราใช้ปลั๊กอิน WP Fastest Cache เพื่อช่วยในเรื่อง Cache ทั้งหลาย ทั้งพวก Gzip, Leverage browser cache เป็นต้น โดยเราไม่ได้เปิดใช้งาน Minify กับ Combine ต่างๆ เพราะเราจะใช้งานปลั๊กอิน Autoptimize แทนค่ะ

wp-fastest-cache

2. WP Fastest Cache

 

ผลลัพธ์ 71-78

wp-fastest-cache-result

ปลั๊กอินแคชอื่นๆ เช่น

Render-Blocking and Above The Fold Content

ส่วนนี้เป็นส่วนสำคัญที่จะโดนติเยอะที่สุด เพราะหลังจากที่ Google มาให้ความสำคัญในส่วนของ Mobile มากขึ้น ตรงนี้จึงถูกนำมาพิจารณาเป็นพิเศษ เนื่องจาก Google ต้องการให้เว็บแสดงผลบนหน้าจอให้เร็วที่สุดแม้ว่าจะอยู่บนการเชื่อมต่อของสัญญาณมือถือ โดยไม่ต้องรอให้โหลดข้อมูลจนครบทั้งหน้า แต่ให้แสดงข้อมูลที่จำเป็นต้องแสดงก่อนเลย (Above The Fold Content) อันที่เหลือก็ค่อยโหลดภายหลังเป็บแบคกราวน์ก็ได้

google-above-the-fold

ปลั๊กอินที่เราจะนำมาใช้ร่วมกันในการแก้ปัญหานี้ก็คือ Autoptimize และ Async JavaScript

Autoptimize

ปลั๊กอินนี้ช่วยในการจัดการเกี่ยวกับการบีบอัพ Minify, Combine และ Inline HTML CSS และ JavaScript ในเว็บเราโดยเฉพาะ เราจะใช้ปลั๊กอินนี้ในการ Inline CSS ที่ใช้ในหน้านั้นๆ ทำให้ไม่ต้องรอโหลด CSS แบบเต็ม ยิ่งถ้ามี CSS หลายไฟล์ก็จะทำให้ช้ามากยิ่งขึ้น

inline-and-defer-css

3. Autoptimize

จากนั้นเราก็จะต้องกำหนด Above The Fold CSS ด้วย ซึ่งในขั้นตอนนี้เราจะต้องใช้วิธีที่เรียกว่า Critical CSS ซึ่งจะเป็นการนำเอา CSS ที่จะแสดงผลก่อนขึ้นมา เพื่อที่จะให้ CSS เหล่านี้แสดงผลได้เลยทันทีที่หน้าเว็บมีการโหลด โดยในแท็บ Optimize More ของปลั๊กอิน Autoptimize นั้นจะมีลิงค์ไปยังเว็บ criticalcss.com เพื่อการนี้โดยเฉพาะ เราต้องทำการสมัครก่อนถึงจะสามารถใช้งานได้ โดยราคาคือ 2 ปอนด์ต่อเดือน เพื่อที่เราจะสามารถสร้าง criticalCSS สำหรับหลายหน้าได้ (เนื่องจากเราเพิ่งทดลอง

ปกติแล้ว CSS ของแต่ละหน้านั้นจะไม่เหมือนกัน เราจะเลือกทำเฉพาะหน้าโพสก็ได้ โดยเลือกเอาซักหน้า เพราะสำหรับเว็บบทความเช่นเว็บเรา เราเน้นที่คนเข้าอ่านบทความเป็นหลักอยู่แล้ว และเนื่องจากหน้าหลัก (Home) และหน้าบทความ (Single Post) ของเว็บเรานั้น ค่อนข้างไม่ต่างกันเท่าไหร่ ทำให้หน้า Home ได้รับอานิสงค์ไปด้วย โดยการสร้าง CritcalCSS สำหรับหน้า single post ก็พอ

 

Home (ซ้าย) Single post (ขวา)

ทำการ Generate CriticalCSS ที่เว็บ โดยการใส่ URL ของหน้าที่เราต้องการจะ generate แล้วคลิกปุ่ม Generate ระบบก็จะสร้างไฟล์มาให้เราดาวน์โหลด

single-criticalcss

3.1 CriticalCSS Generator

ให้เราทำการเปิดไฟล์ CSS ที่ได้มาแล้วทำการก๊อปปี้โค้ดทั้งหมดในไฟล์ วางในช่องสำหรับใส่ Above The Fold CSS ของปลั๊กอิน Autoptimize

inline-criticalcss

3.2 Inline and Defer CSS

Async JavaScript

ปลั๊กอินนี้ช่วยในการ Defer JavaScript ต่างๆ ในเว็บ ทำให้เว็บไม่ต้องรอโหลด JavaScript จนหมด ก็สามารถที่จะปล่อยให้เว็บเราแสดงเนื้อหาขึ้นมาก่อนได้เลย สามารถทำงานร่วมกันกับปลั๊กอิน Autoptimize ได้

async-javascript

4. Async JavaScript

ผลลัพธ์ 78-97

after-criticalcss

เปรียบเทียบกับเว็บต้นฉบับด้านล่างที่ใช้ Jetpack ร่วมด้วย

ผลลัพธ์ 100!

wpthaiuser-page-score

นอกจากหน้า Home ที่ได้ 100 ไปแล้ว ทีนี้เรามาดูหน้า Single Post หรือ หน้าบทความ นั่นเอง เป็นที่น่าเสียดายว่า ตราบใดที่เรายังใช้ Facebook Comments, Facebook Like อยู่ เราจะไม่สามารถที่จะได้คะแนนเต็มในหน้าบทความได้ ต่างจากหน้า Home นะคะ ที่เราไม่ได้ใส่พวกนี้ไว้ เพราะ Facebook Comments และ Facebook Like นั้นเป็น Iframe ที่เป็นหน้าของ Facebook เราแค่นำมาฝังไว้เฉยๆ ดังนั้นเราจึงจำเป็นต้องโหลดสคริปต์ของ Facebook รวมถึงรูปภาพของเขาที่เราไม่สามารถที่จะทำการบีบอัดเพิ่มเติมได้ด้วย หากใครไม่จำเป็นที่จะต้องใช้ก็ปลดออกได้เลย แต่เว็บเราจำเป็นจริงๆ ที่จะต้องคงไว้ เผื่อว่ามีใครสงสัยอะไรหรือต้องการพูดคุยอะไรก็จะได้สะดวก เพราะสามารถเขียนที่หน้าโพสได้เลย คนอื่นก็จะเห็นด้วย อันนี้เราก็ต้องตัดใจเลือกเช่นกัน

facebook-comment

facebook-on-page

สำหรับเว็บที่มีหน้าต่างกันเยอะๆ เช่น เว็บที่ใช้ Page Builder สร้างหน้าต่างๆ ขึ้นมา เว็บบริษัท ที่ส่วนใหญ่เน้นดีไซน์หน้าเดี่ยวๆ หลายๆ หน้าที่ไม่เหมือนกัน เราจะไม่สามารถที่จะใช้ CriticalCSS ชุดเดียวกันกับหน้าอื่นๆ ได้ เพราะ CSS ที่ใช้มันเป็นคนละชุดกัน ยกตัวอย่างเช่น ถ้าเราใช้ CriticalCSS ที่เรา generate จากหน้าบทความ ไปใช้กับหน้า Home ยังโอเค แต่หากเราไปใช้กับหน้า Knowledge Base ซึ่งใช้ Page Builder สร้าง และมีโครงสร้างหน้าที่ต่างกันมากๆ จะไม่ได้ผล จะเกิดปรากฏการณ์ที่เรียกว่า Flash แทน

ลองสังเกตุหลังจากที่คลิกเมนู เริ่มต้นที่นี่ หน้าเว็บจะโหลดแต่เนื้อหาจะว่างอยู่พักนึงก่อนที่จะปรากฏภายหลัง คล้ายๆ โดนแฟลช

no-critical

 

ซึ่งหากทดสอบด้วย Google ก็จะแจ้งเราว่ามีปัญหากับ Prioritize Visible Content นะ แล้วถ้าคลิกลิงค์ see screenshot เราก็จะพบความจริงปรากฏในสิ่งที่ Google เห็น

prioritize-visible-content-2

วิธีแก้โดยเราต้องซื้อตัวเสริมของ Autoptimize ที่ชื่อว่า AO CriticalCSS Powerup (เสียเงินอีกแล้ว) โดยเราต้องล็อกอินตัว CriticalCSS เว็บไซต์ไว้ก่อนนะคะ ถึงจะอัพเกรดได้ เพราะจริงๆ แล้วมันเป็นของ crticalCSS.com ค่ะ แต่เป็นส่วนที่ใช้สำหรับเสริม Autoptimize เมื่อทำการอัพเกรดเรียบร้อยแล้วเราจะได้ Licence Key  มาใส่ในปลั๊กอิน Autoptimize CriticalCSS.com ดาวน์โหลดและวิธีติดตั้งใช้งาน

จากนั้นปลั๊กอิน Autoptimize ของเราจะมีแท็บเพิ่มขึ้นมา ชื่อว่า CriticalCSS แท็บนี้จะช่วยให้เราสามารถที่จะฟิลเตอร์หรือกรองหน้าที่มีเทมเพลตแตกต่างกัน เพื่อใช้ CriticalCSS ที่แตกต่างกันได้ โดยสามารถกรองจาก

  • Part of the Path (URL) ส่วนหนึ่งของ url ในกรณีนี้เราใช้กับหน้าที่สร้างด้วย Page Builder หรือ หน้าของ Post Serie ที่จะมีโครงสร้างต่างจากหน้าของ Categories เล็กน้อย
  • Conditional tags ใช้เงื่อนไข เช่น is home, is single, is archive เป็นต้น

โดยให้ทำการลบโค้ด Above The Fold CSS ที่เราใช้ในรูป 3.2 ออกก่อนได้เลย

ao-criticalcss
ผลลัพธ์
criticalcss-after

ลองดูแบบวิดีโอกันบ้าง จะพบว่า ทันทีที่เราคลิก เริ่มต้นที่นี่ เนื้อหาก็แทบจะปรากฏทันทีเลย โดยไม่มีปรากฏเป็นหน้าว่างค้างเหมือนโดนยิงแฟลช ไม่ได้เร่งวิดีโอให้เร็วขึ้นแต่อย่างใด อันนี้คือข้อดีของการทำตามคำแนะนำของ Google นะคะ คือมันได้ผลจริงๆ และดีกว่าแบบเดิมจริงๆ

after-criticalcss

 

อย่างที่บอกว่าใครไม่อยากเสียเงินเพิ่มก็อาจจะทำเฉพาะหน้าบทความเฉยๆ ก็ได้ค่ะ แต่นี่เราทดสอบ ก็เลยลองทำหมดค่ะ หน้า Home, Knowledge Base, Contact, Post Series ไหนๆ ก็จ่ายแล้วก็ทำไว้ให้หมดทุกหน้าค่ะ 😀

GTMetrix กับ Pingdom

2 เว็บนี้คือ GTMetrix.com กับ Pindgom จะให้คะแนนต่างจาก Google PageSpeed Insights เล็กน้อย โดยนอกจากจะมีการวัดไปที่คะแนนหรือที่เรียกว่าเกรดแล้ว จะวัดที่ความเร็วแบบเป็น milisecond ด้วย แต่เนื่องจากว่าเว็บไซต์เหล่านี้นั้นจะทำการทดสอบเว็บด้วยเซิฟเวอร์ที่กระจายอยู่ตามตำแหน่งต่างๆ ในหลายๆ ประเทศ ดังนั้นเว็บเหล่านี้ก็มักจะนำเอา CDN หรือ Content Delivery Network มาคำนวนด้วย เพราะมันมีผลโดยตรงกับเวลาที่ใช้ในการทดสอบ โดยเมื่อเราใช้ CDN เว็บของเราก็จะโหลดจากเซิฟเวอร์ที่ใกล้กับสถานีที่ทำการทดสอบมากที่สุด ดังนั้นเว็บที่ไม่ได้ใช้ CDN นอกจากจะได้คะแนนน้อยกว่าแล้วก็ยังจะใช้เวลาในการโหลดมากกว่าอีกด้วย  CDN ฟรีที่แนะนำเช่น CloudFlare

cdn-exampleแต่ในเว็บของเราเองตอนนี้เราไม่ได้ใช้ CloudFlare นะคะ ใช้ Jetpack เพื่อที่จะใช้ตัว Photon ซึ่งเป็น CDN แบบเฉพาะรูปภาพ โดย Photon จะทำการเสริฟรูปภาพผ่านเครือข่ายของ WordPress แทน ที่ใช้ Photon ของ Jetpack เพราะเราต้องการคุณสมบัติการแปลงภาพเป็น WebP ของ Photon นั่นเอง และเซิฟเวอร์ของ WPThaiuser นั้นอยู่ที่สิงคโปร์อยู่แล้ว เครือข่ายที่ใกล้ที่สุดของ CloudFlare ในกรุงเทพยังเชื่อมต่อเฉพาะของ Jastel นอกนั้นก็ยังต้องวิ่งไปที่สิงคโปร์กับฮ่องกงอยู่ดี เราเลยเลือกใช้ลูกครึ่ง CDN คือใช้เฉพาะรูปภาพ ไม่ได้ใช้ทั้งเว็บ

GTMetrix

why-slow-cdn

จากภาพด้านบน วัดจากฮ่องกงซึ่งเป็นเซิฟเวอร์ที่ใกล้ที่สุดแล้ว จะเห็นว่าคะแนน CDN ในส่วนของ YSlow นั้นเราได้แค่ 50 เพราะว่าเราใช้ CDN เฉพาะกับรูปภาพ ไฟล์อื่นๆ อย่าง .js และ .css ก็เลยไม่ได้รับอานิสงค์จาก CDN ด้วย หากใครใช้ CloudFlare ก็จะได้เยอะกว่านี้ค่ะในส่วนของ CDN

Pingdom

คะแนนจาก Tools Pingdom ส่วนใหญ่ก็จะติดที่ Query String เพราะการที่เราใช้ Photon ของ Jetpack นั้น ก็จะมี Query String ติดท้ายมาด้วย เช่น ถ้ารูปภาพก็จะมี wepp-compare.png?w=555&ssl=1 โดย w=555 ก็คือความกว้างของภาพ อย่างที่เราบอกว่ามันจะเสริฟภาพตามขนาดที่ปรากฏให้ เหมือนเป็นการย่อภาพอัตโนมัตินั่นเอง ข้อเสียคือเวลาเราทดสอบสปีดตามเว็บเหล่านี้ก็อาจจะโดนหักคะแนนมี Query String เยอะเกินไปได้ค่ะ ยิ่งภาพเยอะก็ยิ่งเยอะตาม ตอนใช้ CloudFlare จะไม่เจอแบบนี้กับกรณีของ CDN เลยนะคะ ได้อย่างเสียอย่าง ก็แบบนี้แหละ 😀 ส่วนเวลานั้นได้ช้ากว่า เพราะเซิฟเวอร์ที่ทดสอบส่วนใหญ่อยู่ไกลๆ ทั้งนั้นค่ะ ถ้าใช้ CloudFlare น่าจะลดได้ประมาณครึ่ง ยังไม่เคยได้ลองกับธีมนี้แต่คิดจากประสบการณ์ที่เคยใช้มาทุกรอบ

tools-pingdom

บทสรุป

เว็บ Speed Test ต่างๆ ไม่ว่าจะเป็น Google, GTMetrix, Pingdom ต่างก็เป็นตัวช่วยที่ดีในการเป็นไกด์ให้เรา ว่าเราควรจะปรับปรุงเว็บในส่วนไหนบ้างเพื่อให้เว็บนั้นเร็วขึ้น เตยก็เคยคิดว่า ไม่ต้องสนใจมันหรอก Google เพราะตอนนั้นทำยังไงก็ไม่ได้คะแนนเยอะขึ้น เพราะตอนนั้นเรายังทำไม่เป็น เรายังไม่รู้ว่าจะใช้เครื่องมืออะไร ซึ่งเว็บเราก็ไม่ได้ช้าอะไรมากนะ เราก็เลยคิดว่า Google มันปลอม ปลอมในที่นี้คือมันไม่น่าเชื่อถือ มันตั้งมางั้นๆ แหละ เว็บที่ไหนจะไปทำได้ คือตอนนั้นขนาดเว็บเราไม่ได้ซับซ้อนอะไรก็ยังไม่ได้ เพราะติดตัว Render-Blocking ตลอด!! เกลียดมันมาก พอตอนได้ลองแก้ไขดูแล้ว ทำให้ได้รู้ว่า จริงๆ มันก็ส่งผลดีต่อยูสเซอร์ของเราอย่างมาก มันเหมือนการขยับปรับแต่งหน้าเว็บเดิมให้มันทำงานได้รวดเร็วยิ่งขึ้น บางครั้งเวลาในการโหลดอาจจะเท่าเดิมนะ แต่ด้านบนมันขึ้นมาเร็วกว่า คนเห็นก่อนก็จะรู้สึกว่ามันเร็วกว่า ส่วนที่เหลือมันก็ค่อยๆ โหลดมันทีหลัง โดยไม่ต้องรอให้โหลดทีเดียวพร้อมกัน นี่คือปัญหาหลักที่ Google ต้องการจะสื่อและให้เราแก้ไขสำหรับยุค Mobile ครองเมืองเช่นนี้

ต่ละเว็บนั้นมีโครงสร้างไม่เหมือนกัน ธีมและปลั๊กอินต่างๆ ไม่เหมือนกัน ทำให้มีการสร้าง JavaScript และ CSS ที่ไม่เหมือนกัน สิ่งที่เตยทำแล้วเวิร์คก็อาจจะไม่เวิร์คกับเว็บของคุณก็ได้ บางเว็บแค่  Activate ปลั๊กอิน Autoptimize ก็พังแล้ว ดังนั้นจึงไม่จำเป็นที่จะต้องเอาแบบของเตยไปเป็นบรรทัดฐานในการปรับแต่งนะคะ เราต้องทดลองเองว่าเว็บของเราเหมาะกับการปรับแต่งแบบไหน ปรับได้สุดแค่ไหนไม่พัง เพราะต่อให้คะแนนดี แต่เว็บแสดงผลไม่ได้ตามที่ต้องการ ก็ไร้ประโยชน์ค่ะ

หวังว่าบทความนี้จะเป็นประโยชน์สำหรับนัก Optimizer ทุกท่าน ไม่มากก็น้อย

Search