เตรียมพร้อมสำหรับ HTTP2: คู่มือสำหรับนักออกแบบเว็บไซต์และนักพัฒนา

Hypertext Transfer Protocol (HTTP) เป็นโปรโตคอลที่ควบคุมการเชื่อมต่อระหว่างเซิร์ฟเวอร์ของคุณและเบราว์เซอร์ของผู้เยี่ยมชมเว็บไซต์ของคุณ เป็นครั้งแรกนับตั้งแต่ปี 2542 เรามี โปรโตคอลเวอร์ชันใหม่ และสัญญาว่าเว็บไซต์จะเร็วกว่ามากสำหรับทุกคน

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

อ่านเพิ่มเติม เกี่ยวกับ Smashing:

• พรีโหลด: ดีสำหรับอะไร
• ทุกสิ่งที่คุณต้องการรู้เกี่ยวกับ AMP
• การปรับปรุงประสิทธิภาพของ Smashing Magazine

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

ประวัติโดยย่อของ HTTP

HTTP เป็นโปรโตคอลแบบเก่า ซึ่งกำหนดครั้งแรกในปี 1991 โดยมีการแก้ไขครั้งใหญ่ครั้งล่าสุด — HTTP/1.1 — เผยแพร่ในปี 1999 เว็บไซต์ในปี 1999 แตกต่างอย่างมากกับเว็บไซต์ที่เราพัฒนาในปัจจุบัน ใน http2 อธิบาย Daniel Sternberg ตั้งข้อสังเกตว่าตอนนี้ปริมาณข้อมูลที่จำเป็นในการโหลดหน้าแรกของเว็บไซต์โดยเฉลี่ยคือ 1.9 MB โดยมีทรัพยากรมากกว่า 100 รายการที่ต้องใช้เพื่อแสดงหน้า - "ทรัพยากร" เป็นอะไรก็ได้จากรูปภาพหรือแบบอักษร ไปยังไฟล์ JavaScript หรือ CSS

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

SPDY

ในปี 2009 วิศวกรสองคนที่ Google โพสต์เกี่ยวกับโครงการวิจัยที่พวกเขาใช้ชื่อว่า SPDY โปรเจ็กต์นี้แก้ไขปัญหาบางอย่างใน HTTP/1.1 SPDY มุ่งมั่นที่จะ:

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

นอกจากนี้ SPDY ต้องการการเชื่อมต่อที่เข้ารหัส (HTTPS) ระหว่างเบราว์เซอร์และเซิร์ฟเวอร์

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

HTTP2

เราได้เห็น SPDY ประสบความสำเร็จและได้รับการยอมรับจากทั้งเซิร์ฟเวอร์และเบราว์เซอร์ อย่างไรก็ตาม คุณอาจสังเกตเห็นด้วยว่าแม้จะรองรับ Internet Explorer 11 แต่เบราว์เซอร์ Edge ของ Microsoft ก็ปล่อยทิ้งไป เกิดอะไรขึ้นที่นี่?

การสนับสนุน SPDY ลดลงใน Edge เนื่องจาก Microsoft ใช้การสนับสนุน HTTP2 ซึ่งเป็นโปรโตคอล HTTP เวอร์ชันล่าสุด ในขณะที่เบราว์เซอร์ปัจจุบันอื่นๆ ยังคงรองรับ SPDY อยู่ Chrome จะยกเลิกการสนับสนุนในปี 2559 และเบราว์เซอร์อื่นๆ มีแนวโน้มที่จะตามมา ในขณะที่เขียน Edge, Firefox, Chrome และ Opera รองรับทั้ง SPDY และ HTTP2 Safari รวมถึงบน iOS จะเข้าร่วมกลุ่มนั้นในปลายปีนี้ด้วยการเปิดตัว Safari 9

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

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

เราจะต้องเปลี่ยนเว็บไซต์ของเราหรือไม่?

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

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

เราต้องการเปลี่ยนแปลงอะไรเพื่อรองรับ HTTP/2?

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

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

ย้ายไป TLS

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

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

เปลี่ยนไฟล์รูปภาพหลายไฟล์ให้กลายเป็น Sprite

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

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

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

ภาพอินไลน์โดยใช้ Data URIs

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

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

การต่อ CSS และ JavaScript

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

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

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

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

การแยกทรัพยากรระหว่างโฮสต์: การแบ่งส่วน

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

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

วิธีเตรียมตัวสำหรับ HTTP/2 ตอนนี้

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

สร้างเนื้อหาส่วนบุคคลนอกเหนือจากสไปรท์และ URI ข้อมูล

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

เช่นเดียวกับ URI ข้อมูล หากคุณกำลังใช้สิ่งเหล่านี้ใน CSS ของคุณ ให้เตรียมรูปภาพให้พร้อมเมื่อคุณเปลี่ยนจากเทคนิคนี้

จัดระเบียบทรัพย์สินของคุณตามส่วนเว็บไซต์

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

จัดการ Domain Sharding

