เว็บเพจ 49MB

 (thatshubham.com)
2 คะแนน โดย GN⁺ 2026-03-16 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • หน้าบทความหนึ่งบนเว็บไซต์ The New York Times ทำให้เกิดคำขอเครือข่าย 422 ครั้งและการรับส่งข้อมูล 49MB จนแม้แค่การเปิดอ่านบทความธรรมดาก็ต้องใช้ทรัพยากรมากเกินไป
  • ระหว่างการโหลดหน้า มีคำขอประมูลโฆษณาจำนวนมากและสคริปต์ติดตามทำงานพร้อมกัน ส่งผลให้ CPU ของเบราว์เซอร์และแบตเตอรี่ถูกใช้ไปโดยไม่จำเป็น
  • การออกแบบ UX แบบเป็นปฏิปักษ์ลักษณะนี้ต่อยอดไปเป็นแบนเนอร์คุกกี้ ป๊อปอัปสมัครสมาชิก วิดีโอเล่นอัตโนมัติ และโฆษณาที่กินพื้นที่หน้าจอ ซึ่งรบกวนประสบการณ์การอ่านของผู้ใช้
  • โมเดลธุรกิจที่ยึด ‘เวลาที่อยู่บนหน้า’ และ ‘อัตราการมองเห็น’ เพื่อเพิ่มรายได้จากโฆษณาสูงสุด กำลังแลกมาด้วยการเสียสละประสบการณ์ของผู้อ่าน และแม้แต่วิศวกรก็ยังติดอยู่ในโครงสร้างนี้
  • บทความยกตัวอย่างหน้าเว็บข่าวน้ำหนักเบาที่เน้นข้อความเป็นหลัก เช่น text.npr.org เพื่อเน้นย้ำการฟื้นคืนประสบการณ์เว็บที่เรียบง่าย ให้เกียรติผู้ใช้ และทำให้ผู้อ่านกับธุรกิจอยู่ร่วมกันได้

ความจริงของเว็บเพจ 49MB

  • เมื่อเข้าเว็บไซต์ The New York Times จะเกิดคำขอ 422 ครั้งและข้อมูล 49MB และต้องใช้เวลา 2 นาทีจึงจะนิ่ง
    • ขนาดนี้ใหญ่กว่าความจุทั้งหมดของ Windows 95 (ฟลอปปีดิสก์ 28 แผ่น) และเทียบได้กับเพลง MP3 ประมาณ 10–12 เพลง
    • เท่ากับว่าต้องดาวน์โหลดข้อมูลระดับอัลบั้มหนึ่งชุดเพียงเพื่ออ่านข้อความไม่กี่ย่อหน้า
  • แม้ประสิทธิภาพฮาร์ดแวร์จะก้าวหน้าอย่างมากเมื่อเทียบกับอดีต แต่เว็บเฟรมเวิร์กที่ขับเคลื่อนด้วยโฆษณาและการติดตามกลับหักล้างความก้าวหน้านั้น

ภาระของ CPU และโครงสร้างการติดตาม

  • เว็บไซต์ข่าวรันระบบประมูลโฆษณาแบบโปรแกรมแมติกภายในเบราว์เซอร์
    • มีคำขอประมูลแบบอะซิงโครนัสไปยัง Rubicon Project, Amazon Ad Systems และอื่น ๆ พร้อมกัน
    • เบราว์เซอร์ต้องดาวน์โหลด พาร์ส และคอมไพล์ JavaScript หลาย MB ซึ่งนำไปสู่ภาระบน main thread
  • ผู้ใช้ขอเพียงข้อความ แต่เบราว์เซอร์กลับต้องประมวลผลสคริปต์ติดตามขนาด 5MBก่อน แล้วจึงค่อยแทรกโฆษณา
  • พร้อมกันนั้นยังมีบีคอนติดตามพฤติกรรม (คำขอ POST) และการรีไดเร็กต์พิกเซลที่มองไม่เห็น (doubleclick.net, casalemedia) ทำงานเพื่อระบุตัวตนข้ามเว็บไซต์
  • กระบวนการเหล่านี้ทำให้มือถือร้อนและแบตเตอรี่หมดไว และผู้ใช้ก็ถูกดึงเข้าสู่ตลาดซื้อขายข้อมูลความถี่สูงโดยไม่รู้ตัว

