คู่มือ WPO ในการปรับความเร็วเว็บไซต์ของคุณ

WPO คืออะไร?

Web Performance Optimization ที่เราเรียกว่า WPO เป็นเพียงการปรับกระบวนการที่แตกต่างที่ส่งผลต่อวิธีที่เว็บไซต์โหลด

วัดความเร็วในการโหลดของเว็บไซต์อย่างไร?

มีเครื่องมือมากในการวัดความเร็วในการโหลด ที่ได้รับความนิยมที่สุดคือ:

• ›

  Google Page Speed

• ›

  Lighthouse

• ›

  GTMetrix

ก่อนเริ่ม audit สำคัญที่จะคำนึงว่าความเร็วในการโหลดแตกต่างสำหรับผู้ใช้ทุกคน ตัวแปรที่แตกต่างสามารถส่งผลต่อความรู้สึกของความเร็วสำหรับผู้ใช้ใน Cuenca เทียบกับใน Ottawa

ด้วยเหตุนี้ แทนที่จะทำงานบนเวลาในการโหลดเป็นวินาที เราขอแนะนำมุ่งเน้นการปรับ:

• ›

  น้ำหนักเว็บไซต์ (MB)

• ›

  Requests

• ›

  เวลาตอบสนองของเซิร์ฟเวอร์

หากเราปรับปรุง 3 พื้นที่นี้ ความเร็วในการโหลดจะปรับปรุงไม่ว่าผู้ใช้อยู่ที่ใด

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

Google Developer Tools

ก่อนเริ่ม ผมต้องการอธิบายตัวเลือกบางอย่างที่ Google เสนอผ่านเครื่องมือผู้พัฒนา เครื่องมือนี้เป็นหนึ่งในที่สำคัญที่สุดในการวิเคราะห์ว่าเว็บไซต์ทำงานอย่างไร คลิกขวาบนหน้าที่เบราว์เซอร์เปิดและแผงพร้อมตัวเลือกที่แตกต่างจะปรากฏ เราจะไปที่ Inspect (Ctrl + Shift + I)

เมื่อเครื่องมือนั้นเปิด เราจะมุ่งหน้าไปยังตัวเลือก NETWORK ที่คุณจะพบที่ด้านบน หากเรากด ENTER อีกครั้งในเบราว์เซอร์ เครื่องมือจะแสดงการโหลดของทรัพยากรที่แตกต่าง

ที่ด้านล่างของภาพ เราสามารถเห็นข้อมูลที่เราสนใจสำหรับมุมมองทั่วไปของวิธีที่เว็บไซต์โหลด

ขุดลึกในแผงนี้จากด้านบนและดูโครงสร้างคอลัมน์ เรามี:

• ›

  Name: ชื่อของทรัพยากร

• ›

  Status: response code ของทรัพยากร (200, 301, 404...)

• ›

  Type: ประเภทของทรัพยากร (script, font, png, jpg, stylesheet...)

• ›

  Initiator: ทรัพยากรใดที่กระตุ้น request

• ›

  Time: request ใช้เวลาเท่าไร

• ›

  Waterfall: การแสดงกราฟิกของเวลาในการโหลดของทรัพยากร

หากเราคลิกขวาที่ด้านบน เราสามารถเพิ่มและลบคอลัมน์ด้วยข้อมูลนี้

การเปิดใช้องค์ประกอบข้อมูลเพิ่มเติมเช่น Domain, Scheme หรือ Cookies สามารถช่วยในกรณีเฉพาะในการระบุทรัพยากรที่อาจทำให้เกิดปัญหาบางอย่าง แต่ในจุดนี้เราจะยึดมั่นที่มาเป็นกำหนดล่วงหน้า

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

รู้น้ำหนักของ URL และลดอย่างไร?

น้ำหนัก ไม่ว่าใน Megabytes หรือ Kilobytes เป็นหนึ่งในเหตุผลหลักที่ URL ใช้เวลาในการโหลด ด้วยเหตุนี้เราเริ่มโดยดำดิ่งในด้านนี้ เพราะจะกำหนดเส้นทางในการบรรลุการปรับที่ดีบนเว็บไซต์ของเรา

