สรุป
Google+ ตอบสนองได้อย่างสมบูรณ์
การปรับเปลี่ยนตามอุปกรณ์
Google+ เป็นที่ที่ผู้คนมารวมตัวกันเพื่อแชร์สิ่งที่สนใจ ตั้งแต่ แมวซอมบี้ไปจนถึงเครื่องคิดเลขย้อนยุค ก่อนหน้านี้ Google+ มีเว็บไซต์ 2 เวอร์ชัน ได้แก่ เวอร์ชันสำหรับเดสก์ท็อป และอีกเวอร์ชันสำหรับเว็บบนอุปกรณ์เคลื่อนที่ซึ่งออกแบบมาสำหรับเบราว์เซอร์รุ่นเก่า
ชาเลนจ์
การรักษาเว็บไซต์ไว้ 2 แห่งถือเป็นความท้าทายไม่เหมือนใคร การมีเว็บไซต์คนละเวอร์ชันทำให้แต่ละฟีเจอร์ต้องใช้ 2 ครั้ง ส่งผลให้มีการใช้โค้ดซ้ำกันจำนวนมากและต้องใช้ความพยายามเพิ่มเติมในการเพิ่มประสิทธิภาพประสบการณ์ 2 รายการสำหรับเดสก์ท็อปและเว็บบนอุปกรณ์เคลื่อนที่ และเมื่อเส้นแบ่งระหว่างอุปกรณ์ต่างๆ เริ่มพร่ามัวมากขึ้น ด้วยเดสก์ท็อปที่รองรับการแตะและอุปกรณ์เคลื่อนที่อันทรงพลังพร้อมด้วยหน้าจอขนาดใหญ่กว่าที่เคย การออกแบบที่แตกต่างกันสำหรับเดสก์ท็อปและอุปกรณ์เคลื่อนที่จึงทำให้ดูไม่สมเหตุสมผล
เมื่อเราเพิ่มคุณลักษณะต่างๆ เข้ามา เว็บไซต์เวอร์ชันเดสก์ท็อปแบบเดิมของเราก็เริ่มช้าลงและพองขึ้นด้วย เมื่อต้นปีนี้ หน้าแรกของเรามีน้ำหนักประมาณ 5 MB และส่งคําขอ HTTP ประมาณ 250 รายการ เพียงแต่ไม่มีประสิทธิภาพมากนัก รูปภาพบนเว็บไซต์มีน้ำหนักมากและไม่ได้รับการเพิ่มประสิทธิภาพ ทำให้หน้าเว็บช้าลงไปอีก ด้วยเหตุนี้ สตรีมของเราจึงแทบไม่สามารถเข้าถึงได้บนเครือข่ายที่ช้าและไม่เสถียร และประสบการณ์ของผู้ใช้เหล่านี้ก็น่าผิดหวังที่สุด นอกจากนี้ ข้อกำหนดให้รองรับเบราว์เซอร์แบบเดิมในเว็บบนอุปกรณ์เคลื่อนที่ ทำให้เราไม่ต้องพึ่งพา JavaScript ในทุกเว็บไซต์ และทำให้เราไม่สามารถใช้ฟีเจอร์ที่มีการโต้ตอบสูงได้ เราไม่สามารถอาศัยความก้าวหน้า ในเว็บเบราว์เซอร์บนอุปกรณ์เคลื่อนที่
โซลูชัน
เราเริ่มต้นด้วยการมุ่งเน้นไปที่การออกแบบที่ตอบสนองตามอุปกรณ์ กล่าวคือการใช้งานแบบหนึ่งที่สามารถทำงานบนอุปกรณ์เคลื่อนที่ แท็บเล็ต เดสก์ท็อป และอื่นๆ ได้ เราศึกษาฟีเจอร์, หน้าเว็บ, ไลบรารี JavaScript และคลาส CSS ทุกรายการอย่างละเอียด เราต้องการสร้างระบบที่ช่วยให้มั่นใจว่าเว็บไซต์จะดาวน์โหลดเฉพาะสิ่งที่จำเป็นจริงๆ ในการทำงาน เว้นแต่ผู้ใช้ขอเพิ่ม ความท้าทายคือการสร้างเว็บไซต์ที่ทำงานได้อย่างถูกต้องบนโทรศัพท์มือถือที่มีความเร็วต่ำด้วยการเชื่อมต่อเครือข่ายมือถือ แต่ยังคงมอบประสบการณ์ที่สมจริงให้กับเบราว์เซอร์ที่เร็วกว่าและหน้าจอขนาดใหญ่
ข้อจำกัดชุดนี้ทำให้เราต้องตรวจสอบการเปลี่ยนแปลงโค้ดทุกๆ ครั้งนับจากนี้ไป เพื่อให้บรรลุเป้าหมายนี้ เราจึงสร้างกฎ 6^5 เพื่อให้มั่นใจว่าเมื่อโหลดหน้าเว็บครั้งแรก เราจะไม่ดาวน์โหลด HTML เกินกว่า 60,000 หน้า, JavaScript 60,000,000 CSS, 60,000 CSS ภาพเคลื่อนไหวของเรามีค่าเป็น 60fps เสมอ และเวลาในการตอบสนองเฉลี่ยอยู่ที่ 0.6 วินาที
เพื่อให้บรรลุเป้าหมายนี้ เราเลือกเฟรมเวิร์ก JavaScript และ CSS ที่สร้างรูปแบบโมดูลและการโหลดแบบ Lazy Loading ตั้งแต่ต้น เราจึงรับรองว่าผู้ใช้จะต้องดาวน์โหลด JavaScript และ CSS เฉพาะเมื่อใช้ฟีเจอร์ที่ต้องใช้จริงๆ เท่านั้น ซึ่งทำผ่านแนวทางที่ใช้เทมเพลตซึ่งผนวกรวมกับระบบบิลด์และโมดูลของเรา เพื่อให้นักพัฒนาซอฟต์แวร์ทำงานได้แบบแทบไม่ต้องทำอะไรเลย
ด้วยเฟรมเวิร์กใหม่นี้ เราได้เริ่มสร้างต้นแบบของการนำ Google+ ไปใช้งานบนเว็บอีกครั้ง เราเริ่มไม่อนุญาตสิ่งที่ “ไม่ดี” และตั้งกฎ การพัฒนาที่เข้มงวด กฎหลักข้อหนึ่งของเราคือ หน้าเว็บทั้งหมดต้องแสดงผลทั้งฝั่งเซิร์ฟเวอร์และฝั่งไคลเอ็นต์ เราใช้การแสดงผลฝั่งเซิร์ฟเวอร์เพื่อให้แน่ใจว่าผู้ใช้จะเริ่มอ่านได้ทันทีที่โหลด HTML และไม่ต้องเรียกใช้ JavaScript เพื่ออัปเดตเนื้อหาของหน้าเว็บ เมื่อหน้าเว็บโหลดขึ้นและผู้ใช้คลิกลิงก์แล้ว เราไม่ต้องการดำเนินการไป-กลับทั้งหมดเพื่อแสดงผลทุกอย่างอีกครั้ง การแสดงผลฝั่งไคลเอ็นต์จึงมีความสำคัญในตอนนี้ โดยเราต้องดึงข้อมูลและเทมเพลต แล้วแสดงผลหน้าเว็บใหม่บนไคลเอ็นต์ วิธีนี้ต้องอาศัยข้อดีข้อเสียมากมาย เราจึงใช้เฟรมเวิร์กที่ทำให้การแสดงผลฝั่งเซิร์ฟเวอร์และฝั่งไคลเอ็นต์ง่ายขึ้นโดยไม่ต้องทำทุกอย่างพร้อมกัน 2 ครั้ง คือทั้งในเซิร์ฟเวอร์และไคลเอ็นต์
กฎอื่นๆ รวมถึงการไม่อนุญาตภาพเคลื่อนไหวเกี่ยวกับความสูงและความกว้างซึ่งอาจทำให้มีการจัดวางเบราว์เซอร์ขึ้นใหม่และส่งผลเสียต่อประสิทธิภาพ สำหรับการปรับแต่ง DOM และภาพเคลื่อนไหว เรากำหนดเวลางานให้ทำงานโดยซิงค์กับอัตราการรีเฟรชการแสดงผลของเบราว์เซอร์ เรายังจัดกลุ่มงานวัดผลทั้งหมดไว้ด้วยกัน เพื่อที่เราจะได้หลีกเลี่ยงการคำนวณสไตล์ซ้ำๆ ที่มีราคาแพง นอกจากนี้ เรายังอาศัยเครื่องมือสร้างโปรไฟล์ของ Chrome อย่างมากเพื่อให้แน่ใจว่าทุกอย่างทำงานได้อย่างที่ควรเป็น นอกจากนี้ เรายังสร้างเครื่องมือที่คํานวณผลจากการเปลี่ยนแปลงโค้ดในโครงสร้างของ JS เพื่อให้แน่ใจว่าเราไม่ได้เพิ่มขนาดหน้าเว็บมากเกินไป
การดำเนินการนี้ต้องใช้เวลาสักระยะหนึ่ง แต่ถ้าเราไม่สามารถระบุและกำจัดปัญหาในขณะที่เราสร้างตัวขึ้นมาได้ คงจะยากขึ้นมาก
เราได้เปิดตัวการใช้งานแบบโต้ตอบนี้ในเวอร์ชันเว็บบนอุปกรณ์เคลื่อนที่เมื่อเดือนกุมภาพันธ์ 2015 ซึ่งทำให้เราสามารถตรวจสอบการออกแบบใหม่และกระบวนการใหม่ของเรา เราใช้ข้อมูลจากการเปิดตัวนี้เพื่อตรวจสอบว่าสิ่งใดใช้ได้ผลและไม่ได้ผล เราได้ทำซ้ำการออกแบบและเริ่มขยายเพื่อรองรับอุปกรณ์ต่างๆ มากขึ้น ในเดือนพฤศจิกายน 2015 เราได้เปิดตัวการใช้งานใหม่นี้ในอุปกรณ์ทั้งหมด
ผลลัพธ์
Google+ สามารถสร้างเว็บแอปที่ซับซ้อนด้วย UI ที่สมบูรณ์ได้โดยไม่ต้องแลกกับประสิทธิภาพ ในตอนนี้เว็บไซต์ทำงานเร็วขึ้นและมีขนาดเล็กกว่าที่เคย
| ก่อน | หลัง | |
|---|---|---|
| น้ำหนักรวมของหน้าแรก บีบอัดเป็นไฟล์ gzip (พร้อมรูปภาพ) | 22,600 กิโลไบต์ | 327 กิโลไบต์ |
| จำนวนคำขอ | 251 | 45 |
| HTML (ไม่ใช่ gzip) | 1,100 กิโลไบต์ | 362 KB |
| JavaScript และ CSS (gzip) | 2,768 KB | 111KB |
| เวลาในการโหลดหน้าเว็บที่สมบูรณ์โดยเฉลี่ย (เวลาในการตอบสนอง) | 12 วินาที 0.7 วินาทีถึงไบต์แรก |
3 วินาที 0.1 วินาทีถึงไบต์แรก |