บทนำ

ในปี 1991 มีการเปิดตัวโปรโตคอล HTTP ตอบกลับคำขอ (HTTP 0.9) เวอร์ชันแรกที่จัดทำเป็นเอกสาร ตั้งแต่นั้นมา เว็บได้ขยายตัวขึ้นอย่างมาก และ 24 ปีต่อมา HyperText Transfer Protocol (HTTP/2) เวอร์ชันล่าสุดได้เปิดตัวในปี 2015 ซึ่งนำเสนอประโยชน์มากมายที่เป็นไปได้ต่อประสิทธิภาพของไซต์เมื่อใช้งานอย่างถูกต้อง

บทความนี้มุ่งเป้าไปที่ SEO ที่ต้องการใช้ HTTP/2 เป็นส่วนหนึ่งของแผนริเริ่มการเพิ่มประสิทธิภาพความเร็วหน้าเว็บ

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

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

คำถามเหล่านี้ช่วยให้คุณถาม ว่า “สิ่งที่ฉันทำอยู่มีประสิทธิภาพและมีคุณค่าหรือไม่” และสุดท้ายทำให้คุณอยู่ในตำแหน่งที่ดีขึ้นในการประเมินว่า HTTP/2 สามารถช่วยปรับปรุงเว็บไซต์ได้อย่างไร

เนื่องจากลักษณะหัวข้อกว้างๆ จึงมีความรู้จำนวนมากเกี่ยวกับ HTTP/2 ที่ไม่จำเป็นเมื่อพยายามทำความเข้าใจถึงความสำคัญของ SEO ประโยชน์หลักของ HTTP/2 สำหรับ SEO คือ Page Speed

เพื่อช่วยให้คุณสำรวจข้อมูลออนไลน์มากมาย ต่อไปนี้คือข้อมูลเบื้องต้นเกี่ยวกับ HTTP/2 ซึ่งอธิบายวิวัฒนาการจาก HTTP 1.1 ไปจนถึง Spdy ที่เข้ากันได้กับ HTTP ของ Google และในที่สุดก็เป็น HTTP/2

การทำความเข้าใจว่าเว็บมีการพัฒนาอย่างไร จะช่วยเน้นย้ำถึงการปรับปรุงที่เกิดขึ้นจากการเพิ่มโปรโตคอล HTTP/2

Google ประเมิน Page Speed ​​อย่างไร

หากต้องการดูวิธีที่ Google ประเมิน Page Speed ​​นั้นไม่ต้องไปไกลกว่า รายงาน ประสบการณ์ผู้ใช้ Chrome รายงานเหล่านี้ให้ตัวชี้วัดประสบการณ์ผู้ใช้สำหรับวิธีที่ผู้ใช้กำลังประสบกับจุดหมายปลายทางยอดนิยมทั่วทั้งเว็บ ซึ่งขับเคลื่อนโดยใช้เมตริกการมีส่วนร่วมของผู้ใช้ที่สำคัญ (First Paint, First Contentful Paint, First Meaningful Paint, Time to Interactive) และได้รับการสนับสนุนเพิ่มเติมผ่านเครื่องมือทั่วไป เช่น Page Speed ​​Insights โครงการ Google Big Query สาธารณะ Lighthouse และการทดสอบหน้าเว็บ การใช้ตัวชี้วัดและเครื่องมือเหล่านี้สามารถช่วยปรับปรุงความเร็วเพจได้

บทนำสู่ HTTP/2

HTTP 1.1

ภายในปี 2015 HTTP 1.1 ล้าสมัยแล้ว หมดยุคแล้วที่หน้าเว็บ/ไซต์ถูกสร้างขึ้น/อาศัย HTML พื้นฐาน, CSS และ JavaScript ตลอดจนทรัพยากรและเฟรมเวิร์กต่างๆ มากมาย ยุคก่อนปี 2015 มีพื้นฐานมาจากแนวคิดที่ว่า คุณถูกจำกัดคำขอต่อการเชื่อมต่อ TCP หนึ่งครั้ง สิ่งนี้นำไปสู่สถานการณ์ที่เว็บไคลเอ็นต์มีทรัพยากรจำนวนมากเข้าคิวรอดาวน์โหลด ทำให้เกิดความแออัดของเครือข่ายและเวลาในการโหลดหน้าเว็บช้า