ข้อมูลต่อไปนี้มาจากเครื่องมือที่กล่าวข้างต้น GTMETRIX และสอดคล้องกับเว็บไซต์ที่ผมกำลังจะเริ่มปรับ

เราจะมุ่งเน้นข้อมูลในคอลัมน์ขวา ที่อ้างถึง (Page Details) โดยเฉพาะ Total Page Size

ในตอนแรก น้ำหนักของเว็บไซต์นี้สูงกว่าค่าเฉลี่ยมาก แต่จำได้ว่าสิ่งที่สำคัญไม่ใช่น้ำหนักรวมของเว็บไซต์แต่ระยะเวลาที่น้ำหนักนั้นใช้ในการโหลด เพราะมีบางสิ่งที่เรียกว่า Lazy Load คุณสมบัติที่เลื่อนการโหลดจนกว่าผู้ใช้ต้องการทรัพยากร เราจะพูดถึงในภายหลัง

เรายังสามารถพบข้อมูลนี้ในเครื่องมือผู้พัฒนา ในแผงที่เราดูข้างต้น ที่ผมจะเตือนคุณอีกครั้ง

หากคุณดูที่ด้านล่าง ทั้ง 7.5 MB และ 215 requests ใกล้กับตัวเลขที่ GTMETRIX รายงาน สำคัญสำหรับคุณที่จะรู้ว่า GTMETRIX ได้ข้อมูลจากไหนในกรณีที่คุณต้องการใช้เครื่องมืออื่น

ตอนนี้มาดูสิ่งที่หนักมากและวิธีที่เราสามารถแก้

ตัวเลือก Waterfall เสนอมุมมองภาพของวิธีที่ทรัพยากรโหลด แสดง URL ทรัพยากร สถานะ โดเมน และคอลัมน์ Size หากเราคลิกคอลัมน์สุดท้ายนั้น จัดเรียงน้ำหนักจากใหญ่ที่สุดไปเล็กที่สุดและจากเล็กที่สุดไปใหญ่ที่สุด

ดูน้ำหนัก เราสามารถเห็น ตามที่เกิดในกรณีส่วนใหญ่ ว่ารูปภาพรับผิดชอบส่วนใหญ่ของน้ำหนักที่มากเกินของ URL

ไม่มีข้อกำหนดทางการสำหรับน้ำหนักสูงสุดที่รูปภาพควรมี แต่เราขอแนะนำไม่เกิน 100 KB และหากคุณมีตัวเลือก (หากใช้ Photoshop คุณมี) ตั้งรูปภาพให้โหลดก้าวหน้าเป็น JPG และหลีกเลี่ยง PNG เมื่อใดที่ไม่ต้องการ Alpha channel (transparency)

โดยลดน้ำหนักรูปภาพเราจะปรับปรุงการโหลดเว็บไซต์อย่างมาก และมีเครื่องมือหลายอันที่คุณสามารถใช้ ผมส่วนตัวปรับด้วย Photoshop แต่มีตัวเลือกออนไลน์ที่น่าสนใจ:

• ›

  https://imagecompressor.io/compress

• ›

  https://kraken.io/web-interface

ทั้ง GTMetrix และเครื่องมือ Google ให้เราดูทรัพยากรตามประเภท คือ เฉพาะรูปภาพ scripts, CSS...

นี่มีประโยชน์สำหรับมุมมองที่กว้างเกี่ยวกับที่จะทำงาน ใน URL นี้ รูปภาพคิดเป็น 4 MB จาก 7.2 MB ดังนั้นส่วนใหญ่ของปัญหาน้ำหนักอยู่ที่นั่น ถึงอย่างนั้น มีทรัพยากรอื่นที่โดดเด่นว่าหนักมากสำหรับประเภท เช่นไฟล์ CSS เกิน 700 KB และ Script เกิน 300 KB

ในจุดนี้ผมต้องการชี้แจงว่าเมื่อเราดำเนินการปรับความเร็วในการโหลด (WPO) เราต้องเผชิญปัญหาบางอย่างที่แม้มีโซลูชัน ไม่อยู่ในเอื้อมในการดำเนินการ

