หน้าเว็บ 14kB อาจโหลดได้เร็วกว่าหน้า 15kB มาก (2022)

• หากคงขนาด เว็บไซต์ ไว้ไม่เกิน 14kB จะสามารถ ลดเวลาโหลด ได้อย่างมากเมื่อเทียบกับ 15kB
• ปรากฏการณ์นี้เกิดจาก อัลกอริทึม TCP slow start ซึ่งทำให้เกิดความต่างของความเร็วที่ผู้ใช้รู้สึกได้จากข้อจำกัดของปริมาณข้อมูลที่ส่งได้ในรอบแรก
• 14kB เทียบได้กับ ความจุของแพ็กเก็ต TCP 10 ชุด ที่เซิร์ฟเวอร์ส่วนใหญ่มักส่งในตอนแรก
• ในสภาพแวดล้อมที่มี latency สูง เช่น อินเทอร์เน็ตผ่านดาวเทียม การเพิ่มขึ้นของการไป-กลับ (RTT) อีกหนึ่งครั้งอาจทำให้เกิดความล่าช้าตั้งแต่ 612ms ขึ้นไป
• ในทางปฏิบัติ การใส่คอนเทนต์หลักให้อยู่ต่ำกว่า 14kB หรือจัดวาง ทรัพยากรสำคัญ ไว้ภายใน 14kB แรก จะช่วยเพิ่มประสิทธิภาพเว็บได้อย่างมีประสิทธิผล

---

ภาพรวมและหลักการสำคัญ

• เป็นที่รู้กันดีว่า เว็บไซต์ ที่มีขนาดเล็กกว่าจะโหลดได้เร็วกว่า
• แต่สิ่งที่คาดไม่ถึงคือเมื่อข้ามจาก 14kB ไปเป็น 15kB จะเกิด ความแตกต่างอย่างมาก ในความเร็วของการตอบสนองครั้งแรก
• ความต่างของความเร็วระหว่างหน้า 15kB กับ 16kB มีน้อยมาก แต่ระหว่าง 14kB กับ 15kB อาจต่างกันได้สูงสุดถึง 612ms

TCP คืออะไร

• Transmission Control Protocol (TCP) ทำงานอยู่บน IP (Internet Protocol) และมีหน้าที่รับประกันความน่าเชื่อถือของแพ็กเก็ต
• เว็บเบราว์เซอร์จะส่งแพ็กเก็ต TCP หลายชุดเมื่อทำ คำขอ HTTP
• หากใช้เพียง IP อย่างเดียวจะไม่สามารถตรวจสอบได้ว่าแพ็กเก็ตไปถึงหรือไม่ ดังนั้น TCP จึงมีฟังก์ชัน ยืนยันการรับแพ็กเก็ต (ACK)
• เซิร์ฟเวอร์ จะส่งแพ็กเก็ตจำนวนเล็กน้อยก่อน และเมื่อได้รับ ACK จาก เบราว์เซอร์ แล้วจึงส่งแพ็กเก็ตเพิ่มเติม
• หากไม่มี ACK ก็จะมีขั้นตอนส่งแพ็กเก็ตซ้ำ

TCP slow start คืออะไร

• TCP slow start คืออัลกอริทึมที่เซิร์ฟเวอร์ค่อย ๆ เพิ่มปริมาณการส่งแพ็กเก็ตทีละขั้นเพื่อประเมินคุณภาพของการเชื่อมต่อเครือข่าย (แบนด์วิดท์)
• ในช่วงเริ่มเชื่อมต่อ เซิร์ฟเวอร์ จะส่งแพ็กเก็ตเพียงเล็กน้อยก่อน (โดยทั่วไปคือ 10 ชุด)
• หากคอมพิวเตอร์ของผู้เข้าชมส่ง ACK กลับมาได้ตามปกติ ปริมาณการส่งแพ็กเก็ตจะเพิ่มขึ้นเป็น สองเท่า
• หากมี ACK หายไป หลังจากนั้นจะส่งแพ็กเก็ตด้วย ความเร็วที่ช้าลง
• รายละเอียดของอัลกอริทึมจริงอาจต่างกันไปตามการติดตั้งใช้งาน แต่แนวคิดหลักเหมือนกัน

