วิธีการกำจัด Render-Blocking Resources

เผยแพร่แล้ว: 2022-12-06

ทรัพยากรการปิดกั้นการแสดงผลเป็นส่วนสำคัญในการเพิ่มประสิทธิภาพโครงสร้างพื้นฐานของหน้าเว็บของคุณ

การลดขนาดจะช่วยให้โหลดหน้าเว็บได้เร็วขึ้นมากและช่วยปรับปรุง Core Web Vitals ของหน้าเว็บได้อย่างมาก

ทรัพยากรการบล็อกการแสดงผลเหล่านี้รวมถึงสิ่งต่างๆ เช่น แบบอักษรภายนอกที่ใช้เวลาโหลดนานเกินไป (ที่ไม่จำเป็นต้องใช้) ไฟล์มีเดียที่ไม่จำเป็น การขยายโค้ดที่ไม่ยอมหายไป และปลั๊กอินเพิ่มเติมที่ไม่ได้ จำเป็น.

มีทรัพยากรประเภทนี้มากมายที่คุณสามารถบีบอัดและรวมเข้าด้วยกันเพื่อสร้างไฟล์เดียวที่ดาวน์โหลดได้เร็วขึ้นบนอุปกรณ์ของคุณ สร้างความเร็วของเพจที่เร็วขึ้นมาก

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

ในความเป็นจริง ประโยชน์ทั้งหมดของการทำกระบวนการนี้รวมถึง:

  • ความเร็วหน้าเร็วขึ้น
  • Google ต้องการทรัพยากรน้อยลงในการโหลดหน้าของคุณ
  • ลดปัญหาที่เกิดจาก Code bloat
  • ขนาดไฟล์โดยรวมที่เล็กลงของ DOM (โมเดลวัตถุเอกสาร)
  • ไฟล์ JavaScript และ CSS ให้ดาวน์โหลดน้อยลง
  • การปรับใช้ที่ดีขึ้นและเร็วขึ้นในแพลตฟอร์มและอุปกรณ์ต่างๆ
  • ปรับปรุงการโต้ตอบของผู้ใช้บนมือถือ
  • ปรับปรุงประสิทธิภาพโดยรวม

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

เหตุใดคุณจึงควรระบุทรัพยากรการปิดกั้นการแสดงผล

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

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

ในปี 2021 เวลาเฉลี่ยที่ใช้ในการแสดงหน้าเว็บบนมือถืออย่างสมบูรณ์คือ 22 วินาที ในปี 2561 มีเวลา 15 วินาที

เห็นได้ชัดว่านี่เป็นตัวเลขที่สูงกว่าเวลาที่ Google แนะนำ 2-3 วินาทีอย่างมาก นอกจากนี้ยังสูงกว่าที่เคยเป็นมาก

อะไรเป็นสาเหตุของปัญหาเหล่านี้กับทรัพยากรการบล็อกการเรนเดอร์

อะไรทำให้ความเร็วในการเรนเดอร์หน้าเว็บโดยรวมเพิ่มขึ้น

แนวโน้มที่น่าสนใจประการหนึ่งที่ควรทราบก็คือมีการพึ่งพาแบบอักษรของบุคคลที่สามมากขึ้นเมื่อเทียบกับแบบอักษรของระบบ การใช้แบบอักษรของบุคคลที่สามเป็นทรัพยากรมีแนวโน้มที่จะรบกวนการประมวลผลและการแสดงผลของเพจ

ด้วยแบบอักษรของระบบ เบราว์เซอร์ไม่ต้องโหลดอะไรเพิ่มเติม ดังนั้นจึงไม่มีขั้นตอนการประมวลผลเพิ่มเติม

นี่คือสถิติของ Web Archive สำหรับการใช้แบบอักษรบนเว็บของบุคคลที่สาม ภาพหน้าจอจาก Web Almanac พฤศจิกายน 2022

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

นอกจากนี้ บริการของ Google เองมีแนวโน้มที่จะมีผลกระทบอย่างมากต่อเวลาในการแสดงผล เช่น Google Analytics หรือการใช้พิกเซล Facebook ของบุคคลที่สามเพื่อวัตถุประสงค์ในการติดตาม

ความปรารถนาที่จะพึ่งพาเทคโนโลยีดังกล่าวไม่จำเป็นต้องน่ากลัวจากมุมมองทางการตลาด

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

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

นอกจากนี้ยังมีความเป็นไปได้ที่การพัฒนาเว็บที่ไม่ดีซึ่งนักพัฒนาเว็บใช้อยู่ในปัจจุบันอาจถูกตำหนิ

ไม่ว่าจะด้วยวิธีใด นี่คือบางสิ่งในโครงการเว็บไซต์ทุกแห่งที่ควรระบุให้เป็นส่วนหนึ่งของการตรวจสอบ Core Web Vitals ของคุณ

อย่างไรก็ตาม ประสบการณ์การใช้งานหน้าเว็บไม่ได้ขึ้นอยู่กับความเร็วในการโหลดหน้าเว็บทั้งหมดเท่านั้น