ในกรณีนี้เราเห็นไฟล์ CSS ใหญ่มาก หากผู้ออกแบบสร้าง CSS เกิน 700 KB การปรับไฟล์เฉพาะนั้นจะยาก

เราสามารถทำอะไรในการลดน้ำหนักของไฟล์เหล่านี้?

Minify (CSS, JS และ HTML)

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

เครื่องมือในการ minify ไฟล์

• ›

  HTML Minifier http://kangax.github.io/html-minifier/

• ›

  CSS Nano https://cssnano.co/

• ›

  Uglify http://lisperator.net/uglifyjs/

โชคดีเรากำลังพูดถึง WordPress และตามที่เราทุกคนรู้ ใน WordPress หายากมากที่จะไม่พบ plugin ที่จัดการการดำเนินการนี้

ส่วนตัวผมชอบใช้ฟรีอย่างสมบูรณ์ Autoptimize และแบบชำระเงิน WP Rocket

ในบทความนี้ผมไม่ต้องการอธิบายวิธีที่ plugins เหล่านี้ทำงานมากเท่าวิธีดำเนินการงานปรับ เพราะหากเราใช้ plugins อื่น ก็มีตัวเลือกเหล่านี้ และสิ่งที่ดีที่สุดคือ เข้าใจสิ่งที่เรากำลังทำ

Minifying กับ WP Rocket

ส่วนนี้ไม่ซับซ้อน เราเพียงไปที่แท็บการปรับไฟล์และทำเครื่องหมายกล่อง minify HTML ใน WP Rocket ตัวเลือกนี้ซ้ำด้านล่างสำหรับไฟล์ CSS และ JS ถึงอย่างนั้น ผมแนะนำเปิดใช้กล่องนี้และทดสอบ ทำตัวเลือกนี้ทีละอัน เพราะหากบางอย่างล้มเหลวจะง่ายกว่าในการระบุปัญหา

ก่อนตรวจสอบผลของ minification เราต้องล้าง cache มิฉะนั้นเราจะไม่เห็นผลของ HTML ที่อัปเดต

ล้าง cache เบราว์เซอร์อย่างไร?

plugins ประเภทเหล่านี้มาพร้อมตัวเลือกในการล้าง cache ที่เราสามารถเห็นที่ด้านบน

อีกวิธีคือผ่านเบราว์เซอร์ เมื่อ Google Developer Tools เปิดใช้ (Ctrl + Shift + I)

คลิกขวาบนลูกศร "reload page" และเลือก "empty cache and hard reload"

Minifying กับ Autoptimize

ด้วย Autoptimize การกระทำ optimize เป็นที่ดำเนินการ minification ด้วยลักษณะเฉพาะของการเสนอตัวเลือกในการเก็บความคิดเห็น HTML ความคิดเห็นเหล่านี้ปกติเพิ่มโดยผู้พัฒนาเพื่อเก็บข้อมูลที่อาจมีประโยชน์ในอนาคต

เพื่อตรวจสอบว่าการปรับนี้มีผล เราจะไปที่ซอร์สโค้ดของ URL และควรเห็นเช่นนี้:

โค้ดกลายเป็นอ่านไม่ออกแต่ฟังก์ชันเดียวกัน

ตัวเลือกเหล่านี้ซ้ำในวิธีเดียวกันใน WP Rocket และ Autoptimize สำหรับไฟล์ CSS และ JS ตามที่ผมกล่าวก่อน ผมไม่แนะนำปรับทุกอย่างในครั้งเดียว แต่ทีละ 1 plugins เหล่านี้เก็บสำเนาของไฟล์ minified ดังนั้นการกลับไปยังต้นฉบับเป็นไปได้โดยยกเลิกการเลือกกล่องที่สอดคล้อง

ในการลดน้ำหนักหน้าเรามี 2 ตัวเลือกอีก:

• ›

  ลบหรือลด plugins ที่เพิ่ม CSS หรือ JS ในการโหลด

• ›

  ลบหรือตัดโค้ดที่ไม่ใช้จากไฟล์ CSS

2 ตัวเลือกนี้ซับซ้อนกว่าและต้องการความรู้มากกว่า เพราะคุณต้องระวังและรับประกันว่าไม่มีการเรียกจากหน้าอื่นถึงส่วนที่กำลังลบ

