การพองตัวของ JavaScript ในปี 2024

 (tonsky.me)
2 คะแนน โดย GN⁺ 2024-02-24 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • กรณีที่เว็บเพจดาวน์โหลด JavaScript แบบไม่บีบอัด ที่ใหญ่กว่าคอนเทนต์จริงมากกำลังกลายเป็นเรื่องปกติ ทำให้ภาระของเบราว์เซอร์เพิ่มขึ้นตั้งแต่หน้าแลนดิ้งเพจธรรมดาไปจนถึงแอปสำหรับงาน
  • การวัดทำบน Firefox บน macOS โดยปิดส่วนขยายและแคช และนับเฉพาะ JavaScript เท่านั้น เพื่อโฟกัสที่ต้นทุนการรันโค้ด โดยไม่รวมรูปภาพ วิดีโอ และสไตล์
  • Wikipedia อยู่ที่ 0.2MB แต่หน้าเรียบง่ายอย่าง Linear 3MB, Zoom·Vercel 6MB, GitLab 13MB ก็ขึ้นไปตั้งแต่หลาย MB จนถึงเลขสองหลัก MB
  • ในกลุ่มแอป Gmail 20MB กับ FastMail 2MB ต่างกันถึง 10 เท่า และเครื่องมือ แชต·ทำงาน อย่าง Jira ราว 50MB กับ Slack 55MB มีปริมาณโค้ดสูงเป็นพิเศษ
  • JavaScript ไม่ได้มีแค่ต้นทุนตอนดาวน์โหลด แต่ยังมีต้นทุนด้าน การพาร์ส·การคงอยู่ในหน่วยความจำ·การรัน ด้วย ดังนั้นโครงสร้างที่ต้องใช้โค้ดบันเดิลขนาดมหึมาเพื่อเรนเดอร์คอนเทนต์เล็กน้อยจึงเป็นภาระต่อประสิทธิภาพและแบตเตอรี่โดยตรง

วิธีการวัดและเกณฑ์เปรียบเทียบ

  • สภาพแวดล้อมที่ใช้วัดคือ Firefox บน macOS และตั้งอยู่บนสมมติฐานว่าแม้ใช้เบราว์เซอร์อื่น ผลโดยรวมก็น่าจะใกล้เคียงกัน
  • เงื่อนไขมีดังนี้
    • โหมดปกติ ไม่ใช่โหมดไม่ระบุตัวตน
    • ปิดส่วนขยายทั้งหมด
    • วัดเฉพาะ JavaScript เท่านั้น
    • ใช้ขนาดแบบไม่บีบอัด
    • เปิดใช้งาน Service Worker
    • cold load โดยปิดแคช
  • คอนเทนต์ถูกตัดออกจากการเปรียบเทียบ เพราะแต่ละเว็บไซต์มีความต่างกันมาก
    • วิดีโอของ YouTube กับข้อความใน Slack มีขนาดโดยธรรมชาติไม่เท่ากัน
    • JavaScript ถูกใช้เป็นตัวชี้วัดร่วมเพื่อเปรียบเทียบความซับซ้อนของการโต้ตอบ
  • ประเด็นสำคัญคือปริมาณงานที่เบราว์เซอร์ต้องแบกรับเพื่อ พาร์สและรัน โค้ด
  • เป็นจุดอ้างอิงว่า บล็อก tonsky.me เองวัดได้ที่ 0.004MB

หน้าแลนดิ้งเพจและคอนเทนต์แบบสแตติก

  • ในตัวอย่างหน้าเว็บทั่วไปที่มีการโต้ตอบเล็กน้อย Wikipedia อยู่ที่ราว 0.2MB
  • หน้าแลนดิ้งเพจที่หนักกว่านั้นมีดังนี้
    • Linear: 3MB
    • Zoom: 6MB
    • Vercel: 6MB
    • GitLab: 13MB
  • ตัวเลขข้างต้นเป็นขนาดของ โค้ด JavaScript เพียงอย่างเดียว โดยไม่รวมรูปภาพ วิดีโอ และสไตล์
  • แม้แต่เว็บไซต์ที่แสดงข้อความแบบสแตติกก็ยังดาวน์โหลด JavaScript หลาย MB
    • Medium: 3MB
    • Substack: 4MB
    • Quora: 4.5MB
    • Pinterest: 10MB
    • Patreon: 11MB
  • มีกรณีที่งานแสดงคอนเทนต์ซึ่งดูเหมือนทำได้ด้วยหน้าสแตติก กลับใช้ JavaScript bundle ขนาดใหญ่

แอปค้นหาและแอปที่มีปฏิสัมพันธ์พื้นฐาน

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

บริการสื่อและอีเมล

  • ขนาด JavaScript ของบริการวิดีโอมีดังนี้
    • Loom: 7MB
    • YouTube: 12MB
    • Pornhub: 1.4MB
  • ในกลุ่มบริการเสียง SoundCloud และ Spotify วัดได้ที่ราว 12MB เท่ากัน
  • ในบริการอีเมล ความแตกต่างยิ่งชัดเจนมาก
    • Google Mail: 20MB
    • FastMail: 2MB
  • FastMail ใช้ JavaScript น้อยกว่า 10 เท่า เมื่อเทียบกับ Google Mail ในหมวดบริการอีเมลเดียวกัน
  • ตัวเลข 20MB ของ Google Mail ใหญ่พอจะนำไปเทียบกับแอปอย่าง Figma ที่มีการเรนเดอร์แบบกำหนดเองด้วย C++/OpenGL ได้