UX แบบเป็นปฏิปักษ์และต้นทุนของการโต้ตอบ

  • เมื่อเข้าหน้าเพจจะมีแบนเนอร์คุกกี้ GDPR, โมดัลสมัครรับจดหมายข่าว, ป๊อปอัปขออนุญาตแจ้งเตือนโผล่มาต่อเนื่อง
    • ผู้ใช้ต้องคลิกและเลื่อนหลายครั้งก่อนจะเข้าถึงเนื้อหาได้
    • สิ่งนี้ขัดกับหลัก**‘ต้นทุนของการโต้ตอบ (Interaction Cost)’** และ**‘การออกแบบแบบมินิมัล’**ของ NNgroup
  • ในกรณีของ Economic Times ผู้ใช้ต้องปิดโมดัลสามชั้นและข้ามแบนเนอร์ด้านบนก่อนจึงจะเข้าถึงเนื้อหาหลักได้
  • แม้ตามเกณฑ์ Core Web Vitals ของ Google เอง อินเทอร์สทิเชียลที่รบกวนการใช้งานลักษณะนี้ก็ถูกระบุว่าเป็นปัจจัยหักคะแนน SEO

เลย์เอาต์ที่ไม่เสถียรและการแทรกโฆษณา

  • ระหว่างที่ผู้อ่านกำลังอ่านย่อหน้า หากการประมูลโฆษณาเสร็จสิ้น จะมีโฆษณา iframe ถูกแทรกเข้ามา ทำให้ข้อความเลื่อนลง 250 พิกเซล
    • สิ่งนี้ถูกวัดเป็นCumulative Layout Shift (CLS) และเชื่อมโยงโดยตรงกับอัตราการออกจากหน้า
  • Google หักคะแนนปัญหานี้อย่างเป็นทางการ แต่ก็มีความย้อนแย้งตรงที่ผลิตภัณฑ์โฆษณาของ Google เองก็ก่อปัญหาแบบเดียวกัน
  • วิดีโอเล่นอัตโนมัติยังคงเล่นต่อแม้ผู้ใช้จะเลื่อนหน้าจอไปแล้ว โดยตรึงอยู่ด้านล่างของหน้าจอ และปุ่มปิดก็เล็กพร้อมพื้นที่คลิกที่แคบ
    • บทความชี้ว่านี่เป็นตัวอย่างของการละเมิดกฎของ Fitts

การสิ้นเปลืองพื้นที่บนมือถือ

  • จาก viewport มือถือเฉลี่ย 800px นั้น โลโก้ แถบแชร์ และ UI ของเบราว์เซอร์กินพื้นที่ไปมาก
    • เนื้อหาจริงที่แสดงได้มีเพียง11% ตามเกณฑ์ของหน้า Guardian
  • สัดส่วน**โฆษณา·โมดัล 89% เทียบกับเนื้อหา 11%**เพิ่มทั้งความล้าทางสายตาและความถี่ในการเลื่อนของผู้ใช้
  • ยังมีวิธีแบบ วางปุ่ม ‘X’ ไว้ใกล้พื้นที่คลิกโฆษณา เพื่อหลอกให้กดพลาด หรือที่เรียกว่ากลยุทธ์ ‘fat-finger tax’
  • เว็บไซต์ข่าวอินเดียบางแห่ง เช่น Jagran ยังขัดขวางการเข้าถึงบทความด้วยโมดัลชวนติดตั้งแอปและป๊อปอัปสมัครสมาชิก