แต่จะเกี่ยวกับประสบการณ์โดยรวมของหน้าเว็บที่วัดโดยเฟรมเวิร์กประสบการณ์หน้าเว็บของ Google หรือ Core Web Vitals มากกว่า

นี่คือเหตุผลที่คุณต้องการปรับปรุงและเพิ่มประสิทธิภาพความเร็วหน้าของคุณสำหรับเส้นทางการแสดงผลที่สำคัญตลอดทั้ง DOM หรือโมเดลวัตถุเอกสาร

เส้นทางการแสดงผลที่สำคัญคืออะไร?

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

นี่เป็นกระบวนการที่อาจใช้เวลาเพียงไม่กี่มิลลิวินาทีหากคุณปรับอย่างเหมาะสม

การปรับให้เหมาะสมสำหรับเส้นทางการเรนเดอร์ที่สำคัญหมายถึงการทำให้แน่ใจว่าคุณได้ปรับให้เหมาะสมสำหรับประสิทธิภาพการเรนเดอร์บนอุปกรณ์ต่างๆ

สิ่งนี้ทำได้โดยการเพิ่มประสิทธิภาพเส้นทางการเรนเดอร์ที่สำคัญเพื่อไปยังสีแรกของคุณโดยเร็วที่สุด

โดยทั่วไป คุณกำลังลดระยะเวลาที่ผู้ใช้ใช้มองหน้าจอสีขาวว่างเปล่าเพื่อแสดงเนื้อหาภาพโดยเร็วที่สุด (ดู 0.0 วินาทีด้านล่าง)

กราฟิกแสดงขั้นตอนของเส้นทางการแสดงผลที่สำคัญของหน้าเว็บทั่วไป ภาพหน้าจอจาก web.dev พฤศจิกายน 2022

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

เส้นทางการแสดงผลที่สำคัญทำงานอย่างไร

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

ตัวอย่างของเส้นทางการแสดงผลที่สำคัญ ภาพหน้าจอจาก Medium พฤศจิกายน 2022

โดยพื้นฐานแล้ว เบราว์เซอร์จำเป็นต้องขอ รับ และแยกวิเคราะห์ไฟล์ HTML และ CSS ทั้งหมด (รวมถึงงานเพิ่มเติมบางอย่าง) ก่อนที่มันจะเริ่มแสดงเนื้อหาภาพใดๆ

กระบวนการนี้เกิดขึ้นภายในเสี้ยววินาที (ในกรณีส่วนใหญ่) ผู้ใช้จะเห็นหน้าว่างสีขาวจนกว่าเบราว์เซอร์จะทำตามขั้นตอนเหล่านี้เสร็จสิ้น

ต่อไปนี้เป็นตัวอย่างของวิธีที่ผู้ใช้อาจพบวิธีการโหลดหน้าเว็บตามขั้นตอนต่างๆ ของกระบวนการโหลดหน้าเว็บ:

วิธีที่ผู้ใช้รับรู้ถึงการแสดงหน้า ภาพหน้าจอจาก web.dev พฤศจิกายน 2022

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

ฉันจะปรับเส้นทางการแสดงผลที่สำคัญให้เหมาะสมได้อย่างไร

ในการปรับปรุงเส้นทางการแสดงผลที่สำคัญ คุณต้องวิเคราะห์ทรัพยากรการบล็อกการแสดงผลของคุณ

ทรัพยากรที่บล็อกการแสดงผลอาจลงเอยด้วยการบล็อกการแสดงผลเริ่มต้นของหน้าและส่งผลเสียต่อคะแนน Core Web Vitals ของคุณ

สิ่งนี้เกี่ยวข้องกับกระบวนการเพิ่มประสิทธิภาพของ:

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

การทำเช่นนี้ทำให้สามารถปรับปรุงทั้ง Core Web Vitals และวิธีการแสดงผลหน้าเว็บต่อผู้ใช้

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

และกระบวนการนี้เกี่ยวข้องกับ:

  • กำลังโหลดองค์ประกอบของหน้าล่วงหน้า
  • อินไลน์สไตล์ที่สำคัญ
  • ชะลอการโหลดไฟล์ JavaScript
  • คำแนะนำเบื้องต้น

โหลดองค์ประกอบของหน้าล่วงหน้า

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

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

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

การโหลดองค์ประกอบล่วงหน้าเป็นเทคนิคที่ช่วยกำจัดสไตล์ชีตที่ปิดกั้นการเรนเดอร์ เนื่องจากองค์ประกอบจะโหลดไฟล์สำคัญที่จำเป็นสำหรับขั้นตอนการลงสีขั้นแรกของกระบวนการก่อนที่จะโหลดไฟล์อื่นๆ ทั้งหมด

คุณสามารถโหลด CSS, JS, ฟอนต์ หรือรูปภาพล่วงหน้าได้ ตัวอย่างวิธีการโหลดไว้ล่วงหน้ามีดังนี้