เหตุผลของเกณฑ์ 14kB

• เซิร์ฟเวอร์ส่วนใหญ่มักส่ง แพ็กเก็ต TCP 10 ชุด พร้อมกันในช่วง slow start
• แม้ขนาดสูงสุดของแพ็กเก็ต TCP จะเป็น 1500 ไบต์ แต่เมื่อหัก header (40 ไบต์) แล้ว ข้อมูลจริงจะเหลือ 1460 ไบต์
• ดังนั้น 10 x 1460 = 14600 ไบต์ (ประมาณ 14kB) จึงเป็นขีดจำกัดของการส่งครั้งแรก
• หากทำให้เว็บไซต์หรือทรัพยากรสำคัญมีขนาดไม่เกิน 14kB (เมื่อมีการบีบอัด ข้อมูลต้นฉบับอาจมีขนาดระดับหลายสิบ kB) ก็จะแสดงผลได้โดยไม่ต้องรอรอบการไป-กลับเพิ่มเติมในช่วงเริ่มต้น

การไป-กลับหนึ่งครั้งทำให้เกิดความล่าช้าได้มากแค่ไหน

ตัวอย่างอินเทอร์เน็ตผ่านดาวเทียม

• ตัวอย่างของสภาพแวดล้อมที่มี latency สูง คือผู้ใช้งาน อินเทอร์เน็ตผ่านดาวเทียม (เช่น แท่นขุดเจาะน้ำมัน เรือสำราญ)
• เมื่อขอหน้าแรกจากโทรศัพท์ ข้อมูลจะวิ่งผ่าน เราเตอร์ → จานดาวเทียม → ดาวเทียมในอวกาศ → สถานีภาคพื้นดิน → เซิร์ฟเวอร์ โดยแต่ละช่วงใช้เวลา หลายสิบถึงหลายร้อย ms
• การส่งข้อมูลไป-กลับทั้งหมดรวมการเดินทางขึ้นอวกาศสองครั้ง การวิ่งผ่านช่วงเครือข่าย และการประมวลผลของเซิร์ฟเวอร์ ทำให้เกิดความล่าช้าเพิ่มเติมราว 612ms
• หากใช้ HTTPS ก็อาจเพิ่มขึ้นเป็น 1836ms จาก handshake เพิ่มเติม

latency ของเครือข่ายภาคพื้นดิน

• แม้แต่เครือข่ายมือถืออย่าง 2G, 3G ก็อาจมี latency 100~1000ms
• ในสภาวะที่หนาแน่น เซิร์ฟเวอร์โอเวอร์โหลด หรือมี packet loss ก็อาจเกิดความล่าช้าเพิ่มเติมได้

กลยุทธ์การปรับแต่งเว็บไซต์ตามกฎ 14kB

• หัวใจสำคัญคือทำให้เว็บไซต์หรือหน้าเว็บ เล็กที่สุดเท่าที่จะเป็นไปได้
• อุดมคติคือออกแบบให้ปริมาณข้อมูลที่ส่งหลังการบีบอัดของแต่ละหน้า ไม่เกิน 14kB
  • เมื่อมีการบีบอัด คอนเทนต์จริงอาจใส่ได้ถึง ~50kB
• หากลดองค์ประกอบที่ไม่จำเป็นส่วนใหญ่ เช่น วิดีโอเล่นอัตโนมัติ ป๊อปอัป ตัวติดตาม และ JS/CSS ที่ไม่จำเป็น ก็สามารถทำได้เพียงพอ
• หากทำทั้งหน้าให้อยู่ใน 14kB ได้ยาก ก็สำคัญมากที่จะต้องจัด ทรัพยากรหลักและคอนเทนต์สำคัญ (เช่น CSS, JS, ข้อความหลัก) ไว้ใน 14kB แรกก่อน
• HTTP header (บีบอัดไม่ได้) และ รูปภาพ (โหลดเฉพาะขั้นต่ำ/เฉพาะส่วนที่มองเห็น หรือใช้ placeholder) ก็รวมอยู่ใน 14kB นี้ด้วย

