ทำไมปุ่ม Facebook Like จึงคิดเป็น 16% ของรหัสของเว็บไซต์โดยเฉลี่ย

ตามข้อมูลที่รวบรวมโดย BuiltWith.com 6% ของไซต์ที่มีการเข้าชมสูงที่สุด 10,000 อันดับแรกโหลดเนื้อหาจากเซิร์ฟเวอร์ของ Facebook สำหรับคนส่วนใหญ่เนื้อหานั้นน่าจะเป็น Javascript SDK ของ Facebook ซึ่งเป็นบล็อกโค้ดขนาดใหญ่ที่จำเป็นในการแสดงคุณสมบัติเช่นปุ่ม Like (ตามที่เห็นในเว็บไซต์สื่อหลายแห่ง) และวิดเจ็ตความคิดเห็นของ Facebook (ใช้กับสื่อขนาดใหญ่หลายแห่ง ไซต์ Buzzfeed ในหมู่พวกเขา)

โค้ด SDK นี้ใหญ่มากจนคิดเป็นประมาณ 16% ของขนาดทั้งหมดของ JavaScript ทั้งหมดในหน้าเว็บโดยเฉลี่ย

ในฐานะที่เป็นไลบรารีซอฟต์แวร์ที่มีขนาดใหญ่และใช้กันอย่างแพร่หลาย Facebook SDK เป็นวิธีที่ดีในการอธิบายคำตอบของคำถาม: ทำไมไซต์โดยเฉลี่ยในปัจจุบันจึงมีขนาดใหญ่มาก? และขนาดเท่าไหร่ไม่สำคัญ?

ทำไมใหญ่จัง?

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

จากชุดคุณสมบัติสามอย่างที่โดดเด่นที่สุด:

“ Canvas” เป็นระบบของ Facebook สำหรับแอพที่ตั้งใจให้โหลดภายใน Facebook (Facebook ได้ผลักดันครั้งใหญ่ในอดีตเพื่อสนับสนุนให้นักพัฒนาสร้างแอพที่อาศัยอยู่ใน Facebook ฉันไม่แน่ใจว่าแอพดังกล่าวใช้กันแพร่หลายแค่ไหนในปัจจุบัน แต่อย่างใดเว็บไซต์ทั่วไปไม่ได้ใช้คุณสมบัติที่เกี่ยวข้องกับ Canvas) ค่าใช้จ่ายในการรวมไว้ใน SDK นั้นค่อนข้างน้อย: เพียง 1.5% ของขนาดทั้งหมด

หลังจากนั้นเรามีการรองรับฟีเจอร์เดิม สิ่งนี้สะท้อนให้เห็นถึงความจริงที่ว่า API จะสะสมอินเทอร์เฟซหลายตัวสำหรับจัดการคุณสมบัติเดียวกันเมื่อเวลาผ่านไป ตัวอย่างเช่นนักพัฒนาสามารถเขียนโค้ดที่เรียกFB.getLoginStatus () (วิธีเดิมในการขอสถานะการเข้าสู่ระบบ Facebook ปัจจุบันของผู้ใช้) หรือAuth.getLoginStatus ()(แนวทางใหม่ที่ได้รับการสนับสนุน) วิธีในการหลีกเลี่ยงการรวมทั้งสองชุดวิธีการคือการเผยแพร่ใน SDK เวอร์ชันแยกกัน แต่ Facebook เลือกที่จะไม่ทำเช่นนี้มีแนวโน้มที่จะลดความซับซ้อนของประสบการณ์สำหรับนักพัฒนาและเพื่อเพิ่มจำนวนไซต์โดยใช้ไฟล์เดียวกันทั้งหมด ( เพื่อเพิ่มความเป็นไปได้ที่ผู้ใช้โดยเฉลี่ยดาวน์โหลดไว้แล้ว) การตัดสินใจนี้มีค่าใช้จ่ายเพียงเล็กน้อย: ประมาณ 3.5% ของโค้ด SDK มีไว้สำหรับการจัดการคุณลักษณะที่ระบุไว้อย่างชัดเจนว่าเป็น "แบบเดิม" (และค่อนข้างเป็นไปได้ที่จะมีคุณลักษณะ "ดั้งเดิม" อีกมากมายที่ไม่ได้ทำเครื่องหมายไว้อย่างชัดเจนเช่นนั้น ).

ที่สำคัญที่สุด SDK ประกอบด้วย polyfills และ polyfill-like utilities จำนวนหนึ่งซึ่งคิดเป็น 15% ของโค้ด Polyfills ใช้เพื่อจัดหาคุณสมบัติที่พบในเบราว์เซอร์รุ่นใหม่ให้กับเบราว์เซอร์รุ่นเก่าและบางครั้งยังใช้เพื่อจัดหาคุณลักษณะใหม่ ๆ ที่กำลังจะมาถึง แต่ยังไม่ได้เพิ่มลงในเบราว์เซอร์ใด ๆ โพลีฟิลล์ส่วนใหญ่ที่รวมอยู่ใน Facebook SDK มีไว้สำหรับฟีเจอร์ที่รวมอยู่ในเบราว์เซอร์ที่ผู้ใช้อินเทอร์เน็ตส่วนใหญ่ใช้อยู่แล้ว พวกเขาทำหน้าที่เพียงเพื่อให้ SDK ใช้งานได้สำหรับ <1% ของผู้ใช้อินเทอร์เน็ตทั่วโลกที่ใช้เบราว์เซอร์รุ่นเก่าเช่น Internet Explorer 8 ซึ่งไซต์หลักจำนวนมาก (หากไม่ใช่ส่วนใหญ่) ได้เลิกสนับสนุน