ในขณะที่การลบ plugins ไม่เป็นไปได้เสมอเนื่องจากทรัพยากรที่ให้ มี plugins ที่ปรับดีกว่าอื่น คือ requests น้อยกว่าและ JS เบากว่า ดังนั้นในระบบนิเวศ WordPress ที่ยอดเยี่ยมมีทางเลือกเสมอ

เวลาในการโหลด vs เวลาตอบสนอง

ตอนนี้ถึงเวลาพูดถึง requests เวลาตอบสนอง และเวลาในการโหลด ในจุดนี้เราต้องกล่าวถึงส่วนพื้นฐานของกระบวนการ: เซิร์ฟเวอร์ การปรับเซิร์ฟเวอร์ปกติอยู่นอกมือเรา ดังนั้นสำคัญที่จะเลือกโซลูชันที่มีประสิทธิภาพ

แต่มาทำทีละขั้น

Request คืออะไร?

request หรือ HTTP Request เป็นการเรียกที่ทำจากไคลเอ็นต์ไปยังเซิร์ฟเวอร์เพื่อขอทรัพยากรที่ให้ requests สามารถไปยังเซิร์ฟเวอร์ที่แตกต่าง

requests สามารถเป็น HTTP หรือ HTTPS หากเราดูโครงสร้างของ request เราสามารถวิเคราะห์ที่ความล่าช้าในเวลาเกิด

การวิเคราะห์เวลา HTTP request

ขอเราแยกแยะสิ่งที่เห็นใน timing chart นี้

• ›

  request ถูกเริ่มแต่บล็อกหรือ queued: หากบล็อกใช้เวลานานอาจเนื่องจากเหตุผลหลายอย่าง: requests ที่มีลำดับความสำคัญสูงกว่าหรือ requests มากไปยังต้นทางนี้

• ›

  DNS Lookup: เบราว์เซอร์กำลังแก้ที่อยู่ IP ของ request

• ›

  Connecting: เวลาในการเชื่อมต่อเซิร์ฟเวอร์ในการแก้ request หากเวลานี้สูง อาจบ่งบอกปัญหาเครือข่าย ข้อผิดพลาดการเชื่อมต่อ หรือเซิร์ฟเวอร์ที่หนักเกินไป

• ›

  Sending: คำขอทรัพยากรถูกส่ง

• ›

  Waiting: นี่คือเวลาที่เซิร์ฟเวอร์ใช้ในการแก้ request และส่งการตอบสนอง หากนาน มีปัญหาบนเซิร์ฟเวอร์

• ›

  Receiving: รับทรัพยากร

HTTPS request เพิ่มขั้นตอนหนึ่งอีก แสดงที่นี่

ภาพหน้าจอสองอันเหล่านี้เป็นของสองเว็บไซต์ที่แตกต่าง หนึ่งไม่ปรับ (HTTP Request) และอีกอันที่ปรับ (HTTPS Request)

หากคุณดูใกล้และเปรียบเทียบ ความแตกต่างใหญ่ที่สุดอยู่ในเวลารอ ในกรณีเหล่านี้ คุณต้องวิเคราะห์เซิร์ฟเวอร์ในรายละเอียดมากขึ้น

Server requests: เราสามารถลดอย่างไร?

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

ถึงอย่างนั้น เรามีตัวเลือกในการปรับปรุง requests แม้การกระทำเหล่านี้ไม่นำการเปลี่ยนแปลงใหญ่มายังการโหลดเว็บไซต์ ผมจะซ้ำตัวเอง: สิ่งที่ดีที่สุดคือลบทรัพยากรที่ไม่เพิ่มอะไร

รวม CSS และ JS

อีกการกระทำที่ได้รับความนิยมเมื่อปรับหน้าเว็บคือรวมทรัพยากร CSS และ JS แต่หมายความว่าอะไร?

เป้าหมายของการรวมคือลด requests โดยแลกกับการเพิ่มน้ำหนักไฟล์ การรวมหมายถึงรวมทรัพยากร CSS หรือ JS ที่แตกต่างเข้าเป็นหนึ่ง

