ฉันใช้เว็บเป็นเวลาหนึ่งวันด้วยงบประมาณ 50 MB

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

ครั้งล่าสุด ฉันท่องเว็บเป็นเวลาหนึ่งวันโดยใช้ Internet Explorer 8 ครั้งนี้ ฉันท่องเว็บเป็นเวลาหนึ่งวันด้วยงบประมาณ 50 MB

ทำไมต้อง 50 MB?

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

แต่มีบางส่วนของโลกที่ข้อมูลมือถือมีราคาแพงและมีโครงสร้างพื้นฐานบรอดแบนด์เพียงเล็กน้อยหรือไม่มีเลย

ผู้คนมักจะซื้อแพ็คเกจข้อมูลครั้งละหลายสิบเมกะไบต์ ทำให้กิกะไบต์เป็นข้อมูลที่ค่อนข้างใหญ่และมีราคาแพงในการซื้อ
— Dan Howdle นักวิเคราะห์โทรคมนาคมสำหรับผู้บริโภคที่ Cable.co.uk

แพงแค่ไหนที่เราพูด?

ค่าใช้จ่ายของข้อมูลมือถือ

จากการศึกษาในปี 2018 โดย cable.co.uk พบว่าซิมบับเวเป็นประเทศที่แพงที่สุดในโลกสำหรับข้อมูลมือถือ โดยที่ 1 GB มีค่าใช้จ่ายเฉลี่ย 75.20 ดอลลาร์ โดยอยู่ระหว่าง $12.50 ถึง 138.46 ดอลลาร์ ช่วงราคาที่มหาศาลนั้นเกิดจากข้อมูลจำนวนน้อยที่มีราคาแพง มาก ยิ่งแผนข้อมูลที่คุณทำข้อตกลงมีขนาดใหญ่ขึ้นตามสัดส่วนจะถูกลงตามสัดส่วนที่ถูกกว่า คุณสามารถอ่านวิธีการศึกษาสำหรับข้อมูลเพิ่มเติม

ซิมบับเวไม่ได้มีแค่ครั้งเดียว อิเควทอเรียลกินี เซนต์เฮเลนา และหมู่เกาะฟอล์คแลนด์อยู่ในแนวเดียวกัน โดยมีข้อมูล 1 GB ราคา 65.83 ดอลลาร์, 55.47 ดอลลาร์ และ 47.39 ดอลลาร์ ตามลำดับ โดยทั่วไป ประเทศเหล่านี้มีโครงสร้างพื้นฐานทางเทคนิคที่ไม่ดีและการนำไปใช้ที่ต่ำ หมายความว่าข้อมูลมีทั้งค่าใช้จ่ายในการจัดส่งและไม่มีการประหยัดจากขนาดเพื่อลดต้นทุน

ข้อมูลก็มีราคาแพงในส่วนของยุโรปเช่นกัน ข้อมูลกิกะไบต์ในกรีซจะทำให้คุณกลับมาที่ 32.71 ดอลลาร์; ในสวิตเซอร์แลนด์ 20.22 ดอลลาร์ สำหรับการเปรียบเทียบ ข้อมูลจำนวนเท่ากันมีค่าใช้จ่าย $6.66 ในสหราชอาณาจักร หรือ $12.37 ในสหรัฐอเมริกา ในอีกด้านของมาตราส่วน อินเดียเป็นสถานที่ที่ถูกที่สุดในโลกสำหรับข้อมูล โดยมีราคาเฉลี่ย 0.26 ดอลลาร์ คีร์กีซสถาน คาซัคสถาน และยูเครน ราคา $0.27, $0.49 และ $0.51 ต่อ GB ตามลำดับ

ความเร็วของเครือข่ายมือถือก็แตกต่างกันไปในแต่ละประเทศเช่นกัน น่าแปลกใจที่ผู้ใช้ประสบกับความเร็วที่เร็วกว่าบนเครือข่ายมือถือมากกว่า WiFi ในอย่างน้อย 30 ประเทศทั่วโลก รวมถึงออสเตรเลียและฝรั่งเศส เกาหลีใต้มีความเร็วในการดาวน์โหลดบนมือถือที่เร็วที่สุด โดยเฉลี่ย 52.4 Mbps แต่อิรักมีการดาวน์โหลดที่ช้าที่สุด เฉลี่ย 1.6 Mbps และอัปโหลด 0.7 Mbps สหรัฐอเมริกาอยู่ในอันดับที่ 40 ของโลกในด้านความเร็วในการดาวน์โหลดบนมือถือที่ประมาณ 34 Mbps และมีความเสี่ยงที่จะถูกทิ้งไว้ข้างหลังในขณะที่โลกกำลังก้าวไปสู่ ​​5G

สำหรับประเภทการเชื่อมต่อเครือข่ายมือถือ 84.7% ของการเชื่อมต่อผู้ใช้ในสหราชอาณาจักรใช้ 4G เทียบกับ 93% ในสหรัฐอเมริกาและ 97.5% ในเกาหลีใต้ ซึ่งเปรียบเทียบกับน้อยกว่า 50% ในอุซเบกิสถานและน้อยกว่า 60% ในแอลจีเรีย เอกวาดอร์ เนปาล และอิรัก

ต้นทุนของข้อมูลบรอดแบนด์

ในขณะเดียวกัน การศึกษาต้นทุนบรอดแบนด์ในปี 2561 แสดงให้เห็นว่าการเชื่อมต่อบรอดแบนด์ในไนเจอร์มีราคา 263 ดอลลาร์ต่อเมกะบิตต่อเดือน เมตริกนี้เข้าใจยากเล็กน้อย ดังนั้นนี่คือตัวอย่าง: หากต้นทุนเฉลี่ยของแพ็กเกจบรอดแบนด์ในประเทศหนึ่งๆ คือ 22 ดอลลาร์ และความเร็วในการดาวน์โหลดเฉลี่ยที่แพ็กเกจนำเสนอคือ 10 Mbps ค่าใช้จ่าย "ต่อเมกะบิตต่อเดือน" จะเท่ากับ เป็น $2.20

เป็นตัวชี้วัดที่น่าสนใจ และสิ่งหนึ่งที่ยอมรับว่าความเร็วบรอดแบนด์มีความสำคัญพอๆ กับขีดจำกัดข้อมูล ค่าใช้จ่าย $263 บ่งบอกถึงการผสมผสานระหว่างบรอดแบนด์ที่ช้ามากและมีราคาแพงมาก สำหรับการอ้างอิง เมตริกคือ $1.19 ในสหราชอาณาจักรและ $1.26 ในสหรัฐอเมริกา

สิ่งที่เข้าใจได้ง่ายกว่าคือราคาเฉลี่ยของแพ็คเกจบรอดแบนด์ โปรดทราบว่าการศึกษานี้กำลังมองหาแพ็คเกจบรอดแบนด์ที่ถูกที่สุดที่นำเสนอ โดยไม่สนใจว่าแพ็คเกจเหล่านี้มี data cap หรือไม่ ดังนั้นให้ตัวเลข ballpark ที่มีประโยชน์มากกว่าต้นทุนของข้อมูลต่อ se