HTTP/2 ได้รับการออกแบบเพื่อกำหนดเป้าหมายสามส่วนหลักของการปรับปรุงเพื่อบรรเทาปัญหาที่กล่าวถึงข้างต้น:

• ความเรียบง่าย
• ประสิทธิภาพสูง
• ความทนทาน

ประโยชน์ของ SEO สำหรับ HTTP/2

Page Speed ​​อาจเป็นเหตุผลหลักที่ SEO จะพิจารณาใช้ HTTP/2 ในเว็บไซต์ของตนเองหรือของลูกค้า Page Speed/ Performance คือชุดของตัวชี้วัดซึ่งเป็นปัจจัยในการจัดอันดับ ตั้งแต่ปี 2010 สำหรับการสืบค้นบนเดสก์ท็อป เนื่องจากการใช้อุปกรณ์มือถือเพิ่มมากขึ้น ในเดือนกรกฎาคม 2018 Google ได้ประกาศอย่างเป็นทางการ ว่า Page Speed ​​จะกลายเป็นปัจจัยอันดับสำหรับมือถือ

HTTP/2 มีฟังก์ชันหลัก 3 อย่างซึ่งสามารถนำมาใช้เมื่อเพิ่มประสิทธิภาพไซต์สำหรับ Page Speed:

1. มัลติเพล็กซ์
2. พุชเซิร์ฟเวอร์
3. การจัดลำดับความสำคัญของสตรีม

มัลติเพล็กซ์

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

เว็บไคลเอ็นต์สมัยใหม่ (Chrome, Firefox, Safari และ Opera) ที่ใช้โปรโตคอล HTTP 1/1.1 รุ่นเก่ามีขีดจำกัดเริ่มต้นสำหรับจำนวนการเชื่อมต่อ TCP พร้อมกันต่อชื่อโฮสต์ ดังนั้น เว็บไคลเอ็นต์ที่ใช้ HTTP 1/1.1 อาจมีปัญหากับความแออัดของ TCP ได้อย่างง่ายดาย สำหรับเว็บไคลเอ็นต์สมัยใหม่ ปัญหานี้แก้ไขได้โดยใช้มัลติเพล็กซ์ ซึ่งสามารถให้การปรับปรุงที่สำคัญที่สุดบางอย่างกับความเร็วของเพจ

ด้านล่างนี้คือประโยชน์ของ Multiplexing โดยใช้การเปรียบเทียบ HTTP/1.1 และ HTTP/2 ซึ่งแสดง พฤติกรรมทั่วไปเมื่อ HTTP/2 multiplexing ถูกเปิดใช้งานและไม่ได้เปิดใช้งาน

( WebpageTest, HTTP/1.1, ไม่มีการสาธิตการมัลติเพล็กซ์ )

( WebpageTest, HTTP/2, สาธิตการมัลติเพล็กซ์ )

ในภาพด้านบน น้ำตกตามประสิทธิภาพ ใช้เพื่อสาธิตการโหลดทรัพยากรระหว่าง ผู้ใช้ (ผู้ร้องขอทรัพยากร) และ เซิร์ฟเวอร์ (ผู้ที่ตอบสนองต่อทรัพยากร) ของหน้าเว็บ โดยทั่วไปแล้ว ทรัพยากรของหน้าจะรวมถึง HTML, JavaScript, CSS และรูปภาพ น้ำตกตามประสิทธิภาพแสดงให้เห็นถึงจุดที่แน่นอนเมื่อมีการเรียก ดาวน์โหลด และแสดงผลทรัพยากรเฉพาะภายในไคลเอนต์ ซึ่งมีความสำคัญอย่างยิ่งต่อการค้นหา ประเมิน และวิเคราะห์ปัญหาความเร็วหน้าเว็บบนไซต์ ดังที่แสดงโดยรูปภาพด้านบน “HTTP/2” ทรัพยากรทั้งหมดเริ่มดาวน์โหลดพร้อมกันโดยไม่ต้องโหลดทรัพยากรใดๆ ที่จุดอื่น เนื่องจาก HTTP/2 ใช้มัลติเพล็กซ์และไม่ต้องอาศัยการส่งคำขอเพียง 1 คำขอผ่านการเชื่อมต่อ TCP เดียวอีกต่อไป คุณจึงสามารถดาวน์โหลดทรัพยากรหลายรายการพร้อมกันได้ดังที่ด้านบน ในทางตรงกันข้าม ดังที่แสดงในรูปภาพ “HTTP/1.1” ทรัพยากรไม่ได้ดาวน์โหลดพร้อมกันเนื่องจากไม่สามารถใช้ฟังก์ชันมัลติเพล็กซ์ได้ เบราว์เซอร์สมัยใหม่โดยเฉลี่ยภายใต้ HTTP/1.1 สามารถมีการเชื่อมต่อได้ 6 รายการพร้อมกัน แต่ข้อดีสำหรับการนำ HTTP/2 ไปใช้ก็คือ TCP handshake ไม่จำเป็นสำหรับทุกๆ คำขอ ในขณะที่ไม่ว่าจะมีการเชื่อมต่อ HTTP/1.1 เริ่มต้นพร้อมกันกี่เครื่องก็ตาม กระบวนการเชื่อมต่อจะต้องเสร็จสิ้นทุกครั้ง ดังนั้นพวกเขาจึงเริ่มดาวน์โหลดที่จุดต่าง ๆ ซึ่งทำให้ผู้ใช้โหลดหน้านานขึ้น