ข้อยกเว้นของกฎ 14kB และประเด็นของโปรโตคอลสมัยใหม่

• กฎ 14kB ไม่ได้เป็นการสรุปแบบเหมารวมเกินไป แต่ก็มีข้อยกเว้นบางประการ
  • เซิร์ฟเวอร์บางตัวขยาย initial window เป็น 30 แพ็กเก็ต
  • อาจอนุญาตให้ใช้หน้าต่างที่ใหญ่ขึ้นได้ผ่าน TLS handshake
  • สามารถ cache จำนวนแพ็กเก็ตที่ส่งได้ในแต่ละเส้นทาง เพื่อส่งได้มากขึ้นในการเชื่อมต่อครั้งถัดไป
• แม้ใน HTTP/2 แนวปฏิบัติที่เซิร์ฟเวอร์เริ่มจาก TCP slow start ที่ 10 แพ็กเก็ตก็โดยทั่วไปยังไม่เปลี่ยนแปลง
• ใน HTTP/3, QUIC กฎ 14kB ก็ยังถูกแนะนำอย่างเป็นทางการ

สรุปและเอกสารอ้างอิง

• สามารถดูเหตุผลทางเทคนิคและข้อมูลอธิบายเพิ่มเติมได้จากลิงก์ต่าง ๆ
• เผยแพร่ครั้งแรก: 2022-08-25, แก้ไขล่าสุด: 2022-08-26, ผู้เขียน: Nathaniel, แท็กที่เกี่ยวข้อง: ประสิทธิภาพเว็บ, HTTP, TCP

ลิงก์อ้างอิง

• ข้อมูลเพิ่มเติมเกี่ยวกับโครงสร้าง Ethernet frame และ TCP header, latency และ bandwidth, รวมถึงสเปกของ TCP/QUIC

[GN⁺]

ความเห็นจาก Hacker News

• นักพัฒนาซอฟต์แวร์ควรให้ความสนใจกับชั้นสื่อสารมากกว่านี้ โดยเฉพาะประเด็นเรื่องความน่าเชื่อถือและ latency ของ 3G/5G ที่ผู้เขียนชี้ไว้ได้อย่างน่าสนใจ วิทยุมักมีการ retransmit เกิดขึ้นแทบตลอดเวลา และในการสื่อสาร HTTP ส่วนใหญ่ แพ็กเก็ตต้องมาถึงตามลำดับก่อน UI จะอัปเดตได้ จริง ๆ แล้วแม้แต่ REST request เดียวก็จะเป็นแพ็กเก็ตเดียวจริง ๆ ก็ต่อเมื่อทั้ง request และ response มีขนาดต่ำกว่า 1400 ไบต์เท่านั้น ถ้าเกินกว่านั้น request ที่ดูเหมือน “ครั้งเดียว” ก็จริง ๆ แล้วถูกแยกเป็นหลายแพ็กเก็ต หากมีแพ็กเก็ตใดแพ็กเก็ตหนึ่งมีปัญหา ทุกแพ็กเก็ตก็ต้องมาถึงตามลำดับก่อนหน้าจอจะรีเฟรชได้ถูกต้อง ถ้าอยากลองทดลองดู ให้เปิดโหมด 3G และ packet loss ใน Chrome DevTools แล้วทดสอบ คุณจะเห็นว่าแค่ optimization เล็ก ๆ อย่างเดียวก็ช่วยให้ UI ตอบสนองดีขึ้นมาก นี่จึงเป็นเหตุผลที่ฟังขึ้นมากว่าทำไม API และ UI ควรทำให้เล็กที่สุดเท่าที่เป็นไปได้