เฉพาะค่าแพ็คเกจอย่างเดียว มอริเตเนียมีบรอดแบนด์ที่แพงที่สุดในโลกโดยเฉลี่ย 768.16 ดอลลาร์ (ช่วง 307.26 ดอลลาร์ ถึง 1,368.72) ค่าใช้จ่ายมหาศาลนี้รวมถึงการสร้างเส้นตรงไปยังทรัพย์สิน เนื่องจากมีเพียงไม่กี่แห่งในมอริเตเนีย ที่ 0.7 Mbps ประเทศมอริเตเนียยังมีเครือข่ายบรอดแบนด์ที่ช้าที่สุดในโลกอีกด้วย

ไต้หวันมีบรอดแบนด์ที่เร็วที่สุดในโลกด้วยความเร็วเฉลี่ย 85 Mbps เยเมนมีความเร็วที่ช้าที่สุดที่ 0.38 Mbps ทว่าแม้แต่ประเทศที่มีโครงสร้างพื้นฐานบรอดแบนด์ที่ได้รับการยอมรับอย่างดีก็ยังมีสิ่งที่เรียกว่า 'ไม่ใช่จุด' สหราชอาณาจักรอยู่ในอันดับที่ 34 จาก 207 ประเทศสำหรับความเร็วบรอดแบนด์ แต่ในเดือนกรกฎาคม 2019 ยังมีโรงเรียนในสหราชอาณาจักรที่ไม่มีบรอดแบนด์

ราคาเฉลี่ยของแพ็คเกจบรอดแบนด์ในสหราชอาณาจักรอยู่ที่ 39.58 ดอลลาร์สหรัฐฯ และในสหรัฐอเมริกาอยู่ที่ 67.69 ดอลลาร์ ค่าเฉลี่ยที่ถูกที่สุดในโลกคือของยูเครน ที่ราคาเพียง $5 แม้ว่าจะพบดีลบรอดแบนด์ที่ถูกที่สุดในคีร์กีสถาน ($1.27 เทียบกับค่าเฉลี่ยของประเทศที่ 108.22 ดอลลาร์)

ซิมบับเวเป็นประเทศที่มีค่าใช้จ่ายสูงที่สุดสำหรับข้อมูลมือถือ และสถิติก็ไม่ได้ดีไปกว่าบรอดแบนด์มากนัก โดยมีค่าใช้จ่ายเฉลี่ย 128.71 ดอลลาร์และ "ต่อเมกะบิตต่อเดือน" ที่ 6.89 ดอลลาร์

ต้นทุนสัมบูรณ์เทียบกับต้นทุนในแง่จริง

ค่าใช้จ่ายทั้งหมดที่ระบุไว้จนถึงตอนนี้เป็นค่าใช้จ่ายที่แน่นอนในสกุลเงิน USD โดยอิงตามอัตราแลกเปลี่ยน ณ เวลาที่ทำการศึกษา ค่าใช้จ่ายเหล่านี้ไม่ได้นำมาคำนวณเป็นค่าครองชีพ ซึ่งหมายความว่าในหลายประเทศ ค่าใช้จ่ายจริงจะสูงกว่ามากในแง่ความเป็นจริง

วันนี้ฉันจะจำกัดการท่องเว็บของฉันไว้ที่ 50 MB ซึ่งในซิมบับเวจะมีราคาประมาณ 3.67 ดอลลาร์สำหรับค่าบริการข้อมูลมือถือ นั่นอาจฟังดูไม่มากนัก แต่ครูในซิมบับเวโดดเด่นในปีนี้เพราะเงินเดือนของพวกเขาลดลงเหลือเพียง 2.50 ดอลลาร์ต่อวัน

สำหรับการเปรียบเทียบ $3.67 นั้นอยู่ที่ประมาณครึ่งหนึ่งของค่าแรงขั้นต่ำ $7.25 ในสหรัฐอเมริกา ในฐานะชาวซิมบับเว ฉันต้องทำงานประมาณครึ่งวันเพื่อหาเงินเพื่อซื้อข้อมูล 50MB นี้ เทียบกับเวลาเพียงครึ่งชั่วโมงในสหรัฐอเมริกา ไม่ใช่เรื่องง่ายที่จะเปรียบเทียบค่าครองชีพระหว่างประเทศต่างๆ แต่สำหรับค่าจ้างเพียงอย่างเดียว ค่าใช้จ่าย 3.67 ดอลลาร์สำหรับข้อมูล 50 MB ในซิมบับเวจะรู้สึกเหมือนอยู่ที่ 52 ดอลลาร์ต่อค่าจ้างขั้นต่ำของคนอเมริกัน

การตั้งค่าการทดลอง

ฉันเปิดตัว Chrome และเปิดเครื่องมือ dev ซึ่งฉันควบคุมเครือข่ายให้มีการเชื่อมต่อ 3G ที่ช้า ฉันต้องการจำลองการเชื่อมต่อที่ช้าเหมือนประสบการณ์ของผู้ใช้ในอุซเบกิสถาน เพื่อดูว่าเว็บไซต์จะให้ประสบการณ์ประเภทใดบ้าง ฉันยังควบคุม CPU ของฉันเพื่อจำลองอุปกรณ์ระดับล่าง

ฉันติดตั้ง ModHeader และตั้งค่าส่วนหัว 'บันทึกข้อมูล' เพื่อให้เว็บไซต์รู้ว่าฉันต้องการลดการใช้ข้อมูลของฉันให้น้อยที่สุด นี่เป็นส่วนหัวที่กำหนดโดย 'โหมด Lite' ของ Chrome สำหรับ Android ซึ่งฉันจะกล่าวถึงในรายละเอียดเพิ่มเติมในภายหลัง

ฉันดาวน์โหลด TripMode; แอปพลิเคชันสำหรับ Mac ซึ่งให้คุณควบคุมว่าแอปใดบน Mac ของคุณสามารถเข้าถึงอินเทอร์เน็ตได้ การเข้าถึงอินเทอร์เน็ตของแอปพลิเคชันอื่น ๆ จะถูกบล็อกโดยอัตโนมัติ

ฉันคาดการณ์ว่างบประมาณ 50 MB จะพาฉันไปได้ไกลแค่ไหน ด้วยน้ำหนักเฉลี่ยของหน้าเว็บเกือบ 1.7 MB นั่นแสดงว่าฉันมีงบประมาณประมาณ 29 หน้า แม้ว่าอาจจะมากกว่านั้นเล็กน้อยหากฉันสามารถอยู่ในไซต์เดิมและใช้ประโยชน์จากการแคชของเบราว์เซอร์ได้

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

การทดลอง

โดยไม่ต้องกังวลใจอีกต่อไป ฉันโหลด google.com โดยใช้งบประมาณ 402 KB และใช้เงิน $0.03 (ประมาณ 1% ของงบประมาณซิมบับเวของฉัน)

โดยรวมแล้วไม่ใช่ขนาดหน้าที่ไม่ดี แต่ฉันสงสัยว่าคำขอเครือข่าย 24 รายการนั้นมาจากไหนและหน้านั้นสามารถทำให้เบาลงได้หรือไม่

หน้าแรกของ Google — DOM

เมื่อดูที่มาร์กอัปของหน้า จะไม่มีสไตล์ชีตภายนอก — CSS ทั้งหมดเป็นแบบอินไลน์

เคล็ดลับประสิทธิภาพ #1: CSS วิกฤตในบรรทัด

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