การโหลด JavaScript ล่วงหน้า

 <link rel="preload" as="script" href="critical.js">

การโหลด CSS ล่วงหน้า

 <link rel="preload" href="style.css" as="style" />

กำลังโหลดฟอนต์ล่วงหน้า

 <link rel="preload" href="fonts/webfont.woff2" as="font" type="font/woff2" crossorigin />

โหลดรูปภาพล่วงหน้า

 <link rel=preload href="cat.png" as=image รูปภาพ>

สิ่งนี้จะช่วยเร่งกระบวนการของเพจ อย่างไรก็ตาม นี่ไม่ใช่วิธีที่เหมาะ

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

น่าเศร้าที่นี่ไม่ใช่ความพยายามที่แท้จริงในการติดตาม

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

Inlining Critical Style

Critical CSS เป็นเทคนิคที่แยก CSS สำหรับเนื้อหาครึ่งหน้าบนเพื่อแสดงเนื้อหาแก่ผู้ใช้โดยเร็วที่สุด

อย่างน้อยที่สุด มักจะต้องใช้:

  • การประกาศแบบอักษรใด ๆ
  • CSS เฉพาะเลย์เอาต์ใด ๆ
  • กฎสไตล์ CSS ทั้งหมดสำหรับองค์ประกอบ DOM (รูปแบบวัตถุเอกสาร) ครึ่งหน้าบน

จากตัวอย่างก่อนหน้าของเราในการโหลดทรัพยากรทั้งหมดพร้อมกัน การแทรกสไตล์ที่สำคัญเกี่ยวข้องกับการใช้โค้ดภายในแท็ก HTML <head> เอง

หากคุณตรวจสอบ เช่น ซอร์สโค้ด google.com คุณจะเห็น CSS ที่สำคัญแทรกอยู่ในส่วน <head> ของ HTML

ซอร์สโค้ด Google.com ภาพหน้าจอจากซอร์สโค้ด Google.com พฤศจิกายน 2022

มีเครื่องมือหลายอย่างที่สามารถช่วยแยก CSS ที่สำคัญได้

  • Criticalcss.com.
  • วิกฤต.
  • ปลั๊กอิน HTML ที่สำคัญของ Webpack

การเลื่อนการโหลดไฟล์ JavaScript

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

ตัวอย่างวิธีการเลื่อนไฟล์ JavaScript:

 <สคริปต์เลื่อน src="script.js"></script>

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

ข้อสองคือ หากคุณไม่ระวัง การชะลอการโหลดไฟล์ JavaScript อาจทำให้เกิดปัญหาเกี่ยวกับการโต้ตอบของเพจ (การโต้ตอบกับเมตริก Core Web Vitals ถัดไปของโปรแกรมระบายสี)

ข้อสามคือคุณสามารถแนะนำปัญหาเกี่ยวกับวิธีการทำงานของไซต์โดยรวม

แนวคิดคือคุณต้องระมัดระวังเมื่อคุณทำงานกับการเพิ่มประสิทธิภาพประเภทนี้ ดังนั้นคุณจะไม่ทำให้เกิดปัญหาที่อื่นในกระบวนการโดยไม่ได้ตั้งใจ

เมื่อทำเช่นนั้น คุณจะส่งผลอย่างมากต่อความเร็วหน้าเว็บและวิธีที่ Google เห็นไซต์ของคุณ

ข้อกังวลอื่น ๆ คือเมื่อคุณใช้ปลั๊กอินเช่น Nitro เพื่อเลื่อนไฟล์ที่สำคัญเช่น CSS และ JavaScript

แม้ว่าสิ่งนี้อาจส่งผลดีต่อความเร็วของหน้า แต่ปัญหาหลักคือปลั๊กอินจะเลื่อนไฟล์ที่สำคัญทั้งหมดออกไปจนกว่าจะโหลดส่วน HTML ของเอกสารในหน้านั้น

สิ่งนี้หมายความว่า? ซึ่งหมายความว่า Google ไม่สามารถมองเห็นเอกสารทั้งหมดตามที่ตั้งใจให้แสดง ซึ่งคล้ายกับการบล็อกไฟล์ CSS และไฟล์ JavaScript โดยใช้ robots.txt ซึ่ง Google จำเป็นต้องพิจารณาว่าไซต์ของคุณเหมาะกับมือถือหรือไม่

หน้า Google Developer อย่างเป็นทางการกล่าวไว้ตามที่กล่าวไว้ที่อื่น:

“สำหรับการแสดงผลและการจัดทำดัชนีที่ดีที่สุด ให้อนุญาตให้ Googlebot เข้าถึง JavaScript, CSS และไฟล์ภาพที่เว็บไซต์ของคุณใช้เสมอ เพื่อให้ Googlebot สามารถเห็นเว็บไซต์ของคุณได้เหมือนผู้ใช้ทั่วไป

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

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