• หน้าโฮมเพจของผมมีขนาดส่งข้อมูล 7.0kB แบบบีบอัด

  • /
  • main.css
  • favicon.png
  • รวม 7.0kB รายการบล็อกและทั้งเว็บไซต์ทำด้วย static site generator แบบคัสตอมของผมเอง (เปิดเผยโค้ด: site.lisp, ใช้ Common Lisp) สำหรับโพสต์คณิตศาสตร์ผมใช้ KaTeX แบบ client-side rendering ซึ่งในกรณีนั้นเพิ่มอีกถึง 347.5kB
  • katex.min.css 23.6kB
  • katex.min.js 277.0kB
  • auto-render.min.js 3.7kB
  • KaTeX_Main-Regular.woff2 26.5kB
  • KaTeX_Main-Italic.woff2 16.7kB
  • เพิ่มรวม 347.5kB ผมกำลังคิดอยู่ว่าวันหนึ่งจะเปลี่ยน KaTeX ไปเป็น server-side rendering ดีไหม บล็อกนี้เป็นโปรเจกต์ที่ผมทำด้วยใจรักมาตั้งแต่สมัยอยู่หอมหาวิทยาลัย ผมเขียนทั้ง HTML, template และ CSS เองทั้งหมด และระมัดระวังเสมอว่าจะใส่เฉพาะสิ่งที่จำเป็นจริง ๆ ในแต่ละหน้าเพื่อให้ขนาดยังเล็กอยู่
  • โฮมเพจของผม
  • รวมโพสต์คณิตศาสตร์
    • ไม่ได้จะบอกว่าไม่ควรใช้วิธีที่ดีกว่า แต่ latency ที่เกิดจาก client-side rendering ตอนโหลดคอมโพเนนต์แบบไดนามิกอย่างนิพจน์ LaTeX นั้น แทบจะไม่มีผู้ใช้ทั่วไปคนไหนสังเกตได้เลย (หรืออาจไม่มีจริง ๆ) การ optimize มากเกินไปก็เป็นปัญหาเหมือนกัน การไล่ตาม performance เพื่อ SEO แบบนี้ ถ้าไม่ใช่บริการที่มีทราฟฟิกระดับหลายล้านวิว ผลตอบแทนต่อเวลาที่ลงไปก็ไม่ได้มากนัก เหมือนกับการกังวลเรื่องอากาศพลศาสตร์ทั้งที่กำลังควบคุมเรือไร้คนขับด้วยแรงน้ำขึ้นน้ำลงในทะเล เมื่อทรัพยากรมีจำกัด ต้องมองต้นทุนและผลประโยชน์รวม ๆ แล้ว optimization ก็ไม่ใช่ตัวเลือกที่ดีที่สุดเสมอไป
    • ถ้ามีคอนเทนต์คณิตศาสตร์ไม่มากแต่ยังอยากใช้ KaTeX การพิจารณาใช้ MathML(mathml-core) แทนก็น่าสนใจในหลายกรณี
    • ผมไม่ค่อยเข้าใจว่าทำไมต้อง render สมการคณิตศาสตร์หรือนิพจน์ LaTeX ด้วย client js ทำไมไม่แปลงเป็น HTML/CSS ล่วงหน้าแล้วใส่แบบ prerendered ไปเลย
    • อีกไอเดียคือค่อยโหลดไลบรารีหนัก ๆ หลังจากหน้า render แรกเสร็จแล้ว หรือโหลดกราฟิกสมการเป็น SVG เฉพาะตอนที่กำลังจะเข้ามาอยู่ใน viewport อันนี้เป็นความเห็นของผม