หากเวลาตอบสนองนาน การรวมอาจเป็นประโยชน์ หากเวลาส่งช้ามาก อาจเทคนิคอื่นดีกว่า

อุดมคติคือรวมในขณะที่มีเซิร์ฟเวอร์ที่ดี ดังนั้นเราชนะทั้งสองด้าน

รวมทรัพยากรกับ WP Rocket และ Autoptimize

การดำเนินการรวมกับ plugins เหล่านี้ง่ายเหมือนก่อน เราเพียงทำเครื่องหมายกล่องที่สอดคล้อง

ใน WP Rocket ตัวเลือกในการรวม CSS และ JS เหมือนกัน แผงเหมือนกันแทบ ตามที่เราเห็นในภาพ มีกล่องในการเพิ่มเส้นทางของไฟล์ที่เราไม่ต้องการรวม

ใต้ checkbox เรายังเห็นหมายเหตุเกี่ยวกับการไม่ใช้ตัวเลือกรวมหากเราใช้ HTTP/2 บทความนี้อธิบายเพิ่มเกี่ยวกับ HTTP/2

Autoptimize เสนอ ตัวเลือกมากในการทำงานกับ CSS และลด requests ในตัวเลือกที่ผมทำเครื่องหมาย รวมและให้คุณคำเตือนเกี่ยวกับผลที่อาจมี แต่ในที่สุดนี่สัมพัทธ์เสมอ

ในส่วนแรกของบทความนี้ ผมต้องการอธิบายสิ่งที่การกระทำพื้นฐานบางอย่างประกอบด้วย ที่เรามักเห็นในแทบทุก plugins ปรับ WPO แต่ยังมีมากที่เราสามารถทำเพื่อปรับปรุงทั้ง requests และเวลาในการโหลด

การกำหนดค่า Cache

ไม่ต้องสงสัย การปรับ cache เป็นหนึ่งในการกระทำที่เราจะสังเกตการปรับปรุงที่ใหญ่ที่สุดในวิธีที่เว็บไซต์โหลด ในบทความเกี่ยวกับ SEO สำหรับ WordPress นี้ผมอธิบายวิธีที่ cache ทำงาน ผมส่งเสริมคุณดูเพื่อเข้าใจวิธีทำงาน

Autoptimize และ WP Rocket ดำเนินการ caching แต่ WP Rocket ให้คุณตัวเลือกอีกคู่ คุ้มค่าสังเกตว่า plugins เปลี่ยนการปรับนี้เป็นสิ่งเรียบง่าย: คุณแทบมีตัวเลือกคู่และกระบวนการรวดเร็วและไม่เจ็บปวด

ตามที่เห็น WP Rocket ให้คุณทำงาน 4 สิ่ง:

• ›

  เปิดใช้ caching สำหรับอุปกรณ์มือถือ

• ›

  บันทึกไฟล์แยกสำหรับอุปกรณ์มือถือ

• ›

  เปิดใช้ caching สำหรับผู้ใช้ที่ login

• ›

  ระบุเวลาในการล้าง cache

ขึ้นอยู่กับแต่ละโครงการตัวเลือกใดที่เลือก แต่ด้วยทั้งหมดในใจ คำแนะนำของผมคือ:

• ›

  Cache มือถือเสมอ เพราะแม้เว็บไซต์ส่วนใหญ่ responsive มีเนื้อหาที่คุณอาจมีบนมือถือแต่ไม่ใช่บนเดสก์ท็อป

• ›

  ไฟล์แยก

• ›

  ไม่มี cache สำหรับผู้ใช้ที่ login เหนือสิ่งอื่นใดเพราะหากผมกำลังแก้ไข ผมไม่ต้องการ caching

• ›

  เวลา cache ที่ขึ้นอยู่กับการเปลี่ยนแปลงที่คุณทำกับเว็บไซต์ หากเว็บไซต์ข่าวประจำวัน สั้น หากเป็นเนื้อหาที่ไม่อัปเดตบ่อย นานกว่า

Lazyload