คำแนะนำทั่วไปคือให้สไตล์ที่สำคัญของคุณ (ครึ่งหน้าบน) เป็นแบบอินไลน์ และสำหรับสไตล์ที่เหลือของคุณเป็นแบบภายนอกและโหลดแบบอะซิงโครนัส การโหลด CSS แบบอะซิงโครนัสสามารถทำได้ในบรรทัดเดียวที่ชาญฉลาดอย่างน่าทึ่งของ HTML:

 <link rel="stylesheet" href="/path/to/my.css" media="print" onload="this.media='all'">

devtools แสดง DOM เวอร์ชันที่ปรับแต่งแล้ว ถ้าคุณต้องการดูสิ่งที่ถูกดาวน์โหลดลงในเบราว์เซอร์จริงๆ ให้สลับไปที่แท็บแหล่งที่มาและค้นหาเอกสาร

คุณจะเห็นว่ามี JavaScript แบบอินไลน์จำนวนมากที่นี่ เป็นที่น่าสังเกตว่ามันถูกทำให้ดูน่าเกลียดมากกว่าที่จะย่อให้เล็กลง

เคล็ดลับประสิทธิภาพ #2: ลดขนาดและอัปลักษณ์ทรัพย์สินของคุณ

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

ถึงกระนั้น สคริปต์อินไลน์ดูเหมือนว่าจะมีขนาดประมาณ 120 KB ของทรัพยากรหน้า 210 KB (ประมาณครึ่งหนึ่งของขนาด gzipped 60 KB) นอกจากนี้ ยังมีไฟล์ JavaScript ภายนอก 5 ไฟล์ที่มีขนาด 291 KB จาก 402 KB ที่ดาวน์โหลด:

ซึ่งหมายความว่า JavaScript คิดเป็นประมาณ 80 เปอร์เซ็นต์ของน้ำหนักหน้าโดยรวม

นี่ไม่ใช่จาวาสคริปต์ที่ไร้ประโยชน์ Google ต้องมีบางอย่างเพื่อแสดงคำแนะนำขณะที่คุณพิมพ์ แต่ฉันสงสัยว่าส่วนใหญ่จะเป็นโค้ดติดตามและการตั้งค่าโฆษณา

สำหรับการเปรียบเทียบ ฉันปิดการใช้งาน JavaScript และโหลดหน้าซ้ำ:

เวอร์ชันการค้นหาของ Google ที่ปิดการใช้งาน JS นั้นมีขนาดเพียง 102 KB ซึ่งต่างจาก 402 KB แม้ว่า Google จะไม่สามารถให้คำแนะนำอัตโนมัติได้ภายใต้เงื่อนไขเหล่านี้ แต่ไซต์ยังคงใช้งานได้ และฉันเพิ่งลดการใช้ข้อมูลลงเหลือหนึ่งในสี่ของจำนวนที่เคยเป็น ถ้าฉันต้องจำกัดการใช้ข้อมูลในระยะยาว สิ่งแรกที่ฉันจะทำคือปิดการใช้งาน JavaScript มันไม่ได้เลวร้ายอย่างที่คิด

เคล็ดลับประสิทธิภาพ #3: น้อยแต่มาก

เนื้อหาที่ฝังอยู่ภายใน น่าเกลียด และย่อเล็กสุดเป็นสิ่งที่ดีและดี แต่ประสิทธิภาพที่ดีที่สุดมาจากการไม่ส่งเนื้อหาลงไปตั้งแต่แรก

• ก่อนเพิ่มคุณลักษณะใหม่ คุณมีงบประมาณด้านประสิทธิภาพอยู่แล้วหรือไม่
• ก่อนเพิ่ม JavaScript ลงในไซต์ของคุณ สามารถใช้ HTML ธรรมดาให้คุณลักษณะของคุณสำเร็จได้หรือไม่ (เช่น การตรวจสอบแบบฟอร์ม HTML5)
• ก่อนที่จะดึงไลบรารี JavaScript หรือ CSS ขนาดใหญ่ลงในแอปพลิเคชันของคุณ ให้ใช้บางอย่างเช่น bundlephobia.com เพื่อวัดว่ามันใหญ่แค่ไหน ความสะดวกสบายคุ้มค่ากับน้ำหนักหรือไม่? คุณสามารถทำสิ่งเดียวกันให้สำเร็จโดยใช้รหัสวานิลลาในขนาดข้อมูลที่เล็กกว่ามากได้หรือไม่

การวิเคราะห์ข้อมูลทรัพยากร

มีจำนวนมากที่จะแกะที่นี่ มาเริ่มกันเลยดีกว่า ฉันมีเพียง 50 MB ที่จะเล่นด้วย ดังนั้นฉันจะโหลดทุก ๆ บิตของการโหลดหน้านี้ ทำความเข้าใจกับบทแนะนำ Chrome Devtools สั้นๆ

โอนแล้ว 402 KB แต่ทรัพยากร 1.1 MB: หมายความว่าอย่างไร

หมายความว่ามีการดาวน์โหลดเนื้อหาจริง 402 KB แต่อยู่ในรูปแบบการบีบอัด (โดยใช้อัลกอริธึมการบีบอัดเช่น gzip หรือ brotli) จากนั้นเบราว์เซอร์ต้องทำงานบางอย่างเพื่อแกะสิ่งที่มีความหมาย ขนาดรวมของข้อมูลที่คลายแพ็กคือ 1.1 MB

การแตกไฟล์นี้ไม่ฟรี — มีค่าใช้จ่ายไม่กี่มิลลิวินาทีในการคลายการบีบอัดทรัพยากร แต่นั่นเป็นค่าใช้จ่ายเล็กน้อยเมื่อเทียบกับการส่ง 1.1MB ลงสาย

เคล็ดลับประสิทธิภาพ #4: บีบอัดเนื้อหาแบบข้อความ

ตามกฎทั่วไป ให้บีบอัดเนื้อหาของคุณเสมอ โดยใช้บางอย่างเช่น gzip แต่อย่าใช้การบีบอัดภาพและไฟล์ไบนารีอื่นๆ ของคุณ คุณควรปรับให้เหมาะสมล่วงหน้าที่แหล่งที่มา การบีบอัดอาจทำให้ใหญ่ขึ้นได้

และหากทำได้ ให้หลีกเลี่ยงการบีบอัดไฟล์ที่มีขนาด 1500 ไบต์หรือเล็กกว่านั้น ขนาดแพ็กเก็ต TCP ที่เล็กที่สุดคือ 1500 ไบต์ ดังนั้นเมื่อบีบอัดเป็น 800 ไบต์ คุณจะไม่บันทึกอะไรเลย เนื่องจากมันยังส่งอยู่ในแพ็กเก็ตไบต์เดียวกัน อีกครั้ง ค่าใช้จ่ายเล็กน้อย แต่เสียเวลาบีบอัด CPU บนเซิร์ฟเวอร์และคลายการบีบอัดเวลา CPU บนไคลเอนต์

กลับไปที่แท็บเครือข่ายใน Chrome: มาเจาะลึกถึงลำดับความสำคัญเหล่านั้นกัน โปรดสังเกตว่าทรัพยากรมีลำดับความสำคัญ "สูงสุด" ถึง "ต่ำสุด" ซึ่งเป็นการคาดเดาที่ดีที่สุดของเบราว์เซอร์ว่าทรัพยากรใดสำคัญกว่าในการดาวน์โหลด ยิ่งมีลำดับความสำคัญสูง เบราว์เซอร์จะพยายามดาวน์โหลดเนื้อหาเร็วขึ้นเท่านั้น

เคล็ดลับประสิทธิภาพ #5: ให้คำแนะนำทรัพยากรแก่เบราว์เซอร์