• เป้าหมาย 14kB ค่อนข้างท้าทาย แต่แนวคิดการจำกัดให้อยู่ภายใน 10 แพ็กเก็ตแรกก็น่าสนใจ มีโปรเจกต์อย่าง 512kb.club ที่โฟกัสเรื่องขนาดเว็บไซต์แบบเดียวกัน เว็บไซต์นั้นเปรียบเทียบขนาดไซต์เหมือนคะแนนกอล์ฟ เว็บไซต์ของผม(anderegg.ca) ก่อนสมัครถูกวัดได้ 71kB รวมทุก resource โปรเจกต์นี้ยังทำให้ผมได้รู้จัก Cloudflare Radar ซึ่งมีเครื่องมือที่ดีสำหรับวิเคราะห์เว็บไซต์และวัดขนาดหน้า แม้เป้าหมายหลักจะเป็นแดชบอร์ดภาพรวมของอินเทอร์เน็ต แต่ก็มีเครื่องมือวิเคราะห์ขนาดหน้าเว็บรวมอยู่ด้วย

  • ขอถามในมุมผู้ใช้หน่อยว่า อีก 500kB ที่เหลือเอาไว้ใช้อะไร? ผมต้องการแค่ข้อความ 90% และส่วนที่เหลือถ้าเป็นกราฟิกแบบเวกเตอร์ก็พอ 14 kB ก็ใส่ทั้งข้อความและกราฟิกได้พอสมควรแล้ว แล้วอีก 500 เอาไปทำอะไร?
  • 512kb เป็นเกณฑ์ที่สมจริง ผมก็ใช้เกณฑ์นี้กับเว็บไซต์ของตัวเองเหมือนกัน เว็บไซต์ระดับ 14kb นั้นเลยแม้แต่มาตรฐานของเว็บไปแล้ว
  • ถ้าเป็นเว็บไซต์ส่วนตัว 512kb เป็นเป้าหมายที่ทำได้สบาย เป้าถัดไปของผมคือ 99kb (ไม่เกิน 100kb) ลงแรงแค่ไม่กี่สุดสัปดาห์ก็พอ เว็บไซต์ของผมอยู่ระดับ Orange บนเกณฑ์ 512kb

• ถ้าอยากทดลองเรื่องนี้ให้สนุกขึ้นอีกหน่อย ขนาด initial window (IW) สามารถตั้งจากฝั่งเซิร์ฟเวอร์ได้ ตัวอย่างเช่นปรับได้แบบนี้

  • ip route change default via <gw> dev <if> initcwnd 20 initrwnd 20 ถ้าลองค้นดู ตอนนี้มีบาง CDN ที่ตั้ง initial window ไว้ถึง 30 แพ็กเก็ต (45kb)
  • เมื่อ 13 ปีก่อน แค่ 10 แพ็กเก็ตก็ยังถูกมองว่าเป็น “การโกง” อยู่เลย ดูได้ที่ที่นี่ และ บล็อกของ Ben Strong (archive)
  • อยากรู้ว่ามีแหล่งอ้างอิงไหมสำหรับข้อมูลที่ว่า CDN ใช้ initial window 30 แพ็กเก็ต
  • จะตั้งเป็น 1000 แพ็กเก็ตแบบเป็น 'พลเมืองไม่ดี' ไปเลยก็ยังได้... แต่ข้อเสียคืออาจทำให้บางคนที่ใช้ dial-up หรือการเชื่อมต่อที่มี bufferbloat เจอคอขวดได้

• สิ่งที่อธิบายในบทความด้านล่างก็ใช้ได้เหมือนกัน: บล็อก Cloudflare - ISP รัสเซียปล่อยผ่านแค่ 16KB แรกจนการท่องเว็บส่วนใหญ่ใช้งานไม่ได้. จากการวิเคราะห์ของ Cloudflare ตอนนี้ ISPs ในรัสเซียกำลัง throttle อินเทอร์เน็ตของผู้ใช้ในประเทศ ทำให้โหลดได้เพียง 16KB แรกต่อ web asset เท่านั้น