ใช้คำแนะนำเบื้องต้นเพื่อเพิ่มประสิทธิภาพเซิร์ฟเวอร์ให้ดียิ่งขึ้น

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

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

ดังนั้น เมื่อสิ่งนี้เกิดขึ้น เวลาในการตอบสนองที่มากกว่าปกติจะเกิดขึ้น – และสิ่งนี้จะเกิดขึ้นก่อนที่เบราว์เซอร์จะเริ่มแสดงผลหน้าเว็บ

เมื่อเวลาแฝงเกิดขึ้น คุณอาจพบกับสถานการณ์ที่ไซต์อาจใช้เวลาสองสามวินาทีก่อนที่จะปรากฏในหน้าต่างเบราว์เซอร์

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

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

คำแนะนำเบื้องต้น ภาพหน้าจอจาก developer.chrome.com พฤศจิกายน 2022

ดังนั้นคำแนะนำล่วงหน้าทำงานอย่างไร

ตามคู่มือนักพัฒนา Google Chrome “คำแนะนำเบื้องต้นคือรหัสสถานะ HTTP (103 คำแนะนำเบื้องต้น) ซึ่งใช้เพื่อส่งการตอบสนอง HTTP เบื้องต้นที่แม่นยำก่อนการตอบกลับขั้นสุดท้าย”

สิ่งนี้ทำให้สำเร็จได้อย่างไร

ซึ่งช่วยให้เซิร์ฟเวอร์สามารถให้คำแนะนำบางประเภทแก่เบราว์เซอร์สำหรับทรัพยากรที่สำคัญบางอย่าง (ไฟล์ JavaScript, สไตล์ชีต CSS และอื่นๆ) ที่หน้าเว็บน่าจะโหลดและใช้งาน

กระบวนการนี้เกิดขึ้นในช่วงเวลาไม่กี่มิลลิวินาทีหรือน้อยกว่า ในขณะที่เซิร์ฟเวอร์ทำงานในการแสดงผลทรัพยากรของหน้าหลัก

คำแนะนำล่วงหน้าเป็นสิ่งที่ "ช่วยให้เบราว์เซอร์พร้อม" และเร่งเวลาคิดของเซิร์ฟเวอร์โดยการทำงานล่วงหน้าในการโหลดนี้

ด้วยเหตุนี้ กระบวนการนี้จึงช่วยเพิ่มความเร็วในการโหลดหน้าเว็บ

เครื่องมือที่จะช่วยคุณเพิ่มประสิทธิภาพเส้นทางการแสดงผลที่สำคัญของคุณ

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

ไม่ต้องกลัว (มากเกินไป!) มีปลั๊กอิน WordPress ที่สามารถช่วยคุณได้

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

  • ปลั๊กอิน CSS ที่สำคัญ : เครื่องมือที่มีประโยชน์นี้ช่วยให้คุณสร้าง CSS สำคัญที่เว็บไซต์ของคุณต้องการ เพียงเพิ่ม URL ของคุณ คลิกที่สร้าง แล้วไปได้เลย
  • Autoptimize Page Speed ​​Plugin: ปลั๊กอินนี้เป็นอีกหนึ่งปลั๊กอินความเร็วของเพจที่ช่วยให้คุณสามารถเลื่อนไฟล์สำคัญออกไปได้ นอกจากนี้ยังช่วยแทรก CSS แบบอินไลน์ลงในส่วนหัวของหน้า เลื่อนสคริปต์ไปที่ส่วนท้าย และย่อขนาดไฟล์ HTML ของคุณ
  • ปลั๊กอินความเร็วเพจจรวด WP: ปลั๊กอิน ความเร็วเพจนี้เป็นหนึ่งในปลั๊กอินแคชที่ทรงพลังที่สุด หลังการติดตั้ง ปลั๊กอินเฉพาะนี้จะช่วยให้คุณสามารถใช้ประโยชน์จากการแคชเพจ การบีบอัด GZIP การโหลดแคชล่วงหน้า และการแคชเบราว์เซอร์
  • WP-Optimize: นี่คือปลั๊กอิน WordPress ที่ให้คุณทำหลายสิ่งหลายอย่างเพื่อช่วยเพิ่มประสิทธิภาพไซต์ของคุณให้ดียิ่งขึ้นสำหรับการโหลดที่รวดเร็ว ซึ่งรวมถึงการเพิ่มประสิทธิภาพฐานข้อมูลของคุณ บีบอัดรูปภาพของคุณ และแคชหน้าของคุณ พร้อมกับลดขนาดและซิงโครไนซ์ไฟล์ CSS และ JavaScript ของคุณ

โปรดทราบ: ผู้เขียนคนนี้ไม่มีอคติทางการเงินใดๆ กับเครื่องมือเหล่านี้

ทำไมฉันต้องสนใจ?

ข้อมูลพฤติกรรมผู้ใช้ของ Google รายงานว่าผู้ใช้ส่วนใหญ่ออกจากไซต์ที่ช้าหลังจากผ่านไปประมาณสามวินาที