( Upwork HTTP/1.1 เทียบกับ HTTP/2 ไดอะแกรม )

โปรแกรมรวบรวมข้อมูลการค้นหา เช่น Google และ Bing ไม่ได้รับประโยชน์โดยตรงจากการใช้ HTTP/2 ตามที่อธิบายไว้ข้างต้น ประโยชน์หลักจากการเพิ่มประสิทธิภาพเหล่านี้อาจเป็นไปได้สำหรับ Page Speed ดังนั้นแม้ว่าการใช้ HTTP/2 อาจไม่ส่งผลต่อโปรแกรมรวบรวมข้อมูลการค้นหาโดยตรง แต่ก็สามารถส่งผลกระทบต่อ Page Speed ​​ซึ่งเป็นปัจจัยในการจัดอันดับโดยตรงสำหรับการค้นหาของ Google สำหรับเดสก์ท็อปตั้งแต่ปี 2010 และการค้นหาบนมือถือตั้งแต่เดือนกรกฎาคม 2018 ดังนั้นจึงเป็นเรื่องสำคัญที่เว็บไซต์จะไม่แสดงผล ประสบการณ์ที่ช้าสำหรับผู้ใช้ เนื่องจาก Google อาจระงับประสิทธิภาพโดยส่งผลกระทบต่อการจัดอันดับ หรือเมื่อเร็วๆ นี้ ตั้งค่าสถานะผู้ใช้ว่าไซต์ของคุณอาจทำงานช้า

พุชเซิร์ฟเวอร์

Server Push ช่วยให้เซิร์ฟเวอร์เฉพาะหรือเครือข่าย Edge สามารถส่งทรัพยากรไปยังเว็บไคลเอ็นต์ได้เมื่อไคลเอ็นต์ไม่ได้รับการร้องขอ เพื่อให้เข้าใจว่าเซิร์ฟเวอร์พุชทำงานอย่างไร สิ่งสำคัญอันดับแรกคือต้องเข้าใจรูปแบบการตอบกลับคำขอที่เว็บไซต์ปฏิบัติตาม ผู้ใช้ร้องขอหน้าจากเว็บไซต์ และเซิร์ฟเวอร์ตอบสนองด้วยเนื้อหา/ทรัพยากรที่ร้องขอ

ตามสมมุติฐาน ให้นึกถึงไซต์ที่มีสไตล์ทั้งหมดที่กำหนดไว้ในสไตล์ชีตภายนอกที่เรียกว่า styles.css เมื่อผู้ใช้ร้องขอโครงกระดูก HTML สำหรับหน้า (สมมติว่าในกรณีนี้ index.html) เซิร์ฟเวอร์พุชสามารถ "ดัน" CSS ไปยังผู้ใช้ทันทีหลังจากเริ่มส่งการตอบสนองต่อ index.html

( S mashing Magazine, Server Push )