คุณสมบัติ lazyload ช่วย แสดงทรัพยากร (รูปภาพและ Iframes) เมื่อผู้ใช้ต้องการ คือ เบราว์เซอร์ไม่โหลดทรัพยากรเหล่านี้จนกว่าผู้ใช้เลื่อน คุณสมบัตินี้ใช้งานในหลาย plugins และยังมาเป็นกำหนดค่าล่วงหน้าในธีม WordPress บางอัน จากเวอร์ชัน Chrome 76 มาเป็นเนทีฟในเบราว์เซอร์

นี่หมายถึงโดย เพิ่มแอตทริบิวต์ loading="lazy" เบราว์เซอร์ตีความ lazy loading ของรูปภาพแล้ว แต่แน่นอนไม่ใช่ทุกเบราว์เซอร์จะตีความนี้ ดังนั้นผมแนะนำใช้ plugin ต่อ ที่นี่คือวิดีโอที่ดึงจาก web.dev แสดงตัวอย่างของสิ่งที่ image lazy loading เกี่ยวกับ

การปรับ Iframe

หากเราใช้ iframes ในการฝังเนื้อหาจากเว็บไซต์อื่น เรามีสองการกระทำที่เราสามารถใช้ในการปรับปรุงการโหลด

• ›

  Lazy loading ผ่านฟังก์ชัน lazyload

• ›

  หรือแทนที่ iframe ด้วยรูปภาพจนกว่าผู้ใช้คลิก

ทั้งตัวเลือกแรกและที่สองสามารถเปิดใช้ผ่าน plugin หลักของเราอีกครั้ง WP Rocket

Autoptimize ไม่มีส่วนนี้แต่เสนอการติดตั้ง plugin เสริมในการทำ https://wordpress.org/plugins/wp-youtube-lyte/

การโหลด deferred ของไฟล์ JS ด้วย Defer หรือ Async

ไฟล์ JS เป็นหนึ่งในผู้ร้ายของสิ่งที่ audits ความเร็วเรียก render blocking ของหน้า สิ่งนี้เกิดเมื่อขณะการเรนเดอร์ เบราว์เซอร์หยุดในการดาวน์โหลดไฟล์ JS และดำเนินการ เป้าหมายของการปรับ WPO คือส่งข้อมูลให้ผู้ใช้โดยเร็วที่สุดเท่าที่จะเป็นไปได้ ด้วยเหตุนี้นี่ถือเป็นการบล็อก เพราะไม่มีการเรนเดอร์จนกว่า JS ที่ดาวน์โหลดดำเนินการ

ด้วยเหตุนี้การกระทำประเภทนี้มักถูกระบุใน audit เมื่อใช้ plugins บุคคลที่สามหรือธีมที่ไม่ปรับดี เราสามารถมี JS ที่บล็อกการเรนเดอร์เพราะเช่นใน header

ในกรณีเหล่านี้เราควรใช้สองแอตทริบิวต์ที่เพิ่มในโค้ดเรียก JS Defer และ Async เพื่อให้แอตทริบิวต์เหล่านี้ทำงาน scripts ต้องเป็นภายนอก

ที่ SEO Alive เราใช้ plugin Pre Party Resource Hints ที่ให้คุณเลือกไฟล์ใดและวิธีโหลดใดที่คุณต้องการใช้ ความน่าทึ่ง!

ความแตกต่างระหว่าง Defer และ Async คืออะไร?

แม้ว่าทั้งสองแอตทริบิวต์มีเป้าหมายคล้าย ป้องกันการตีความ DOM HTML จากการหยุดโดย JS มีความแตกต่างที่โดดเด่นระหว่างทั้งสอง

ด้วย แอตทริบิวต์ Async ทรัพยากรถูกดาวน์โหลดโดยไม่หยุดการโหลด HTML แต่เมื่อดาวน์โหลด การโหลด HTML ถูกหยุดในการดำเนินการ JS ด้วยแอตทริบิวต์ defer ทรัพยากรยังถูกดาวน์โหลดควบคู่กับการโหลด HTML แต่ รันเมื่อการโหลดเสร็จ ดังนั้นไม่มีการบล็อกโดยสคริปต์