ข้อเสนอเพื่อการปรับปรุง

  • โครงสร้างที่บังคับให้ต้องกดปิด 3–4 ครั้งก่อนเห็นเนื้อหาคือการสิ้นเปลืองทรัพยากรทางการรับรู้ของผู้ใช้
    • ควรปรับให้ป๊อปอัปแสดงหลังอยู่บนหน้า 60 วินาที หรือเลื่อนถึง 50% ของหน้าเท่านั้น
    • การยินยอมคุกกี้และการสมัครรับจดหมายข่าวสามารถรวมไว้เป็นส่วนด้านล่างที่ไม่บล็อกการใช้งานได้
  • ควรจองช่องโฆษณาด้วยคอนเทนเนอร์ความสูงคงที่เพื่อป้องกันเลย์เอาต์ขยับ
    • ตัวอย่าง: min-height: 250px; background: var(--skeleton-loader);
    • หากโหลดโฆษณาไม่สำเร็จ ให้ใช้ ResizeObserver ย่อเฉพาะในพื้นที่ที่ผู้ใช้ยังมองไม่เห็น

การมีอยู่ของเว็บไซต์ข่าวน้ำหนักเบา

  • text.npr.org, lite.cnn.com, cbc.ca/lite เป็นต้น มีเวอร์ชันน้ำหนักเบาที่ไม่มีการติดตามและไม่มีโมดัลให้บริการ
    • การเสพข่าวผ่านฟีด RSS ก็ยังคงมีใช้งานอย่างคึกคัก
  • ตัวอย่างเหล่านี้แสดงให้เห็นว่ายังมีความต้องการต่อประสบการณ์เว็บที่เรียบง่ายและเน้นเนื้อหาเป็นศูนย์กลาง

