ผลกระทบของเว็บที่พองตัวต่อผู้ใช้ที่ใช้อุปกรณ์ช้า
(danluu.com)- หลังปี 2017 แม้แบนด์วิดท์ที่เพิ่มขึ้นจะแซงการเพิ่มขึ้นของขนาดข้อมูลที่ส่งของเว็บไซต์ทั่วไปได้ระดับหนึ่ง แต่ ความต้องการ CPU ของเว็บแอป กลับเพิ่มเร็วกว่า性能ของอุปกรณ์ราคาถูก ทำให้การเข้าถึงเว็บแย่ลงแม้ใช้อินเทอร์เน็ตเร็ว
- แม้บนการเชื่อมต่อ
1Gbpsก็ยังเกิดเบราว์เซอร์แครชบนTecno Spark 8Cเมื่อเข้าเว็บบอร์ด Discourse และบนItel P32เว็บไซต์อย่าง Discourse, Reddit, Shopify, Substack, Wix, Mastodon, Bluesky อยู่ในสถานะ FAIL หรือแทบใช้งานไม่ได้ - การวัดเปรียบเทียบ
LCP*และ เวลา CPU ของเมนเธรด ทำบนM3 Max,M1 Pro, Chrome ที่ตั้ง10xCPU throttling,Tecno Spark 8C,Itel P32และพบว่าคะแนน PageSpeed Insights มีความสัมพันธ์กับความเร็วที่ผู้ใช้รู้สึกจริงค่อนข้างต่ำ - เว็บไซต์ที่เรียบง่ายหรือเก่าอย่าง MyBB, phpBB, WordPress รุ่นเก่า, HN, danluu.com ยังทำงานได้ค่อนข้างดีบนมือถือราคาถูก ขณะที่เว็บไซต์ที่มีการโหลดแบบไดนามิกมากอย่าง Discourse, Medium, Reddit, Substack มีอาการ เลื่อนหน้าจอช้า ค้นหาช้า แตะช้า เด่นชัด
- ผู้ใช้อุปกรณ์ราคาถูกในภูมิภาคอย่าง Nigeria, India, Latin America คือผู้ใช้เว็บจริง และถ้าสร้างเว็บโดยอิงแค่ iOS กับอินเทอร์เน็ตเร็ว ก็จะตัดผู้ใช้ที่ไม่มั่งคั่งรวมถึงผู้ใช้เดสก์ท็อปสเปกต่ำออกไป
เว็บที่ CPU กลายเป็นคอขวดมากกว่าแบนด์วิดท์
- ในปี 2017 เว็บที่พองตัวส่งผลเสียต่อการใช้งานอย่างมากบนการเชื่อมต่อช้า และหลังจากนั้นแบนด์วิดท์ของการเชื่อมต่อระดับสูงก็เพิ่มขึ้นเร็วมากตามเกณฑ์ของ Nielsen ที่ราว
50%ต่อปี - ผู้ใช้ที่ใช้อินเทอร์เน็ตช้ายังมีอยู่อีกมาก และเว็บสมัยใหม่จำนวนมากก็ยังใช้งานยากบนการเชื่อมต่อช้า แต่สำหรับเว็บไซต์ทั่วไป การเพิ่มขึ้นของแบนด์วิดท์ก็แซงการเพิ่มขึ้นของขนาดข้อมูลที่ส่งได้ระดับหนึ่ง
- ในทางกลับกัน ความต้องการด้านประสิทธิภาพ CPU ของเว็บแอป ไม่ได้ดีขึ้นเร็วเท่ากับแบนด์วิดท์ ทำให้แม้จะมีอินเทอร์เน็ตดี แต่อุปกรณ์สเปกต่ำก็ยังใช้งานเว็บได้ยาก
- ฟอรั่ม “สมัยใหม่” ที่ใช้ Discourse บางครั้งทำให้เบราว์เซอร์แครชบน
Tecno Spark 8Cและแม้ระหว่างช่วงที่ยังไม่แครช ความลื่นไหลก็ติดลบยิ่งกว่าการใช้ BBS ผ่าน8 MHz 286กับโมเด็ม1200 baud - เพย์โหลดแบบบีบอัดสำหรับโหลดหัวข้อข้อความใน Discourse มีขนาด
2.6 MBซึ่งมากกว่าในอดีตราว1000xแต่บนการเชื่อมต่อ1Gbpsก็ยังถือว่าเบาเมื่อเทียบกัน - ในมุม CPU แม้
Tecno Spark 8Cที่มี8-core (2 1.6 GHz Cortex-A75 / 6 1.6 GHz Cortex-A55)ก็ยังรับภาระของ Discourse ไม่ไหว ทั้งที่ CPU นี้เร็วกว่า286โดยประมาณ100000x
อุปกรณ์ที่ใช้ทดสอบและตัวชี้วัด
- อุปกรณ์ทดสอบคือ
M3 Max Macbook (14-core),M1 Pro Macbook (8-core),M3 Maxที่เปิด10xthrottling ใน Chrome DevTools,Tecno Spark 8C,Itel P32 - เครือข่ายที่ใช้เป็นอินเทอร์เน็ต
1Gbpsและเราเตอร์ WiFi ที่ benchmark แล้วว่ามี latency ต่ำภายใต้โหลด เพื่อให้เป็นเงื่อนไขที่เอื้อต่ออุปกรณ์ - กลุ่มเว็บไซต์ที่นำมาเทียบครอบคลุมบล็อก/ไมโครบล็อก, ฟอรั่ม, และแพลตฟอร์มสำหรับธุรกิจขนาดเล็ก
- บล็อก/ไมโครบล็อก: danluu.com, Substack, Medium, Ghost, Hugo, Tumblr, Mastodon, Twitter, Threads, Bluesky, Patreon
- ฟอรั่ม: Discourse, Reddit, Quora, vBulletin, XenForo, phpBB, MyBB
- แพลตฟอร์มธุรกิจขนาดเล็ก: Wix, Squarespace, Shopify, WordPress
- ตัวชี้วัดหลักคือขนาดที่ส่งแบบบีบอัด (
wire), ขนาดหลังคลายการบีบอัด (raw),LCP*, และ เวลา CPU ของเมนเธรด LCP*ไม่ใช่ Largest Contentful Paint ที่ Chrome วัด แต่ยึดจุดเวลาที่เนื้อหาที่มีประโยชน์จริงปรากฏต่อผู้ใช้ ในกรณีที่การอัปเดตหน้าจอขนาดใหญ่ไม่ช่วยผู้ใช้- เวลา CPU ไม่ใช่ Core Web Vital แต่ใช้เป็นตัวชี้วัดง่าย ๆ ที่สอดคล้องอย่างมากกับการใช้งานที่ผู้ใช้รู้สึกจริงบนอุปกรณ์ช้า
ช่องว่างด้านการใช้งานที่เห็นจากตาราง
- danluu.com และ HN ทำงานได้เร็วบนทุกอุปกรณ์ที่ทดสอบ
- danluu.com มี
6kB wire / 18kB raw, บนTecno Spark 8Cได้0.4s LCP* / 0.3s CPU - HN มี
11kB wire / 50kB raw, บนTecno Spark 8Cได้0.5s LCP* / 0.5s CPU
- danluu.com มี
- ฟอรั่ม PHP แบบเก่าทำงานบนอุปกรณ์ช้าได้ดีกว่าฟอรั่มสมัยใหม่อย่างมาก
- MyBB บน
Tecno Spark 8Cได้0.8s LCP* / 0.8s CPU - phpBB ได้
1.7s LCP* / 1.5s CPU - vBulletin ได้
4.4s LCP* / 4.8s CPU - Discourse ได้
15s LCP* / 26s CPUและบนItel P32เป็นFAIL
- MyBB บน
- ในกลุ่มแพลตฟอร์มบล็อก ธีม WordPress แบบเก่าก็ยังเร็วกว่าทั้ง Medium และ Substack มากบนอุปกรณ์สเปกต่ำ
- WordPress(old) บน
Tecno Spark 8Cได้0.7s LCP* / 1.7s CPU - Medium ได้
2.8s LCP* / 33s CPU - Substack ได้
14s LCP* / 14s CPU
- WordPress(old) บน
- เว็บไซต์สมัยใหม่หลายแห่งล้มเหลวบน
Itel P32หรือแทบใช้งานไม่ได้จริง- XenForo, Mastodon, Bluesky, Wix, Substack, Shopify, Discourse, Reddit เป็น
FAIL - Threads ได้
28s LCP* / 66s CPU, Twitter ได้24s LCP* / 43s CPU, Medium ได้3.2s LCP* / 63s CPU
- XenForo, Mastodon, Bluesky, Wix, Substack, Shopify, Discourse, Reddit เป็น
- หน้าเว็บที่ใช้
10s+ CPUจะให้ประสบการณ์ที่แย่แม้โหลดเสร็จแล้ว- การเลื่อนหน้าจอตกเหลือเพียงไม่กี่ FPS และการแตะมีดีเลย์ยาวจนผู้ใช้ไม่แน่ใจว่าการแตะถูกลงทะเบียนหรือยัง
- ถ้าแตะซ้ำ การแตะครั้งแรกอาจเพิ่งมาทำงานช้า ๆ แล้วการแตะครั้งที่สองกลับก่อให้เกิดพฤติกรรมผิดที่ผิดทาง
ความต่างระหว่างอุปกรณ์จริงกับ CPU throttling
- CPU throttling ของ Chrome DevTools สะดวกก็จริง แต่ไม่สามารถประมาณผลบนอุปกรณ์ช้าจริงได้อย่างสม่ำเสมอ
- เมื่อเทียบ
M3/10กับTecno Spark 8Cความต่างของแต่ละไซต์ออกมาห่างกันมาก- danluu.com และ Ghost พอประมาณได้ระดับหนึ่ง
- Medium, Substack, Twitter ใช้เวลา CPU ช้ากว่าบน
Tecno Spark 8Cราว3x - Reddit และ Discourse ช้ากว่าราว
4x - Shopify กลับให้ผลว่าบน
Tecno Spark 8Cเร็วกว่าM3/10มากกว่าหนึ่งหลัก
- หน้าเว็บที่ช้าอาจช้าลงแบบ superlinear เมื่ออุปกรณ์ยิ่งช้า และความช้าของหน้าหนึ่งก็ทำนายความช้าของอีกหน้าได้ไม่ดี
- Discourse, Medium, Reddit ดูเหมือนใช้ CPU ไม่มากบน
M3และM1แต่เมื่อเป็นTecno Spark 8Cกลับอยู่ในกลุ่มที่ช้าที่สุด - Reddit ใช้ CPU ราว
~90%แม้แค่นั่งรอโดยไม่โต้ตอบ ทำให้ค่า CPU แสดงเป็น∞
จุดแข็งของเว็บไซต์เก่าและหน้าเว็บที่เรียบง่าย
- เว็บไซต์เก่าโดยรวมเร็วกว่าของใหม่ และเว็บไซต์ที่แทบไม่เปลี่ยนหน้าตาในช่วง 10~20 ปีที่ผ่านมาอยู่ในกลุ่มที่เร็วที่สุด
- MyBB เร็วกว่า Discourse ที่
M3ถึง3.6x / 5xและที่Tecno Spark 8Cถึง19x / 33x - WordPress(old) เร็วกว่า Medium ที่
M3 Maxถึง17.5x / 10xและที่Tecno Spark 8Cถึง4x / 19x - Ghost แม้เป็นแพลตฟอร์มสมัยใหม่ที่ออกหลัง Medium 1 ปี แต่เป็นข้อยกเว้นที่ให้ประสิทธิภาพแข่งขันกับแพลตฟอร์มเก่าได้
- ในการทดสอบภาคผนวก NodeBB ก็เกือบเป็นข้อยกเว้นในบรรดาฟอรั่มสมัยใหม่เช่นกัน
- บน
M1ได้0.3s / 0.4s - บน
Tecno Spark 8Cได้3.4s / 7.2s - เร็วกว่า Discourse มาก และหลังโหลดเสร็จ การเลื่อนกับการแตะก็ยังทำงานได้ตามปกติเป็นพื้นฐาน
- บน
กับดักของการโหลดแบบไดนามิกและการจูนตัวชี้วัด
- เว็บไซต์อย่าง Discourse, Reddit, Substack ที่โหลดบางส่วนของหน้าให้มาก่อนแล้วค่อยโหลดที่เหลือแบบไดนามิก มีการใช้งานจริงที่แย่กว่าคะแนนในตาราง
- บนอุปกรณ์ช้า การคาดเดาระยะที่จะเลื่อนทำได้ยาก และถ้าเลื่อนไกลเกินไป การโหลดเพิ่มอาจถูกกระตุ้นจนหน้าค้าง
- หน้าเว็บที่ลบเนื้อหาเก่าที่เคยเลื่อนผ่านไปแล้ว แทบใช้งานไม่ได้บนอุปกรณ์ช้า
- หน้าแบบโหลดไดนามิกยังใช้การค้นหาเร็วของเบราว์เซอร์อย่าง
Ctrl/Command+Fตรง ๆ ได้ยาก และต้องทำระบบค้นหาเอง- การค้นหาใน Google Docs ช่วงหลายเดือนหรือราวหนึ่งปีที่ผ่านมา โหลดช้าจนใช้ทันทีหลังเปิดเอกสารแทบไม่ได้
- การค้นหาใน Discourse ไม่เคยทำงานได้ดีบนอุปกรณ์ช้าหรือแม้แต่อุปกรณ์ที่ไม่ได้เร็วมาก
- ในทางทฤษฎี งาน CPU หนักตอนต้นอาจทำให้การโต้ตอบภายหลังเร็วขึ้นได้ แต่หน้าเว็บที่ทดสอบทั้งหมดกลับช้าทั้งตอนโหลดแรก ตอนโหลดต่อ และตอนโต้ตอบหลังโหลด
การเล่นเกมกับ LCP
- เดิม
LCPเป็นตัวชี้วัดเพื่อประมาณว่าผู้ใช้เห็นเนื้อหาหลักของหน้าเมื่อไร แต่การวัดของ Chrome กลับใกล้เคียงกับการดูว่าเกิดการ paint ขนาดใหญ่บนหน้าจอเมื่อไร - บางไซต์แสดงหน้าจอโหลดขนาดใหญ่ที่ไม่ช่วยผู้ใช้อย่างรวดเร็วเพื่อลดค่า
LCPแล้วค่อยแบ่งการแสดงเนื้อหาจริงออกเป็นการอัปเดตย่อย ๆ เพื่อไม่ให้ถูกนับเป็นLCP - Discourse ได้นำ Discourse Splash มาใช้แบบเปิดเผย และอธิบายว่าหน้าสแปลชขนาดใหญ่ช่วยลด
LCPได้มากในกรณีโหลดช้า - คำตอบอย่างเป็นทางการของ Discourse มีใจความว่า ถ้าแบนเนอร์เนื้อหาจริงมีขนาดใหญ่กว่าสแปลช ก็จะเสียเปรียบในแง่
LCP - กรณีที่ช่องว่างระหว่าง
LCP*ตามเนื้อหาที่มีประโยชน์จริง กับLCPที่ Chrome วัด กว้างมาก คือ Wix และ Discourse- Wix มีช่องว่าง
6xบนM3,12xบนM1,3xบนTecno Spark 8C - Discourse มีช่องว่าง
10xบนM3,12xบนM1,4xบนTecno Spark 8C
- Wix มีช่องว่าง
ผลของการปรับประสิทธิภาพต่อธุรกิจ
- ในบริษัทขนาดใหญ่ การปรับปรุงประสิทธิภาพของเว็บไซต์และแอปมีมูลค่าทางการเงินมากพอจะวัดได้ด้วย A/B test
- แม้ดูใน long-term holdback การปรับปรุงประสิทธิภาพก็ยังเป็นปัจจัยที่ส่งผลต่อการเติบโตและการรักษาผู้ใช้ค่อนข้างมาก
- ที่ Twitter ค่า latency p99 จากการสังเกตผู้ใช้จริงอยู่ราว
60sไม่เฉพาะใน India และหลายประเทศใน Africa แต่รวมถึง United States ด้วย - แต่ละประเทศมีผู้ใช้อุปกรณ์หรือการเชื่อมต่อที่ช้าจำนวนมากพอ ทำให้ปัจจัยจำกัดไม่ได้อยู่ที่ค่าเฉลี่ยของอุปกรณ์และการเชื่อมต่อของประชากรทั้งหมดเท่านั้น แต่ใกล้กับ ความอดทนของผู้ใช้ มากกว่า
- การปรับปรุงจาก
60sเป็น50sบนอุปกรณ์ช้า อาจให้ผลลักษณะเดียวกับการลดจาก5sเป็น4.5sสำหรับผู้ใช้อุปกรณ์ระดับสูง และส่งผลต่อรายได้ การเติบโต และการรักษาผู้ใช้ได้
การออกแบบโดยคำนึงถึงอุปกรณ์สเปกต่ำ
- บนอุปกรณ์ช้า หรือในสภาพที่แบนด์วิดท์ต่ำและการเชื่อมต่อไม่เสถียร ประสบการณ์ที่ดีที่สุดโดยรวมมักเป็นการโหลดเนื้อหาจำนวนมากในคราวเดียวเป็น หน้าแบบสแตติก
- การใส่
width,height,altให้รูปภาพอย่างเหมาะสมช่วยได้ แต่ progressive JPEG ไม่ได้ช่วยมากเป็นพิเศษ - สำหรับอุปกรณ์ช้าที่มีการเชื่อมต่อเร็ว หน้าแบบสแตติกที่เบาทำงานได้ดี และหน้าแบบไดนามิกที่เบาและคำนึงถึงประสิทธิภาพก็ยังพอทำได้
- ในหน้าเว็บหนัก ๆ การโหลดเพิ่มระหว่างเลื่อนและการดักการค้นหาไว้เองจะทำลายรูปแบบการโต้ตอบที่ใช้งานได้จริง
- Substack อาจมี
LCPของบทความที่เร็วบน iPhone 8 แต่ถ้าจะเลื่อนลงไปใต้หัวเรื่อง อาจต้องรอโหลดหน้าถัดไป6sแล้วหลังจากนั้นยังต้องรออีก1s~2s - ในทางกลับกัน หน้า plain HTML ขนาดใหญ่กลับทำงานได้ค่อนข้างดีบนอุปกรณ์สเปกต่ำ
https://danluu.com/diseconomies-scale/มี0.1 MB wire / 0.4 MB rawhttps://danluu.com/threads-faq/มี0.4 MB wire / 1.1 MB raw- ข้อความ
1.1 MBในหน้าเดียวทำงานได้ดีกว่าเว็บไซต์สมัยใหม่ส่วนใหญ่บนอุปกรณ์ช้า
- Zig standard library documentation โหลดซอร์สโค้ดทั้งหมดมาก่อนแล้วเรนเดอร์ในเครื่อง แต่บน
Tecno Spark 8Cใช้ CPU4.7sแล้วก็ยังรักษาความลื่นไหลได้ค่อนข้างดี
ผู้ใช้รายได้น้อยและการเข้าถึง
Tecno Spark 8Cหาซื้อได้ราวUSD 50-60ใน Nigeria และUSD 100-110ใน India แต่เมื่อเทียบกับรายได้ครัวเรือนมัธยฐานในภูมิภาคเหล่านั้น สัดส่วนนี้สูงกว่า iPhone รุ่นปัจจุบันในสหรัฐมาก- ในระดับโลก
Tecno Spark 8Cไม่ได้ใกล้เคียงกับอุปกรณ์ที่ถูกที่สุด และItel P32ก็ยังอยู่สูงกว่าอุปกรณ์สเปกต่ำสุดที่มีใช้งานจริง - ตามข้อมูลของ Alex Russell ส่วนแบ่ง iOS อยู่ที่
7%ใน India และ6%ใน Latin America - จาก telemetry ของ Windows พบว่าผู้ใช้โน้ตบุ๊กและเดสก์ท็อปส่วนใหญ่มีแนวโน้มใช้อุปกรณ์สเปกต่ำที่ช้ากว่า iPhone รุ่นล่าสุด
- โทรศัพท์ “lifeline” ที่แจกให้ผู้ได้รับสิทธิ์อาจมี iPhone 6 หรือ iPhone 8 แต่ก็มีหลายเครื่องที่ต่ำกว่า
Itel P32และยังมีโควตาดาต้าน้อย ทำให้หลังใช้หมดอาจลำบากในการหางาน กรอกแบบฟอร์มสวัสดิการ หรือใช้ Maps - แอปมือถือสามารถดาวน์โหลดล่วงหน้าได้เมื่อมีการเชื่อมต่อที่ดี แต่เว็บแอปถ้าต้องดาวน์โหลด JavaScript ที่บีบอัดแล้วหลาย MB ทุกครั้งที่เข้าใช้งาน ก็จะใช้ไม่ได้บนการเชื่อมต่อที่จำกัด
เงื่อนไขทดลองและข้อจำกัด
- แต่ละเว็บไซต์ถูกวัดโดยพยายามหา “ประสบการณ์พื้นฐานที่สุด” ที่เป็นไปได้
- WordPress ใช้เดโมธีมพื้นฐานปัจจุบัน
twentytwentyfour - Shopify ใช้ธีมแรกที่เห็นในรายการธีม
- Discourse, vBulletin, XenForo, phpBB, MyBB ใช้หน้าที่ค้นพบจากฟอรั่มทางการ
- WordPress ใช้เดโมธีมพื้นฐานปัจจุบัน
- งานนี้เป็นโปรเจ็กต์ระยะสั้นที่เก็บข้อมูลและวิเคราะห์ภายในวันเดียว จึงไม่ได้สะท้อนถึงธีมที่พบได้บ่อยที่สุดหรือการปรับแต่งของผู้ใช้จริงทั้งหมด
- โน้ตบุ๊กทดสอบที่แบตเตอรี่ราว
60%ไม่เสียบไฟ และอยู่ในห้อง20°Cจนใกล้ภาวะสมดุลความร้อนก่อนเริ่มทดสอบ - มือถือทดสอบที่ชาร์จราว
100%เสียบไฟไว้ และไม่มีแอปหรือแท็บอื่นเปิดค้าง - ผู้ใช้จริงบนอุปกรณ์เดียวกันมีแนวโน้มเจอประสิทธิภาพแย่กว่านี้ เพราะมีแอปอื่นและงานเบื้องหลังมากกว่า
- ขนาดข้อมูลวัดบนมือถือ ดังนั้นหากมือถือกับเดสก์ท็อปรับ asset ต่างกัน ตัวเลขจะสะท้อนขนาด asset ฝั่งมือถือ
CPUวัดเป็นเวลา CPU ของเมนเธรด โดยแม้จะบันทึกเวลาในเธรดอื่นด้วย แต่ไม่ได้ใช้ในตัวชี้วัด
กรณีที่น่าสนใจรายเว็บไซต์
- Wix บน
Tecno Spark 8Cเลื่อนหน้าจอได้ไม่เสถียร และบนItel P32ล้มเหลวแบบไม่แน่นอน - Patreon มีประสิทธิภาพการเลื่อนแย่กว่าที่ตัวเลขการโหลดแรกบอกไว้ จนไม่สะดวกในการหาบทความเก่าและต้องทำดัชนีโพสต์ Patreon แยกไว้เอง
- Discourse มีการเล่นเกมกับ
LCPอย่างหนัก และแม้บนM3 Maxกับการเชื่อมต่อ1Gbpsค่าLCPที่ Chrome วัดจะเป็น115msแต่เนื้อหาจริงโหลดใน1.1s - Bluesky แสดงหน้าจอว่างบน
Itel P32 - สองกรณีใช้งานจริงแรกของ Shopify ช้ากว่าหน้าเดโมที่ทดสอบทั้งคู่มาก
- Tumblr มี JavaScript error บน
Itel P32แต่กลับทำให้หน้าโหลดเร็วขึ้น และการเลื่อนกับการคลิกลิงก์ยังใช้งานได้ - MyBB ไม่มีเวอร์ชันมือถือ จึงอาจเสียเปรียบ Google แต่บนมือถือช้า การเลื่อนและการแตะกลับใช้งานได้ดีจริง
- Woo Commerce เทียบกับ Shopify โดยดูแค่ประสิทธิภาพการโหลดแรกได้ยาก และต้องมีการเทียบแยกที่รวม flow จริงอย่างตะกร้าสินค้าและ checkout จึงถูกตัดออกจากตาราง
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
พอลองใช้ โทรศัพท์ Android ที่ค่อนข้างช้าเมื่อไม่นานมานี้ ก็พบว่าแม้แต่หน้าเว็บที่ดูเหมือนมีแค่ข้อความกับรูปภาพก็ยังโหลดได้อย่างทรมานมาก
คอขวดที่แท้จริงดูจะไม่ใช่เครือข่าย แต่เป็นตัวติดตาม โฆษณา และความเทอะทะของ JavaScript มากกว่า
โทรศัพท์รุ่นเก่าที่ช้าทำให้แม้แต่เบราว์เซอร์เต็มรูปแบบอย่าง Firefox บนมือถือก็หนักเกินไป จนต้องหันไปใช้เบราว์เซอร์เบาๆ อย่าง Firefox Focus แต่พอใช้ส่วนขยายไม่ได้ก็ใช้ uBlock Origin ไม่ได้ด้วย และประสบการณ์บนเว็บก็ยิ่งแย่ลง
บางเว็บไซต์จะบ่นถ้าไม่ใช่เบราว์เซอร์ “มาตรฐาน” จนใช้งานแทบไม่ได้ และบริษัทต่างๆ ก็พยายามบังคับให้ติดตั้งแอปแทน
เมื่อก่อนยังมีเวอร์ชันแบบย่อสำหรับอุปกรณ์และการเชื่อมต่อที่ช้า แต่ตอนนี้ค่อยๆ หายไป ซึ่งดูเหมือนเป็นเพราะหากไม่มี JavaScript ที่เทอะทะก็หมุนระบบโฆษณาและเครือข่ายติดตามได้ยาก
โดยเฉพาะเวลาหน้าเว็บเลื่อนไม่มีที่สิ้นสุดและมีโฆษณาสุ่มแทรกอยู่เต็มไปหมด
ตัวอย่างล่าสุดคือเว็บช็อปของ Nike แสดงข้อผิดพลาดไร้สาระระหว่างจ่ายเงิน และฝ่ายซัพพอร์ตก็บอกแค่ว่า “ลองใช้แอปดู”
เว็บไซต์จองตั๋วของสายการบินยุโรปก็เป็นอีกตัวอย่างคลาสสิกของเว็บบริษัทใหญ่ที่พังบ่อย
มันแปลกที่ในปี 2024 แบรนด์ต่างๆ ซึ่งแทบมีทรัพยากรไม่จำกัด กลับคิดว่าการทำเว็บไซต์ที่ใช้งานได้ไม่ได้ส่งผลเสียต่อแบรนด์
เพราะมันต้องทำงานได้ในทุกประเทศ และโทรศัพท์ที่ช้าที่สุดจำนวนมากก็คือสินค้าของบริษัทนั้นเอง
มันไม่เร็ว แต่ก็ไม่ได้มีปัญหาในการใช้งานเว็บไซต์ แค่ไม่ฉับไวเท่าฮาร์ดแวร์ใหม่ๆ แต่ก็ยังใช้งานได้สบาย
แต่ก็เปิดใช้ uBlock Origin อยู่
เลยอดสงสัยไม่ได้ว่าอุปกรณ์ Android เหล่านี้อ่อนกว่าสเปกพื้นฐานของ MacBook อายุ 11 ปีในโลกความจริงจริงหรือ
เห็นด้วยอย่างมากกับประเด็นของ Dan ที่ว่าเราควรตระหนักถึง ระดับความเหลื่อมล้ำ ทั่วโลก แต่ก็ควรรวมประเทศรายได้ปานกลางอย่างละตินอเมริกาและเอเชียตะวันออกเฉียงใต้ด้วย
ตัวอย่างเช่น มีผู้ใช้ที่มีโควตาดาต้ารายเดือนแค่เลขหลักเดียวเป็น GB และมี RAM/CPU ระดับเรือธงของสหรัฐเมื่อ 10 ปีก่อน
ไม่ถึงกับใช้ Discourse ไม่ได้เลย แต่ประสบการณ์ก็น่าจะช้าจนน่าหงุดหงิด
ที่ Dan มองว่าการปรับปรุง CPU/RAM/ดิสก์แบบค่อยเป็นค่อยไปช่วยเพิ่มการมีส่วนร่วมได้อย่างวัดผลได้ ก็น่าจะเป็นเพราะผู้ใช้กลุ่มนี้เป็นหลัก
กราฟของ Dan ยังชี้ให้เห็นว่าผู้ใช้เครื่องราคาถูกสุดอย่าง Itel P32 แทบไม่ได้ประโยชน์จากการปรับแต่งแบบค่อยเป็นค่อยไป
สิ่งที่อาจช่วยได้จริงคือสถาปัตยกรรมไคลเอนต์ที่ต่างออกไปโดยสิ้นเชิง ซึ่งยอมแลกฟีเจอร์และความสวยงามเพื่อให้โค้ดบางที่สุดเท่าที่จะทำได้ หรือก็คือ โหมดเบา/โหมดพื้นฐาน ทางเลือก
แต่แนวทางแบบนี้ก็มักไม่ค่อยประสบความสำเร็จ เพราะปัญหาเรื่องการขาดความเข้าใจยังย้อนกลับมาอีก ในลักษณะที่นักพัฒนาชาวอเมริกันตัดสินใจผิดว่าจะเก็บอะไรไว้หรือทิ้งอะไรไปเพื่อประสิทธิภาพ
สงสัยว่า Discourse ให้สิ่งใดที่ PhpBB หรือฟอรัม DLang ไม่มี
นอกจากดีไซน์ที่เหมาะกับมือถือแล้ว ในโลกปกติแค่แก้ responsive CSS ไม่กี่บรรทัดก็น่าจะพอ
ดาต้า 30GB ต่อเดือนราคา $3.64 คิดเป็นค่าแรงขั้นต่ำราว 4–6 ชั่วโมง
สิ่งที่สำคัญกว่าคือผู้คนไม่ได้ใช้ดาต้าอย่างสุรุ่ยสุร่ายแบบโลกตะวันตก
คาเฟ่ ร้านอาหาร ซูเปอร์มาร์เก็ต และห้างทุกแห่งมี Wi‑Fi ฟรี และคนส่วนใหญ่มักถามรหัส Wi‑Fi ก่อนถามเมนูเสียอีก
ไม่เคยเห็นหรือได้ยินใครบ่นเลยว่าเว็บไซต์ทำให้ดาต้าหมดเร็วเกินไป
ฟังดูเหมือนเป็นความกังวลที่คนซึ่งไม่เคยใช้ชีวิตอยู่ในประเทศกำลังพัฒนาสร้างขึ้นมาเอง
ที่นี่ดาต้าหมดเพราะดูวิดีโอใน TikTok, Instagram และ Facebook ไม่ใช่เพราะเว็บที่เทอะทะ
ซอฟต์แวร์ขยะที่ติดมากับเครื่องก็เช่นกัน
เพิ่งซื้อโน้ตบุ๊กใหม่มาไม่นานและโดนเสนอแพ็กเกจ “จูนเครื่อง” ราคา $50
ลองนึกภาพว่าดีลเลอร์ขายรถใหม่ยื่นข้อเสนอแบบนั้น ก็คงรู้สึกแปลกมาก
ถ้าอยู่ในที่สัญญาณไม่ดี ปัญหาจะหนักขึ้น 10 เท่า
ไม่ได้พูดถึงแค่ UI ที่รกจนเห็นหน้าจอได้เพียงหนึ่งในสามเพราะมีหัวเว็บติดบนสุดกับโฆษณา แต่หมายถึงขนาดของตัวเว็บไซต์เองที่ประกอบกันแบบส่งๆ จนดูเหมือนเอกสารออกแบบ
เว็บไซต์ที่ต่อให้ทำมาดีแล้วก็น่าจะยังเทอะทะอยู่ดี จะกลายเป็นใช้งานไม่ได้เมื่ออยู่บนการเชื่อมต่ออินเทอร์เน็ตช้าๆ และยังไม่ต้องพูดถึงฮาร์ดแวร์ช้าๆ
มันยากจะจินตนาการว่าการใช้อินเทอร์เน็ตในสภาพแวดล้อมที่อธิบายมานั้นรู้สึกอย่างไร ได้แต่หวังว่าคนเหล่านั้นจะใช้เว็บไซต์ท้องถิ่นที่เหมาะกับแบนด์วิดท์และอุปกรณ์ของตนเอง และไม่ต้องมาเจอขยะเทอะทะแบบที่พวกเราเจอ
เว็บไซต์ส่วนใหญ่แทบจะเป็นการทรมาน
น่าสนใจที่คนส่วนใหญ่มักโทษแต่หัวหน้าหรือบริษัทยักษ์ใหญ่น่ากลัว
นักพัฒนาเองก็ไม่ค่อยยอมรับว่ามีกลุ่ม เว็บโปรแกรมเมอร์ฝีมือไม่ถึง จำนวนมากที่ไม่เข้าใจเรื่องประสิทธิภาพ และดูเหมือนไม่คิดจะทำความเข้าใจด้วย
พวกเขาก็มีส่วนรับผิดชอบต่อโลกของเว็บซอฟต์แวร์อันน่าเศร้านี้พอ ๆ กับหัวหน้าหรือชนชั้นปกครองในองค์กรที่บังคับให้สร้างซอฟต์แวร์แย่ ๆ
พอถามรายละเอียดของ HTML, CSS, JS ซึ่งเป็น “ผลลัพธ์” ที่สร้างออกมาจริง ๆ พวกเขาก็มองเหมือนผมพูดคนละภาษา
พวกเขามาจากโลกของ JavaScript framework และแทบไม่ได้คิดถึงผลลัพธ์ที่อยู่ข้างล่างนั้นเลย
ปรัชญาของผมแทบจะตรงกันข้าม คือถามว่าโค้ดที่น้อยที่สุดซึ่งยังดูแลรักษาได้และให้ผลลัพธ์เทียบเท่ากับเว็บไซต์ HTML+CSS+JS ที่เขียนด้วยมืออย่างดีคืออะไร
ปกติแล้วผลลัพธ์จะเล็กลงอีกหลายหลัก
มีคนถามว่าผมทำอย่างไรให้ตาราง 1000 แถวกรองแบบเรียลไทม์ได้ แถมยังโหลดเร็วและใช้งานได้ดีบนมือถือ ผมก็ตอบว่าแค่ส่งข้อมูลทั้งหมดมาในคำขอแรก แล้วซ่อนข้อมูลที่ไม่ตรงกับตัวกรองแบบไดนามิกเท่านั้น
เว็บเซิร์ฟเวอร์ก็แค่ส่งข้อมูลแคชชุดเดียวกันให้ทุกคน และ JavaScript ที่รันบนเว็บก็มีแค่นั้นเอง เลยดูเร็วผิดปกติในสายตาพวกเขา
พอไปดู HTML ของแถวตารางที่คล้ายกันในโซลูชันแบบ framework ของพวกเขา 80% กลับเป็น boilerplate ที่ไม่ได้ใช้เลย
การพัฒนาเว็บแข็งทื่อเกินไปแล้ว และหลายคนก็ถอยห่างจากแก่นแท้ของเทคโนโลยีเว็บมากเกินไป
ถ้ากลุ่มผู้ใช้หลักคือคนในสหรัฐหรือ EU การไม่ปรับแต่งอย่างหนักสำหรับฮาร์ดแวร์สเปกต่ำและการเชื่อมต่อแบนด์วิดท์ต่ำ/หน่วงสูงที่ไม่เสถียร อาจพอเข้าใจได้
แต่ถ้าเป้าหมายคือชนบทในแอฟริกา การปรับแต่งเชิงรุกก็น่าจะเป็นเรื่องพื้นฐาน
แต่หน้าแรกกลับโหลดภาพขนาดมหึมา 2MB แล้วค่อยย่อด้วย CSS ให้เหลือ 500×1000 พิกเซล และหลังจากนั้นก็ยิ่งแย่กว่าเดิม
ผมจำขนาด JS payload ที่แน่นอนไม่ได้ แต่มีระดับหลาย MB และแม้ตัวระบบส่วนใหญ่จะดูเหมือนแอปแบ็กเอนด์แบบเทมเพลตดั้งเดิม ฟรอนต์เอนด์กลับหนักอย่างสุดโต่ง
ผมสมัครเพราะชอบแนวคิด แต่เทคโนโลยีแย่มาก
ผมไม่ผ่านแม้แต่รอบสัมภาษณ์แรก เลยไม่รู้ว่าทำไมถึงเป็นแบบนั้น แต่ก็นึกเหตุผลอื่นแทบไม่ออกนอกจากนักพัฒนาในยุโรปตะวันตกไม่ค่อยตระหนักจริง ๆ ว่าตัวเองกำลังทำอะไรในแง่นี้
จุดเริ่มต้นไม่ใช่นักพัฒนา แต่คือ งบประมาณ
ถ้าผู้บริหารระดับบนไม่ได้เก่งเทคโนโลยีหรือไม่มีพื้นฐานวิศวกรรม ปกติพวกเขาจะตั้งงบให้ฟีเจอร์ใหม่ แต่ให้กับงานบำรุงรักษาและการล้างหนี้เทคนิคน้อยเกินไปหรือไม่ให้เลย
ต่อให้มีงบสำหรับบำรุงรักษา ก็แทบทั้งหมดจะถูกโยนให้ทีมดูแลระบบต่างประเทศที่ถูกกว่า
ทีมฟีเจอร์ใช้เวลา 6 เดือนสร้างฟีเจอร์ แล้วทำ “KT session” 1 ชั่วโมงกับทีมดูแลต่างประเทศก่อนส่งมอบโค้ด
ทีมต่างประเทศมีข้อมูลเกี่ยวกับฟีเจอร์อยู่บ้าง แต่ไม่พอจะจัดการหนี้เทคนิคที่มีอยู่เดิม ได้แค่ประคองไม่ให้ไฟไหม้
ถ้าวงจรนี้เกิดซ้ำ 100 ถึง 1000 ครั้งในองค์กร ฟรอนต์เอนด์ที่เดิมอาจมีได้ไม่เกิน 250,000 บรรทัดก็จะพุ่งเป็น 2 ล้านบรรทัดอย่างรวดเร็ว
ต่อให้ทีมฟีเจอร์ใหม่ได้วิศวกรเก่งที่สุดเข้ามา พวกเขาก็ยังต้องทำงานอยู่ในกรอบที่มีอยู่แล้ว
ถ้า mockup กับองค์ประกอบไม่ตรงกัน อาจเป็นไปได้ว่า mockup ผิด, UI kit ถูกอัปเกรด, หรือ UI kit เดิมต้อง refactor แต่ไม่มีงบสำหรับสิ่งนั้น
สุดท้ายทีมก็จะถูกสั่งให้คัดลอกคอมโพเนนต์แล้วแก้ให้เข้ากับฟีเจอร์ของตัวเอง
ตอนส่งต่อให้ทีมดูแลรักษา ทีมใหม่ก็ไม่อยากไปแตะงานฟีเจอร์เดิมจึงปล่อยไว้แบบนั้น
ผู้บริหารที่ไม่ใช่สายเทคนิคก็มองไม่ออกว่าต่างกันตรงไหน และหลังจากหลายปีที่แต่ละทีมคัดลอก/วางเพื่อให้เข้ากับฟีเจอร์ใหม่ ใน codebase ก็จะมีคอมโพเนนต์ชื่อ “Button” เกิน 50 ตัว
ถ้าในทีมมีนักพัฒนาฝีมือดีที่ให้ความสำคัญกับประสิทธิภาพ และพยายามผลักดันเว็บไซต์ที่มีประสิทธิภาพกว่าหรือทำให้มีประสิทธิภาพตั้งแต่แรก หน้าเว็บก็อาจดีขึ้นได้
แต่ส่วนใหญ่เป็นปัญหาเรื่อง แรงจูงใจ
ถ้าผู้บริหารไม่สนใจ ก็มีโอกาสสูงที่โปรแกรมเมอร์จะเลือกทำให้มันพอใช้งานได้ในครึ่งเวลาแล้วเคลียร์งานใน backlog มากกว่าใช้เวลาปรับปรุงประสิทธิภาพ
เพราะงั้นอุปกรณ์ช้าจึงเป็นตัวกรองชั้นดีที่ช่วยหลีกเลี่ยงขยะพวกนี้
ผมเพิ่งเปลี่ยนจาก LG รุ่นเรือธง อายุ 6 ปีมาเป็น Galaxy เครื่องใหม่ แล้วความต่างด้านประสิทธิภาพมหาศาลมาก
มันไม่ควรเป็นแบบนั้น
ตอนออกใหม่มันเป็นเครื่องระดับสูงมาก และก็ไม่ได้เก่าขนาดนั้น แถมยังทำงานเหมือนใหม่
พอเห็นว่าเครื่องทดสอบ Galaxy S9 ก็เจอปัญหาแบบเดียวกัน มันเลยไม่ใช่แค่ปัญหาเฉพาะโทรศัพท์ผม
ผมอยากให้การทดสอบมี Amazon อยู่ด้วย
จากประสบการณ์ของผม เว็บไซต์ Amazon เป็นหนึ่งในเว็บที่แย่ที่สุดบนอุปกรณ์พกพาที่อายุเกิน 4 ปี
แม้บนฮาร์ดแวร์มือถือระดับสูงที่ค่อนข้างใหม่ มันก็ยังเป็นเว็บเดียวในบรรดาเว็บที่ผมเข้าเป็นประจำที่แทบใช้งานไม่ได้
ผมใช้ OnePlus 5 ที่ลง Android 14 ผ่าน LineageOS เป็นเครื่องหลัก และประสบการณ์ใช้งานสำหรับงานที่ไม่ใช่เกมก็ถือว่าดีพอ
เครื่องนี้มี RAM 6GB เลยยังใกล้เคียงมือถือระดับกลางสมัยนี้
สิ่งเดียวที่ผมบ่นคือผมต้องเปลี่ยนแบตเตอรี่ และการแกะเครื่องมันน่ารำคาญ
ตรงกันข้าม Galaxy S8 ที่ใช้ SoC เดียวกัน แต่มีหน่วยความจำ 4GB และใช้ Android 9 เดิมพร้อมการปรับแต่งของ Samsung กลับกระตุกไม่หยุด
ความต่างของหน่วยความจำ 2GB อาจมีผล แต่ความต่างระหว่างสองเครื่องนี้มากราวฟ้ากับเหว
ผมไม่แน่ใจว่าเป็นเพราะการจัดการหน่วยความจำของ Android 14 ดีกว่า Android 9 มาก หรือเป็นเพราะซอฟต์แวร์ของ Samsung ที่ช้าและเทอะทะฉุดเครื่องไว้กันแน่
ไม่ว่าอย่างไร การที่หลายบริษัทไม่ทดสอบบนอุปกรณ์เก่าหรือรุ่นล่างก็น่าหงุดหงิด
ถ้าคุณทำเพื่อผู้ใช้ทั่วโลก ก็ควรตระหนักว่าคนส่วนใหญ่บนโลกไม่ได้ใช้รุ่นเรือธงล่าสุด
จริง ๆ แล้วมันไม่ได้ทำงานแย่ขนาดนั้น
แน่นอนว่าผมก็เห็นด้วยว่าไม่ควรจำเป็นต้องทำแบบนั้น
แต่ผมใช้ตัวบล็อกโฆษณาทุกตัวใน Firefox ด้วย เลยน่าจะช่วยได้
ทุกวันนี้เทคโนโลยีช่างไม่ใส่ใจแม้แต่กับ คนที่ไม่คุ้นเคยกับเทคโนโลยี
ผมว่าสมาร์ตโฟนเป็นตัวอย่างที่ชัดที่สุด
ผมเห็นคนจำนวนมากที่แทบใช้เครื่องของตัวเองไม่เป็นหรือไม่รู้เลยว่าจะใช้ยังไง และสำหรับพวกเขามันดูเหมือนมนตร์ดำไปหมด
ปัญหาใหญ่ที่สุดคือมันพึ่งพา การนำทางด้วยท่าทาง มากเกินไป ทั้งที่สิ่งเหล่านี้มองไม่เห็นจนแทบเหมือนไม่มีอยู่
แถบท่าทางของ iPhone นั้นยังพอคลำทางเจอได้บ้าง แต่แนวคิดเรื่องศูนย์การแจ้งเตือนหรือศูนย์ควบคุมนั้นไม่มีทางรู้เลย
ไม่ใช่ว่าคนเหล่านี้โง่ และในเรื่องอื่นพวกเขาอาจเก่งกว่าผมมากก็ได้
ปัญหาในโลกเทคโนโลยีไม่ใช่เพราะพวกเขาพยายามไม่พอ แต่เป็นเพราะขาดอินเทอร์เฟซที่ใช้งานได้อย่างเป็นธรรมชาติ
ถ้าอยากดูเอกสารจริง ๆ ต้องตามเข้าไปถึงหน้าคู่มือในเว็บไซต์ Apple และต้องขุดลึกลงไปอีกหน่อยถึงจะเจอหน้าที่อธิบายท่าทางแบบคร่าว ๆ เพียงไม่กี่อย่าง
เรื่องว่าเมื่อไรควรใช้ท่าทางไหนก็มีแค่ตัวอย่างสั้น ๆ ไม่กี่ประโยค
และนี่ก็ยังพูดถึงแค่ระบบปฏิบัติการเท่านั้น
ผมยังสงสัยว่ามีแอปสักกี่ตัวที่ให้เอกสารอธิบายพร้อมมาด้วยว่าในแอปของตัวเองใช้ฟีเจอร์ท่าทางอย่างไร
https://support.apple.com/guide/iphone/learn-basic-gestures-...
ทั้งที่พวกเขาโตมาแวดล้อมกับอุปกรณ์เหล่านั้นอย่างชัดเจน
เพราะงั้นผมจึงไม่คิดว่านี่เป็นความผิดของเทคโนโลยียุคใหม่อย่างเดียว
แทนที่จะให้ผู้ใช้เลือกดีไซน์และรูปแบบปฏิสัมพันธ์ที่เหมาะกับตัวเอง นักออกแบบหรือเจ้าของผลิตภัณฑ์กลับทำราวกับว่าตนรู้ว่าอะไรดีที่สุดสำหรับผู้ใช้ทุกคน
นี่เป็นหนึ่งในเรื่องที่ผมหงุดหงิดที่สุดหลังย้ายมาจาก Android
ปุ่มย้อนกลับอยู่ไหน ปุ่มโฮมอยู่ไหน แล้วตัวปุ่มเองหายไปไหน
ผมเกลียดความหมกมุ่นกับความมินิมอลของ Apple มาก และถ้าโทรศัพท์เครื่องนี้พัง ผมจะกลับไป Android
บทความนี้อ่านยากโดยพื้นฐานสำหรับผมที่อายุ 48 ปีและอ่านบนเดสก์ท็อป
พอเพิ่มสิ่งต่อไปนี้ลงใน
bodyผ่านเครื่องมือนักพัฒนา ผมก็อ่านได้font-size: 18px;line-height: 1.5em;max-width: 38rem;พอทำแบบนี้แล้วจะเห็นเลยว่ามันอ่านง่ายและดูดีขึ้นแค่ไหน
ผมอ่านบทความของ Dan Luu บ่อย แต่ต้องแก้แบบนี้ทุกครั้ง
เอาจริงนะ เหล่านักเทคโนโลยีทั้งหลาย การทำให้หน้าเว็บอ่านง่ายขึ้นใช้เพิ่มแค่ 64 ไบต์ เท่านั้น
หน้านั้นเกือบจะโอเคอยู่แล้ว แค่กด CTRL + เพื่อซูมก็พอ
หน้านั้นแทบจะเป็นข้อความล้วนและแทบไม่มีอะไรให้โต้ตอบ
คุณมีวิธีแก้ที่เหมาะกับกรณีใช้งานของคุณ และผมก็มีวิธีของผม
ผู้อ่านที่มีความบกพร่องทางสายตาก็เข้าถึงด้วยวิธีของตัวเองได้
เพราะต้นทางเรียบง่าย วิธีแก้ด้านการเข้าถึงจึงเรียบง่ายอย่างสมเหตุสมผลด้วย
ผมคิดว่า Dan รู้วิธีสื่อสารอย่างมีประสิทธิภาพ
นั่นคือทำให้มันเรียบง่าย และไม่ตั้งสมมติฐานว่าจะต้องอ่านด้วยตาเท่านั้น
คุณสามารถปรับการแสดงผลให้ตรงกับจุดประสงค์ของตัวเองได้ง่าย
ถ้าไม่ชอบรูปแบบการแสดงผลนี้ คุณก็จัดรูปแบบใหม่เองก่อนอ่านได้
Dan ก็แค่ส่งสารของเขามาในรูปแบบสตรีมข้อความเรียบง่ายที่ปรับแต่งได้สะดวก
โดยรวมแล้วผู้อ่านของ Luu น่าจะชอบแนวทางที่ ไม่เน้นสไตล์ มากกว่า
ผู้ใช้สามารถเปลี่ยนขนาดหน้าต่าง ขนาดตัวอักษร สี และอื่น ๆ ตามความชอบของตัวเองได้
ไม่ควรต้องมาปรับใหม่ทีละไฟล์ทุกครั้ง และควรอนุญาตให้เพิ่ม ไฟล์ CSS ของผู้ใช้ ที่ใช้กับหลายไฟล์ได้
มันอยู่ในหน้าการตั้งค่าปกติของ Firefox
ถ้าเว็บไซต์บังคับ
font-size: 18px;มันอาจทำให้ข้อความยิ่งเล็กลงสำหรับผู้ใช้ที่เลือกฟอนต์ขนาดใหญ่กว่าไว้ในเบราว์เซอร์แต่คุณจะใช้ โหมดอ่าน ของเบราว์เซอร์ก็ได้ ซึ่งคลิกครั้งเดียว แทนที่จะต้องไล่ทำหลายขั้นตอนในเครื่องมือนักพัฒนา
ข้อมูลเพิ่มเติมคือบน Raspberry Pi 3 ใช้ YouTube ไม่ได้แล้ว
มันกลายเป็นแบบนี้ในช่วง 1 ปีที่ผ่านมา ก่อนหน้านั้นยังพอ “ดู” วิดีโอได้ที่ราว 10~15FPS ซึ่งก็เพียงพอสำหรับเปิดดูวิดีโอซ่อมของในเวิร์กช็อป
ตอนที่ Raspberry Pi Model B หรือรุ่นแรกสุดออกวางจำหน่ายนั้น ยังเล่นวิดีโอ 1080p จากสตอเรจ ดู YouTube และเล่นเกมได้
ไม่รู้ว่า YouTube กำลังทำอะไรอยู่ หรือบริการอื่น ๆ กำลังทำอะไรกันแน่
ถ้าคิดเรื่องวิกฤตสภาพภูมิอากาศและการเปลี่ยนแปลงอย่างจริงจัง ก็ควรตรวจสอบลูกเล่นแบบนี้ของ Google และ Meta อย่างเข้มงวดมาก
การเผา CPU cycle เพื่อผลกำไร หรือถ้าจะเดาแบบฉับพลันก็คือการที่ YouTube พังบนอุปกรณ์พลังต่ำเพราะ ad tech ควรถูกสื่อวิจารณ์อย่างหนัก และควรใช้บริการที่มีประสิทธิภาพกว่านี้แม้ประสบการณ์ผู้ใช้โดยรวมจะแย่ลงก็ตาม
Pi3 มีฮาร์ดแวร์เร่ง x264 แต่ YouTube เริ่มใช้ codec อื่นมาพักใหญ่แล้ว
แม้แต่บน MacBook Air ชิป Intel รุ่นต้นปี 2021 วิดีโอยังหยุดแบบสุ่มเมื่อมีโหลดระดับปานกลาง ซึ่งเมื่อก่อนไม่เคยเป็น
การไปโจมตีจุดนั้นเพื่อแก้ปัญหาสภาพภูมิอากาศก็ไร้เหตุผลพอ ๆ กับการแบนหลอดพลาสติกหรือถุงพลาสติก
เป็นจุดอ้างอิงอีกอย่างได้ว่า ถ้าเป็น YouTube เมื่อ 10 ปีก่อน ฮาร์ดแวร์นั้นก็น่าจะใช้งานได้สบาย ๆ
ตัวการคือการพองตัวของเว็บโดยรวม และที่เจาะจงกว่านั้นคือปีศาจแห่ง abstraction ที่กลายเป็นเรื่องปกติใน JS
แม้กับคนที่ไม่เชื่อเรื่อง “วิกฤตสภาพภูมิอากาศ” เลย ก็ยังพูดได้ว่าเมื่อเวลาผ่านไปความเป็นงานช่างและคุณภาพได้หายไปจนเกิดความยุ่งเหยิงแบบนี้
เพราะงั้นจึงเป็นประเด็นที่น่าจะเห็นพ้องกันได้ตลอดทั้งสเปกตรัมทางการเมือง
จะทำแบบ Consumer Reports ก็ได้ หรือเป็นส่วนเสริมที่ทำงานคล้ายเรตติ้งของ Nielsen ก็ได้
คนฝั่ง Discourse คนนั้นเป็นตัวอย่างคลาสสิกของการออกแบบผลิตภัณฑ์โดยยึดโลกที่ตัวเองอยากให้มีอยู่ ไม่ใช่โลกที่เราอาศัยอยู่จริง
อุปกรณ์ที่ใช้ Qualcomm SoC มีอยู่หลายพันล้านเครื่อง และต่อจากนี้ก็จะยังมีการผลิตและขายต่อไป
ต่อให้บ่นแค่ไหนก็ไม่เปลี่ยน
ต้องยอมรับและปรับแต่งให้เหมาะกับอุปกรณ์พวกนั้น
ผู้ใช้ของอุปกรณ์เหล่านั้นไม่สนใจคำบ่นของนักพัฒนา และถ้าซอฟต์แวร์ล่ม พวกเขาก็จะมองว่าเป็นแค่นักพัฒนาซอฟต์แวร์ที่ไร้ความสามารถ
ปกติผมชอบบทความของ Dan Luu แต่รู้สึกว่าครั้งนี้พลาดเป้า
ตาราง LCP/CPU นั้นดี แต่หลังจากนั้นเนื้อหาก็ไหลไปเป็นเหมือนจิตวิทยาแบบนั่งเทียน
เขาเอาคอมเมนต์สุ่ม ๆ ไม่กี่อันของผู้ก่อตั้ง Discourse มาเป็นฐาน แล้วให้ผู้อ่านจินตนาการทัศนคติของวิศวกรซอฟต์แวร์เอาเอง
ถึงขั้นลาก Knuth ลงมาวิพากษ์จากคำพูดเรื่องประสิทธิภาพ single-core เทียบกับ multi-core และคำพูดเกี่ยวกับ Itanium ทั้งที่นั่นเป็นจุดถกเถียงเชิงวิชาการเก่าแก่
รู้สึกว่าบทความมันอ่อนเกินไป และพึ่งพาการทะเลาะกันบนอินเทอร์เน็ตมากเกินจนยืนระยะได้ไม่ดี
คำพูดของผู้ก่อตั้ง Discourse แค่ช่วยอธิบายให้เห็นชัดมากเท่านั้น
ถ้าคุณเพิ่งใช้เว็บยุคนี้มา ก็คงเห็นว่ามันพองตัวเกินจินตนาการจนตอนนี้ Google ถึงกับบอกว่า Largest Contentful Paint 2.4 วินาที ถือว่าเร็ว: https://blog.chromium.org/2020/05/the-science-behind-web-vit...
นี่เป็นข้อมูลเมื่อ 4 ปีก่อน ดังนั้นตอนนี้มีโอกาสสูงว่าจะแย่ลงอีก
ไม่ต้องไปไกล ตั้งแต่ YouTube บนเดสก์ท็อปที่โหลด CSS 2.5MB ไปจนถึงกรณีที่ผู้ก่อตั้ง Vercel คุยว่าเป็นเว็บที่เร็วมาก แต่พอใส่ข้อจำกัดนิดหน่อยกลับใช้เวลาโหลด 20 วินาที: https://x.com/dmitriid/status/1735338533303259571
แม้เวลา response ของ บริการ API ง่าย ๆ สำหรับฟรอนต์เอนด์จะอยู่ที่ 500ms ก็ไม่มีใครหัวเราะเยาะ
ยังสงสัยด้วยซ้ำว่ามีวิศวกรกี่คนที่รู้และใส่ใจว่าค่า cloud ของตัวเองออกมาเท่าไร
การประมวลผลแบบขนาน ทุกวันนี้ นอกจากกรณีใช้งานเฉพาะทางหรือการรันโปรแกรม single-thread เดิมซ้ำกับข้อมูลหลายชุดแล้ว แทบไม่ได้ถูกใช้ในซอฟต์แวร์ 90%
ทั้งภาษาโปรแกรมและฮาร์ดแวร์ต่างก็ยังไม่รองรับ fine-grained parallelism ได้ดีพอ และการทำให้ซอฟต์แวร์แบบดั้งเดิมเร็วขึ้นด้วยแนวทางขนานนั้นยากมาก
Luu เขียนค่อนข้างปรานีแล้วด้วยซ้ำ
Knuth แทบจะเป็นการบ่นว่า ของฟรีมื้อกลางวัน ที่กินกันมาหลายทศวรรษกำลังจะจบลง
Jeff Atwood เป็นแค่ตัวอย่างที่ถูกหยิบมา
นักคิดสายเว็บชื่อดังที่มีผู้ติดตามเยอะยังคงพรั่งพรูมุมมองคล้าย ๆ กันออกมา และผู้ติดตามจำนวนมากก็รับเอาคำพูดนั้นไปตรง ๆ
ทุกบริษัทเลิกใส่ใจไปแล้ว โดยเฉพาะบริษัทอย่าง Google และ Apple ที่เคยอยู่แถวหน้าของมาตรฐานและแนวปฏิบัติการออกแบบเว็บที่ดี
เมื่อไม่นานมานี้ Google ได้ยุติ HTML Gmail ซึ่งเคยทำงานได้เร็วและดีแม้บนโทรศัพท์ Android ปี 2008 ที่มี RAM 256MB และ Firefox รุ่นเก่า
แน่นอนว่าเวอร์ชันใหม่ที่พองตัวด้วย JavaScript กลับทำให้เบราว์เซอร์พังไปเลย
แม้จะเป็นตัวอย่างสุดโต่ง แต่โทรศัพท์ราคาถูกก็มี RAM แค่ 2GB และตอนนี้ก็ยากที่จะคาดหวังประสิทธิภาพที่สมเหตุสมผลขณะท่องเว็บบนอุปกรณ์แบบนี้
เว็บบนมือถือแย่มาก และนี่เป็นสิ่งที่ตั้งใจทำเพื่อผลักผู้ใช้ไปหาแอป “เนทีฟ”
เพราะมันทำให้บริษัทอย่าง Apple และ Google เก็บข้อมูลและแสดงโฆษณาได้ง่ายกว่า
เว็บไซต์ของพวกเขาบนมือถือแย่มาก และของ Decathlon ก็แย่แม้แต่บนเดสก์ท็อปที่ไม่ได้แรงมาก
แต่พวกเขาก็ไม่ได้ผลักดันให้ใช้แอปอย่างเด่นชัด จึงน่าจะต้องมองว่าเป็นแค่ความไร้ความสามารถ
ดูเหมือนว่านักพัฒนาจะทดสอบทุกอย่างเฉพาะบนอุปกรณ์ระดับสูงที่ต่อกับแบ็กโบนเท่านั้น
RIP Google
Reddit แบบใหม่ใช้งานไม่ได้ ส่วน old Reddit ก็เก่าเกินไปแล้ว
Twitch ก็แทบจะพอใช้ได้เพราะมีปัญหาเรื่องแชตและสตรีมวิดีโอ
รายการนี้ยังยาวได้อีก
ถ้าคุณมีสูตรสำเร็จสุดท้ายอยู่แล้ว การเปลี่ยนแปลงทั้งหมดก็จะกลายเป็นการเปลี่ยนแปลงแย่ ๆ เพื่อประกันงานเท่านั้น
สักวันหนึ่งลิงบนก้อนดินนี้คงจะตระหนักได้ว่างานและเงินไม่มีอยู่จริง แต่ตอนนั้นมันจะสายเกินไป
ไม่สิ ตอนนี้แหละ
RIP Humans