เบราว์เซอร์จะเดาว่าเนื้อหาที่มีลำดับความสำคัญสูงสุดคืออะไร แต่คุณสามารถให้คำแนะนำทรัพยากรโดยใช้แท็ก <link rel="preload"> เพื่อแนะนำให้เบราว์เซอร์ดาวน์โหลดเนื้อหาโดยเร็วที่สุด เป็นความคิดที่ดีที่จะโหลดแบบอักษร โลโก้ และสิ่งอื่นใดที่ปรากฏในครึ่งหน้าบนล่วงหน้า

มาพูดถึงการแคชกัน ฉันจะกด ALT ค้างไว้แล้วคลิกขวาเพื่อเปลี่ยนส่วนหัวของคอลัมน์เพื่อปลดล็อกข้อมูลที่น่าสนใจยิ่งขึ้น เรากำลังจะไปตรวจสอบ Cache-Control

Cache-Control ระบุว่าทรัพยากรสามารถแคชได้หรือไม่ ระยะเวลาที่สามารถแคชได้ และกฎใดที่ควรปฏิบัติตามในการตรวจสอบความถูกต้องอีกครั้ง การตั้งค่าแคชที่เหมาะสมเป็นสิ่งสำคัญในการลดต้นทุนข้อมูลสำหรับการเข้าชมซ้ำ

เคล็ดลับประสิทธิภาพ #6: ตั้งค่าส่วนหัวของการควบคุมแคชบนสินทรัพย์ที่แคชได้ทั้งหมด

โปรดทราบว่าค่าการควบคุมแคชเริ่มต้นด้วยคำสั่งของ public หรือ private ตามด้วยค่าหมดอายุ (เช่น max-age=31536000 ) คำสั่งหมายความว่าอย่างไร และเหตุใดจึงมีค่า max-age จำเพาะเจาะจงอย่างผิดปกติ

ค่า 31536000 คือจำนวนวินาทีที่มีอยู่ในหนึ่งปี และเป็นค่าสูงสุดตามทฤษฎีที่อนุญาตโดยข้อกำหนดคุณลักษณะการควบคุมแคช เป็นเรื่องปกติที่จะเห็นค่านี้ใช้กับสินทรัพย์คงที่ทั้งหมดและหมายความว่า "ทรัพยากรนี้จะไม่เปลี่ยนแปลง" อย่างมีประสิทธิภาพ ในทางปฏิบัติ ไม่มีเบราว์เซอร์ใดที่จะแคชตลอดทั้งปี แต่จะแคชเนื้อหาตราบเท่าที่สมเหตุสมผล

เพื่ออธิบายคำสั่งสาธารณะ/ส่วนตัว เราต้องอธิบายแคชหลักสองรายการที่มีอยู่นอกเซิร์ฟเวอร์ อย่างแรก มีแคชของเบราว์เซอร์แบบดั้งเดิม ซึ่งทรัพยากรถูกเก็บไว้ในเครื่องของผู้ใช้ ('ไคลเอ็นต์') แล้วมีแคช CDN ซึ่งอยู่ระหว่างไคลเอนต์และเซิร์ฟเวอร์ ทรัพยากรถูกแคชไว้ที่ระดับ CDN เพื่อป้องกันไม่ให้ CDN ขอทรัพยากรจากเซิร์ฟเวอร์ต้นทางซ้ำแล้วซ้ำอีก

คำสั่ง Cache-Control ของ public อนุญาตให้แคชทรัพยากรทั้งในไคลเอ็นต์และ CDN ค่า private หมายถึงเฉพาะไคลเอนต์เท่านั้นที่สามารถแคชได้ CDN ไม่ควรทำ ค่าหลังนี้มักจะใช้สำหรับเพจหรือทรัพย์สินที่มีอยู่หลังการรับรองความถูกต้อง ซึ่งมันเป็นเรื่องปกติที่จะแคชบนไคลเอนต์ แต่เราไม่ต้องการให้ข้อมูลส่วนตัวรั่วไหลโดยการแคชใน CDN และส่งมอบให้กับผู้ใช้รายอื่น

สิ่งหนึ่งที่ทำให้ฉันสนใจคือโลโก้ Google มีการควบคุมแคชเป็น "ส่วนตัว" รูปภาพอื่นๆ บนหน้ามีแคชสาธารณะ และฉันไม่รู้ว่าทำไมโลโก้ถึงได้รับการปฏิบัติแตกต่างไปจากนี้ หากคุณมีความคิดใด ๆ แจ้งให้เราทราบในความคิดเห็น!

ฉันรีเฟรชหน้าและทรัพยากรส่วนใหญ่ให้บริการจากแคช นอกเหนือจากตัวเพจเอง ซึ่งคุณได้เห็นแล้วว่าเป็น private, max-age=0 ซึ่งหมายความว่าไม่สามารถแคชได้ นี่เป็นเรื่องปกติสำหรับหน้าเว็บแบบไดนามิกซึ่งเป็นสิ่งสำคัญที่ผู้ใช้จะได้รับหน้าล่าสุดเสมอเมื่อรีเฟรช

เมื่อถึงจุดนี้ ฉันบังเอิญคลิก URL 'คำอธิบาย' ใน devtools ซึ่งพาฉันไปที่ข้อมูลอ้างอิงการวิเคราะห์เครือข่าย ซึ่งทำให้ฉันใช้งบประมาณประมาณ 5 MB อ๊ะ.

Google Dev Docs

4.2 MB ของหน้า 5 MB ใหม่นี้เหลือเพียงรูปภาพ โดยเฉพาะ SVG น้ำหนักที่มากที่สุดคือ 186 KB ซึ่งไม่ใหญ่มาก — มีเพียงจำนวนมากเท่านั้น และทั้งหมดดาวน์โหลดพร้อมกัน

การโหลดหน้า 5 MB นั้นเป็น 10% ของงบประมาณของฉันสำหรับวันนี้ จนถึงตอนนี้ ฉันใช้ไปแล้ว 5.5 MB รวมถึงไม่มีการโหลด JavaScript ของหน้าแรกของ Google และใช้จ่าย $0.40 ไม่ได้ตั้งใจจะเปิดเพจนี้

อะไรจะดีไปกว่าประสบการณ์การใช้งานของผู้ใช้ที่นี่

เคล็ดลับประสิทธิภาพ #7: ขี้เกียจโหลดรูปภาพของคุณ

โดยปกติ ถ้าฉันคลิกลิงก์โดยไม่ได้ตั้งใจ ฉันจะกดปุ่มย้อนกลับในเบราว์เซอร์ของฉัน ฉันไม่ได้รับประโยชน์ใดๆ จากการดาวน์โหลดภาพเหล่านั้น — เสีย 4.2 MB เสียจริง!

นอกเหนือจากวิดีโอ ซึ่งโดยทั่วไปแล้วคุณจะรู้ว่าคุณกำลังทำอะไรอยู่ รูปภาพยังเป็นสาเหตุของการใช้ข้อมูลบนเว็บมากที่สุดอีกด้วย จากการศึกษาเว็บไซต์ 500 อันดับแรกของโลก พบว่ารูปภาพใช้น้ำหนักหน้าเฉลี่ยถึง 53% “ซึ่งหมายความว่ามีผลกระทบอย่างมากต่อเวลาในการโหลดหน้าเว็บและประสิทธิภาพโดยรวมในเวลาต่อมา”