นอกจากการศึกษาที่แสดงว่าการลดเวลาในการโหลดหน้าเว็บและการปรับปรุงประสบการณ์การใช้งานหน้าเว็บทำให้ผู้ใช้พึงพอใจมากขึ้นแล้ว ยังมีการอัปเดตที่สำคัญๆ ของ Google อีกหลายรายการที่คุณจะต้องเตรียมพร้อม

การระบุและเพิ่มประสิทธิภาพทรัพยากรการบล็อกการเรนเดอร์จะมีความสำคัญต่อการอยู่เหนือเกมเมื่อมีการอัปเดตเหล่านี้

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

จากข้อมูลของ Google ตัวชี้วัด Core Web Vitals สามตัวเดียวกัน (LCP, FID และ CLS) พร้อมกับเกณฑ์ที่เกี่ยวข้องจะเชื่อมโยงกับการจัดอันดับเดสก์ท็อป

นอกจากนี้ Google กำลังทำงานกับเมตริก Core Web Vitals ใหม่ล่าสุดที่อาจอยู่ระหว่างการทดลอง โดยคำนึงถึงระยะเวลาสูงสุดของเหตุการณ์และระยะเวลาของเหตุการณ์ทั้งหมด

คำอธิบายของพวกเขาเกี่ยวกับปัจจัยเหล่านี้ที่พวกเขากำลังพิจารณาคือ:

ระยะเวลาสูงสุดของเหตุการณ์: เวลาแฝงของการโต้ตอบจะเท่ากับระยะเวลาของเหตุการณ์เดี่ยวที่ใหญ่ที่สุดจากเหตุการณ์ใดๆ ในกลุ่มการโต้ตอบ
ระยะเวลาของ เหตุการณ์ทั้งหมด: เวลา ในการตอบสนองของการโต้ตอบคือผลรวมของระยะเวลาของเหตุการณ์ทั้งหมด โดยไม่สนใจการทับซ้อนใดๆ

ด้วยการศึกษาจำนวนมากที่เชื่อมโยงการลดเวลาในการโหลดหน้าเว็บเข้ากับการปรับปรุง KPI ที่มีค่า (คอนเวอร์ชั่น อัตราตีกลับ เวลาบนไซต์) การปรับปรุงเวลาแฝงของไซต์จึงกลายเป็นเป้าหมายทางธุรกิจอันดับต้น ๆ สำหรับหลาย ๆ องค์กร

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

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

เป้าหมายของการเพิ่มประสิทธิภาพทรัพยากรการปิดกั้นการแสดงผล

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

ทรัพยากรที่ปิดกั้นการแสดงผลจะต้องถูกลดความสำคัญลง และทรัพยากรใดๆ ที่ขัดขวางไม่ให้หน้าแสดงผลอย่างรวดเร็ว

การเพิ่มประสิทธิภาพแต่ละจุดจะช่วยปรับปรุงโดยรวมของความเร็วหน้าเว็บ ประสบการณ์การใช้งานหน้าเว็บ และคะแนน Core Web Vitals

ทำไมต้องปรับปรุง Render-Blocking CSS?

Google ได้กล่าวหลายครั้งว่าการเข้ารหัสไม่จำเป็นสำหรับการจัดอันดับ

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

เมื่อพูดถึงไฟล์ CSS จะถือว่าเป็นทรัพยากรที่บล็อกการเรนเดอร์

ทำไมถึงเป็นเช่นนี้?

แม้ว่าจะเกิดขึ้นภายในเวลาไม่กี่มิลลิวินาทีหรือน้อยกว่านั้น (ในกรณีส่วนใหญ่) เบราว์เซอร์จะไม่เริ่มแสดงเนื้อหาใดๆ ของหน้าจนกว่าจะสามารถร้องขอ รับ และจัดการสไตล์ CSS ทั้งหมดได้

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

ซึ่งหมายความว่าโดยพื้นฐานแล้วเพจของคุณจะ "เปลือยเปล่า" เนื่องจากไม่มีคำที่ดีกว่านี้

การลบสไตล์ CSS จะทำให้หน้าเว็บใช้งานไม่ได้อย่างแท้จริง

เนื้อหาส่วนใหญ่จะต้องทาสีใหม่เพื่อให้ดูถูกปากผู้ใช้น้อยที่สุด

วิธีการกำจัด Render-Blocking Resources

หากเราตรวจสอบกระบวนการแสดงผลหน้าเว็บ กล่องสีเทาด้านล่างแสดงถึงเวลาของเบราว์เซอร์ที่จำเป็นในการรับทรัพยากร CSS ทั้งหมด ด้วยวิธีนี้ จะสามารถเริ่มสร้าง DOM ของ CSS (หรือแผนผัง CCSOM)

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

นอกจากนี้ยังอาจแตกต่างกันไป ซึ่งอาจขึ้นอยู่กับขนาดและปริมาณของไฟล์ CSS เหล่านี้