เครื่องมือเพิ่มประสิทธิภาพและการแก้ไขเอกสาร

  • แอปสาย productivity ก็มี JavaScript ใหญ่เมื่อเทียบกับงานที่ทำ
    • Todoist: 9MB
    • Dropbox: 10MB
    • 1Password: 13MB
    • Trello: 13.5MB
    • Discord: 21MB
  • Dropbox ใช้กับการแสดงรายการไฟล์ในโฟลเดอร์, 1Password ใช้กับรายการรหัสผ่าน, และ Trello ใช้กับการแสดงการ์ด แต่ละตัวใช้มากกว่า 10MB
  • บริการแก้ไขเอกสารอยู่ในระดับเลขสองหลัก MB
    • Google Docs: 13.5MB
    • Notion: 16MB
  • แม้งานแก้ไขเอกสารจะมีฟีเจอร์ยากอย่างการขยับเคอร์เซอร์และการซิงก์ แต่ขนาด JavaScript ของบริการที่เปรียบเทียบก็ยังถือว่าใหญ่มาก

โซเชียลเน็ตเวิร์กและกรณีขนาดมหึมา

  • โซเชียลเน็ตเวิร์กโดยทั่วไปใช้ JavaScript ราว 12MB สำหรับฟีเจอร์อย่างไลก์ ฟีด และส่งข้อความ
    • Twitter: 11MB
    • Facebook: 12MB
    • TikTok: 12.5MB
    • Instagram: 16MB
    • LinkedIn: 31MB
  • LinkedIn ซึ่งรวมทั้งบล็อก แพลตฟอร์ม การค้นหา การส่งข้อความ และฟีเจอร์โซเชียล วัดได้ที่ 31MB
  • ส่วนกรณีเว็บแอปที่ใหญ่มากนั้นแทบเป็นอีกหมวดหนึ่งไปเลย
    • Jira: เกือบ 50MB
    • Slack: 55MB
  • Slack เป็นแอปแชตที่จัดการรายชื่อผู้ใช้ ข้อความ และรีแอ็กชัน แต่กลับดาวน์โหลด JavaScript ถึง 55MB
  • react.dev เริ่มต้นที่ 2MB แต่เมื่อเลื่อนหน้าซ้ำ ๆ พบว่า JavaScript เพิ่มขึ้นเรื่อย ๆ
    • ตัวอย่างหนึ่งคือทำให้เพิ่มขึ้นได้ถึง 100MB
    • ตามอัปเดต ประสบการณ์ของผู้ใช้ทั่วไปจะไม่เห็นทราฟฟิกเครือข่ายเพิ่มเติมหลังโหลดครั้งแรก เพราะ embedded code editor ถูกเก็บไว้ในแคช
    • อย่างไรก็ตาม ระหว่างการเลื่อนหน้า JavaScript 100MB อาจยังคงถูกพาร์ส ประเมินผล และเริ่มต้นทำงานต่อเนื่อง

โค้ด 10MB หมายความว่าอะไร

  • ในปี 2015 ขนาดเฉลี่ยของเว็บเพจกำลังเข้าใกล้ 2.5MB ของ Doom 1 shareware version
  • ในปี 2024 Slack ใช้ JavaScript เพียงอย่างเดียว จนแตะขนาดทรัพยากรทั้งหมดของ Quake 1 ต้นฉบับที่ 55MB
  • โค้ด 10MB อาจดูเป็นระดับปกติไปแล้ว แต่ถ้าสมมติว่าหนึ่งบรรทัดมีความยาวเฉลี่ย 65 อักขระ ก็จะเท่ากับราว 150,000 บรรทัด
  • และเพราะโค้ดนี้อยู่ในสถานะ minify แล้ว ขนาดต้นฉบับอาจเกิน 300,000 บรรทัด
  • Google Maps มักถูกยกเป็นตัวอย่างตัวแทนของ SPA แต่กลับวัดได้ 4.5MB ซึ่งเมื่อเทียบกับเว็บแอปสมัยใหม่แล้วถือว่าเล็กเสียด้วยซ้ำ
  • Figma เป็นแอปฟรอนต์เอนด์ที่ซับซ้อน จึงเป็นธรรมดาที่ขนาดดาวน์โหลด JavaScript จะใหญ่ แต่ Gmail มีขนาดใกล้กัน ขณะที่ LinkedIn ใหญ่กว่า 1.5 เท่า และ Slack ใหญ่กว่า 2.5 เท่า