แนวทางปฏิบัติที่ดีที่สุดในปัจจุบันสำหรับ HTTP/1.1 คือการจำกัดการแบ่งกลุ่มข้อมูลที่ชื่อโฮสต์สองชื่อ มีวิธีรับ HTTP/2 เพื่อรวมการเชื่อมต่อ ถ้าใบรับรอง TLS ถูกต้องสำหรับทั้งโฮสต์และโฮสต์แก้ไขเป็น IP เดียวกัน เนื่องจากผู้ติดตั้งใช้งานเบราว์เซอร์ต้องการให้ HTTP/2 ทำงานบน HTTPS จึง จำเป็นต้องรับใบรับรอง TLS เพื่อเรียกใช้ผ่าน HTTP/2 ดูเพิ่มเติมในสไลด์ 26 ของสไลด์เด็คของ Ilya Grigorik จากการประชุม Velocity

เพิ่มเติมที่จะมา

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

เมื่อจะเปลี่ยน?

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

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

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

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

แผนปฏิบัติการ HTTP/2 ของคุณ

1. เปิดใช้งานด้วยการเชื่อมต่อที่ปลอดภัยหรือเปลี่ยนไปใช้ TLS ทันที นี่ควรเป็นลำดับความสำคัญของคุณ
2. เตรียมพร้อมสำหรับ HTTP/2 ในกระบวนการสร้างของคุณ เว็บไซต์ใดๆ ที่คุณสร้างตอนนี้มักจะได้รับประโยชน์จากการเพิ่มประสิทธิภาพ HTTP/2 ตลอดอายุการใช้งาน ใช้เคล็ดลับด้านบนเพื่อสร้างกระบวนการสร้างที่สามารถปรับให้เหมาะสมสำหรับทั้งสองโปรโตคอล
3. ตรวจสอบสถิติของคุณ เมื่อเปรียบเทียบการใช้งานเบราว์เซอร์บนเว็บไซต์ของคุณกับตารางสนับสนุนใน Can I Use คุณสามารถดูเปอร์เซ็นต์ของผู้เข้าชมที่จะได้รับประโยชน์จากการเพิ่มประสิทธิภาพ HTTP/2
4. ตรวจสอบโฮสติ้งของคุณ เมื่อคุณถึงจุดที่คุณจะได้รับประโยชน์จากการเปลี่ยน คุณจะต้องแน่ใจว่าเซิร์ฟเวอร์ของคุณรองรับ HTTP/2 พูดคุยกับผู้ให้บริการโฮสต์หรือผู้ดูแลระบบเซิร์ฟเวอร์ของคุณเพื่อค้นหาแผนการย้ายข้อมูล
5. เปิดตัวการเพิ่มประสิทธิภาพ HTTP/2 เมื่อเซิร์ฟเวอร์ของคุณรองรับ HTTP/2 แล้ว ที่เหลือก็ขึ้นอยู่กับคุณ หยุดใช้แนวทางปฏิบัติที่ดีที่สุดแบบเก่าและเปลี่ยนไปใช้แนวทางใหม่ ซึ่งหมายความว่าผู้ใช้ที่มีเบราว์เซอร์ที่ไม่รองรับ HTTP/2 จะได้รับประสบการณ์ที่ช้าลง ซึ่งเป็นสาเหตุที่ไดรเวอร์ที่อยู่เบื้องหลังการเปลี่ยนแปลงของคุณควรเป็นจุดเปลี่ยนเมื่อคนส่วนใหญ่จะได้รับประโยชน์

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

หาข้อมูลเพิ่มเติม

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

• “Hypertext Transfer Protocol เวอร์ชัน 2 (HTTP/2)” (ข้อกำหนด), Internet Engineering Task Force สำหรับผู้ที่ชื่นชอบการอ่านข้อกำหนดหรือผู้ที่ต้องการเข้าใจประเด็นที่ละเอียดกว่า สำหรับคนอื่นๆ คำถามที่พบบ่อย HTTP/2 เป็นบทสรุปที่ยอดเยี่ยมของคุณสมบัติหลัก
• อธิบาย http2 , Daniel Sternberg ebook ฟรีเล่มนี้ควรค่าแก่การอ่าน หากคุณต้องการเจาะลึกรายละเอียดของโปรโตคอลในขณะที่คุณวางแผนกลยุทธ์ของคุณ
• เครือข่ายเบราว์เซอร์ประสิทธิภาพสูง Ilya Grigorik, O'Reilly หนังสือเล่มนี้ครอบคลุมทั้งแนวทางปฏิบัติที่ดีที่สุดของ HTTP/1.1 และ HTTP/2 มันจะเป็นประโยชน์สำหรับทุกคนที่ต้องการทั้งเพิ่มประสิทธิภาพในวันนี้และเตรียมพร้อมสำหรับอนาคต
• “HTTP/2 มาแล้ว มาเพิ่มประสิทธิภาพกันเถอะ” (slidedeck) Ilya Grigorik ชุดสไลด์ที่ยอดเยี่ยมนี้มีข้อมูลเพิ่มเติมเกี่ยวกับประเด็นบางส่วนที่กล่าวถึงในบทความนี้
• ตัวบ่งชี้ HTTP/2: Firefox และ Chrome ปลั๊กอินของเบราว์เซอร์นี้จะบอกคุณว่าเว็บไซต์ที่คุณเข้าชมนั้นให้บริการผ่าน HTTP/2 หรือไม่
• หากต้องการอ่านเพิ่มเติม โปรดดูรายการลิงก์จำนวนมากที่รวบรวมโดย Rebecca Murphey