ภาวะ JavaScript บวมในปี 2024

 (tonsky.me)
2 คะแนน โดย GN⁺ 2024-02-24 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

ปัญหาขนาดของ JavaScript

  • ค่อนข้างห่างไกลจากวงการพัฒนา frontend สมัยใหม่อยู่บ้าง และจำได้ว่าเคยเห็นบทความเกี่ยวกับขนาดเว็บที่บวมจนหน้าเว็บมีขนาดหลายเมกะไบต์
  • จึงมีภาพจำว่าถ้าหน้าเว็บเฉลี่ยมีขนาด 3MB แล้ว JavaScript bundle ก็น่าจะอยู่ราว 1MB
  • เพื่อดูว่าความจริงเป็นเท่าไร จึงได้ลองทำการทดลอง

วิธีการ

  • ใช้ Firefox บน macOS (น่าจะเหมือนกันในเบราว์เซอร์อื่น)
  • ใช้โหมดปกติ ไม่ใช่โหมดไม่ระบุตัวตน (เพราะอยากดูตัวเลขภายในแอป และคิดว่าน่าจะใกล้เคียงประสบการณ์จริงมากกว่า)
  • ปิดส่วนขยายทั้งหมด
  • วัดเฉพาะ JavaScript
  • แบบไม่บีบอัด
  • เปิดใช้งาน service worker (เพื่อให้ใกล้เคียงสถานการณ์จริงมากขึ้น)
  • ปิดการแคชทั้งหมด (โหลดใหม่ตั้งแต่ต้น)

หน้าแลนดิ้งเพจ

  • ตัวอย่างหน้าเว็บทั่วไปที่มีการโต้ตอบเล็กน้อย: Wikipedia, 0.2MB
  • ตัวอย่างหน้าเว็บที่เริ่มบวมเล็กน้อย: Linear, 3MB
  • ตัวอย่างหน้าแลนดิ้งเพจที่แย่: Zoom, 6MB; Vercel, 6MB; Gitlab, 13MB

เว็บไซต์ที่ส่วนใหญ่เป็นแบบคงที่

  • แทบจะไม่มีอะไรเรียบง่ายไปกว่าการแสดงกำแพงข้อความแบบคงที่
  • แต่ Medium ต้องใช้ถึง 3MB เพื่อทำแค่นั้น
  • Substack ต้องใช้ 4MB, Quora 4.5MB, Pinterest 10MB, Patreon 11MB

การค้นหา

  • การโต้ตอบของแอปถูกจำกัดอยู่ที่การค้นหาเป็นหลัก
  • StackOverflow ต้องใช้ 3.5MB, NPM 4MB, Airbnb 7MB, Booking.com 12MB
  • Google ต้องใช้ถึง 9MB เพื่อแสดงเพียงช่องข้อความธรรมดาและรายการลิงก์

แอปที่มีปฏิสัมพันธ์แบบเดียว

  • Google Translate ต้องใช้ 2.5MB สำหรับกล่องข้อความสองกล่อง
  • ChatGPT ต้องใช้ 7MB สำหรับกล่องข้อความเพียงกล่องเดียว

วิดีโอ

  • Loom ใช้ 7MB, YouTube ใช้ 12MB
  • Pornhub เป็นเว็บที่ใส่ใจเรื่องประสิทธิภาพ จึงใช้เพียง 1.4MB

เสียง

  • SoundCloud และ Spotify ต่างก็ใช้ 12MB

อีเมล

  • Google Mail ต้องใช้ 20MB
  • FastMail ให้ความสามารถเดียวกันแต่ใช้เพียง 2MB

งานเพิ่มประสิทธิภาพ

  • Todoist ใช้ 9MB, Dropbox 10MB, 1Password 13MB, Trello 13.5MB
  • Discord ต้องใช้ 21MB สำหรับการแชต

การแก้ไขเอกสาร

  • Google Docs ใช้ 13.5MB, Notion ใช้ 16MB

โซเชียลเน็ตเวิร์ก

  • Twitter ใช้ 11MB, Facebook 12MB, TikTok 12.5MB, Instagram 16MB, LinkedIn 31MB

หมวดหมู่ยักษ์ใหญ่

  • Jira ใช้เกือบ 50MB, Slack ใช้ 55MB
  • react.dev เริ่มต้นที่ 2MB แต่เมื่อเลื่อนหน้าก็สามารถโตได้ไม่สิ้นสุด

มันแย่ลงเร็วขึ้นเรื่อย ๆ หรือไม่?

  • ในปี 2015 ขนาดหน้าเว็บเฉลี่ยใกล้เคียงกับ Doom 1 เวอร์ชัน shareware (2.5MB)
  • ในปี 2024 Slack กินพื้นที่ 55MB ซึ่งเท่ากับขนาดดั้งเดิมของ Quake 1 หากนับเฉพาะ JavaScript