• คนที่ไม่รู้ว่า TCP Slow Start คืออะไร กับคนที่ใส่ใจจนถึงขั้นต้องกังวลเรื่องความหน่วงการโหลดเว็บไซต์ระดับจิ๋ว ๆ มีส่วนทับซ้อนกันน้อยมาก สตาร์ตอัปควรโฟกัสกับการเป็นสตาร์ตอัปก่อน และมีแต่บริษัทใหญ่เท่านั้นที่พอมีแรงไปหมกมุ่นกับ optimization แบบนี้

  • ถ้าใช้แนวคิดแบบ “เพราะต้องโฟกัสกับเรื่องสำคัญกว่า เลยไม่มีเวลาใส่ใจ performance optimization” คุณก็จะไม่มีวันใส่ใจมันเลย นั่นแหละเหตุผลที่ทุกวันนี้แอปและเว็บไซต์ส่วนใหญ่ช้าและแย่มาก
  • ถ้าเป็นจริง ซอฟต์แวร์จากบริษัทอย่าง Microsoft ก็ควรต้องทำงานได้สมบูรณ์แบบและมีประสิทธิภาพสูงสุดเสมอ
  • ในเชิงแนวคิดฟังดูถูกต้อง แต่ถ้า Evan Wallace แห่ง Figma ไม่หมกมุ่นกับ performance Figma ก็คงไม่เป็นแบบทุกวันนี้ บางครั้ง “performance” เองก็กลายเป็นฟีเจอร์หลักของผลิตภัณฑ์ได้
  • เรื่องนี้อาจไม่ใช่สิ่งที่ต้องเลือกด้วยซ้ำ แต่ทำให้มันติดมาด้วยเป็นค่าเริ่มต้นได้เลย ผมทำทั้งเดโม 1 พันล้านเซลล์และเดโม checkbox[1] ด้วย datastar แล้วขนาดเพิ่งเกิน 10kb นิดเดียว ความต่างบนเครือข่ายมือถือกับ 3G ชัดมาก จากการทดลองของผม ถ้าเกิน 14kb บนการเชื่อมต่อคุณภาพต่ำจะช้าลงอีก 3 วินาที เพราะ maintainer ของ datastar ใส่ใจถึงระดับ TCP slow start ผมเลยได้อานิสงส์ไปด้วยโดยแทบไม่ต้องพยายาม
    • checkboxes.andersmurphy.com
  • ผมไม่คิดว่าขนาดของบริษัทจะเกี่ยวกับ performance optimization มากนัก กลับกัน บริษัทใหญ่หลายแห่งมักจะช้ากว่าเสียอีก

• หน้าโฮมเพจของผมมีขนาด 17.2KB! (ไม่รวม dependencies) ผม optimize หน้าเว็บส่วนตัวอย่างหนักจริง ๆ จนได้คะแนน Lighthouse เต็ม 100 ด้วย เดิมคิดว่าเป็นไปไม่ได้แต่ก็ทำสำเร็จ และบอกไว้ก่อนว่าทำด้วย Rails การ optimize แบบนี้คุ้มค่าจริง ๆ ประสบการณ์ของหน้าเว็บที่เปิดขึ้นมาไวทันใจโดยไม่รู้สึกหน่วงนั้นน่าพอใจมากในตัวมันเอง

  • พอได้สัมผัสว่า news.ycombinator.com โหลดทันทีทันใด มันสบายใจทางจิตวิทยามากจนเผลอเปิดอัตโนมัติทุกครั้งเวลาพัก
  • ผม optimize template code สำหรับหลายพันเว็บไซต์อย่างหนักมากจนได้คะแนน Lighthouse 100/100/100/100 แม้บนมือถือก็ยังเต็ม 100 โหลดแรกจริง ๆ ใหญ่กว่า 17.2kB มาก ประมาณ 120kB แต่เคล็ดลับคือกำจัด HTTP requests ที่ไม่จำเป็นทั้งหมด รัน JS เฉพาะส่วน "above-the-fold" แล้วที่เหลือใช้ lazy eval, defer และการเลื่อนโหลดทุกอย่างที่เลื่อนได้ JS/CSS ทำเป็น inline ส่วน third-party widgets ก็ใช้แนวทาง 'facade' เช่นไอคอนป็อปอัปไว้ก่อน แล้วค่อยยิง request จริงทีหลัง SSR backend ก็ช่วยมากเช่นกัน แม้แต่วิดีโอพื้นหลังจาก Vimeo ก็ยังได้ 100 คะแนน แต่ทำกับ Youtube ไม่ได้ วิธีได้คะแนนสมบูรณ์แบบคืออ่านผล Lighthouse แล้วตีความจนถึงขั้นเขียน codebase ใหม่ทั้งก้อน ผลคือคอมเพลนต์จากลูกค้าเรื่องความช้าหายไปหมด และกลายเป็นข้อได้เปรียบสูงทั้งในแง่ SEO และคะแนนจริง
  • Rails ไม่ได้เกี่ยวโดยตรงกับ optimization ด้าน rendering แต่อย่างใด แต่ก็ขอแสดงความยินดีกับคะแนน Lighthouse เต็ม