บทสรุป: ความสนใจของผู้อ่านคือทรัพยากร

  • UI ข่าวในปัจจุบันมองผู้อ่านเป็นเป้าหมายที่ต้องจับกุม และถูกออกแบบมาเพื่อเพิ่มการมองเห็นโฆษณาให้สูงสุด
  • แต่ความสามารถในการทำกำไรกับการเข้าถึงที่ดีสามารถอยู่ร่วมกันได้ และวิศวกรเองก็ไม่พอใจกับโครงสร้างนี้
  • ต้นตอของปัญหาคือแรงจูงใจทางธุรกิจระยะสั้นที่ยึด CPM เป็นศูนย์กลาง
  • จึงเกิดเป็นระบบที่ปฏิบัติต่อความสนใจของผู้อ่านเหมือนทรัพยากรที่สกัดได้ และ
    การใช้ RSS, ปิดแท็บ, และการเพิ่มขึ้นของอัตราการออกจากหน้าถูกเสนอว่าเป็นรูปแบบการต่อต้านที่ทรงพลังที่สุด

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

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

 
GN⁺ 2026-03-16
ความเห็นจาก Hacker News
  • ทุกครั้งที่นักพัฒนาของเราเปิดเว็บไซต์หนึ่ง จะใช้ข้อมูลราว 750MB
    พอมีตั๋วแจ้งว่าเซิร์ฟเวอร์ช้าเลยไปตรวจดู ก็พบว่าวิดีโอทั้งหมดบนหน้าเพจกำลัง preload ล่วงหน้าทีละส่วน
    ที่ยังพอรอดได้ก็เพราะออฟฟิศเชื่อมตรงกับดาต้าเซ็นเตอร์ด้วยไฟเบอร์ออปติก
    ผมคิดว่าไม่ควรให้นักพัฒนาเว็บได้ใช้เครือข่ายเร็วเกิน 128kbit ถ้าเร็วกว่านั้นทุกอย่างจะพังหมด
    • ใน แท็บ Network ของเบราว์เซอร์ที่ใช้ Chromium หรือ Firefox สามารถจำลองความเร็ว 3G หรือ 4G ได้
      ถ้าใช้ร่วมกับฟีเจอร์จำกัด CPU ก็เหมาะมากสำหรับตรวจสอบประสิทธิภาพเว็บไซต์ในสภาพแวดล้อมสเปกต่ำ
    • ควรใช้ข้อจำกัด 128kbit กับ ฝ่ายการตลาด ด้วย เพราะตัวการหลักของสคริปต์ติดตามคือพวกเขา
    • ถึงจะพัฒนาบนคอมพิวเตอร์แรง แต่ตอนทดสอบควรทำบนอุปกรณ์สเปกต่ำอย่าง Chromebook
    • ควรดูตัวอย่างเว็บไซต์อย่าง mcmaster.com ที่ทำ contextual prefetching ได้ดี
      การใช้ dev server ที่ช้าจะช่วยฝึกให้ลดทรัพยากรที่ไม่จำเป็นไปเองตามธรรมชาติ
    • เมื่อก่อนผมใช้ เว็บแบบข้อความ อย่าง text.npr.org ผ่าน Lyx
      มันทำงานได้ดีแม้ในสภาพแวดล้อมที่ช้ามากอย่าง Gopher, Gemini, หรือ Bitlbee บน IRC
      นักพัฒนาแอป Electron เองก็ควรทดสอบบนพีซีที่มี RAM 2GB และ Celeron รุ่นเก่าด้วย ถึงจะเรียกว่าเป็นแอปที่เสร็จสมบูรณ์จริง
  • ลองเปิด nytimes.com เล่น ๆ แล้วพบว่าพิกเซลติดตามกับสคริปต์โฆษณาน่ากลัวมาก
    แต่ถ้าวัดตามปริมาณข้อมูลที่ส่ง 36.3MB จากทั้งหมด 44.47MB เป็น วิดีโอสำหรับงานข่าว
    หมายความว่าปัญหาไม่ใช่โฆษณาที่มากเกินไปอย่างเดียว แต่เป็นโครงสร้างคอนเทนต์ที่เน้นวิดีโอด้วย
    • แต่ก็ยังสงสัยว่าทำไมทุกหน้าต้องมี วิดีโอเล่นอัตโนมัติ
      บังคับให้ผู้ใช้ดาวน์โหลด 36MB ก่อนจะกดคลิกอะไรด้วยซ้ำ มันยอมรับได้ยากมาก
  • ช่วงนี้ NYT กำลังตกต่ำลงสุด ๆ
    ผมไม่อ่านเลยเพราะเต็มไปด้วยโฆษณาและก้อน JavaScript เลยเอาแค่พาดหัวไปค้นอ่านในเว็บไซต์อื่นแทน
    โดยพื้นฐานแล้วผมท่องเว็บโดย ปิด JavaScript ไว้ และแทบไม่เห็นโฆษณา
    พอปิด JS หน้าเว็บก็เร็วขึ้นมาก และลดความเสี่ยงข้อมูลส่วนตัวรั่วไหลด้วย
    ผมไม่คิดว่าวิธีนี้ผิดจริยธรรม เพราะเว็บไซต์ต่างหากที่เริ่มเล่นไม่แฟร์ก่อน
    • เว็บไซต์ข่าวน้ำหนักเบา อย่าง lite.cnn.com, text.npr.org, newsminimalist.com ใช้งานสบายกว่ามาก
    • NYT ก็รู้ว่าผู้ใช้แบบนี้เป็น คนส่วนน้อยที่ไม่ทำรายได้
      ถึงขั้นว่าการไม่เข้าเว็บเลยอาจดีกับพวกเขามากกว่าด้วยซ้ำ
    • คนส่วนใหญ่ไม่ได้สนใจ JS หรือจำนวนเมกะไบต์
      ขอแค่คอนเทนต์แสดงและใช้งานได้ก็พอ
      NYT จึงมุ่งไปที่ “คนส่วนใหญ่ที่ไม่สนเทคโนโลยี” กลุ่มนี้
    • ผมสงสัยว่าในอนาคต YouTube จะยังยอมให้มี ไคลเอนต์ทางเลือก อยู่หรือไม่ หรือจะปิดด้วย DRM
  • แพ็กเกจ บรอดแบนด์แพ็กแรก ของครอบครัวผมในปี 2005 จำกัดที่ 400MB ต่อเดือน
    ปัญหาพื้นฐานของอุตสาหกรรมหนังสือพิมพ์คือ โมเดลเศรษฐกิจที่พึ่งโฆษณากำลังพังทลาย
    เมื่อก่อนเก็บเงินจากผู้อ่านแค่ค่าพิมพ์ ที่เหลือให้โฆษณาช่วยจ่าย
    แต่ตอนนี้ Facebook Marketplace, Craigslist และที่อื่น ๆ แย่งโฆษณาเหล่านั้นไปหมด
    สุดท้ายข่าวจึงกลายเป็น สินค้าตลาดเฉพาะ และการขายข้อมูลผู้อ่านก็เป็นเฮือกสุดท้าย
    • ยังจำได้ว่าปี 2010 เคยดาวน์โหลดอัปเดตเกมขนาด 120MB แล้วโดนพ่อแม่ดุ
      เพราะตอนนั้นจำกัดทั้งเดือนแค่ 250MB ทุกวันนี้คิดแล้วยังไม่น่าเชื่อ
  • การพัฒนาเว็บสมัยนี้คือ นรกของโฆษณาและการติดตาม จริง ๆ
    เว็บไซต์อย่าง HN ที่ระวังการใช้ JS ทุกบรรทัดกลับรู้สึกเหมือนของขวัญจากพระเจ้า
    เราควรทำให้เว็บอืดน้อยกว่านี้
    • แค่เว็บไซต์สามารถกินหน่วยความจำทั้งหมดได้ ไม่ได้แปลว่าควรทำแบบนั้น
    • หลายครั้งมีป๊อปอัปและโอเวอร์เลย์เต็มหน้าจน แทบดูคอนเทนต์ไม่ได้เลย
      ทั้งที่ UX แบบนี้ไม่น่าทำเงินได้ แต่ก็ยังทำซ้ำอยู่เรื่อย ๆ
  • การใช้ ขนาดติดตั้ง Windows 95 (ราว 40MB) เป็นหน่วยเปรียบเทียบนั้นตลกดี
    เมื่อก่อน Win95 เองก็เคยถูกเรียกว่า “บวม” แต่ทุกวันนี้หน้าเว็บใหญ่กว่านั้นมาก
    ปัญหาไม่ใช่แค่ตัวโฆษณา แต่คือ ความสิ้นเปลืองทรัพยากรและความรบกวนสมาธิ
    ถ้าเปิด JS แล้วหน้าจอเริ่มวุ่นวาย ผมก็ปิดหนีทันที
    • ผมสงสัยเรื่อง โครงสร้างเศรษฐกิจ ของอุตสาหกรรมโฆษณา
      เงินไม่กี่เซ็นต์ที่ได้จากการทำให้ผู้ใช้หงุดหงิดมันคุ้มจริงหรือ
      ดูเหมือนคนส่วนใหญ่จะยอมรับมันไปเฉย ๆ
      ผมเป็นนักพัฒนาวัยปลาย 30 ที่โตมากับยุค “อินเทอร์เน็ตเสรี” เลยแทบไม่มีความอดทนต่อโฆษณาเลย
  • เว็บไซต์สายการบินนี่หนักเป็นพิเศษ ที่อย่าง Air Canada แม้แต่ขั้นตอนจองง่าย ๆ ก็ยังถูกปกคลุมด้วย JS หลาย MB
    ผมคิดถึงอินเทอร์เฟซแบบบรรทัดคำสั่งอย่าง Amadeus terminal สมัยก่อน
    ก็เลยคิดอยู่ว่าถ้าอยากให้เว็บกลับมาเป็นศูนย์กลางของผู้ใช้อีกครั้ง ต้องทำอย่างไร
    • เว็บไซต์ของ China Southern แย่มาก
      ทั้งป้ายชื่อฟิลด์ผิด, placeholder ถูกตัด, date picker โผล่เป็นภาษาจีน
      และหลังเลือกที่นั่งแล้วก็ขึ้นข้อความว่า “เลือกไม่ได้” UX พังหมดแล้ว
    • เราควรวิจารณ์นักพัฒนาที่ ไล่ตามเทรนด์ของ Big Tech
      เพราะแค่ HTML form ง่าย ๆ ก็ทำเว็บที่ใช้งานได้ดีพอแล้ว
      การใช้ JS เกินเหตุเป็นผลจากการถูกปลูกฝังมากกว่า
    • เว็บสมัยนี้ให้ความรู้สึกเหมือนทำมาเพื่อ เติมเรซูเม่นักพัฒนา
    • ผมคิดว่าเราต้องมี โมเดลรายได้ใหม่ ที่ไม่ใช่การคลิกโฆษณา แต่ก็ยังไม่รู้ว่าทางเลือกคืออะไร
  • น่าเสียดายที่บทความไม่ได้พูดถึง รายการบล็อก DNS
    ผมใช้ Hagezi ultimate list บล็อกโฆษณาแทบทั้งหมด และบนเดสก์ท็อปก็ใช้ uBlock ปรับละเอียดเพิ่ม
    ผมยังบล็อกโดเมนฟอนต์ของ Google และ Adobe เองด้วย เพื่อให้เร็วขึ้นและเป็นส่วนตัวขึ้น
    • ไม่ได้ทดสอบแบบละเอียด แต่รู้สึกว่าด้วยตัวกรองพวกนี้ ทราฟฟิกลดลงเหลือไม่ถึง 1/10
  • การตัดสินใจให้เว็บไซต์ รันสคริปต์ได้ คือความผิดพลาดครั้งใหญ่ที่สุดของยุค 90
    การที่โปรแกรมที่ผู้ใช้ไม่ได้ตรวจสอบมารันบนคอมพิวเตอร์ของผมนั้น เป็นโครงสร้างที่ผิดมาตั้งแต่ต้น
    ถ้าปิด JS แล้วเว็บพัง นั่นเป็นเพราะนักพัฒนาออกแบบผิด
    ถ้าตอนนั้นแยก HTML ออกจากโค้ดที่รันได้ โลกคงดีกว่านี้มาก
    • แค่จะดูคอนเทนต์แบบอ่านอย่างเดียว แต่ต้อง ดาวน์โหลดโค้ดที่รันได้ มาด้วย มันไม่มีเหตุผลเลย
      เรนเดอร์ที่เซิร์ฟเวอร์แล้วส่งผลลัพธ์มาอย่างเดียวก็พอ
    • แต่เพราะผู้ใช้ต้องการ เว็บแบบ interactive สุดท้ายการทำ scripting ก็คงถูกนำเข้ามาอยู่ดี
      หน้าเว็บขนาด 49MB ก็เป็นแค่ ภาพสะท้อนของลำดับความสำคัญ เท่านั้น
      ทุกวันนี้อินเทอร์เน็ตเร็วกลายเป็นเรื่องปกติแล้ว ผู้ใช้ส่วนใหญ่จึงไม่รู้สึกว่าเป็นปัญหา
  • น่าขันตรงที่แม้แต่บทความวิจารณ์แบบนี้ก็ยังโหลดทรัพยากร third-party อย่าง Cloudflare Insights มาโดยไม่จำเป็น
    ผมใช้ uBlock Origin hard mode เพื่อบล็อกทรัพยากรพวกนี้ทิ้งทั้งหมด