ในส่วนที่เหลือประมาณ 80% ของ SDK นั้นยากกว่าเล็กน้อยที่จะแก้ปัญหาว่าฟีเจอร์ใดที่จำเป็นสำหรับวัตถุประสงค์ เนื่องจากมันถูกเขียนขึ้นเพื่อใช้คุณสมบัติง่ายๆเช่นปุ่ม Like ต้องมีรหัสที่ใช้สำหรับความคิดเห็นเท่านั้นการฝังวิดีโอปุ่มล็อกอินและคุณสมบัติอื่น ๆ ที่ไม่เกี่ยวข้อง Facebook อาจเลือกที่จะแจกจ่ายไฟล์ที่มีขนาดเล็กกว่ามากสำหรับการรวมคุณลักษณะเดียวเช่นปุ่ม Like แต่มีเป้าหมายทางธุรกิจในการสนับสนุนให้ไซต์ใช้คุณลักษณะที่ FB ให้มาให้มากที่สุด

ขนาดมีความสำคัญหรือไม่?

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

แต่ไม่ว่าเบราว์เซอร์ของผู้ใช้จะดาวน์โหลด SDK แล้วหรือยัง แต่ก็ยังมีค่าใช้จ่ายที่เกี่ยวข้องกับการเรียกใช้ Javascript จำนวนมากโดยเฉพาะบนอุปกรณ์เคลื่อนที่ ใน MacBook Pro รุ่นใหม่ที่ฉันกำลังเขียนอยู่นั้น SDK ของ Facebook จะใช้เวลาประมาณ 50ms (1/20 ของวินาที) เพื่อทำงานบนไซต์เช่น Buzzfeed ไม่เลวโดยเฉพาะอย่างยิ่งเมื่อนำมาใช้ในบริบทกับโค้ด JS ที่เหลือรวมถึงโค้ดที่เกี่ยวข้องกับโฆษณาซึ่งใช้เวลาดำเนินการนานกว่ามาก แต่ก็ยังคงเป็นต้นทุนที่ไม่สำคัญสำหรับบางสิ่งที่ใช้เพื่อแสดงความคิดเห็นที่ด้านล่างสุดของ หน้า.

ในสมาร์ทโฟนรุ่นใหม่ (Google Pixel) เวลาในการดำเนินการ JS จะเพิ่มขึ้นเป็นสองเท่าโดยใช้เวลามากกว่า 1/10 ของวินาที:

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

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

คุณควรรวมไว้หรือไม่

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

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

การแก้ไขชื่อ: เดิมทีฉันตั้งชื่อว่า "ทำไม 16% ของโค้ดบนไซต์โดยเฉลี่ยเป็นของ Facebook และนั่นหมายถึงอะไร" ดังที่บางคนชี้ให้เห็นอย่างถูกต้องนี่หมายความว่า Javascript ทั้งหมด 16% ในทุกไซต์บนอินเทอร์เน็ต (หรืออย่างน้อยที่สุดจากไซต์อันดับต้น ๆ ทั้งหมด) ประกอบด้วย Facebook Javascript SDK นี่ไม่ใช่เจตนาของฉันและฉันสามารถเห็นได้ว่ามันเกิดขึ้นได้อย่างไรในฐานะนักแสดงที่โลดโผนเกินไป

หวังว่าชื่อใหม่จะชัดเจนขึ้นว่า Facebook SDK จะวัดได้ที่ 16% ของขนาด Javascript ของไซต์โดยเฉลี่ยและไม่ได้หมายความว่าจะแสดงถึง 16% ของ Javascript ไซต์ทั้งหมดในอินเทอร์เน็ตอีกต่อไป ดังที่ David Gilbertson กล่าวไว้ที่นี่จำนวนจริงทั่วโลกจะน้อยกว่านี้มาก - 0.96% นอกจากนี้เขายังยกประเด็นที่ดีเกี่ยวกับการแคช: Facebook Javascript SDK ไม่ได้ถูกแคชไว้อย่างดีที่สุด แต่จะได้รับการแคชในรูปแบบที่เหมาะสมที่สุดเป็นเวลานานถึง 20 นาทีหลังจากนั้นเบราว์เซอร์ของผู้ใช้จะตรวจสอบเซิร์ฟเวอร์ของ Facebook เพื่อตรวจสอบ มีเวอร์ชันล่าสุดแล้ว