• ผมคิดว่าบทความนี้มีจุดอ่อนเชิงตรรกะอยู่สองข้อ

  1. มีสูตรที่บอกว่าบนการสื่อสารผ่านดาวเทียม การส่งหนึ่งแพ็กเก็ตใช้เวลาราว 1600ms แต่ในฐานะเหตุผลรองรับกฎ 14kb มันยังอ่อนอยู่ เพราะไม่มีการเปรียบเทียบกับเว็บไซต์ขนาดใหญ่ จึงไม่ได้แสดงให้เห็นว่า 10 แพ็กเก็ต ≠ 16 วินาที
  2. บทความบอกว่าจะนับรูปภาพของหน้าเว็บเข้าในกฎ 14kb ด้วย แต่มีสักกี่กรณีที่รูปถูก inline มาตั้งแต่โหลดแรก? ในความเป็นจริงนี่เป็นกรณียกเว้นที่พบได้น้อยมาก จึงควรพูดให้ชัดกว่านี้ว่ามันใช้ไม่ได้กับ 99.9% ของกรณี - "<i>กรณีที่รูปถูก inline เหรอ?</i>" ตัวอย่างหนึ่งคือการใช้ thumbnail ความละเอียดต่ำเฉพาะจอแรก พร้อมใส่ CSS blur แล้วค่อย fade in รูปจริงแบบ asynchronous ทีหลัง ถ้าทำดี ๆ จะใช้เพิ่มแค่ประมาณ 1~200 ไบต์เท่านั้น ผมใช้กับบล็อกของตัวเอง และแพลตฟอร์มอย่าง Wordpress, Medium ก็ใช้กันเยอะ เป็นทริกสำหรับ hyper-optimization ฝั่ง frontend เชิงพาณิชย์โดยเฉพาะ - ผมก็ไม่เห็นด้วยกับสมมติฐานที่ว่าผู้ใช้ส่วนใหญ่ใช้การเชื่อมต่อดาวเทียมแบบ latency ต่ำ และในโลกที่ทุกเว็บไซต์หนักระดับหลาย MB กันหมด จะมีแค่หน้าเว็บของผมหน้าเดียวที่ทนไม่ไหว

• คนยุคนี้มีแนวโน้มสร้างแม้แต่เว็บไซต์ static ธรรมดาด้วยเฟรมเวิร์กอย่าง Next.js ทำให้อดเสียดายไม่ได้ที่ยุค HTML+CSS+js กำลังเลือนหายไป

  • เห็นด้วย ผมก็ทำมาหมดแล้วทั้งเว็บทรัพยากรต่ำสุด การ optimize JavaScript เอง และเว็บตามกฎ 14kb แต่วิธีนี้พาไปสู่ข้อจำกัดด้านการออกแบบและสถาปัตยกรรม พอฟีเจอร์เพิ่ม การตัดสินใจ “ย่อให้เล็กที่สุด” ตอนนั้นจะกลายเป็นหนี้เทคนิคทั้งหมด คนส่วนใหญ่หลงใหลกับแนวคิด “เว็บล้วนไร้เฟรมเวิร์ก” อยู่พักหนึ่ง ก่อนจะพบว่าสุดท้ายมันทรมานกว่า แต่ถ้าใช้ isomorphic JS framework คุณเริ่มจากหน้า static ได้ optimize เท่าที่เหมาะ แล้วค่อยเปลี่ยนเป็น thick client JS เมื่อต้องการก็ได้
  • จริง ๆ เทรนด์กำลังย้อนกลับแล้ว ตอนนี้เฟรมเวิร์กส่วนใหญ่รองรับ static site ได้ดีมาก อย่าง Astro ก็เกิดมาเพื่อ static site โดยตรง
  • เหมือนเพิ่งรู้กัน แต่จริง ๆ ก็เป็นแบบนี้มาตลอดตั้งแต่ก่อน jQuery จะดังมากในปี 2010 เสียอีก
  • Next.js optimize bundle code ได้หนักมาก จึงเหมาะกับการ deploy บน lambda หรือเซิร์ฟเวอร์ขนาดเล็ก และ static site ที่ทำด้วย Next ก็ทำให้ bundle เล็กได้มากเช่นกัน