ต้นทุนที่เบราว์เซอร์ต้องจ่าย

  • ปัญหาไม่ได้จบแค่ขนาดตอนดาวน์โหลด
  • JavaScript เป็นสิ่งที่เบราว์เซอร์ต้อง พาร์ส เก็บไว้ในหน่วยความจำ และรัน จึงก่อให้เกิดต้นทุนต่อเนื่อง
  • หากยึดเกณฑ์ว่าขนาดคอนเทนต์ควรใหญ่กว่าขนาดโค้ด โครงสร้างที่ต้องใช้ JavaScript ใหญ่กว่าถึง 1,000 เท่าเพื่อเรนเดอร์บทความบล็อกยาว 10K ตัวอักษร ก็ถือว่ามากเกินไป
  • เว็บไซต์ที่ถูกยกเป็นตัวอย่างที่ดีนั้นทำงานได้เพียงพอด้วย JavaScript แค่ 0.1MB
  • ในสภาพแวดล้อมเว็บเดียวกัน GitLab ถูกนำมาเทียบเป็นกรณีที่ต้องใช้ JavaScript 13MB หรือมากกว่า 500,000 บรรทัด เพื่อแสดงหน้าแลนดิ้งเพจแบบสแตติก

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

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

 
GN⁺ 2024-02-24
ความคิดเห็นใน Hacker News

  • ลองเทียบพวกที่ 10MB, 12MB กับ Pornhub 1.4MB ที่ใส่ใจเรื่องประสิทธิภาพจริง ๆ ก็พอ
    เว็บไซต์โป๊เป็นเว็บไฮเทคของจริงมาโดยตลอด และวิศวกรรมก็ดี ต่างจากบริษัทยักษ์ใหญ่ “เทค” แบบตลก ๆ
    แทบจำไม่ได้เลยว่าเคยทำ UI/UX พื้นฐาน การส่งคอนเทนต์ หรือการออกแบบที่มีสามัญสำนึกพัง

    • ไม่ค่อยเข้าใจว่าทำไม แอปหน้าเดียว (SPA) ถึงได้รับความนิยมบนเว็บขนาดนั้น
      รู้สึกเหมือนอยู่ ๆ ทุกคนก็กลัวการรีเฟรชหน้าเว็บ เพียงเพราะในเว็บแอปพลิเคชันจริง ๆ การรีเฟรชหน้าเป็นพฤติกรรมที่ไม่ต้องการ
      ผมทำงานกับแอปพลิเคชันองค์กรมา 20 ปี และเคยเห็นระบบที่สร้างก่อนผมเกิดด้วยซ้ำ ผมคิดว่า React เป็นฟรอนต์เอนด์ที่ดีที่สุดสำหรับแทนที่ UI ไคลเอนต์/เซิร์ฟเวอร์อันเลวร้ายแบบเก่าในระบบพวกนั้น
      Angular/Vue ฯลฯ ก็อยู่ในบริบทเดียวกัน แต่สำหรับหน้าเว็บทั่วไป แทบไม่จำเป็นเลย เว้นแต่การโต้ตอบและการอัปเดตแบบเรียลไทม์จะเป็นแกนหลักของผลิตภัณฑ์อย่าง Gmail หรือ Facebook
      ที่อย่าง Pornhub ใช้ PHP ก็พอแล้ว และเว็บไซต์ส่วนใหญ่ก็เช่นกัน ดูได้จากที่ยังมีคนจำนวนมากชอบ HN หรือ old.reddit.com และผมก็คิดว่าคงมีคนจำนวนมากชอบ old.Facebook มากกว่า Facebook ใหม่ที่ช้าลงด้วย
    • ยังจำ กลเม็ดโฆษณาน่าสงสัย มากมายที่เว็บไซต์โป๊ใช้กันได้
      เช่น ป๊อปอัป ป๊อปอันเดอร์ ส่งไปยังไซต์รวบรวมคล้าย ๆ กันด้วยคอนเทนต์ปลอม เปิดไซต์พันธมิตรแทนคอนเทนต์ ทำให้ผลการค้นหาปนเปื้อน
      โป๊ไม่ได้เป็นอุตสาหกรรมที่ผลักดันเทคโนโลยีมากเท่าที่คนพูดกัน ตำนานเมืองเรื่อง Betamax กับ VHS ก็ไม่จริง และคำกล่าวที่ว่าเป็นผู้นำนวัตกรรมอินเทอร์เน็ตก็เกินจริง
      มีผู้เล่นบางรายที่ทำผลิตภัณฑ์คุณภาพสูง แต่ไม่ได้เป็นตัวแทนทั้งอุตสาหกรรม มีลิงก์ฟาร์ม คอนเทนต์หลอก ไซต์โคลน โฆษณาเท็จ และการปั่นผลการค้นหาอยู่มาก
      ที่ตอนนี้ไซต์อันดับต้น ๆ ตอบสนองไว น่าจะเป็น ผลของการแข่งขัน ถ้า UX แย่ ผู้ใช้ก็ย้ายไปที่อื่นทันทีเพราะมีโป๊ฟรีล้นเหลือ จึงต้องปรับให้ดีที่สุดเพื่อรักษาผู้ใช้ไว้
      เว็บไซต์อื่น ๆ มีแรงจูงใจอย่างผู้ถือหุ้น ผู้ให้บริการคอนเทนต์ สัญญาผูกขาด หรือสถานะผูกขาด จึงไม่จำเป็นต้องปรับประสบการณ์ผู้ใช้ให้ถึงระดับนั้น
    • ผมเคยทำงานในสาขานั้น เหตุผลหลักอย่างหนึ่งที่ความบันเทิงผู้ใหญ่ถูกปรับแต่งประสิทธิภาพอย่างหนักคือมี ผู้ใช้จากประเทศที่อินเทอร์เน็ตช้า จำนวนมาก
      ใช้เวลานับไม่ถ้วนไปกับการปรับทุกอย่างให้เหมาะสม ทั้งการส่งวิดีโอ ไลฟ์สตรีมมิง (เมื่อก่อนเป็น Flash ตอนนี้เป็น WebRTC) ขนาดหน้าเว็บ ฯลฯ
    • playboy.com/app เล็กกว่า Pornhub อีก โดยอยู่ที่ 1.1MB เมื่อยืนยันตัวตน และ 993KB เมื่อไม่ได้ยืนยันตัวตน
    • YouTube ก็ลอกฟีเจอร์ “ช่วงที่น่าสนใจของวิดีโอ” ไปตรง ๆ

  • สงสัยว่าทำไมถึงดู ข้อมูลก่อนบีบอัด กันอยู่ ตัวอย่างแย่ ๆ บางไซต์ที่ยกมา พอบีบอัดแล้วก็เล็กกว่า 1.5MB ของ GMaps ได้ง่าย ๆ
    แอปไดนามิกอย่าง Spotify หรือ GMail ผมคิดว่าโอเค ถ้าการนำทางหลังโหลดหน้าแล้วเร็ว
    แบบ Discord ที่ตอนเริ่มใช้เวลาหลายวินาทีเพื่ออัปเดต ยังดีกว่า GitLab ที่ให้รอสูงสุด 2 วินาทีทุกครั้งที่คลิก
    ผมคิดว่าการให้ความสำคัญกับคอลด์สตาร์ตและการเรนเดอร์แบบสแตติกในยุคนี้ กลับทำให้ประสบการณ์ของบางไซต์แย่ลง
    ลองทดลองนำทางใน file tree บน GitHub ดู บนอุปกรณ์ของผมมันคล่องกว่าส่วนอื่น ๆ ของ GitHub มาก บังเอิญว่าส่วนนี้เป็นหนึ่งในไม่กี่ส่วนที่ไม่ได้เรนเดอร์แบบสแตติก
    ผมคลิกหน้า GitHub เป็นร้อย ๆ หน้าทุกวัน แทนที่จะให้ผมต้องโหลด footer ทั้งหมดใหม่ทุกครั้งแค่เพื่อดู pipeline สักอัน ผมอยากให้ส่ง JavaScript ก้อนใหญ่มาก ๆ มาครั้งเดียว แล้วแคชให้ได้มากที่สุด
    [1]: GMail กับ Spotify เป็นแค่ตัวอย่าง และจริง ๆ ไม่ได้ใช้

    • การบีบอัดช่วยเรื่องการส่งข้อมูล แต่เครื่องยังต้อง parse โค้ดทั้งหมดนั้นอยู่ดี
      เรื่องนี้ถูกพูดถึงบ่อยในการถกเรื่องการเข้าถึง เพราะประสิทธิภาพ CPU ระหว่าง iOS กับ Android ต่างกันมาก และถ้าดูไปถึงอุปกรณ์ราคาถูกที่คนทั่วไปใช้กันเยอะ อุปกรณ์ Android ใหม่ที่ขายวันนี้บางเครื่องยังช้ากว่า iPhone ปี 2014 ด้วยซ้ำ
      ถ้านักพัฒนาใช้แต่ iPhone รุ่นล่าสุดหรือ Android เรือธง ก็พลาดได้ง่ายว่าโค้ดที่บวมขึ้นส่งผลต่อผู้ใช้ระดับกลางมากแค่ไหน
      https://infrequently.org/2024/01/performance-inequality-gap-...
    • แม้จะเป็นการโหลดหน้าเดียว ก็ยังต้องใช้เวลา หน่วยความจำ พื้นที่ดิสก์ และพลังงานในการคลายบีบอัดและใช้งานสคริปต์
      การแคชช่วยลดต้นทุนด้านพลังงานและเวลาที่ใช้ดาวน์โหลดกับคลายบีบอัดได้ แต่ลบต้นทุนตอนใช้งานจริงไม่ได้
      จากกฎจำง่ายตามประสบการณ์ส่วนตัว ยิ่ง JavaScript ก่อนบีบอัด ใหญ่เท่าไร ก็ยิ่งมีโค้ดที่ CPU ต้องรันต่อเนื่องเวลาขยับเมาส์ กดปุ่ม หรือเลื่อนหน้ามากขึ้นเท่านั้น
      ยอมเสียประสิทธิภาพด้านเวลาไปนิดเพื่อได้ประสิทธิภาพด้านพลังงานจะดีกว่า และในจุดที่ใช้ CSS แทนได้ ผมชอบแบบสแตติกมากกว่าพฤติกรรมสวย ๆ
      หรือปัญหาที่ใหญ่กว่าจริง ๆ อาจเป็นไซต์ที่ดาวน์โหลดไฟล์เพิ่มในหลาย ๆ การกระทำ ไม่ใช่แค่การคลิกแล้ว URL ย้ายไปหน้าอื่น นี่เป็นความบวมแบบซ่อนเร้น และแย่มากต่อการเก็บถาวรด้วย
      อยากให้เลิกใช้ JavaScript ทำให้ URL ในแถบที่อยู่ยังเหมือนเดิมแต่แสดง “หน้า” อื่น นี่ก็แย่มากต่อการเก็บถาวรจริง ๆ
      อีกกฎจำง่ายคือ ยิ่ง JavaScript ก่อนบีบอัดใหญ่เท่าไร เวอร์ชันของไซต์ที่ถูกเก็บถาวรก็ยิ่งมีโอกาสทำงานถูกต้องน้อยลงเท่านั้น
    • file tree ของ GitHub คล่องกว่าส่วนอื่น ๆ ของ GitHub จริง แต่ส่วนนั้นก็เป็นส่วนเดียวที่ ใช้ไม่ได้บนการเชื่อมต่อช้า ด้วย
      สัปดาห์ก่อนอินเทอร์เน็ตผมช้า พอคลิกไฟล์บนเว็บไซต์ GitHub มันพยายามโหลดด้วยสคริปต์แล้วล้มเหลว ทำให้ file tree ใช้ไม่ได้จริง ๆ
      แต่ถ้าคัดลอก URL ของไฟล์แล้ววางในแถบที่อยู่ของเบราว์เซอร์ มันโหลดได้ถูกต้อง
    • Gmail แย่มาก ไม่รู้ว่ามีแค่ผมหรือเปล่า แต่หลังทำเครื่องหมายอีเมลว่าอ่านแล้ว ต้องรอ 20 วินาที ก่อนปิดแท็บ ไม่งั้นสถานะว่าอ่านแล้วจะไม่ถูกบันทึก
      Spotify มีปัญหาเรื่องการเชื่อมต่อเครือข่ายเยอะ ต่อให้ดาวน์โหลดอัลบั้มไว้แล้ว ถ้าเครือข่ายเปลี่ยนมันก็แพนิกสุด ๆ ใช้โหมดออฟไลน์ไปเลยยังดีกว่าพยายามออนไลน์ตลอดเวลา
    • GitHub ตอนนี้ใกล้เคียงกับตัวอย่างที่แย่ที่สุดของเทคนิคสไตล์ “Pjax” หรือ HTMX
      คงตัดสินสถาปัตยกรรมนั้นทั้งหมดจากสิ่งนี้ได้ยาก คล้ายกับการชี้ SPA ที่แย่มากหนึ่งตัวแล้วบอกว่า SPA ทั้งหมดไม่ดี

  • ซอฟต์แวร์ทั้งหมดสะท้อน รูปร่างหน้าตาขององค์กร ที่สร้างมันขึ้นมา
    ข้อมูลส่วนใหญ่ที่ถูกส่งไปมีแนวโน้มจะไม่ใช่ JavaScript ที่จำเป็นจริง ๆ ต่อการทำงานของหน้าเว็บ แต่เป็นเครื่องมือวิเคราะห์และสคริปต์จาก third-party ต่าง ๆ
    มีเพียงหมวด “elephant” เท่านั้นที่เข้าข่ายโมดูลแบบ lazy loading อย่าง React
    ของพวกนี้จำนวนมากขับเคลื่อนโดยทีมการตลาดที่ไม่รู้หรือไม่สนใจปัญหานี้
    หลายครั้งนักพัฒนาก็แค่เอา Google Tag Manager หรือบริการแทรกสคริปต์อื่น ๆ ไปติดบนหน้าเว็บเท่านั้น บางกรณีแม้แต่นักพัฒนาก็ไม่ได้ทำเองด้วยซ้ำ แต่ proxy ของโครงสร้างพื้นฐานฝั่งปฏิบัติการเป็นฝ่ายแก้หน้าเว็บ
    ความกังวลที่มีนัยสำคัญกว่าอาจเป็นเรื่องที่ฝ่ายการตลาดมีอำนาจควบคุมผลลัพธ์มากกว่าคนที่ทำงานจริง
    สำหรับหน้า “elephant” ความอ้วนเทอะทะอยู่ที่ตัวองค์กรเอง ไม่ใช่ปัญหาของคนโง่ไม่กี่คน แต่เป็นปัญหาของ ความโง่ที่ถูกขยายสเกล

    • Google Tag Manager คือเครื่องมือชั้นยอดในการทำลายประสิทธิภาพของหน้าเว็บ
      ที่ทำงานเก่าของผม แผนกที่ไม่ใช่สายเทคนิคเป็นคนถือ Google Tag Manager และเราต้องคอยจับตาขยะที่ถูก inject เข้าไปในหน้า production อยู่ตลอด
      ผมสู้หนักมากเพื่อพยายามเอามันออก
    • เมื่อก่อนผมเคยเชื่อมโยง Google กับความปราดเปรียวและรวดเร็ว
      Google Search เคยเป็นแบบนั้นเมื่อเทียบกับ Yahoo และ Chrome ตอนเปิดตัวก็เป็นแบบนั้นเมื่อเทียบกับ IE/Firefox
      ตัว Chrome เองแทบไม่มี UI เลย และนั่นแหละคือฟีเจอร์ของมัน

  • เพิ่งกลับจากโรดทริปที่นิวซีแลนด์มาเมื่อไม่นานนี้ พื้นที่ชนบทจำนวนมาก แทบไม่มีสัญญาณมือถือหรือไม่มีเลย
    พอรวมกับการโรมมิ่งก็รู้สึกเหมือนช้าลงไปอีกชั้น ทำให้ใช้งานเว็บจำนวนมากได้ลำบากจริง ๆ
    ถ้ามี PM ของ Spotify อยู่ อยากให้ช่วยทบทวน UX แบบออฟไลน์หน่อย ออฟไลน์เป็นหนึ่งในฟีเจอร์หลักของพรีเมียม แต่พอใช้แอปแบบออฟไลน์จริง ๆ กลับแย่มากในหลายด้าน

    • ออฟไลน์ดีกว่าอินเทอร์เน็ตที่ไม่เสถียรมาก
      ถ้า Spotify ตัดสินว่ามีอินเทอร์เน็ต มันจะไปถามเซิร์ฟเวอร์เพื่อเอาเนื้อหาทั้งหมดของ context menu รอการตอบกลับอยู่หลายวินาที แล้วบางครั้งก็ยอมแพ้ไม่แสดงเมนู บางครั้งก็ย้อนกลับไปทำสิ่งที่ถ้าเป็นโหมดออฟไลน์จะทำได้ทันที
      ผมเกลียด player ตัวนี้จริง ๆ
    • Spotify อย่างน้อยบน iOS ดูเหมือนจะติดกับดัก การแบ่งขาวดำระหว่างออนไลน์/ออฟไลน์
      ในสถานะกึ่งกลางที่ latency สูงมากหรือ packet loss เยอะ จริง ๆ ควรทำงานเหมือนออฟไลน์ แต่ Spotify กลับคิดว่าออนไลน์
      อย่างไรก็ตามปัญหาแบบนี้พบได้บ่อยมาก และไม่ใช่แค่ Spotify ที่ทำพลาด อีกทั้งการกำหนด threshold ที่ถูกต้องก็คงยากจริง ๆ
    • ผมอยู่ลอนดอน ปกติสัญญาณดีแทบทุกที่ แต่เครือข่ายรถไฟใต้ดินเป็นข้อยกเว้น และแม้กำลังทยอยติดตั้ง 5G อยู่ แต่ก็ยังไม่ได้ครอบคลุมทั้งหมด
      ไม่เข้าใจว่าทำไม Spotify ถึงให้ผมรอ 30 วินาที เพื่อให้แอปโหลดอะไรบางอย่างตอนที่ไม่มีสัญญาณ ผมแค่อยากฟังพอดแคสต์ที่ดาวน์โหลดไว้ต่อเท่านั้น
    • โหมดออฟไลน์ของ Spotify น่าหงุดหงิดมาก จนผมเริ่มทำ แอปเพลงบน iOS แบบ offline-first เอง
    • น่าจะตั้ง ค่า timeout สำหรับการย้อนกลับไปโหมดออฟไลน์ให้ aggressive กว่านี้ได้
      ผมสงสัยว่าการตัดสินใจเชิงวิศวกรรมแบบไหนที่ทำให้การถ่วงน้ำหนักสถานการณ์แบบนี้ซับซ้อนขนาดนั้น

  • บทความนี้พลาดประเด็นไปเต็ม ๆ โดยเฉพาะตรงที่ไม่ได้แยกดูว่าทำไมไฟล์ JavaScript ในเว็บแอปพลิเคชันจริง ๆ ถึงใหญ่ขนาดนั้น
    ตัวอย่างเช่น ถ้ามอง Google Translate ให้ละเอียด มันไม่ใช่แอปที่โต้ตอบครั้งเดียวแล้วจบ มีทั้งพจนานุกรม ข้อเสนอแนะทางเลือก การถอดเสียง การออกเสียง วิธีป้อนข้อมูลหลายแบบ ฯลฯ
    ต่อให้คำนึงถึงเรื่องเหล่านั้นแล้ว 2.5MB ก็ยังใหญ่เกินไป และผมคิดว่าฟีเจอร์บางอย่างที่เลือกใช้ได้ควรและสามารถทำ lazy loading ได้ แต่บทความนี้ขี้เกียจเกินไปจนไม่ช่วยให้ถกกันได้ลึกขึ้นเท่าไร

    • ของพวกนั้นแทบไม่ได้อยู่ใน initial bundle ไม่ใช่หรือ? ส่วนใหญ่น่าจะเป็นข้อมูลที่มาจากเซิร์ฟเวอร์
      if data.transliteration show icon with audio embed จะต้องใช้ JavaScript สักเท่าไรกัน?
    • ไม่ได้อยากด่าตัวบทความ แต่ก็ขำดีที่การโหลดสกรีนช็อตช้า
      เข้าใจได้ว่าอาจมีรูปใหญ่และจำนวนมาก แต่ก็แอบประชดประชันนิด ๆ
    • แอปส่วนใหญ่มีช่องให้ปรับแต่งประสิทธิภาพแน่นอน แต่ถ้า ลดทอนจนง่ายเกินไป แบบ “แค่จะแสดงกล่องข้อความกล่องเดียว ทำไมต้องใช้ JavaScript หลาย MB” การเปรียบเทียบก็จะไร้ประโยชน์ไปเลย

  • ผมเข้าใจว่านัยยะตรงนี้คือ “มี JavaScript มากเกินไป” แต่ก็ควรพูดด้วยว่าส่วนใหญ่ในนี้เป็น ขยะสำหรับติดตามผู้ใช้ล้วน ๆ มากแค่ไหน

    • เว็บไซต์แบรนด์ของแทบทุกบริษัทมักมีไลบรารีติดตามและวิเคราะห์สำหรับการตลาดกับการเก็บ feedback ด้าน UX ติดตั้งอยู่
      ที่แย่กว่านั้นคือบางส่วนไม่ได้ถูก bundle ไปกับโค้ดของ host แต่ถูกดึงมาจากภายนอก ทำให้ latency และความเสี่ยงด้านความปลอดภัยที่อาจเกิดขึ้นเพิ่มขึ้น
    • ที่ทำงานเก่าผมต้องทำสงครามกับ Google Tag Manager
      มันเป็นเครื่องมือที่ปล่อยให้นักการตลาด inject ขยะอะไรก็ได้เข้าไปในเว็บแอปพลิเคชันโดยไม่ต้องให้นักพัฒนาเข้ามาเกี่ยว
      ความสัมพันธ์ก็พังไปบ้าง ผมก็ไม่ได้ชนะ และประสิทธิภาพก็ยังห่วยเหมือนเดิม
      ถัดจากนั้น สิ่งที่ก่อปัญหาด้านประสิทธิภาพคือไลบรารีหนัก ๆ อย่างแผนที่และกราฟ ซึ่งโดยทั่วไปแก้ได้ด้วย lazy loading ที่ฉลาด
      จากประสบการณ์ตรง มีกรณีที่ฟีเจอร์เล็กมากแต่กลับโหลดไลบรารีสแกน QR code กับไลบรารีแผนที่ตอนเริ่มต้น, กรณีที่ดึงสตริง internationalization ทั้งหมดด้วยคำขอแบบ waterfall ตอนเริ่มต้นจนบล็อกก่อนที่ JS ใด ๆ จะรันได้, และกรณีที่ Zendesk ทำลายประสิทธิภาพของหน้าเว็บอย่างสิ้นเชิง แต่เพราะเป็นคำสั่งจากเบื้องบนจึงทำได้แค่ใส่ lazy load
      ถัดมาคือโค้ดที่ออกแบบไม่ดีซึ่งทำให้เกิด DOM element หรือการ re-render หรือคำขอแบบ waterfall มากเกินไป
      สุดท้ายคือขนาดโค้ดระดับแอป ซึ่งก็แก้ได้ด้วย lazy loading แต่โดยทั่วไปไม่จำเป็นจนกว่าแอปพลิเคชันจะใหญ่โตมาก ๆ
    • ทดสอบได้ง่าย ๆ ด้วยการเปิด ad blocker
      เช่น landing page ของ GitLab พอบล็อกสคริปต์ติดตามแล้ว จาก 13MB เหลือ “แค่” 6MB
      แผนกการตลาดจะทำให้ software bloat เพิ่มเป็นสองเท่าเสมอ
    • แต่ถึงอย่างนั้น โค้ดติดตามผู้ใช้ที่เลวร้ายเป็นชิ้น ๆ ไม่น่าจะกินหน่วยความจำเป็นระดับหลายเมกะไบต์ได้ไม่ใช่หรือ? ก็แค่รวบรวมข้อมูล session ของผู้ใช้แล้วส่งไปที่ไหนสักแห่ง

  • เป็นการเปรียบเทียบว่าเว็บไซต์ยอดนิยมโหลด JavaScript มากแค่ไหนในการโหลดแบบ cold load ประเด็นหลักมีดังนี้
    PornHub โหลด JS น้อยกว่า YouTube ประมาณ 10 เท่า (1.4MB เทียบกับ 12MB)
    Gmail มี footprint ใหญ่จนเข้าใจยาก (20MB) ส่วน Fastmail เบากว่าถึง 10 เท่าที่ 2MB และ Figma แม้จะเป็นแอปที่ซับซ้อนกว่า แต่ก็อยู่ราว 20MB ใกล้เคียงกัน
    Jira นี่ 58MB เลย มหาศาลมาก

    • Pornhub จำเป็นต้องเล็ก
      Jira หลังจากดาวน์โหลดครั้งหนึ่งแล้ว ก็น่าจะโหลดจากในเครื่องเหมือนแอปออฟไลน์จนกว่าจะมีอัปเดต
      Pornhub มีโอกาสสูงที่จะถูกรันในโหมดไม่ระบุตัวตน จึงพึ่งแคชไม่ได้
    • YouTube สำหรับผมรู้สึกค่อนข้างลื่นไหล แต่ Figma เป็นหนึ่งในประสบการณ์ที่แย่ที่สุดอย่างสม่ำเสมอในบรรดาเว็บแอป
      Jira ก็แย่มากและช้า
    • Figma ใช้ WASM ดังนั้นขนาดรวมจึงใหญ่กว่านี้มาก: https://www.figma.com/blog/figma-faster/
    • ไม่รู้ว่าไคลเอนต์อีเมลต้องใช้ JS 20MB ไปทำไม
    • YouTube 12MB เนี่ย มันกลายเป็นแบบนั้นได้ยังไงกัน?

  • ทุกหน้าของ https://wordsandbuttons.online/ แม้จะมีแอนิเมชันและการโต้ตอบ ก็ยังมีขนาด ต่ำกว่า 64KB
    เช่นหน้านี้ https://wordsandbuttons.online/trippy_polynomials_in_arctang... มีขนาด 51KB
    โค้ดก็ไม่ได้ประหยัดเลยแม้แต่น้อย 80% เป็นการคัดลอกวางที่ต่างกันเล็กน้อย และไม่มีความพยายามจะย่อให้ฉลาดขึ้นเลย ทั้งหมดเป็น vanilla JS แบบเก่า ไม่มีการบีบอัดหรือเอาช่องว่างออก
    ถ้าเปิดด้วย “View page source” โค้ดจะอยู่ในสภาพที่อ่านได้เต็มที่
    เคล็ดลับคือ นโยบายไม่พึ่งพา dependency เลย ไม่มีทั้ง third-party และ dependency ภายใน โค้ดที่ต้องใช้ทั้งหมดถูกส่งมาพร้อมไฟล์ HTML
    ที่ย้อนแย้งคือในระยะยาว การคัดลอกวางไม่ใช่สาเหตุของความบวม แต่เป็นวิธีป้องกัน

    • อย่างน้อยก็น่าจะเพิ่ม margin ได้บ้าง
      บนมือถือ ขอบนี่มองไม่เห็นจริง ๆ
    • dependency และเครื่องมือ JS “สมัยใหม่” ก็ทำสิ่งเดียวกันได้
      dependency เองไม่ใช่สาเหตุ แต่เป็นอาการ เว็บไซต์และบริษัทต่าง ๆ ไม่มีแรงจูงใจที่จะลดความบวมอีกต่อไป ดังนั้น dependency ที่ซ้ำซ้อนจึงแทบไม่ได้รับการเก็บกวาด

  • นึกถึงบทความ The Website Obesity Crisis จากปี 2015 [1] หลังจากนั้น [2] สถานการณ์ก็ยิ่งแย่ลง และตอนนี้ก็ผ่านไปเกือบ 10 ปีแล้ว
    จะโง่ไหมถ้าบอกว่าอีก 10 ปีข้างหน้า การท่องเว็บด้วย PC ประมาณยุคปี 2015 จะเป็นไปไม่ได้? ถ้าไม่มีอะไรเปลี่ยน ก็ดูเหมือนจะเป็นอย่างนั้น
    แม้จะลง Firefox รุ่นล่าสุดบน MacBook เก่าปี 2013 ก็ยังรับ JavaScript 23.98MB ของหน้า https://civitai.com ไม่ไหว และค้างไปประมาณ 30 วินาทีขณะพยายามเรนเดอร์เว็บฟรอนต์เอนด์สุดหายนะนี้
    ไม่ใช่แค่ปัญหาของเว็บเท่านั้น แอปมือถือแบบ all-in-one ก็ใหญ่เกินไปจนโทรศัพท์ปี 2013 โหลดไม่ไหวเช่นกัน และครึ่งหนึ่งในนั้นก็เขียนอยู่บนสแต็กเทคโนโลยีเว็บ
    ไม่เข้าใจว่าทำไมบริษัทที่มีงบประมาณมากถึงไม่มีปัญญาใช้แอปพลิเคชันแบบ native
    [1] https://idlewords.com/talks/website_obesity.htm
    [2] https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

  • สภาพของเว็บน่าเศร้ามาก
    คนส่วนใหญ่ที่ใช้การเชื่อมต่อไฟเบอร์ไม่รู้สึกด้วยซ้ำว่าเว็บช้าลงแค่ไหน
    แต่ถ้ายังอยู่บนการเชื่อมต่อ 2Mbps มันแย่มากจริง ๆ ผมอยู่ในสภาพนั้น และมันทรมาน
    ดังนั้นการไม่ใช้ตัวบล็อกโฆษณา/ติดตามนี่ไม่อยู่ในข่ายพิจารณาเลย
    อยากเห็นการทดสอบนี้ตอนเปิด Ublock Origin

    • ผมก็อยากเห็นเหมือนกัน
      โค้ดส่วนใหญ่พวกนี้น่าจะใช้ติดตามผู้ใช้และจัดการโฆษณา
    • ถ้าเป็นการเชื่อมต่อ 2Mbps ลองคิดดูว่าจะเกิดอะไรขึ้นถ้าใช้แอปสมัยใหม่บน iPhone 3 หรือ Nexus รุ่นแรก?
      ผมไม่เข้าใจว่าทำไมถึงคิดว่า แม้เราจะมีคอมพิวเตอร์ที่ดีขึ้น เร็วขึ้น และความเร็วเครือข่ายที่สูงขึ้นแล้ว ก็ยังต้องโฟกัสกับการทำให้แอปและเว็บไซต์เล็กลงเรื่อย ๆ
    • Raspberry Pi รุ่นใหม่แข่งขันกับสมาร์ตโฟนในอดีตได้ และสมาร์ตโฟนเหล่านั้นก็มีพลังประมวลผลใกล้เคียงกับเซิร์ฟเวอร์รุ่นเก่า
      ด้วยกฎของมัวร์ นักพัฒนาจึงสามารถยอมเสียความเหมาะสมที่สุด ผลักดันให้มากขึ้น และเคลื่อนไหวได้รวดเร็ว ซึ่งก็เกิดขึ้นบ่อยในกรณีแบบนี้
    • คนส่วนใหญ่ที่ใช้การเชื่อมต่อไฟเบอร์งั้นเหรอ? ผมคิดว่าคนมีเงินจำนวนมากก็ยังไม่มีไฟเบอร์ใช้ และใน HN ก็คงไม่ใช่คนส่วนใหญ่อย่างแน่นอน