แทนที่จะดาวน์โหลดรูปภาพทั้งหมดในการโหลดหน้าเว็บ เป็นการดีที่จะโหลดรูปภาพแบบ Lazy Loading เพื่อให้เฉพาะผู้ใช้ที่มีส่วนร่วมกับหน้าเท่านั้นที่จ่ายค่าใช้จ่ายในการดาวน์โหลด ผู้ใช้ที่เลือกที่จะไม่เลื่อนดูครึ่งหน้าล่าง จึงไม่เปลืองแบนด์วิธที่ไม่จำเป็นในการดาวน์โหลดภาพที่พวกเขาจะไม่เคยเห็น

มีคู่มือ css-tricks.com ที่ยอดเยี่ยมสำหรับการเปิดตัวการโหลดแบบ Lazy Loading สำหรับรูปภาพซึ่งมีความสมดุลที่ดีระหว่างผู้ที่มีการเชื่อมต่อที่ดี ผู้ที่มีการเชื่อมต่อที่ไม่ดี และผู้ที่ปิดการใช้งาน JavaScript

หากหน้านี้ใช้การโหลดแบบ Lazy Loading ตามคำแนะนำด้านบน แต่ละ SVG 38 รายการจะถูกแสดงด้วยรูปภาพตัวยึดตำแหน่งขนาด 1 KB โดยค่าเริ่มต้น และโหลดเฉพาะในมุมมองแบบเลื่อนเท่านั้น

เคล็ดลับประสิทธิภาพ #8: ใช้รูปแบบที่เหมาะสมสำหรับรูปภาพของคุณ

ฉันคิดว่า Google พลาดเคล็ดลับโดยไม่ได้ใช้ WebP ซึ่งเป็นรูปแบบภาพที่เล็กกว่า 26% เมื่อเทียบกับ PNG (โดยไม่สูญเสียคุณภาพ) และมีขนาดเล็กลง 25-34% เมื่อเทียบกับ JPEG (และของ คุณภาพเทียบเท่า) ฉันคิดว่าฉันจะแปลง SVG เป็น WebP

การแปลงเป็น WebP ทำให้ SVG ตัวใดตัวหนึ่งลดลงจาก 186 KB เหลือเพียง 65 KB แต่จริงๆ แล้ว เมื่อดูจากภาพเคียงข้างกัน WebP ออกมาเป็นเม็ดเล็กๆ:

จากนั้นฉันก็ลองแปลงหนึ่งใน PNGs เป็น WebP ซึ่งควรจะไม่มีการสูญเสียและควรมีขนาดเล็กลง อย่างไรก็ตาม เอาต์พุต WebP นั้น *หนักกว่า* (127 KB จาก 109 KB)!

สิ่งนี้ทำให้ฉันประหลาดใจ WebP ไม่จำเป็นต้องเป็นสัญลักษณ์แสดงหัวข้อย่อยสีเงินที่เราคิดว่าเป็น และแม้แต่ Google ก็ยังละเลยที่จะใช้ในหน้านี้

ดังนั้น คำแนะนำของฉันคือ ถ้าเป็นไปได้ ให้ทดลองกับรูปแบบภาพต่างๆ ตามภาพแต่ละภาพ รูปแบบที่รักษาคุณภาพที่ดีที่สุดสำหรับขนาดที่เล็กที่สุดอาจไม่ใช่รูปแบบที่คุณคาดหวัง

ตอนนี้กลับไปที่ DOM ฉันเจอสิ่งนี้:

สังเกตเห็นคีย์เวิร์ด async บนสคริปต์ Google Analytics หรือไม่

แม้จะเป็นหนึ่งในสิ่งแรกๆ ในส่วนหัวของเอกสาร แต่สิ่งนี้ได้รับความสำคัญต่ำ เนื่องจากเราได้เลือกไม่รับคำขอบล็อกอย่างชัดเจนโดยใช้คีย์เวิร์ด async

คำขอบล็อกคือคำขอที่หยุดการแสดงผลของหน้า การเรียก <script> ถูกบล็อกโดยค่าเริ่มต้น เป็นการหยุดการแยกวิเคราะห์ HTML จนกว่าสคริปต์จะดาวน์โหลด รวบรวม และดำเนินการ นี่คือเหตุผลที่เรามักจะใส่การเรียก <script> ไว้ที่ส่วนท้ายของเอกสาร

เคล็ดลับประสิทธิภาพ #9: หลีกเลี่ยงการเขียนสคริปต์การบล็อกการโทร

การเพิ่มแอตทริบิวต์ async ให้กับแท็ก <script> เป็นการบอกเบราว์เซอร์ว่าอย่าหยุดแสดงผลหน้าเว็บแต่ให้ดาวน์โหลดสคริปต์ในเบื้องหลัง ถ้า HTML ยังคงถูกแยกวิเคราะห์ตามเวลาที่สคริปต์ถูกดาวน์โหลด การแยกวิเคราะห์จะหยุดชั่วคราวในขณะที่สคริปต์ถูกเรียกใช้งาน แล้วจึงกลับมาทำงานต่อ ซึ่งดีกว่าการบล็อกการแสดงผลทันทีที่พบ <script>

นอกจากนี้ยังมีคุณลักษณะการ defer ซึ่งแตกต่างกันเล็กน้อย <script defer> บอกให้เบราว์เซอร์แสดงหน้าในขณะที่สคริปต์โหลดในพื้นหลัง และแม้ว่า HTML จะยังคงถูกแยกวิเคราะห์ตามเวลาที่ดาวน์โหลดสคริปต์ สคริปต์ต้องรอจนกว่าหน้าจะแสดงผลก่อนจึงจะสามารถดำเนินการได้ . ทำให้สคริปต์ไม่บล็อกอย่างสมบูรณ์ อ่าน “โหลด JavaScript อย่างมีประสิทธิภาพด้วยการเลื่อนและ async” สำหรับข้อมูลเพิ่มเติม

อย่างไรก็ตาม พอ Google ผ่า ได้เวลาลองใช้เว็บไซต์อื่นแล้ว ฉันยังมีงบประมาณเหลืออีกเกือบ 45 MB!

อเมซอน

หน้าแรกของ Amazon โหลดด้วยน้ำหนักรวมประมาณ 6 MB หนึ่งในนั้นคือรูปภาพขนาด 587 KB ที่ฉันหาไม่เจอบนหน้าด้วยซ้ำ นี่เป็น PNG ซึ่งน่าจะมีข้อความที่คมชัด แต่อยู่บนพื้นหลังการถ่ายภาพ ซึ่งเป็นชุดค่าผสมแบบคลาสสิกที่ประสิทธิภาพแย่มาก

อันที่จริง มีรูปภาพหลายร้อยกิโลไบต์สองสามรูปในแท็บเครือข่ายของฉันซึ่งฉันมองไม่เห็นบนหน้าจริงๆ ฉันสงสัยว่ามีการกำหนดค่าผิดพลาดที่ใดที่หนึ่งใน Amazon แต่ภาพที่มองไม่เห็นเหล่านี้รวมกันเคี้ยวข้อมูลของฉันอย่างน้อย 1 MB

แล้วภาพพระเอกล่ะ? เป็นภาพหลักในหน้า และถ่ายโอนได้เพียง 94 KB — แต่อาจลดขนาดลงได้ประมาณ 15% หากครอบตัดรอบข้อความและนักฟุตบอลโดยตรง จากนั้นเราก็สามารถใช้สีพื้นหลังเดียวกันใน CSS ได้เช่นเดียวกับในภาพ มีข้อดีเพิ่มเติมในการปรับขนาดหน้าจอให้เล็กลงได้ในขณะที่ยังคงความชัดเจนของข้อความ