• นอกจาก latency แล้ว การลดการใช้ทรัพยากรให้น้อยที่สุดยังเป็นเงื่อนไขสำคัญของอนาคตที่ยั่งยืนด้วย ผลกระทบของเครือข่ายต่อสิ่งแวดล้อมก็ไม่ได้เล็กน้อยเลย น่าเสียดายที่บรรยากาศในคอมเมนต์ดูประชดประชันกันอยู่บ้าง แม้ optimization นี้จะไม่ใช่ทางออกสูงสุดของทุกอย่าง แต่ผมอยากให้มีการเน้นเรื่องการลดการใช้พลังงานมากกว่านี้

  • ทราฟฟิกอินเทอร์เน็ตส่วนใหญ่คือวิดีโอสตรีมมิง ต่อให้ optimize หน้าเว็บไปไม่กี่เมกะก็แทบไม่เห็นผล แน่นอนว่าควรถกเรื่องประสิทธิภาพ แต่การพยายาม optimize ทุกอย่างในทุกจุดอาจทำให้ทรัพยากรถูกดึงออกจากส่วนที่ควร optimize จริง ๆ
  • นี่ยังไม่ถึงขั้นเป็นผลไม้ตกพื้นให้เก็บเลย ระหว่างที่คุณ optimize เพื่อประหยัดไฟให้หน้าเว็บสัก 1~2mWh การค้นหาในเสิร์ชเอนจินครั้งเดียวใช้มากกว่า 100 เท่า และการใช้แชตบอตครั้งหนึ่งมากกว่า 10,000 เท่า แถมเรื่องนี้ก็ถูกบรรเทาได้มากด้วย caching และ lazy loading
  • การกังวลเรื่องลดขนาดหน้าถือว่าแทบไม่มีประโยชน์เลย ต่อให้เผื่อความปลอดภัยคูณสิบ ปริมาณไฟฟ้าที่ใช้ไปกับการท่องเว็บทั้งปี ก็ยังน้อยกว่าพลังงานที่ใช้ทำแฮมเบอร์เกอร์หนึ่งชิ้นมาก ทางกลับกัน ถ้านักพัฒนากินสลัดสักหนึ่งมื้อแทนที่จะนั่ง optimize อยู่เป็นสัปดาห์ ผลกระทบต่อสิ่งแวดล้อมอาจมากกว่า
  • เห็นด้วยเต็มที่ ผมเคยไปที่ BBC แล้วตกใจมากเมื่อเห็นว่าบทความข่าวสั้น ๆ แบบข้อความล้วนบทหนึ่งเก็บลงแคชถึง 120MB มันส่งเสริมทั้งการใช้พลังงานและวัฒนธรรมความสิ้นเปลืองโดยไม่จำเป็น เว็บไซต์ของผมก็พยายามทำให้ minimal ที่สุด และเวลาอัปโหลด YouTube ก็ใช้แค่ 1080P แทน 4K ผมว่า 4K กับ 8K ไม่ได้จำเป็นต้องมีอยู่ด้วยซ้ำ คนมักพูดกันแต่เรื่องเพิ่มโซลาร์อีกกี่ MW แต่จริง ๆ แล้วควรลองนึกภาพดูว่าการ “ผลิตให้น้อยลง” จะดีแค่ไหน ผมคิดถึงยุค 56K modem ที่เว็บมีขนาดเล็กกว่านี้ และเชื่อว่าคงเคยมีจุดกึ่งกลางที่เหมาะสมอยู่ที่ไหนสักแห่ง ซึ่งตอนนี้เราผ่านมันมาไกลมากแล้ว
  • ผู้คนมักจะเริ่มสนใจก็ต่อเมื่อมันเริ่มกระทบตัวเองโดยตรง ผมเองก็เป็นคนที่คำนึงถึงสิ่งแวดล้อม มีคนโต้แย้งว่า AI แย่กว่า แต่จริง ๆ AI ก็ต้อง crawl หน้าเว็บหนัก ๆ แบบนี้เหมือนกัน และเกณฑ์ 14kb ก็ยังไม่ถึง 1% ของ page payload เฉลี่ยบนมือถือด้วยซ้ำ