ก่อนที่จะทำความเข้าใจว่า Server Push สามารถช่วยปรับปรุง Page Speed ​​ได้อย่างไร สิ่งสำคัญคือต้องเข้าใจว่าเบราว์เซอร์ทำงานอย่างไรกับทรัพยากรต่างๆ เช่น รูปภาพ, CSS และ JavaScript เพื่อให้ปรากฏภายในเบราว์เซอร์ของคุณ คุณเห็นไหมว่าเบราว์เซอร์ส่งคำแนะนำสำหรับวิธีดาวน์โหลดรูปภาพ, CSS และทรัพยากร JavaScript ในการเยี่ยมชมเว็บไซต์ครั้งแรก คุณมักจะส่งคำขอ GET ซึ่งเป็นไฟล์ .html เมื่อได้รับไฟล์.

Server Push ช่วยปรับปรุง Page Speed ​​อย่างไร

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

แม้ว่า Server Push จะไม่ส่งผลกระทบโดยตรงต่อวิธีที่ Googlebot รวบรวมข้อมูลเว็บไซต์ของคุณ หรือโปรแกรมรวบรวมข้อมูลอื่นๆ แต่ประโยชน์ SEO นั้นได้มาจากการปรับปรุงปัจจัยที่เน้นผู้ใช้เป็นศูนย์กลาง เช่น First Paint และเนื้อหาที่มีความหมายแรก

การใช้การทดสอบหน้าเว็บ, Lighthouse, Page Speed ​​Insights และรายงานประสบการณ์ผู้ใช้ Chrome คุณสามารถกำหนดได้ว่าไซต์/เพจมีประสิทธิภาพเป็นอย่างไรเมื่อเปรียบเทียบกับคู่แข่งในอุตสาหกรรมเดียวกัน ด้านล่างนี้เป็นภาพสองภาพที่สาธิตการใช้งานโดยไม่มี (ภาพที่ 1) และด้วย Server Push (ภาพที่ 2)

(ทดสอบหน้าเว็บโดยไม่ต้องพุชเซิร์ฟเวอร์)

(WebpageTest, HTTP/1.1, พร้อมเซิร์ฟเวอร์พุช)

ด้วยการพุชของเซิร์ฟเวอร์ เซิร์ฟเวอร์สามารถกำหนดค่าให้ส่งส่วนประกอบของหน้าเพิ่มเติมเสมอ (เช่น ไฟล์ CSS, JavaScript และรูปภาพ) หากมีการร้องขอให้ส่งผ่านไฟล์ .html ที่มีส่วนประกอบเหล่านี้

ในน้ำตกด้านบน เราจะเห็นว่า push.php ใช้ไฟล์ CSS สี่ไฟล์

หากไม่มีเซิร์ฟเวอร์พุช เบราว์เซอร์จะต้องรับไฟล์ push.php แยกวิเคราะห์ HTML แล้วส่งคำขอเฉพาะสำหรับไฟล์ CSS เพิ่มเติมแต่ละไฟล์ เมื่อได้รับไฟล์ CSS ทั้งหมดแล้วจึงจะสามารถเริ่มใช้งานในกระบวนการแสดงผลได้

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

การจัดลำดับความสำคัญ HTTP/2

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

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

ก่อนที่จะพูดถึงวิธีการดำเนินการ สิ่งสำคัญคือต้องเข้าใจว่าทำไมเราจึงต้องการใช้การจัดลำดับความสำคัญสำหรับทรัพยากรของเรา

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

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

สตรีม: นี่คือการไหลของไบต์แบบสองทิศทางภายในการเชื่อมต่อที่สร้างขึ้นซึ่งอาจมีหนึ่งหรือข้อความ

สตรีมหลัก: นี่คือสตรีมที่ทรัพยากรขึ้นอยู่กับ

สตรีมย่อย: นี่เป็นสตรีมที่ขึ้นต่อกันของสตรีมหลัก พวกเขาใช้พาเรนต์เดียวกันและเรียกว่าสตรีมลูก

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

Exclusive Bit: นี่คือแฟล็กที่ระบุว่าควรดาวน์โหลดสตรีมโดยไม่แชร์แบนด์วิดท์กับสตรีมอื่น

กรอบส่วนหัว: นี่คือการระบุสำหรับสตรีมที่เป็นของเฟรม

Binary Framing Layer: นี่คือวิธีการห่อหุ้มและถ่ายโอนข้อความ HTTP ระหว่างไคลเอนต์และเซิร์ฟเวอร์

ตัวอย่างด้านล่างแสดงตัวอย่างข้างต้น:

( การจัดลำดับความสำคัญของสตรีม HTTP/2 ของ Google Developers )