ในเรื่องนี้มีความแตกต่างระหว่าง WP Rocket และ Autoptimize WP Rocket ทำการตัดสินใจง่ายกว่ามากสำหรับคุณและดำเนินการในวิธีกึ่งอัตโนมัติเพื่อไม่ให้ JS บล็อกการเรนเดอร์ ใน Autoptimize ในทางกลับกัน คุณสามารถสลับเฉพาะตัวเลือก Async

ใน Autoptimize ภายใต้แท็บ extra เรามีตัวเลือกนี้ในการเพิ่มไฟล์ JS ที่ต้องการโหลดด้วย Async แต่สำหรับความยืดหยุ่นที่มากกว่าพวกเขาแนะนำ plugin เสริมอีกอัน "Async Javascript"

ด้วย plugin นี้เราสามารถทำงานกับทั้ง Defer และ Async และยังเสนอตัวเลือก one-click ในการทำให้สิ่งต่างง่าย สิ่งที่ดีของ plugin นี้คือเราสามารถทำงานกับ scripts และยกเว้นที่เห็นว่าจำเป็น ใน WP Rocket ในทางกลับกัน เราต้องไว้วางใจสิ่งที่ plugin ทำ แม้ทำดี

ตัวเลือกนี้อยู่ในแท็บการปรับไฟล์เดียวกัน

CDN คืออะไรและช่วยเราอย่างไร?

CDN คือสิ่งที่รู้จักว่าเครือข่ายการกระจายเนื้อหา CDN รับผิดชอบในการบันทึกส่วนของข้อมูลและทรัพยากรเพื่อบรรเทาภาระของเซิร์ฟเวอร์สำหรับทรัพยากรเหล่านั้นและตอบสนองดีขึ้นกับการโหลด CDNs ยังมีฟังก์ชันสำเนาทางภูมิศาสตร์ในการรักษาทรัพยากรพร้อมใช้ที่จุดที่แตกต่างและให้บริการให้ผู้ใช้ไม่ว่าเชื่อมต่อจากที่ใด ปกติบริการประเภทนี้ใช้สำหรับไฟล์หนักเช่นรูปภาพและวิดีโอ

การสมัครบริการนี้สำคัญเมื่อเรามีเว็บไซต์ที่มีผู้เข้าชมมาก แม้ว่าไม่ควรตัดออกสำหรับเว็บไซต์ที่มีผู้เข้าชมน้อย

การกระทำอื่นที่จะทำให้เราได้การปรับปรุงเพิ่มเล็กน้อย

ในการสรุปบทความเรามีการปรับปรุง 3 อันอีก ที่แม้ว่าจะไม่ผลิตการเปลี่ยนแปลงใหญ่ในเวลาในการโหลด จะช่วยลด requests และในที่สุดนั่นคือสิ่งที่เราต้องการ

การปรับฟอนต์

การปรับฟอนต์ สามารถทำผ่าน plugins หรือด้วยตนเองโดยแก้ไขและปรับ CSS อุดมคติจะเป็นเรียกเฉพาะฟอนต์ที่จะใช้และไม่ใช่ ตามที่เกิดในหลายกรณี ดาวน์โหลดไฟล์พร้อม Google Fonts ทั้งหมด

Autoptimize มีตัวเลือกในการทำงานกับฟอนต์

ยากที่จะพูดว่าตัวเลือกใดที่จะเลือกโดยไม่เห็นโครงการ เพราะผมไม่รู้ว่าฟอนต์ใดที่เทมเพลตของคุณใช้และเมื่อโหลด ดังนั้นสิ่งที่ดีที่สุดคือทดสอบและดูผล

ตามที่เห็น หลังจากตัวเลือก Google Fonts เรามี "Remove Emoji" ที่จะประหยัด request ไปยังเซิร์ฟเวอร์ ฟังก์ชันคือเพียงแปลงสัญลักษณ์ที่แทนอีโมจิเป็นไอคอน

WP Rocket ยังให้เรา ปิดใช้อีโมจิเหล่านี้ และยังเสนอตัวเลือกในการป้องกันเนื้อหาจากการฝังบนเว็บไซต์บุคคลที่สาม

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

ผมหวังว่าคู่มือการปรับ WPO นี้มีประโยชน์และคุณสามารถใช้กับโครงการของคุณหรือสำหรับลูกค้าของคุณ