วิธีที่ Wix ปรับปรุงประสิทธิภาพของเว็บไซต์ด้วยการพัฒนาโครงสร้างพื้นฐาน

กรณีศึกษาเกี่ยวกับการเปลี่ยนแปลงสำคัญบางอย่างที่แนะนำที่ 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 สำหรับแต่ละเว็บไซต์เป็นแบบคงที่เป็นส่วนใหญ่ แต่มีข้อควรระวังบางประการดังนี้

1. ข้อมูลมีการเปลี่ยนแปลงบ่อยครั้ง ทุกครั้งที่ผู้ใช้แก้ไขเว็บไซต์หรือเปลี่ยนแปลงข้อมูลเว็บไซต์ เช่น สินค้าคงคลังใน Store ของเว็บไซต์
2. แต่มีข้อมูลและคุกกี้บางรายการที่เฉพาะสำหรับผู้เข้าชม ทำให้คน 2 คนที่เข้าชมเว็บไซต์เดียวกันจะเห็น HTML ที่ต่างกันไป ตัวอย่างเช่น เพื่อรองรับคุณลักษณะของผลิตภัณฑ์อย่างการจำว่าผู้เข้าชมใส่สินค้าอะไรลงในรถเข็น หรือการแชทที่ผู้เข้าชมเริ่มกับธุรกิจก่อนหน้านี้ ฯลฯ
3. หน้าเว็บบางหน้าแคชไม่ได้ ตัวอย่างเช่น หน้าเว็บที่มีรหัสผู้ใช้ที่กำหนดเองซึ่งแสดงเวลาปัจจุบันเป็นส่วนหนึ่งของเอกสารจะไม่มีสิทธิ์ใช้การแคช

ในช่วงแรก เราใช้วิธีการที่ค่อนข้างปลอดภัยในการแคช HTML โดยไม่มีข้อมูลผู้เข้าชม จากนั้นจะแก้ไขเฉพาะบางส่วนของการตอบสนอง HTML ในระหว่างที่ผู้เข้าชมแต่ละคนใช้แคชแต่ละครั้ง

โซลูชัน CDN ภายในองค์กร

เราติดตั้งใช้งานโซลูชันภายในองค์กร โดยใช้แคช HTTP วานิชสำหรับการพร็อกซีและการแคช, Kafka สำหรับข้อความที่ระบุว่าไม่ถูกต้อง และบริการที่ใช้ Scala/Netty ซึ่งพร็อกซีการตอบสนอง HTML เหล่านี้ แต่เปลี่ยนแปลง HTML และเพิ่มข้อมูลและคุกกี้เฉพาะผู้เข้าชมไปยังการตอบกลับที่แคชไว้

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

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

การลดความซับซ้อน

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

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

การแคชเบราว์เซอร์ (และการเตรียม CDN)

ขั้นตอนต่อไปคือการนำข้อมูลเฉพาะผู้เข้าชมนี้ออกจาก 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)

เดิมที ไฟล์ทั้งหมดเราบีบอัดโดยใช้การบีบอัด 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 รวมถึงร่วมสนทนาเกี่ยวกับประสิทธิภาพของเว็บในช่องที่คุณชื่นชอบ

แล้วประสิทธิภาพเว็บไซต์ Wix ล่าสุดของคุณเป็นอย่างไร