ในการดำเนินการจัดลำดับความสำคัญ HTTP/2 คุณจะต้องเพิ่มข้อมูลการจัดลำดับความสำคัญภายใน Headers Frame ซึ่งอยู่ภายใน HTTP/2 Binary Framing Layer ใหม่ สตรีมหลักและการขึ้นต่อกัน/ไม่ขึ้นกับสตรีมย่อยอื่นๆ จะกำหนดลำดับความสำคัญ/การถ่วงน้ำหนัก และส่งผลให้ส่งไปยังเว็บไคลเอ็นต์ของทรัพยากร

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

การจัดลำดับความสำคัญ HTTP/2 - ความเข้ากันได้ของเซิร์ฟเวอร์ทั่วไป/โฮสติ้ง/CDNs

การเปรียบเทียบนี้ถูกต้องเมื่อ 02/01/2020 แต่ควรตรวจสอบว่าผู้ให้บริการที่มีศักยภาพได้ปรับปรุงความเข้ากันได้หรือไม่ก่อนตัดสินใจเลือก

สิ่งสำคัญคือต้องพิจารณาเบราว์เซอร์เฉพาะอย่างมีวิจารณญาณ เนื่องจากเบราว์เซอร์บางตัวไม่สนับสนุนการจัดลำดับความสำคัญของ HTTP/2 และจัดลำดับความสำคัญต่างกันเนื่องจากเป็นเว็บไคลเอ็นต์ที่แตกต่างกัน ด้านล่างนี้คือตารางที่อธิบายว่าเว็บไคลเอ็นต์ใดสามารถรองรับการจัดลำดับความสำคัญของ HTTP/2 ได้

ความเข้ากันได้ของไคลเอ็นต์เว็บการจัดลำดับความสำคัญของ HTTP/2

การจัดลำดับความสำคัญ HTTP/2 สามารถปรับปรุงการรับรู้ของผู้ใช้เกี่ยวกับ Page/Site Speed ​​ได้อย่างมาก และจะส่งผลในทางบวกต่อข้อมูลที่สะสมภายในรายงานประสบการณ์ของผู้ใช้ Chrome แม้ว่าการเพิ่มประสิทธิภาพนี้จะไม่มีผลกระทบต่อโปรแกรมรวบรวมข้อมูลการค้นหา เช่น Googlebot แต่เครื่องมือต่างๆ เช่น Lighthouse และ Page Speed ​​Insights จะช่วยคุณประเมินผลกระทบของการจัดลำดับความสำคัญ HTTP/2 ต่อประสิทธิภาพความเร็วหน้าเว็บจากมุมมองของผู้ใช้

ด้วยการกำหนดค่าน้ำหนักของสตรีมอย่างถูกต้องกับทั้งเซิร์ฟเวอร์และไคลเอ็นต์ที่ใช้ CDN/โฮสต์ที่สนับสนุน HTTP/2 คุณจะสามารถปรับปรุงเมตริกความเร็วหน้าเว็บสำหรับไคลเอ็นต์ของคุณได้อย่างมาก

ข้อกำหนดเบื้องต้นสำหรับ HTTP/2 . คืออะไร

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

1. สิ่งสำคัญคือต้องตรวจสอบให้แน่ใจว่าเปิดใช้งาน HTTPS
2. ใช้ใบรับรอง TLS จากหน่วยงานที่ตรวจสอบสิทธิ์แล้วเปิดใช้งานและติดตั้งใบรับรอง
3. ตรวจสอบให้แน่ใจว่าซอฟต์แวร์เว็บเซิร์ฟเวอร์ของคุณ เช่น Nginx, Apache และ IIS รองรับ HTTP/2 รายการรับรองความถูกต้องทั้งหมดสำหรับการสนับสนุนสามารถดูได้ที่ http://ayi.ma/browsershttp2 ซึ่งจะแสดงการสนับสนุนเบราว์เซอร์สำหรับ HTTP/2 หากคุณกำลังมองหาการสนับสนุน HTTP/2 สำหรับ CDN's/Hosting โปรดดู ที่ http://ayi.ma/serverhosting

ข้อผิดพลาดทั่วไป/สิ่งที่ต้องเปลี่ยนแปลงด้วยการแนะนำ HTTP/2