ฉันเคยพูดไปแล้ว และฉันจะพูดอีกครั้ง: การเพิ่มประสิทธิภาพและการโหลดรูปภาพของคุณแบบ Lazy Loading เป็นข้อดีที่ใหญ่ที่สุดเพียงอย่างเดียวที่คุณสามารถสร้างให้กับน้ำหนักหน้าของไซต์ของคุณ

การปรับภาพให้เหมาะสมที่สุด การลดข้อมูลที่สำคัญที่สุด คุณสามารถทำให้กรณี JavaScript เป็นเรื่องใหญ่สำหรับประสิทธิภาพโดยรวม แต่ไม่ใช่การลดข้อมูล การเพิ่มประสิทธิภาพหรือลบภาพเป็นวิธีที่ปลอดภัยที่สุดในการรับประกันประสบการณ์การใช้งานที่เบากว่ามาก และนั่นคือการเพิ่มประสิทธิภาพหลักที่ Data Saver อาศัย
— Tim Kadlec ทำความ เข้าใจ Chrome Lite Pages

เพื่อความเป็นธรรมสำหรับ Amazon หากฉันปรับขนาดเบราว์เซอร์เป็นขนาดมือถือและรีเฟรชหน้า ไซต์นั้นได้รับการปรับให้เหมาะสำหรับมือถือและน้ำหนักหน้ารวมเพียง 2.1 MB

แต่สิ่งนี้นำฉันไปสู่จุดต่อไปของฉัน ...

เคล็ดลับประสิทธิภาพ #10: อย่าตั้งสมมติฐานเกี่ยวกับการเชื่อมต่อข้อมูล

เป็นการยากที่จะตรวจพบว่ามีคนบนเดสก์ท็อปใช้การเชื่อมต่อบรอดแบนด์หรือเชื่อมต่ออินเทอร์เน็ตผ่านด็องเกิลหรืออุปกรณ์เคลื่อนที่ที่จำกัดข้อมูล หลายคนทำงานบนรถไฟแบบนั้น หรืออาศัยอยู่ในพื้นที่ที่โครงสร้างพื้นฐานบรอดแบนด์ไม่ดี แต่สัญญาณมือถือแรง ในกรณีของ Amazon มีพื้นที่ให้ประหยัดข้อมูลขนาดใหญ่บนไซต์เดสก์ท็อป และเราไม่ควรนิ่งเฉยเพียงเพราะขนาดหน้าจอบ่งบอกว่าฉันไม่ได้ใช้อุปกรณ์พกพา

ใช่ เราควรคาดหวังการโหลดหน้าเว็บที่ใหญ่ขึ้นหากวิวพอร์ตของเรา 'ขนาดเดสก์ท็อป' เนื่องจากรูปภาพจะใหญ่ขึ้นและปรับให้เหมาะสมกับหน้าจอได้ดีกว่าภาพบนมือถือที่มีเนื้อหยาบ แต่หน้าไม่ควรมีขนาดใหญ่กว่า

ยิ่งกว่านั้น ฉันกำลังส่งส่วนหัว Save-Data พร้อมกับคำขอของฉัน ส่วนหัวนี้ระบุอย่างชัดเจนถึงความต้องการใช้ข้อมูลที่ลดลง และฉันหวังว่าเว็บไซต์อื่นๆ จะเริ่มสังเกตเห็นสิ่งนี้ในอนาคต

การโหลด 'เดสก์ท็อป' เริ่มต้นอาจเป็น 6 MB แต่หลังจากนั่งดูมันเป็นเวลาหนึ่งนาที มันก็เพิ่มขึ้นเป็น 8.6 MB เนื่องจากทรัพยากรที่มีลำดับความสำคัญต่ำกว่าและการติดตามกิจกรรมเริ่มทำงาน น้ำหนักหน้านี้รวม JavaScript ย่อขนาดเกือบ 1.7 MB ฉันไม่อยากแม้แต่จะ เริ่ม มองสิ่งนั้น

เคล็ดลับประสิทธิภาพ #11: ใช้ Web Workers สำหรับ JavaScript ของคุณ

ไหนจะแย่กว่ากัน — 1.7 MB ของ JavaScript หรือ 1.7 MB ของรูปภาพ? คำตอบคือ JavaScript: ทั้งสองเนื้อหาไม่เท่ากันเมื่อพูดถึงประสิทธิภาพ

ภาพ JPEG ต้องถอดรหัส แรสเตอร์ และทาสีบนหน้าจอ ต้องดาวน์โหลดบันเดิล JavaScript จากนั้นแยกวิเคราะห์ คอมไพล์ ดำเนินการ และยังมีขั้นตอนอื่นๆ อีกจำนวนหนึ่งที่เอ็นจินจำเป็นต้องทำให้เสร็จ โปรดทราบว่าค่าใช้จ่ายเหล่านี้ไม่เท่ากัน
— Addy Osmani ต้นทุนของ JavaScript ในปี 2018

หากคุณต้องส่ง JavaScript มากขนาดนี้ ให้ลองใส่ไว้ใน Web Worker สิ่งนี้ทำให้ JavaScript จำนวนมากหลุดออกจากเธรดหลัก ซึ่งขณะนี้มีอิสระในการทาสี UI ใหม่ ช่วยให้หน้าเว็บของคุณตอบสนองได้ดีบนอุปกรณ์ที่ใช้พลังงานต่ำ

ตอนนี้ฉันมีงบประมาณประมาณ 15.5 MB และใช้งบประมาณข้อมูลซิมบับเวไปแล้ว 1.14 ดอลลาร์ ฉันต้องทำงานครึ่งวันเป็นครูเพื่อหาเงินมาไกลขนาดนี้

Pinterest

ฉันได้ยินเรื่องดีๆ เกี่ยวกับประสิทธิภาพของ Pinterest มาบ้าง ฉันจึงตัดสินใจทดสอบ

บางทีนี่อาจไม่ใช่การทดสอบที่ยุติธรรมที่สุด ฉันถูกนำไปที่หน้าลงชื่อเข้าใช้ ซึ่งกระบวนการแบบอะซิงโครนัสพบว่าฉันเข้าสู่ระบบ Facebook และเข้าสู่ระบบโดยอัตโนมัติ หน้าโหลดค่อนข้างเร็ว แต่คำขอเพิ่มขึ้นเนื่องจากมีการโหลดเนื้อหาล่วงหน้ามากขึ้นเรื่อยๆ

อย่างไรก็ตาม ฉันเห็นว่าในการโหลดหน้าถัดไป พนักงานบริการพบเนื้อหาส่วนใหญ่ ซึ่งช่วยลดน้ำหนักของหน้าได้ประมาณครึ่งหนึ่ง:

ไซต์ Pinterest เป็นเว็บแอปแบบโปรเกรสซีฟ มันติดตั้งพนักงานบริการเพื่อจัดการแคชของ CSS และ JS ด้วยตนเอง ตอนนี้ฉันสามารถปิด WiFi และใช้ไซต์ต่อไปได้ (แม้ว่าจะไม่ค่อยมีประโยชน์):

เคล็ดลับประสิทธิภาพ #12: ใช้พนักงานบริการเพื่อให้การสนับสนุนออฟไลน์