แผนผังการเรนเดอร์ต่อไปนี้แสดงตัวอย่างเบราว์เซอร์ที่เรนเดอร์ไฟล์ทั้งหมดพร้อมกับ CSS ภายใน DOM:

DOM CSSOM Render Tree ภาพหน้าจอจาก Medium พฤศจิกายน 2022

นอกจากนี้ ข้อมูลต่อไปนี้แสดงตัวอย่างลำดับการแสดงผลของหน้า ซึ่งไฟล์ทั้งหมดโหลดในกระบวนการ ตั้งแต่การสร้าง DOM ไปจนถึงการลงสีขั้นสุดท้ายและการจัดองค์ประกอบหน้า ซึ่งเรียกว่าเส้นทางการแสดงผลที่สำคัญ .

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

คำแนะนำอย่างเป็นทางการของ Google ระบุสิ่งต่อไปนี้:

“CSS เป็นทรัพยากรที่บล็อกการเรนเดอร์ ส่งไปยังไคลเอ็นต์โดยเร็วที่สุดและเร็วที่สุดเท่าที่จะเป็นไปได้เพื่อเพิ่มประสิทธิภาพเวลาในการเรนเดอร์ครั้งแรก”

ต้องแปลง HTML เป็นสิ่งที่เบราว์เซอร์สามารถทำงานได้: DOM ไฟล์ CSS เป็นแบบเดียวกัน จะต้องแปลงเป็น CSSOM

ด้วยการเพิ่มประสิทธิภาพไฟล์ CSS ภายใน DOM และ CSSOM คุณสามารถช่วยลดเวลาที่เบราว์เซอร์ใช้ในการแสดงผลทุกอย่าง ซึ่งมีส่วนช่วยอย่างมากในการปรับปรุงประสบการณ์การใช้งานเพจ

ทำไมต้องปรับปรุง Render-Blocking JavaScript?

คุณทราบหรือไม่ว่าไม่จำเป็นต้องโหลด JavaScript เสมอไป

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

ดังนั้น นี่จึงไม่ใช่ส่วนที่จำเป็นทางเทคนิคของการเรนเดอร์หน้าเว็บ

แต่ข้อแม้สำหรับสิ่งนี้คือ: ไซต์สมัยใหม่ส่วนใหญ่เขียนโค้ดในลักษณะที่จำเป็นต้องมี JavaScript (เช่น Bootstrap JS framework) เพื่อแสดงประสบการณ์ครึ่งหน้าบน

แต่ถ้าเบราว์เซอร์พบไฟล์ JavaScript ก่อนการเรนเดอร์ครั้งแรกของเพจ กระบวนการเรนเดอร์สามารถหยุดได้จนกว่าจะดำเนินการภายหลังและหลังจากไฟล์ JavaScript ถูกเรียกใช้งานอย่างสมบูรณ์

สามารถระบุเป็นอย่างอื่นได้โดยการเลื่อนไฟล์ JavaScript เพื่อใช้ในภายหลัง

ตัวอย่างหนึ่งคือถ้ามีฟังก์ชัน JS เช่นการแจ้งเตือนที่สร้างไว้ใน HTML การดำเนินการนี้อาจหยุดการแสดงหน้าจนกว่าจะมีการเรียกใช้โค้ด JavaScript นี้

JavaScript มีอำนาจแต่เพียงผู้เดียวในการปรับเปลี่ยนรูปแบบทั้ง HTML และ CSS ดังนั้นสิ่งนี้จึงสมเหตุสมผล

การแยกวิเคราะห์และการดำเนินการของ JavaScript อาจล่าช้าเนื่องจากข้อเท็จจริงที่ว่า JavaScript สามารถเปลี่ยนเนื้อหาของหน้าทั้งหมดได้ การหน่วงเวลานี้สร้างขึ้นในเบราว์เซอร์โดยค่าเริ่มต้น – สำหรับสถานการณ์ดังกล่าว “เผื่อไว้”

คำแนะนำอย่างเป็นทางการของ Google:

“JavaScript ยังสามารถบล็อกการสร้าง DOM และทำให้หน้าแสดงผลล่าช้า เพื่อมอบประสิทธิภาพสูงสุด … กำจัด JavaScript ที่ไม่จำเป็นออกจากเส้นทางการแสดงผลที่สำคัญ”

วิธีระบุทรัพยากรการบล็อกการแสดงผล

ในการระบุเส้นทางการแสดงผลที่สำคัญและวิเคราะห์ทรัพยากรที่สำคัญ:

  • ทำการทดสอบโดยใช้ webpagetest.org และคลิกที่ภาพ "น้ำตก"
  • มุ่งเน้นไปที่ทรัพยากรทั้งหมดที่ขอและดาวน์โหลดก่อนบรรทัดสีเขียว “เริ่ม Render”

วิเคราะห์มุมมองน้ำตกของคุณ ค้นหาไฟล์ CSS หรือ JavaScript ที่ร้องขอก่อนบรรทัด "เริ่มแสดงผล" สีเขียว แต่ไม่สำคัญสำหรับการโหลดเนื้อหาครึ่งหน้าบน