10MB ใหญ่แค่ไหน?

  • ตอนนี้ 10MB ไม่ได้ให้ความรู้สึกว่าใหญ่หรือพิเศษอะไรนักแล้ว
  • หากสมมติว่าหนึ่งบรรทัดมี 65 ตัวอักษรโดยเฉลี่ย ก็หมายความว่าแต่ละเว็บไซต์กำลังส่งโค้ดราว 150,000 บรรทัด
  • Google Maps มีขนาด 4.5MB ซึ่งถือว่าค่อนข้างพอประมาณเมื่อเทียบกับมาตรฐานสมัยใหม่

บทสรุป

  • ปัญหาไม่ได้มีแค่ขนาดดาวน์โหลด
  • JavaScript คือสิ่งที่เบราว์เซอร์ต้อง parse, เก็บไว้ในหน่วยความจำ และรัน
  • เชื่อว่าเนื้อหาควรมีขนาดมากกว่าตัวโค้ด
  • Gitlab ต้องใช้โค้ด 13MB หรือ JS มากกว่า 500K LoC เพื่อแสดงหน้าแลนดิ้งเพจแบบคงที่

GN⁺ ความเห็น:

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

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-02-24
ความเห็นจาก Hacker News
  • เว็บไซต์สำหรับผู้ใหญ่เป็นตัวอย่างที่ใส่ใจเรื่องประสิทธิภาพจริง ๆ โดย Pornhub โหลดข้อมูลเพียง 1.4MB เท่านั้น ซึ่งดีกว่าประสิทธิภาพที่บริษัทเทคยักษ์ใหญ่บางแห่งแสดงให้เห็นอย่างมาก Pornhub แทบไม่ค่อยพลาดในเรื่อง UI/UX พื้นฐานหรือการส่งมอบคอนเทนต์
  • เคยใช้งานเว็บผ่านบริการโรมมิงในพื้นที่ชนบทของนิวซีแลนด์ และประสบการณ์ก็แย่มาก UX แบบออฟไลน์ของ Spotify เองก็ยังต้องปรับปรุง
  • มีการตั้งคำถามว่าทำไมเราถึงกำลังดูข้อมูลที่ไม่ถูกบีบอัดอยู่ แอปแบบไดนามิกอย่าง Spotify และ Gmail อาจพอให้อภัยได้ ถ้าหลังโหลดหน้าแล้วสามารถนำทางได้รวดเร็ว บางเว็บไซต์กลับไปเน้นการโหลดครั้งแรกจนทำให้ประสบการณ์ผู้ใช้แย่ลง
  • ซอฟต์แวร์สะท้อนองค์กรที่สร้างมันขึ้นมา ปริมาณข้อมูลที่ส่งส่วนใหญ่มักไม่ใช่ JavaScript ที่จำเป็นต่อการทำงานของหน้าเว็บจริง ๆ แต่เป็นสคริปต์ analytics และสคริปต์จากบุคคลที่สามแทน ฝ่ายการตลาดมักไม่รู้หรือไม่สนใจเรื่องเหล่านี้
  • บทวิเคราะห์นี้ขาดการดูขนาดไฟล์ JavaScript ของเว็บแอปโดยตรง ตัวอย่างเช่น Google Translate ไม่ใช่แค่แอปโต้ตอบธรรมดาและมีฟีเจอร์มากมาย แต่ขนาด 2.5MB ก็ยังมากเกินไปอยู่ดี
  • ทุกหน้าของเว็บไซต์ Wordsandbuttons.online มีขนาดต่ำกว่า 64KB แม้จะมีแอนิเมชันและการโต้ตอบก็ตาม นี่เป็นผลจากนโยบายไม่พึ่งพา third-party
  • ควรพูดถึงไม่ใช่แค่การใช้ JavaScript มากเกินไป แต่รวมถึงปริมาณสคริปต์ติดตามด้วย
  • มีการเปรียบเทียบปริมาณ JavaScript ที่เว็บไซต์ยอดนิยมโหลด ตัวอย่างเช่น Pornhub โหลด JavaScript น้อยกว่า YouTube ราว 10 เท่า
  • สภาพปัจจุบันของเว็บชวนหดหู่มาก คนที่ใช้อินเทอร์เน็ตความเร็วสูงอาจไม่ทันสังเกตว่าเว็บช้าลงไปมากแค่ไหน แทบจินตนาการไม่ออกเลยว่าจะไม่ใช้ตัวบล็อกโฆษณา/ตัวติดตาม
  • มีการสร้างและดูแลเฟรมเวิร์กกับ abstraction ที่ซับซ้อนเพื่อให้บำรุงรักษาง่ายขึ้น แต่หลายคนเป็นนักพัฒนาที่ไม่รู้แม้แต่พื้นฐานของ JavaScript กำลังมีการ over-engineer เว็บแอป และสร้างชั้นที่มากเกินไปจนบังภาษาจริงไว้ หากเรียนรู้ JavaScript ให้ลึกและใช้ JavaScript ล้วนแทนเฟรมเวิร์ก ก็สามารถลดขนาดโค้ดเบส JavaScript ลงได้มาก