คงจะดีไม่น้อยหากฉันต้องโหลดเว็บไซต์เพียงครั้งเดียวผ่านเครือข่าย และรับข้อมูลทั้งหมดที่ฉันต้องการแม้ว่าฉันจะออฟไลน์อยู่

ตัวอย่างที่ดีคือเว็บไซต์ที่แสดงการพยากรณ์อากาศสำหรับสัปดาห์ ฉันควรดาวน์โหลดหน้านั้นเพียงครั้งเดียวเท่านั้น หากฉันปิดข้อมูลมือถือและกลับไปที่หน้าในภายหลัง จะสามารถให้บริการเนื้อหาที่รู้จักล่าสุดแก่ฉันได้ หากฉันเชื่อมต่ออินเทอร์เน็ตอีกครั้งและโหลดหน้าเว็บ ฉันจะได้รับการคาดการณ์ที่เป็นปัจจุบันมากขึ้น แต่ควรยังคงให้บริการเนื้อหาแบบคงที่ เช่น CSS และรูปภาพจากพนักงานบริการในเครื่อง

ซึ่งทำได้โดยการตั้งค่าพนักงานบริการด้วยกลยุทธ์การแคชที่ดี เพื่อให้สามารถเข้าถึงหน้าที่แคชได้อีกครั้งแบบออฟไลน์ เว็บไซต์เอกสาร lodash เป็นตัวอย่างที่ดีของพนักงานบริการในป่า:

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

พนักงานบริการสามารถประหยัดเวลาของคุณได้อย่างแท้จริงเมื่อคุณมีงบประมาณข้อมูลที่จำกัด ฉันไม่เชื่อว่าประสบการณ์การใช้งาน Pinterest นั้นเหมาะสมที่สุดในแง่ของการใช้ข้อมูล – หน้าต่อมามีขนาดประมาณ 0.5 MB แม้กระทั่งบนหน้าที่มีภาพไม่กี่ภาพ — แต่ให้ JavaScript ของคุณจัดการคำขอหน้าสำหรับคุณและรักษาองค์ประกอบการนำทางที่เหมือนกันไว้ สามารถมีประสิทธิภาพมาก BBC จัดการขนาดการถ่ายโอนเพียง 3.1 KB สำหรับการกลับมาเยี่ยมชมบทความที่แสดงผลได้ผ่านแอปพลิเคชันหน้าเดียว

จนถึงตอนนี้ Pinterest เพียงอย่างเดียวได้ใช้งบประมาณไปแล้ว 14 MB ซึ่งหมายความว่าฉันได้ใช้งบประมาณไปประมาณ 30 MB หรือ 2.20 ดอลลาร์ (ค่าจ้างเกือบต่อวัน) ของงบประมาณซิมบับเวของฉัน

ฉันควรระวัง 20 MB สุดท้ายของฉัน… แต่มันจะสนุกตรงไหน?

Gamespot

ฉันเลือกอันนี้เพราะรู้สึกว่ามันอืดมากบนมือถือของฉันในอดีต และฉันต้องการค้นหาเหตุผลว่าทำไม แน่นอนว่าการโหลดหน้าแรกใช้ข้อมูล 8.5 MB

6.5 MB ของวิดีโอนี้เหลือเพียงวิดีโอที่เล่นอัตโนมัติครึ่งหน้า ซึ่ง - พูดตามตรง - ดูเหมือนจะไม่ดาวน์โหลดจนกว่าฉันจะเริ่มเลื่อนดู แต่ถึงอย่างไร…

ฉันสามารถดูวิดีโอในวิวพอร์ตได้เพียงครึ่งเดียว — ด้านขวามือถูกตัด มันมีความยาว 30 วินาทีเช่นกัน และฉันก็พนันได้เลยว่าคนส่วนใหญ่จะไม่นั่งดูจนจบ เนื้อหาเดียวนี้เพิ่มขนาดของหน้ามากกว่าสามเท่า

เคล็ดลับประสิทธิภาพ #13: อย่าโหลดวิดีโอล่วงหน้า

ตามกฎแล้ว ห้ามโหลดล่วงหน้าเว้นแต่โหมดการสื่อสารหลักของไซต์ของคุณคือวิดีโอ

หากคุณเป็น YouTube หรือ Netflix ถือว่ามีเหตุผลที่จะมีผู้มาที่หน้าเว็บของคุณต้องการให้วิดีโอโหลดอัตโนมัติและเล่นอัตโนมัติ มีความคาดหวังว่าวิดีโอจะเคี้ยวข้อมูลบางส่วน แต่เป็นการแลกเปลี่ยนเนื้อหาที่ยุติธรรม แต่ถ้าคุณเป็นไซต์ที่มีสื่อหลักเป็นข้อความและรูปภาพ — และคุณเพิ่งเสนอเนื้อหาวิดีโอเพิ่มเติม — อย่าโหลดวิดีโอล่วงหน้า

นึกถึงบทความข่าวที่มีวิดีโอแบบฝัง ผู้ใช้หลายคนต้องการเพียงแค่อ่านพาดหัวบทความก่อนจะไปยังสิ่งต่อไป คนอื่นจะอ่านบทความแต่ละเว้นการฝังใดๆ และคนอื่นๆ จะขยันคลิกและดูวิดีโอที่ฝังไว้แต่ละรายการ เราไม่ควรจำกัดแบนด์วิดท์ของผู้ใช้ทุกคนโดย สันนิษฐาน ว่าพวกเขาต้องการดูวิดีโอเหล่านี้

ย้ำ: ผู้ใช้ไม่ชอบเล่นวิดีโออัตโนมัติ ในฐานะนักพัฒนา เราทำเพียงเพราะผู้จัดการของเราบอกให้เราทำ และพวกเขาแค่บอกให้เราทำเพราะแอปที่เจ๋งที่สุดกำลังทำอยู่ และแอปที่เจ๋งที่สุดก็ทำเพราะโฆษณาวิดีโอสร้างรายได้มากกว่าแบบดั้งเดิม 20 ถึง 50 เท่า โฆษณา Google Chrome ได้เริ่มบล็อกวิดีโอที่เล่นอัตโนมัติสำหรับบางไซต์ โดยขึ้นอยู่กับความชอบส่วนบุคคล ดังนั้นแม้ว่าคุณจะพัฒนาไซต์ของคุณให้เล่นวิดีโออัตโนมัติ ก็ไม่รับประกันว่าผู้ใช้ของคุณจะได้รับประสบการณ์นั้น

หากเราเห็นด้วยว่าเป็นความคิดที่ดีที่จะทำให้วิดีโอเป็นประสบการณ์ที่เลือกใช้ (คลิกเพื่อเล่น) เราสามารถก้าวไปอีกขั้นและทำให้วิดีโอคลิกเพื่อโหลดได้เช่นกัน นั่นหมายถึงการเยาะเย้ยภาพตัวแทนของวิดีโอด้วยปุ่มเล่นและดาวน์โหลดเฉพาะวิดีโอเมื่อคุณคลิกปุ่มเล่น People on fast connections should notice no difference in buffer speed, and people on slow connections will appreciate how fast the rest of your site loaded because it didn't have to preload a large video file.

Anyway, back to Gamespot, where I was indeed forced to preload a large video file I ended up not watching. I then clicked through to a game review page that weighed another 8.5 MB, this time with 5.4 MB of video, before I even started scrolling down the page.