ตัวอย่างการเรนเดอร์เริ่มต้น ภาพหน้าจอจาก WebPageTest พฤศจิกายน 2022

หลังจากระบุทรัพยากรที่ปิดกั้นการแสดงผล (อาจ) ให้ทดสอบการลบออกเพื่อดูว่าเนื้อหาครึ่งหน้าบนได้รับผลกระทบหรือไม่

ในตัวอย่างของฉัน ฉันสังเกตเห็นบางคำขอ JavaScript ที่อาจมีความสำคัญ

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

ตัวอย่างผลการทดสอบหน้าเว็บที่แสดงทรัพยากรการปิดกั้นการแสดงผล ภาพหน้าจอจาก WebPageTest พฤศจิกายน 2022

นอกจากนี้ยังมีวิธีอื่นในการปรับปรุงทรัพยากรดังกล่าว

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

สำหรับไฟล์ CSS ที่ไม่สำคัญ คุณยังสามารถลดจำนวนไฟล์ CSS ที่คุณมีโดยการรวมเป็นไฟล์เดียวแล้วบีบอัด

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

วิธีลดองค์ประกอบการบล็อกการแสดงผลบนหน้า

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

มีวิธีแก้ไขปัญหานี้มากมาย ตั้งแต่การเลื่อนไฟล์ JavaScript และ CSS ไปจนถึงการลดผลกระทบที่ CSS สามารถมีได้

วิธีหนึ่งที่เป็นไปได้คืออย่าเพิ่ม CSS โดยใช้กฎ @import

ตรวจสอบให้แน่ใจว่าไม่ได้เพิ่ม CSS โดยใช้ @Import Rule

จากมุมมองด้านประสิทธิภาพ แม้ว่า @import ดูเหมือนจะทำให้ไฟล์ HTML ของคุณสะอาดขึ้น แต่ก็สามารถสร้างปัญหาเกี่ยวกับประสิทธิภาพได้

การประกาศ @import จะทำให้เบราว์เซอร์ประมวลผลไฟล์ CSS ช้าลง ทำไม เพราะมันกำลังดาวน์โหลดไฟล์ที่นำเข้าทั้งหมดด้วย

การแสดงผลจะถูกบล็อกทั้งหมดจนกว่ากระบวนการจะเสร็จสิ้น

ทางออกที่ดีที่สุดคือใช้วิธีการมาตรฐานในการรวมสไตล์ชีต CSS โดยใช้การประกาศ <link rel=”stylesheet”> ใน HTML

ลดขนาดไฟล์ CSS และ JavaScript ของคุณ

หากคุณใช้ WordPress การใช้ปลั๊กอินเพื่อลดขนาดไฟล์ CSS และ JavaScript ของคุณอาจมีผลกระทบอย่างมาก

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

นอกจากนี้ แม้ว่าคุณจะไม่ได้ใช้ WordPress คุณก็สามารถใช้บริการของนักพัฒนาที่มีคุณสมบัติเหมาะสมเพื่อดำเนินการให้เสร็จสิ้นด้วยตนเองได้

การดำเนินการนี้จะใช้เวลามากขึ้นแต่ก็คุ้มค่า

ไฟล์ที่ย่อขนาดมักจะเบากว่าไฟล์เดิมมาก ซึ่งหมายความว่าการเรนเดอร์ครั้งแรกจะเสร็จเร็วกว่ามาก

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

ใช้แบบอักษรของระบบแทนแบบอักษรของบุคคลที่สาม

แม้ว่าแบบอักษรของบุคคลที่สามอาจทำให้ไซต์ "สวยขึ้น" แต่ก็ไม่ได้เป็นเช่นนั้น

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

เนื่องจากไฟล์ภายนอก เบราว์เซอร์จึงต้องส่งคำขอภายนอกเพื่อดาวน์โหลดไฟล์เหล่านี้เพื่อแสดงหน้าเว็บของคุณ ซึ่งอาจส่งผลให้เวลาในการดาวน์โหลดสูงขึ้นอย่างมาก

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

ในกรณีนี้ การลบไฟล์ที่ไม่จำเป็นเหล่านี้สามารถปรับปรุงทรัพยากรการบล็อกการแสดงผลของคุณได้อย่างมาก และมีส่วนช่วยในการปรับปรุงโดยรวมของคุณใน Core Web Vitals

ในทางกลับกัน การใช้แบบอักษรของระบบจะเก็บการประมวลผลไว้ภายในเบราว์เซอร์เท่านั้นโดยไม่มีการร้องขอจากภายนอก

นอกจากนี้ยังมีแบบอักษรของระบบที่อาจคล้ายกับแบบอักษรของบุคคลที่สามที่คุณใช้

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

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

