กรณีศึกษาเกี่ยวกับการเปลี่ยนแปลงที่สำคัญบางอย่างที่ Wix นำมาใช้เพื่อปรับปรุงประสิทธิภาพการโหลดเว็บไซต์ของเว็บไซต์หลายล้านแห่ง ซึ่งช่วยให้เว็บไซต์เหล่านั้นได้รับคะแนน PageSpeed Insights และ Core Web Vitals ที่ดี
เปอร์เซ็นต์ของเว็บไซต์ Wix ที่ได้คะแนน 75 เปอร์เซ็นต์ไทล์ "ดี" ในเมตริก Core Web Vitals ทั้งหมดเพิ่มขึ้นกว่า 3 เท่าเมื่อเทียบกับปีก่อน จากการใช้ประโยชน์จากมาตรฐานอุตสาหกรรม ผู้ให้บริการระบบคลาวด์ และความสามารถของ CDN รวมถึงการเขียนรันไทม์ของเว็บไซต์ใหม่ครั้งใหญ่ ตามข้อมูลจาก CrUX และ HTTPArchive
Wix ยึดถือวัฒนธรรมที่มุ่งเน้นประสิทธิภาพ และเราจะเปิดตัวการปรับปรุงเพิ่มเติมต่อผู้ใช้ต่อไป เมื่อเรามุ่งเน้นที่ KPI ประสิทธิภาพ เราคาดว่าจำนวนเว็บไซต์ที่ผ่านเกณฑ์ของ Core Web Vitals จะเพิ่มขึ้น
ภาพรวม
โลกของประสิทธิภาพนั้นซับซ้อนอย่างน่าทึ่ง โดยมีตัวแปรและความซับซ้อนมากมาย งานวิจัยแสดงให้เห็นว่าความเร็วของเว็บไซต์ส่งผลโดยตรงต่ออัตรา Conversion และรายได้ของธุรกิจ ในช่วงไม่กี่ปีที่ผ่านมา อุตสาหกรรมนี้ให้ความสำคัญกับประสิทธิภาพ การแสดงผล และการทําให้เว็บเร็วขึ้นมากขึ้น ตั้งแต่เดือนพฤษภาคม 2021 เป็นต้นไป สัญญาณที่บ่งบอกถึงประสบการณ์การใช้งานหน้าเว็บจะรวมอยู่ในการจัดอันดับของ Google Search
ความท้าทายที่ไม่เหมือนใครของ Wix คือการรองรับเว็บไซต์หลายล้านเว็บไซต์ ซึ่งบางเว็บไซต์สร้างขึ้นเมื่อหลายปีก่อนและไม่เคยได้รับการอัปเดตนับจากนั้น เรามีเครื่องมือและบทความต่างๆ เพื่อช่วยผู้ใช้ในสิ่งที่ทำได้เพื่อวิเคราะห์และปรับปรุงประสิทธิภาพของเว็บไซต์
Wix เป็นสภาพแวดล้อมที่มีการจัดการและผู้ใช้ไม่สามารถควบคุมทุกอย่างได้ การใช้โครงสร้างพื้นฐานร่วมกันทำให้เกิดปัญหาหลายอย่างสำหรับเว็บไซต์เหล่านี้ทั้งหมด แต่ก็เปิดโอกาสให้ปรับปรุงที่สำคัญในวงกว้าง เช่น ใช้ประโยชน์จากต้นทุนที่ลดลงตามจำนวน
พูดเป็นภาษากลาง
ปัญหาหลักอย่างหนึ่งเกี่ยวกับประสิทธิภาพคือการหาคำศัพท์ที่เข้าใจตรงกันเพื่อพูดคุยเกี่ยวกับแง่มุมต่างๆ ของประสบการณ์ของผู้ใช้ โดยพิจารณาทั้งประสิทธิภาพทางเทคนิคและประสิทธิภาพที่ผู้ใช้รับรู้ การใช้ภาษาที่เข้าใจง่ายและเป็นสากลภายในองค์กรช่วยให้เราอภิปรายและจัดหมวดหมู่ส่วนต่างๆ ทางเทคนิคและข้อเสียเปรียบได้อย่างง่ายดาย ชี้แจงรายงานประสิทธิภาพ และช่วยให้เข้าใจว่าควรมุ่งเน้นปรับปรุงด้านใดก่อน
เราได้ปรับการตรวจสอบและการพูดคุยภายในทั้งหมดให้รวมเมตริกมาตรฐานอุตสาหกรรม เช่น Web Vitals ซึ่งประกอบด้วยเมตริกต่อไปนี้
ความซับซ้อนของเว็บไซต์และคะแนนประสิทธิภาพ
การสร้างเว็บไซต์ที่โหลดทันทีนั้นค่อนข้างง่าย ตราบใดที่คุณทำให้เว็บไซต์เรียบง่ายมากโดยใช้ HTML เท่านั้นและแสดงผ่าน CDN
อย่างไรก็ตาม ความจริงก็คือเว็บไซต์มีความซับซ้อนและล้ำสมัยมากขึ้นเรื่อยๆ ทำงานเหมือนแอปพลิเคชันมากกว่าเอกสาร และรองรับฟังก์ชันการทำงานต่างๆ เช่น บล็อก โซลูชันอีคอมเมิร์ซ โค้ดที่กำหนดเอง เป็นต้น
Wix มีเทมเพลตที่หลากหลายมาก ซึ่งช่วยให้ผู้ใช้สร้างเว็บไซต์ที่พร้อมใช้งานทางธุรกิจได้ง่ายๆ ฟีเจอร์เพิ่มเติมเหล่านี้มักจะมีต้นทุนด้านประสิทธิภาพบางส่วน
เส้นทาง
ในตอนต้น มี HTML
ทุกครั้งที่โหลดหน้าเว็บ ระบบจะเริ่มด้วยคําขอเริ่มต้นไปยัง URL เพื่อดึงข้อมูลเอกสาร HTML การตอบกลับ HTML นี้จะทริกเกอร์คำขอไคลเอ็นต์และตรรกะเบราว์เซอร์เพิ่มเติมทั้งหมดให้ทำงานและแสดงผลเว็บไซต์ ข้อมูลนี้เป็นส่วนสําคัญที่สุดของการโหลดหน้าเว็บ เนื่องจากไม่มีสิ่งใดเกิดขึ้นจนกว่าการตอบกลับครั้งแรกจะมาถึง (เรียกว่า TTFB - เวลาในการตอบสนองครั้งแรก)
อดีต: การแสดงผลฝั่งไคลเอ็นต์ (CSR)
เมื่อใช้งานระบบขนาดใหญ่ คุณจะต้องพิจารณาข้อดีข้อเสียต่างๆ เช่น ประสิทธิภาพ ความเสถียร และต้นทุน เมื่อไม่กี่ปีที่ผ่านมา Wix ใช้การแสดงผลฝั่งไคลเอ็นต์ (CSR) ซึ่งจะสร้างเนื้อหา HTML จริงผ่าน JavaScript ฝั่งไคลเอ็นต์ (เช่น ในเบราว์เซอร์) ซึ่งช่วยให้เรารองรับเว็บไซต์ขนาดใหญ่ได้โดยไม่ต้องมีต้นทุนการดําเนินงานแบ็กเอนด์จำนวนมาก
CSR ช่วยให้เราสามารถใช้เอกสาร HTML ทั่วไปซึ่งโดยทั่วไปจะว่างเปล่า ทั้งหมดที่ทําคือเรียกให้ดาวน์โหลดโค้ดและข้อมูลที่จําเป็น จากนั้นจึงนําไปใช้สร้าง HTML แบบเต็มในอุปกรณ์ไคลเอ็นต์
วันนี้: การแสดงผลฝั่งเซิร์ฟเวอร์ (SSR)
เมื่อหลายปีก่อน เราได้เปลี่ยนไปใช้การแสดงผลฝั่งเซิร์ฟเวอร์ (SSR) เนื่องจากมีประโยชน์ทั้งต่อ SEO และประสิทธิภาพ ทั้งยังช่วยปรับปรุงเวลาในการปรากฏของหน้าเว็บครั้งแรกและช่วยให้การจัดทําดัชนีดีขึ้นสําหรับเครื่องมือค้นหาที่ไม่รองรับการเรียกใช้ JavaScript อย่างเต็มรูปแบบ
แนวทางนี้ช่วยปรับปรุงประสบการณ์การแสดงผล โดยเฉพาะในอุปกรณ์/การเชื่อมต่อที่ช้า และเปิดโอกาสให้เพิ่มประสิทธิภาพให้ดียิ่งขึ้น แต่วิธีนี้ยังหมายความว่าจะมีการสร้างการตอบกลับ HTML ที่ไม่ซ้ำกันแบบเรียลไทม์สําหรับคําขอหน้าเว็บแต่ละรายการ ซึ่งไม่เหมาะสําหรับการใช้งานจริง โดยเฉพาะสําหรับเว็บไซต์ที่มีการดูจํานวนมาก
เปิดตัวการแคชในหลายตำแหน่ง
HTML ของเว็บไซต์แต่ละแห่งเป็นแบบคงที่ส่วนใหญ่ แต่มีข้อควรระวังบางประการดังนี้
- ข้อมูลมีการเปลี่ยนแปลงบ่อยครั้ง ทุกครั้งที่ผู้ใช้แก้ไขเว็บไซต์หรือทําการเปลี่ยนแปลงข้อมูลเว็บไซต์ เช่น ในสินค้าคงคลังร้านค้าของเว็บไซต์
- คุกกี้มีข้อมูลและคุกกี้บางอย่างที่เจาะจงผู้เข้าชม ซึ่งหมายความว่าผู้เข้าชม 2 คนที่เข้าชมเว็บไซต์เดียวกันจะเห็น HTML ที่ต่างกันเล็กน้อย เช่น เพื่อรองรับฟีเจอร์ของผลิตภัณฑ์ เช่น การจดจำสินค้าที่ผู้เข้าชมใส่ไว้ในรถเข็น หรือแชทที่ผู้เข้าชมเริ่มกับธุรกิจก่อนหน้านี้ และอื่นๆ
- หน้าเว็บบางหน้าแคชไม่ได้ ตัวอย่างเช่น หน้าเว็บที่มีโค้ดผู้ใช้ที่กำหนดเองซึ่งแสดงเวลาปัจจุบันเป็นส่วนหนึ่งของเอกสารจะไม่มีสิทธิ์ใช้แคช
ในช่วงแรก เราใช้แนวทางที่ค่อนข้างปลอดภัยในการแคช HTML โดยไม่ใช้ข้อมูลผู้เข้าชม จากนั้นจึงแก้ไขเฉพาะบางส่วนของคำตอบ HTML ขณะดำเนินการสำหรับผู้เข้าชมแต่ละรายสำหรับการตีข้อมูลแคชแต่ละครั้ง
โซลูชัน CDN ของบริษัท
เราทําเช่นนี้โดยใช้โซลูชันที่พัฒนาขึ้นเอง ซึ่งก็คือการใช้ Varnish HTTP แคช สําหรับการพร็อกซีและการแคช, Kafka สําหรับข้อความการลบล้าง และบริการที่ใช้ Scala/Netty ซึ่งทำหน้าที่เป็นพร็อกซีสําหรับการตอบกลับ HTML เหล่านี้ แต่เปลี่ยนรูปแบบ HTML และเพิ่มข้อมูลเฉพาะผู้เข้าชมและคุกกี้ลงในคําตอบที่แคชไว้
โซลูชันนี้ช่วยให้เราติดตั้งใช้งานคอมโพเนนต์ที่เล็กเหล่านี้ในสถานที่ตั้งทางภูมิศาสตร์และภูมิภาคของผู้ให้บริการระบบคลาวด์ได้มากขึ้น ซึ่งกระจายอยู่ทั่วโลก ในปี 2019 เราได้เปิดตัวภูมิภาคใหม่กว่า 15 แห่ง และเริ่มเปิดใช้การแคชสําหรับการดูหน้าเว็บกว่า 90% ที่มีสิทธิ์แคช การแสดงเว็บไซต์จากสถานที่ตั้งเพิ่มเติมช่วยลดเวลาในการตอบสนองของเครือข่ายระหว่างไคลเอ็นต์กับเซิร์ฟเวอร์ที่แสดงการตอบกลับ HTML ด้วยการนำเนื้อหาไปไว้ใกล้กับผู้เข้าชมเว็บไซต์มากขึ้น
นอกจากนี้ เรายังเริ่มแคชการตอบกลับ API บางรายการที่อ่านอย่างเดียวโดยใช้วิธีแก้ปัญหาเดียวกันและทำให้แคชเป็นโมฆะเมื่อมีการเปลี่ยนแปลงเนื้อหาเว็บไซต์ เช่น ระบบจะแคชรายการโพสต์บล็อกในเว็บไซต์และทำให้ข้อมูลดังกล่าวใช้งานไม่ได้เมื่อมีการเผยแพร่/แก้ไขโพสต์
การลดความซับซ้อน
การใช้แคชช่วยปรับปรุงประสิทธิภาพได้อย่างมาก โดยส่วนใหญ่อยู่ในระยะ TTFB และ FCP และปรับปรุงความน่าเชื่อถือด้วยการแสดงเนื้อหาจากตำแหน่งที่อยู่ใกล้กับผู้ใช้ปลายทางมากขึ้น
อย่างไรก็ตาม ความจำเป็นในการแก้ไข HTML สำหรับการตอบกลับแต่ละรายการทำให้เกิดความซับซ้อนที่ไม่จำเป็น ซึ่งหากนำออกแล้ว ก็จะเป็นโอกาสในการปรับปรุงประสิทธิภาพให้ดียิ่งขึ้น
การแคชเบราว์เซอร์ (และการเตรียมพร้อมสําหรับ CDN)
~ 13%
คำขอ HTML ที่แสดงจากแคชของเบราว์เซอร์โดยตรง ซึ่งจะช่วยประหยัดแบนด์วิดท์และลดเวลาในการโหลดสำหรับการดูซ้ำ
ขั้นตอนถัดไปคือการนําข้อมูลเฉพาะผู้เข้าชมนี้ออกจาก HTMLโดยสมบูรณ์ และดึงข้อมูลจากปลายทางแยกต่างหากซึ่งไคลเอ็นต์เรียกใช้เพื่อวัตถุประสงค์นี้หลังจากที่ HTML มาถึง
เราได้ย้ายข้อมูลและคุกกี้นี้ไปยังปลายทางใหม่อย่างละเอียด ซึ่งจะเรียกใช้เมื่อโหลดหน้าเว็บแต่ละหน้า แต่แสดงผล JSON ขนาดเล็ก ซึ่งจําเป็นต่อกระบวนการไฮเดรตเท่านั้น เพื่อให้หน้าเว็บโต้ตอบได้อย่างเต็มที่
ซึ่งทำให้เราเปิดใช้การแคช HTML ของเบราว์เซอร์ได้ ซึ่งหมายความว่าตอนนี้เบราว์เซอร์จะบันทึกการตอบกลับ HTML สำหรับการเข้าชมซ้ำ และเรียกใช้เซิร์ฟเวอร์เพื่อตรวจสอบว่าเนื้อหาไม่มีการเปลี่ยนแปลงเท่านั้น ซึ่งทําได้โดยใช้ HTTP ETag ซึ่งโดยพื้นฐานแล้วคือตัวระบุที่กําหนดให้กับทรัพยากร HTML เวอร์ชันที่เฉพาะเจาะจง หากเนื้อหายังคงเหมือนเดิม เซิร์ฟเวอร์จะส่งการตอบกลับ 304 ไม่มีการเปลี่ยนแปลงไปยังไคลเอ็นต์โดยไม่มีเนื้อหา
นอกจากนี้ การเปลี่ยนแปลงนี้ยังหมายความว่า HTML ของเราจะไม่เจาะจงผู้เข้าชมอีกต่อไปและไม่มีคุกกี้ กล่าวคือ เนื้อหาสามารถแคชได้ทุกที่ ซึ่งเปิดโอกาสให้ใช้ผู้ให้บริการ CDN ที่มีการแสดงข้อมูลทางภูมิศาสตร์ที่ดีขึ้นมากในหลายร้อยแห่งทั่วโลก
DNS, SSL และ HTTP/2
เมื่อเปิดใช้การแคชแล้ว เวลารอจะลดลงและส่วนสําคัญอื่นๆ ของการเชื่อมต่อครั้งแรกจะมีประสิทธิภาพมากขึ้น การปรับปรุงโครงสร้างพื้นฐานและการตรวจสอบเครือข่ายช่วยให้เราปรับปรุงเวลาในการตอบสนองของ DNS, การเชื่อมต่อ และ SSL ได้
ระบบเปิดใช้ HTTP/2 สำหรับโดเมนผู้ใช้ทั้งหมด ซึ่งจะช่วยลดทั้งจำนวนการเชื่อมต่อที่จำเป็นและค่าใช้จ่ายเพิ่มเติมที่มาพร้อมกับการเชื่อมต่อใหม่แต่ละครั้ง การเปลี่ยนแปลงนี้ทําได้ง่ายดาย ขณะเดียวกันก็ใช้ประโยชน์จากประโยชน์ด้านประสิทธิภาพและความยืดหยุ่นที่มาพร้อมกับ HTTP/2
การบีบอัด Brotli (เทียบกับ gzip)
21 - 25%
การลดขนาดการโอนไฟล์มัธยฐาน
เดิมทีไฟล์ทั้งหมดของเราได้รับการบีบอัดโดยใช้การบีบอัด gzip ซึ่งเป็นตัวเลือกการบีบอัด HTML ที่พบได้บ่อยที่สุดบนเว็บ โปรโตคอลการบีบอัดนี้เริ่มใช้งานครั้งแรกเมื่อเกือบ 30 ปีที่แล้ว
การบีบอัด Brotli เวอร์ชันใหม่มีการปรับปรุงการบีบอัดโดยแทบไม่มีข้อเสีย และกำลังได้รับความนิยมมากขึ้นเรื่อยๆ ตามที่อธิบายไว้ในบทการบีบอัดของ Web Almanac ประจำปี เบราว์เซอร์หลักๆ ทั้งหมดรองรับการแชร์ไฟล์ผ่าน URL นี้มาระยะหนึ่งแล้ว
เราได้เปิดใช้การรองรับ Brotli ในพร็อกซี nginx ของเราที่ขอบสำหรับไคลเอ็นต์ทั้งหมดที่รองรับ
การเปลี่ยนไปใช้การบีบอัด Brotli ทำให้ขนาดการโอนไฟล์ค่ามัธยฐานลดลง 21% ถึง 25% ซึ่งส่งผลให้การใช้แบนด์วิดท์ลดลงและเวลาในการโหลดดีขึ้น
เครือข่ายนำส่งข้อมูล (CDN)
การเลือก CDN แบบไดนามิก
เราที่ Wix ได้ใช้ CDN ในการแสดงโค้ด JavaScript และรูปภาพทั้งหมดในเว็บไซต์ของผู้ใช้เสมอ
เมื่อเร็วๆ นี้เราได้ผสานรวมกับโซลูชันของผู้ให้บริการ DNS เพื่อเลือก CDN ที่มีประสิทธิภาพดีที่สุดโดยอัตโนมัติตามเครือข่ายและต้นทางของลูกค้า ซึ่งช่วยให้เราแสดงไฟล์แบบคงที่จากตำแหน่งที่ดีที่สุดสำหรับผู้เข้าชมแต่ละราย และหลีกเลี่ยงปัญหาความพร้อมให้บริการใน CDN บางรายการ
โดเมนผู้ใช้ที่ให้บริการโดย CDN (เร็วๆ นี้)
ขั้นตอนสุดท้ายและสำคัญที่สุดคือการแสดง HTML จากโดเมนผู้ใช้ผ่าน CDN
ดังที่อธิบายไว้ข้างต้น เราได้สร้างโซลูชันภายในของเราเองเพื่อแคชและแสดงผลลัพธ์ HTML และ API ที่เจาะจงเว็บไซต์ การดูแลรักษาโซลูชันนี้ในภูมิภาคใหม่ๆ จำนวนมากก็มีต้นทุนการปฏิบัติงานด้วยเช่นกัน และการเพิ่มสถานที่ใหม่ก็กลายเป็นกระบวนการที่เราจำเป็นต้องจัดการและเพิ่มประสิทธิภาพอย่างต่อเนื่อง
ขณะนี้เรากำลังผสานรวมกับผู้ให้บริการ CDN ต่างๆ เพื่อรองรับการแสดงเว็บไซต์ Wix ทั้งหมดจากตำแหน่ง CDN โดยตรง เพื่อปรับปรุงการกระจายเซิร์ฟเวอร์ของเราทั่วโลก และปรับปรุงเวลาในการตอบกลับให้ดียิ่งขึ้น การดำเนินการนี้เป็นเรื่องท้าทายเนื่องจากมีโดเมนจำนวนมากที่เราให้บริการ ซึ่งต้องมีการสิ้นสุด SSL ที่ขอบ
การผสานรวมกับ CDN จะช่วยให้เว็บไซต์ Wix เข้าถึงลูกค้าได้ใกล้ชิดกว่าที่เคย รวมถึงมีการปรับปรุงประสบการณ์การโหลดเพิ่มเติม รวมถึงเทคโนโลยีใหม่ๆ เช่น HTTP/3 โดยไม่ต้องทำอะไรเพิ่มเติม
ข้อมูลเบื้องต้นเกี่ยวกับการตรวจสอบประสิทธิภาพ
หากคุณใช้เว็บไซต์ Wix คุณอาจสงสัยว่าข้อมูลนี้ส่งผลต่อผลลัพธ์ประสิทธิภาพเว็บไซต์ Wix อย่างไร และเราเปรียบเทียบกับแพลตฟอร์มเว็บไซต์อื่นๆ อย่างไร
เราได้ทํางานส่วนใหญ่ข้างต้นไปเมื่อปีที่แล้ว และบางงานยังอยู่ระหว่างการเปิดตัว
สมุดภาพเว็บของ HTTPArchive เพิ่งเผยแพร่ฉบับปี 2020 ซึ่งมีบทที่ยอดเยี่ยมเกี่ยวกับประสบการณ์ของผู้ใช้ CMS โปรดทราบว่าตัวเลขหลายรายการที่อธิบายไว้ในบทความนี้มาจากช่วงกลางปี 2020
เราหวังว่าจะได้ดูรายงานที่อัปเดตในปี 2021 และกำลังตรวจสอบรายงาน CrUX สำหรับเว็บไซต์ของเราและเมตริกประสิทธิภาพภายในอย่างสม่ำเสมอ
เรามุ่งมั่นที่จะปรับปรุงเวลาในการโหลดอย่างต่อเนื่องและมอบแพลตฟอร์มที่ผู้ใช้สามารถสร้างเว็บไซต์ได้ตามจินตนาการโดยไม่เสียประสิทธิภาพ
DebugBear เพิ่งเผยแพร่รีวิวประสิทธิภาพของเครื่องมือสร้างเว็บไซต์ที่น่าสนใจมาก ซึ่งกล่าวถึงบางประเด็นที่เราได้พูดถึงข้างต้นและตรวจสอบประสิทธิภาพของเว็บไซต์ที่เรียบง่ายมากซึ่งสร้างขึ้นบนแต่ละแพลตฟอร์ม เว็บไซต์นี้สร้างขึ้นเกือบ 2 ปีที่แล้วและไม่ได้แก้ไขนับตั้งแต่นั้น แต่แพลตฟอร์มนี้ได้รับการปรับปรุงอย่างต่อเนื่องและประสิทธิภาพของเว็บไซต์ก็ดีขึ้นด้วย ซึ่งสามารถเห็นได้จากการดูข้อมูลของเว็บไซต์ในช่วง 1 ปีครึ่งที่ผ่านมา
บทสรุป
เราหวังว่าประสบการณ์ของเราจะช่วยกระตุ้นให้คุณนำวัฒนธรรมที่มุ่งเน้นประสิทธิภาพมาใช้ในองค์กร และหวังว่ารายละเอียดข้างต้นจะเป็นประโยชน์และใช้ได้กับแพลตฟอร์มหรือเว็บไซต์ของคุณ
โดยสรุป
- เลือกชุดเมตริกที่คุณสามารถติดตามได้อย่างสม่ำเสมอโดยใช้เครื่องมือที่ได้รับการรับรองจากอุตสาหกรรม เราขอแนะนําให้ใช้ Core Web Vitals
- ใช้ประโยชน์จากการแคชของเบราว์เซอร์และ CDN
- ย้ายข้อมูลไปยัง HTTP/2 (หรือ HTTP/3 หากเป็นไปได้)
- ใช้การบีบอัด Brotli
ขอขอบคุณที่รับชมเรื่องราวของเรา และเราขอเชิญให้คุณถามคําถาม แชร์แนวคิดใน Twitter และ GitHub รวมถึงเข้าร่วมการสนทนาเกี่ยวกับประสิทธิภาพเว็บในช่องทางที่คุณชื่นชอบ