What was really galling was when I looked at what the video actually was. It was an advert for a Samsung TV! This advert cost me $0.40 of my Zimbabwe wages. Not only was it pre-loaded, but it also didn't end up playing anywhere as far as I'm aware, so I never actually saw it.

The 'real' video — the gameplay footage (in other words, the content) — wasn't actually loaded until I clicked on it. And that ploughed through my remaining data in seconds.

แค่นั้นแหละ. That's my 50 MB gone. I'll need to work another 1.5 days as a Zimbabwean schoolteacher to repeat the experience.

Performance Tip #14: Optimize For First Page Load

What's striking is that I used 50 MB of data and in most cases, I only visited one or two pages on any given site. If you think about it, this is true of most user journeys today.

Think about the last time you Googled something. You no doubt clicked on the first search result. If you got your answer, you closed the tab, or else you hit the back button and moved onto the next search result.

With the exception of a few so-called 'destination sites' such as Facebook or YouTube, where users habitually go as a starting point for other activities, the majority of user journeys are ephemeral. We stumble across random sites to get the answers to our questions, never to return to those sites again.

Web development practices are heavily skewed towards optimising for repeat visitors. “Cache these assets — they'll come in handy later”. “Pre-load this onward journey, in case the user clicks to read more”. “Subscribe to our mailing list”.

Instead, I believe we should optimize heavily for one-off visitors. Call it a controversial opinion, but maybe caching isn't really all that important. How important can a cached resource that never gets surfaced again be ? And perhaps users aren't actually going to subscribe to your mailing list after reading just the one article, so downloading the JavaScript and CSS for the mail subscription modal is both a waste of data and an annoying user experience.

The Decline Of Proxy Browsers

I had hoped to try out Opera Mini as part of this experiment. Opera Mini is a mobile web browser which proxies web pages through Opera's compression servers. It accounts for 1.42% of global traffic as of June 2019, according to caniuse.com.

Opera Mini claims to save up to 90% of data by doing some pretty intensive transcoding. HTML is parsed, images are compressed, styling is applied, and a certain amount of JavaScript is executed on Opera's servers. The server doesn't respond with HTML as you might expect — it actually transcodes the data into Opera Binary Markup Language (OBML), which is progressively loaded by Opera Mini on the device. It renders what is essentially an interactive 'snapshot' of the web page — think of it as a PDF with hyperlinks inside it. Read Tiffany Brown's excellent article, “Opera Mini and JavaScript” for a technical deep-dive.

It would have been a perfect way to eek my 50 MB budget as far as possible. Unfortunately, Opera Mini is no longer available on iOS in the UK. Attempting to visit it in the app store throws an error:

It's still available “in some markets” but reading between the lines, Opera will be phasing out Opera Mini for its new app — Opera Touch — which doesn't have any data-saving functionality apart from the ability to natively block ads.

Opera desktop used to have a 'Turbo mode', acting as a traditional proxy server (returning a HTML document instead of OBML), applying data-saving techniques but less intensively than Opera Mini. According to Opera, JavaScript continues to work and “you get all the videos, photos and text that you normally would, but you eat up less data and load pages faster”. However, Opera quietly removed Turbo mode in v60 earlier this year, and Opera Touch doesn't have a Turbo mode either. Turbo mode is currently only available on Opera for Android.

Android is where all the action is in terms of data-saving technology. Chrome offers a 'Lite mode' on its mobile browser for Android, which is not available for iPhones or iPads because of “platform constraints“. Outside of mobile, Google used to provide a 'Data Saver' extension for Chrome desktop, but this was canned in April.

Lite mode for Chrome Android can be forcibly enabled, or automatically kicks in when the network's effective connection type is 2G or worse, or when Chrome estimates the page will take more than 5 seconds to reach first contentful paint. Under these conditions, Chrome will request the lite version of the HTTPS URL as cached by Google's servers, and display this stripped-down version inside the user's browser, alongside a “Lite” marker in the address bar.

I'd love to try it out — apparently it disables scripts, replaces images with placeholders, prevents loading of non-critical resources and shows offline copies of pages if one is available on the device. This saves up to 60% of data. However, it isn't available in private (Incognito) mode, which hints at some of the privacy concerns surrounding proxy browsers.

โหมด Lite แชร์ HTTPS URL กับ Google ดังนั้นจึงสมเหตุสมผลที่โหมดนี้ไม่พร้อมใช้งานในโหมดไม่ระบุตัวตน อย่างไรก็ตาม ข้อมูลอื่นๆ เช่น คุกกี้ ข้อมูลการเข้าสู่ระบบ และเนื้อหาของหน้าส่วนบุคคลจะ ไม่ ถูกแชร์กับ Google — ตาม ghacks.net — และ “ไม่เคยทำลายการเชื่อมต่อที่ปลอดภัยระหว่าง Chrome และเว็บไซต์” มีคนสงสัยว่าเหตุใดจึงไม่มีบริการบันทึกข้อมูลเหล่านี้ได้รับอนุญาตบน iOS (และไม่มีข่าวว่าโหมด Lite จะพร้อมใช้งานบน iOS หรือไม่)

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

ฉันไม่พบเครื่องมือบันทึกข้อมูลที่เข้ากันได้กับ OSX หรือ iOS ยกเว้น Bandwidth Hero สำหรับ Firefox (ซึ่งต้องมีการตั้งค่าบริการบีบอัดข้อมูลของคุณเอง — ไกลเกินกว่าความสามารถทางเทคนิคของผู้ใช้ส่วนใหญ่!) และ skyZIP Proxy (ซึ่งอัปเดตล่าสุดใน ปี 2017 และพิมพ์ผิดเยอะมาก ฉันไม่สามารถวางใจได้)

บทสรุป

การลดปริมาณข้อมูลของเว็บไซต์ของคุณไปพร้อมกับการปรับปรุงประสิทธิภาพของส่วนหน้า เป็นสิ่งเดียวที่น่าเชื่อถือที่สุดที่คุณสามารถทำได้เพื่อเพิ่มความเร็วไซต์ของคุณ

นอกจากค่าใช้จ่ายของข้อมูลแล้ว มีเหตุผลดีๆ มากมายที่จะมุ่งเน้นที่ประสิทธิภาพ ดังที่อธิบายไว้ในบล็อกโพสต์ของ GOV.UK ในหัวข้อ:

• 53% ของผู้ใช้จะละทิ้งไซต์บนมือถือหากใช้เวลาในการโหลดนานกว่า 3 วินาที
• ผู้คนต้องมีสมาธิมากขึ้น 50% เมื่อพยายามทำงานง่ายๆ บนเว็บไซต์โดยใช้การเชื่อมต่อที่ช้า
• หน้าเว็บที่มีประสิทธิภาพมากขึ้นจะช่วยยืดอายุการใช้งานแบตเตอรี่ของอุปกรณ์ของผู้ใช้ และโดยทั่วไปแล้วจะใช้พลังงานน้อยกว่าบนเซิร์ฟเวอร์เพื่อส่งมอบ ไซต์ที่มีประสิทธิภาพดีต่อสิ่งแวดล้อม

เราไม่มีอำนาจในการเปลี่ยนแปลงต้นทุนความไม่เท่าเทียมกันของข้อมูลทั่วโลก แต่เรามีอำนาจในการลดผลกระทบ ปรับปรุงประสบการณ์สำหรับทุกคนในกระบวนการ