ปัญหาอื่นๆ เมื่อใช้ฟอนต์ของบุคคลที่สามคือฟอนต์จะมองไม่เห็นจนกว่าฟอนต์จะโหลดเอง ซึ่งส่งผลเสียต่อ Core Web Vitals และประสบการณ์ของผู้ใช้ เพื่อหลีกเลี่ยงปัญหานี้ คุณสามารถใช้ CSS สลับแบบอักษร

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

เด็กใหม่บนบล็อก: แบบอักษรที่เปลี่ยนแปลงได้

ในปี 2020 แบบอักษรแปรผันได้รับการสนับสนุนอย่างกว้างขวางในเบราว์เซอร์ส่วนใหญ่ ฟอนต์แปรผันคืออะไรกันแน่?

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

นอกจากนี้ยังมีประโยชน์หลายประการในการใช้แบบอักษรแปรผัน ซึ่งรวมถึง:

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

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

ปรับปรุงเทคนิคการเข้ารหัสและการรวมไฟล์ของคุณ

หากคุณกำลังทำงานกับโค้ดด้วยตัวเอง คุณอาจ (หรืออาจไม่ใช่ … ไม่มีใครตัดสินที่นี่) พบว่าเทคนิคนั้นไม่เหมาะสม

ตัวอย่างหนึ่ง: คุณกำลังใช้ CSS แบบอินไลน์ในทุกที่ ซึ่งทำให้เกิดความผิดพลาดในการประมวลผลและการแสดงผลภายในเบราว์เซอร์

วิธีแก้ปัญหาง่ายๆ คือตรวจสอบให้แน่ใจว่าคุณใช้ CSS แบบอินไลน์ทั้งหมดและเขียนโค้ดอย่างถูกต้องภายในไฟล์สไตล์ชีต CSS

หากโค้ดของผู้พัฒนารายอื่นไม่เป็นไปตามมาตรฐาน อาจสร้างปัญหาหลักในการแสดงผลเพจได้

ตัวอย่างเช่น สมมติว่าคุณมีหน้าเว็บที่เขียนโค้ดโดยใช้เทคนิคแบบเก่ามากกว่าแบบสมัยใหม่และบางกว่า

เทคนิคที่เก่ากว่าอาจรวมถึงการขยายโค้ดจำนวนมากและส่งผลให้การแสดงผลหน้าเว็บช้าลง

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

การรวมไฟล์ยังสามารถปรับปรุงสถานการณ์ได้อีกด้วย

ตัวอย่างเช่น: หากคุณมีไฟล์ JavaScript แปดหรือ 10 ไฟล์ที่ทั้งหมดมีส่วนร่วมในงานเดียวกัน คุณสามารถจ้างนักพัฒนาที่สามารถรวมไฟล์เหล่านี้ทั้งหมดให้คุณได้

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

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

ประเด็นที่สำคัญ

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

  • ขั้นตอนที่ 1: รวบรวมข้อมูลเว็บไซต์ของคุณโดยใช้ Screaming Frog หรือเครื่องมือรวบรวมข้อมูลอื่นๆ
  • ขั้นตอนที่ 2: ระบุเพจด้วยความเร็วเพจที่ช้า
  • ขั้นตอนที่ 2ก: คุณสามารถใช้ Google Search Console หรือ Google Analytics เพื่อจุดประสงค์นี้ได้เช่นกัน
  • ขั้นตอนที่ 3: จัดเรียงเพจที่มีประสิทธิภาพต่ำที่สุดที่คุณพบในรายการที่จัดลำดับความสำคัญ
  • ขั้นตอนที่ 4: ไปที่รายการตรวจสอบด้านบน (คุณยังสามารถสร้างสเปรดชีตของแต่ละรายการต่อหน้าได้หากต้องการ) และค้นหา ลด หรือซ่อมแซมทรัพยากรที่ปิดกั้นการแสดงผลเหล่านี้ตามต้องการ
  • ขั้นตอนที่ 5: ล้างและทำซ้ำสำหรับทุกหน้าในไซต์ของคุณ

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

ด้วยกระบวนการนี้ คุณเองก็จะได้รับประโยชน์จากข้อได้เปรียบที่คุณจะได้รับ และคุณยังได้รับประสบการณ์ที่เพิ่มขึ้นจาก Core Web Vitals ของ Google

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

Google กำลังพยายามปรับปรุงความเร็วของหน้าเว็บอยู่ตลอดเวลา แต่มีสิ่งหนึ่งที่คงเส้นคงวาอยู่เสมอ: ยิ่งเพจของคุณเร็วเท่าไหร่ก็ยิ่งดีเท่านั้น

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

และสิ่งนี้ยังแปลเป็นประสบการณ์การใช้งานที่ดีขึ้นอีกด้วย

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

After all, keeping your site in top shape for prime time is what all of this optimization work is all about!

แหล่งข้อมูลเพิ่มเติม:

  • Advanced Core Web Vitals: A Technical SEO Guide
  • Difference Between Search Console CWV Report & PageSpeed Insights
  • Core Web Vitals: A Complete Guide

Featured Image: SuperOhMo/Shutterstock