เนื่องจากข้อจำกัดของโปรโตคอล HTTP 1.0 และ HTTP 1.1 เวอร์ชันก่อนหน้า นักพัฒนาซอฟต์แวร์และ SEO ได้พยายามหาวิธีแก้ไขปัญหามากมายที่ข้อจำกัดเหล่านี้นำเสนอสำหรับประสิทธิภาพความเร็วและความปลอดภัยของเพจ

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

หลีกเลี่ยงการแชร์โดเมน

น่าแปลกที่เว็บไซต์จำนวนมากยังคงใช้แฮ็คนี้แม้ว่าจะมีการใช้ HTTP/2 อย่างถูกต้องก็ตาม เมื่อเปิดใช้งาน HTTP/2 สิ่งสำคัญคือต้องหลีกเลี่ยงการใช้การแบ่งส่วนข้อมูลโดเมน Domain Sharding เป็นเทคนิคในการแบ่งทรัพยากรตามชื่อโฮสต์ต่างๆ ซึ่งช่วยให้สามารถให้บริการทรัพยากรพร้อมกันได้มากขึ้น

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

นอกจากนี้ การใช้ Domain Sharding คุณจะทำลายการจัดลำดับความสำคัญของสตรีม และทรัพยากรของคุณจะไม่สามารถโหลดเพื่อใช้ Page Speed ​​ให้เกิดประโยชน์สูงสุดได้

ใช้เซิร์ฟเวอร์ Push อย่างเหมาะสม

Server Push มีข้อเสียบางประการที่คุณควรทราบ อันที่จริงการพุชของเซิร์ฟเวอร์อาจมีการใช้มากเกินไป และคุณควรเลือกเมื่อเลือกว่าจะใช้เมื่อใด คุณไม่จำเป็นต้องผลักดันทรัพยากรมากเกินไปเพราะอาจทำให้เว็บไคลเอ็นต์ดาวน์โหลดไม่เฉพาะ HTML แต่ทุกอย่างที่ "ผลัก" ด้วย ซึ่งหมายความว่าหน้าเว็บอาจใช้เวลาในการโหลดและแสดงผลนานขึ้น (เพิ่มเมตริกที่เน้นผู้ใช้เป็นศูนย์กลางซึ่ง Google เน้นเช่น Time to Interactive)

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

การทดสอบในชีวิตจริงภายใต้ HTTP/2

ความรู้เชิงทฤษฎีมีความสำคัญเสมอสำหรับการวางรากฐานเพื่อทำความเข้าใจ HTTP/2 และประโยชน์ของมัน เมื่อเข้าใจและเข้าใจแนวคิดแล้ว แม้ว่าการทดสอบทฤษฎีเหล่านี้เป็นสิ่งสำคัญเพื่อวัดผลกระทบที่ HTTP/2 สามารถทำได้กับ Page Speed

ตอนที่ 2 ของซีรี่ส์ Page Speed ​​นี้ HTTP/2 ในชีวิตจริง - การใช้การทดสอบและวิเคราะห์เว็บไซต์ จะกล่าวถึงประโยชน์ที่แท้จริงของ HTTP/2 ในเรื่องความเร็วของเพจและมูลค่าของ SEO ดังนั้นอย่าพลาด!

แล้ว HTTP/3 ล่ะ?

แม้ว่า HTTP/3 จะแสดงศักยภาพที่ชัดเจนในฐานะโปรโตคอลที่สืบทอดต่อไปยัง HTTP/2 แต่ก็ไม่ได้และไม่ควรส่งสัญญาณการสิ้นสุดของ HTTP/2 สำหรับ SEO ทั่วทั้งเว็บ เช่นเดียวกับการพัฒนาครั้งสำคัญใหม่ๆ ของเว็บทั่วโลก จะต้องผ่านขั้นตอนการเปิดตัวตามปกติ และอาจต้องใช้เวลาพอสมควรกว่าที่เว็บไซต์จะปรับใช้โปรโตคอลใหม่ และก่อนที่มันจะกลายเป็นมาตรฐานโดยพฤตินัยในอุตสาหกรรม SEO การใช้งาน HTTP/2 ยังคงแสดงถึงประโยชน์และประโยชน์ง่ายๆ ที่เมื่อนำไปใช้อย่างถูกต้องจะช่วยปรับปรุงประสิทธิภาพของเว็บไซต์ของคุณได้