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