ส่วนหัวคำขอคำแนะนำไคลเอ็นต์ Save-Data
รายการ
ซึ่งใช้ได้ในเบราว์เซอร์ Chrome, Opera และ Yandex ช่วยให้นักพัฒนาซอฟต์แวร์สามารถนำเสนอแอปพลิเคชันที่ใช้ทรัพยากรน้อยลงและรวดเร็วขึ้นให้แก่ผู้ใช้ที่เลือกใช้โหมดประหยัดข้อมูลในเบราว์เซอร์ของตน
ความต้องการด้านหน้าขนาดเล็ก
ทุกคนเห็นด้วยว่าหน้าเว็บที่เร็วและใช้ทรัพยากรน้อยลงช่วยให้ผู้ใช้ได้รับประสบการณ์การใช้งานที่น่าพึงพอใจมากขึ้น เข้าใจและเก็บรักษาข้อมูลได้ดีขึ้น รวมถึงช่วยเพิ่ม Conversion และรายได้เพิ่มขึ้น การวิจัยของ Google แสดงให้เห็นว่า"... หน้าเว็บที่เพิ่มประสิทธิภาพโหลดได้เร็วกว่าหน้าเว็บแบบเดิม 4 เท่า และใช้ไบต์ลดลง 80% เนื่องจากหน้าเว็บเหล่านี้โหลดเร็วกว่ามาก เราจึงพบว่ามีการเข้าชมหน้าเว็บเหล่านี้เพิ่มขึ้น 50% ด้วย"
และแม้ว่าจำนวนการเชื่อมต่อ 2G ในที่สุดก็ลดลง แต่ 2G ยังยังเป็นเทคโนโลยีเครือข่ายยอดนิยมในปี 2015 ความแพร่หลายและความพร้อมใช้งานของเครือข่าย 3G และ 4G เพิ่มขึ้นอย่างรวดเร็ว แต่ต้นทุนการเป็นเจ้าของที่เกี่ยวข้องและข้อจำกัดของเครือข่ายยังคงเป็นปัจจัยสำคัญสำหรับผู้ใช้หลายร้อยล้านราย
ซึ่งเป็นอาร์กิวเมนต์ที่สำคัญสำหรับการเพิ่มประสิทธิภาพหน้าเว็บ
นอกจากนี้ยังมีวิธีอื่นๆ ในการปรับปรุงความเร็วของเว็บไซต์โดยไม่ต้องอาศัยการมีส่วนร่วมจากนักพัฒนาซอฟต์แวร์โดยตรง เช่น เบราว์เซอร์พร็อกซีและบริการแปลงข้อมูล แม้ว่าบริการดังกล่าวจะเป็นที่นิยมใช้กันมาก แต่ก็มีข้อเสียอย่างมาก เช่น การบีบอัดรูปภาพและข้อความที่เรียบง่าย (และบางครั้งก็ยอมรับไม่ได้) ไม่สามารถดำเนินการกับหน้าที่ปลอดภัย (HTTPS) ได้ การเพิ่มประสิทธิภาพเฉพาะหน้าเว็บที่เข้าชมผ่านผลการค้นหา และอื่น ๆ อีกมากมาย ความนิยมของบริการเหล่านี้เป็นตัวบ่งชี้ว่านักพัฒนาซอฟต์แวร์เว็บไม่สามารถตอบสนองความต้องการของผู้ใช้ที่สูงสำหรับแอปพลิเคชันและหน้าเว็บที่เร็วและใช้น้อย แต่การบรรลุเป้าหมายนั้นก็เป็นเส้นทางที่ซับซ้อน และบางครั้งก็ยาก
ส่วนหัวของคำขอ Save-Data
เทคนิคที่ค่อนข้างตรงไปตรงมาคือการให้เบราว์เซอร์ช่วยโดยใช้ส่วนหัวของคำขอ Save-Data
เมื่อระบุส่วนหัวนี้ หน้าเว็บสามารถปรับแต่งและมอบประสบการณ์การใช้งานที่มีการเพิ่มประสิทธิภาพแก่ผู้ใช้ที่มีข้อจำกัดด้านต้นทุนและประสิทธิภาพ
เบราว์เซอร์ที่รองรับ (ด้านล่าง) ช่วยให้ผู้ใช้เปิดใช้โหมด *ประหยัดอินเทอร์เน็ต ซึ่งให้สิทธิ์เบราว์เซอร์ในการใช้ชุดการเพิ่มประสิทธิภาพเพื่อลดปริมาณข้อมูลที่ต้องใช้ในการแสดงผลหน้าเว็บ เมื่อฟีเจอร์นี้มีการแสดงหรือแสดงโฆษณา เบราว์เซอร์อาจขอรูปภาพที่มีความละเอียดต่ำลง เลื่อนการโหลดทรัพยากรบางอย่างออกไป หรือกำหนดเส้นทางคำขอผ่านบริการที่ใช้การเพิ่มประสิทธิภาพเฉพาะเนื้อหาอื่นๆ เช่น การบีบอัดทรัพยากรรูปภาพและข้อความ
การสนับสนุนเบราว์เซอร์
- Chrome 49+ จะโฆษณา
Save-Data
เมื่อผู้ใช้เปิดใช้ตัวเลือก "โปรแกรมประหยัดอินเทอร์เน็ต" บนอุปกรณ์เคลื่อนที่ หรือส่วนขยาย "โปรแกรมประหยัดอินเทอร์เน็ต" บนเบราว์เซอร์ในเดสก์ท็อป - Opera 35+ จะโฆษณา
Save-Data
เมื่อผู้ใช้เปิดใช้โหมด "Opera Turbo" บนเดสก์ท็อป หรือตัวเลือก "การประหยัดอินเทอร์เน็ต" บนเบราว์เซอร์ Android - Yandex 16.2+ จะโฆษณา
Save-Data
เมื่อมีการเปิดใช้โหมด Turbo บนเดสก์ท็อปหรือเบราว์เซอร์ ในอุปกรณ์เคลื่อนที่
กำลังตรวจหาการตั้งค่า Save-Data
แอปพลิเคชันสามารถตรวจสอบส่วนหัวของคำขอคำแนะนำไคลเอ็นต์ Save-Data
เพื่อกำหนดว่าจะมอบประสบการณ์การใช้งาน "ระดับเบา" แก่ผู้ใช้เมื่อใด ส่วนหัวของคำขอนี้แสดงถึงความต้องการปริมาณการใช้อินเทอร์เน็ตที่ไคลเอ็นต์ต้องการเนื่องจากมีค่าใช้จ่ายในการโอนสูง ความเร็วในการเชื่อมต่อต่ำ หรือสาเหตุอื่นๆ
เมื่อผู้ใช้เปิดใช้โหมดประหยัดข้อมูลในเบราว์เซอร์ เบราว์เซอร์จะเพิ่มส่วนหัวของคำขอ Save-Data
ต่อท้ายคำขอขาออกทั้งหมด (ทั้ง HTTP และ HTTPS)
ระหว่างการเขียนนี้ เบราว์เซอร์จะโฆษณาโทเค็น *on- 1 รายการเท่านั้นในส่วนหัว (Save-Data: on
) แต่อาจขยายระยะเวลานี้ในอนาคตเพื่อระบุค่ากำหนดอื่นๆ ของผู้ใช้
นอกจากนี้ ยังอาจตรวจสอบได้ว่า Save-Data
เปิดอยู่ใน JavaScript หรือไม่ โดยทำดังนี้
if ('connection' in navigator) {
if (navigator.connection.saveData === true) {
// Implement data saving operations here.
}
}
การตรวจหาการมีอยู่ของออบเจ็กต์ connection
ภายในออบเจ็กต์ navigator
เป็นสิ่งสำคัญ เนื่องจากออบเจ็กต์ดังกล่าวแสดงถึง Network Information API ซึ่งใช้ในเบราว์เซอร์อินเทอร์เน็ตของ Chrome, Chrome สำหรับ Android และ Samsung เท่านั้น ในส่วนนี้ คุณเพียงแค่ต้องตรวจสอบว่า navigator.connection.saveData
เท่ากับ true
หรือไม่ และนำการดำเนินการบันทึกข้อมูลไปใช้ในเงื่อนไขดังกล่าวได้
หากแอปพลิเคชันของคุณใช้ Service Worker ก็จะตรวจสอบส่วนหัวของคำขอและใช้ตรรกะที่เกี่ยวข้องเพื่อเพิ่มประสิทธิภาพการใช้งานได้
อีกทางเลือกหนึ่งคือ เซิร์ฟเวอร์มองหาค่ากำหนดที่โฆษณาในส่วนหัวของคำขอ Save-Data
แล้วส่งกลับคำตอบอื่น เช่น มาร์กอัปที่ต่างกัน รูปภาพและวิดีโอที่เล็กลง และอื่นๆ
เคล็ดลับการใช้งานและแนวทางปฏิบัติแนะนำ
- เมื่อใช้
Save-Data
ให้จัดเตรียมอุปกรณ์ UI บางอย่างที่รองรับและอนุญาตให้ผู้ใช้สลับระหว่างประสบการณ์ต่างๆ ได้โดยง่าย เช่น- แจ้งให้ผู้ใช้ทราบว่า
Save-Data
ได้รับการรองรับและสนับสนุนให้ใช้ - ให้ผู้ใช้ระบุและเลือกโหมดที่มีข้อความแจ้งที่เหมาะสม รวมถึงปุ่มเปิด/ปิดหรือช่องทำเครื่องหมายที่ใช้งานง่าย
- เมื่อเลือกโหมดประหยัดอินเทอร์เน็ต ให้ประกาศและมอบวิธีที่ง่ายและชัดเจนในการปิดใช้โหมดและเปลี่ยนกลับไปใช้เวอร์ชันเต็มหากต้องการ
- แจ้งให้ผู้ใช้ทราบว่า
- อย่าลืมว่าแอปพลิเคชันที่ใช้ทรัพยากรน้อยไม่ได้มีความสำคัญน้อยกว่า แต่ไม่ได้ละเลยฟังก์ชันการทำงานหรือข้อมูลสำคัญ เพียงแต่เข้าใจต้นทุนที่เกี่ยวข้องและประสบการณ์ของผู้ใช้มากกว่า เช่น
- แอปพลิเคชันแกลเลอรีรูปภาพอาจแสดงตัวอย่างที่มีความละเอียดต่ำลงหรือใช้กลไกภาพสไลด์ที่เน้นโค้ดน้อยกว่า
- แอปพลิเคชันการค้นหาอาจแสดงผลลัพธ์น้อยลงในแต่ละครั้ง จำกัดจำนวนผลการค้นหาที่ใช้สื่อจำนวนมาก หรือลดจำนวนทรัพยากร Dependency ที่ต้องใช้ในการแสดงผลหน้าเว็บ
- เว็บไซต์ที่มุ่งเน้นข่าวอาจแสดงเรื่องราวน้อยลง ละเว้นหมวดหมู่ที่ไม่ค่อยได้รับความนิยม หรือแสดงตัวอย่างสื่อที่มีขนาดเล็กกว่า
- ระบุตรรกะของเซิร์ฟเวอร์เพื่อตรวจสอบส่วนหัวของคำขอ
Save-Data
และพิจารณาระบุการตอบกลับของหน้าเว็บทางเลือกที่ใช้ทรัพยากรน้อยลงเมื่อเปิดใช้ เช่น ลดจำนวนทรัพยากรและทรัพยากร Dependency ที่จำเป็น ใช้การบีบอัดทรัพยากรที่เข้มงวดขึ้น ฯลฯ- หากคุณแสดงการตอบกลับทางเลือกตามส่วนหัว
Save-Data
อย่าลืมเพิ่มการตอบกลับดังกล่าวลงในรายการ Vary ซึ่งก็คือVary: Save-Data
เพื่อบอกแคชอัปสตรีมว่าควรแคชและแสดงเวอร์ชันนี้ก็ต่อเมื่อส่วนหัวของคำขอSave-Data
มีอยู่เท่านั้น ดูรายละเอียดเพิ่มเติมได้ในแนวทางปฏิบัติแนะนำสำหรับการโต้ตอบกับแคช
- หากคุณแสดงการตอบกลับทางเลือกตามส่วนหัว
- หากคุณใช้ Service Worker แอปพลิเคชันจะตรวจหาเวลาที่เปิดใช้ตัวเลือกการบันทึกข้อมูลได้โดยตรวจสอบว่ามีส่วนหัวของคำขอ
Save-Data
หรือไม่ หรือตรวจสอบค่าของพร็อพเพอร์ตี้navigator.connection.saveData
หากเปิดใช้ ให้พิจารณาว่าคุณจะเขียนคำขอใหม่เพื่อดึงข้อมูลไบต์น้อยลงหรือใช้การตอบกลับที่ดึงข้อมูลแล้วได้ - ลองเพิ่ม
Save-Data
ด้วยสัญญาณอื่นๆ เช่น ข้อมูลเกี่ยวกับประเภทการเชื่อมต่อและเทคโนโลยีของผู้ใช้ (ดู NetInfo API) ตัวอย่างเช่น คุณอาจต้องการมอบประสบการณ์การใช้งานแบบง่ายๆ แก่ผู้ใช้ที่ใช้การเชื่อมต่อ 2G แม้ว่าจะไม่ได้เปิดใช้Save-Data
ก็ตาม ในทางกลับกัน เพียงเพราะผู้ใช้ใช้การเชื่อมต่อ 4G ที่ "เร็ว" ไม่ได้หมายความว่าผู้ใช้ไม่สนใจจะประหยัดอินเทอร์เน็ต เช่น เมื่อใช้โรมมิ่ง นอกจากนี้ คุณอาจเพิ่มการแสดงของSave-Data
ด้วยคำแนะนำไคลเอ็นต์Device-Memory
เพื่อปรับให้เข้ากับผู้ใช้ในอุปกรณ์ที่มีหน่วยความจำจำกัดมากขึ้น หน่วยความจำอุปกรณ์ของผู้ใช้จะมีโฆษณาอยู่ใน คำแนะนำไคลเอ็นต์ของnavigator.deviceMemory
ด้วย
Recipes
สิ่งที่คุณจะได้รับผ่าน Save-Data
จำกัดอยู่ที่สิ่งที่คุณคิดได้เท่านั้น ลองดูกรณีการใช้งาน 2-3 กรณีการใช้งานเพื่อให้เห็นภาพว่าทำอะไรได้บ้าง เมื่ออ่านแล้ว คุณอาจพบกับกรณีการใช้งานอื่นๆ ของตัวเอง
ดังนั้นโปรดลองทดสอบและดูว่าใช้อะไรได้บ้าง
กำลังตรวจสอบ Save-Data
ในโค้ดฝั่งเซิร์ฟเวอร์
แม้ว่าสถานะ Save-Data
จะเป็นสิ่งที่คุณสามารถตรวจจับใน JavaScript ผ่านพร็อพเพอร์ตี้ navigator.connection.saveData
ได้ แต่ในบางครั้งก็เป็นวิธีที่ดีกว่า JavaScript อาจล้มเหลวในการดำเนินการได้ในบางกรณี นอกจากนี้ การตรวจหาฝั่งเซิร์ฟเวอร์เป็นวิธีเดียวในการแก้ไขมาร์กอัปก่อนที่ส่งไปยังไคลเอ็นต์ ซึ่งเกี่ยวข้องกับ Use Case ที่มีประโยชน์ที่สุดบางกรณีของ Save-Data
ไวยากรณ์เฉพาะสำหรับการตรวจหาส่วนหัว Save-Data
ในโค้ดฝั่งเซิร์ฟเวอร์จะขึ้นอยู่กับภาษาที่ใช้ แต่แนวคิดพื้นฐานควรเหมือนกันสำหรับระบบแบ็กเอนด์ของแอปพลิเคชัน เช่น ใน PHP ส่วนหัวของคำขอจะจัดเก็บใน $_SERVER
Superglobalarray ที่ดัชนีซึ่งขึ้นต้นด้วย HTTP_
ซึ่งหมายความว่าคุณจะตรวจหาส่วนหัว Save-Data
ได้โดยตรวจสอบการมีอยู่และค่าของตัวแปร $_SERVER["HTTP_SAVE_DATA"]
ดังนี้
// false by default.
$saveData = false;
// Check if the `Save-Data` header exists and is set to a value of "on".
if (isset($_SERVER["HTTP_SAVE_DATA"]) && strtolower($_SERVER["HTTP_SAVE_DATA"]) === "on") {
// `Save-Data` detected!
$saveData = true;
}
หากคุณใส่การตรวจสอบนี้ก่อนที่จะส่งมาร์กอัปไปยังไคลเอ็นต์ ตัวแปร $saveData
จะมีสถานะ Save-Data
และพร้อมใช้งานทุกที่ในหน้าเว็บ หลังจากได้เห็นกลไกนี้แล้ว เรามาดูตัวอย่างวิธีที่เราใช้จำกัดปริมาณข้อมูลที่เราส่งไปยังผู้ใช้กัน
แสดงรูปภาพความละเอียดต่ำสำหรับหน้าจอความละเอียดสูง
กรณีการใช้งานทั่วไปสำหรับรูปภาพบนเว็บคือการแสดงรูปภาพเป็นชุด 2 รูป ได้แก่ รูปภาพ 1 รูปสำหรับหน้าจอ "มาตรฐาน" (1x) และอีกรูปหนึ่งที่มีขนาดใหญ่เป็น 2 เท่า (2 เท่า) สำหรับหน้าจอความละเอียดสูง (เช่น จอแสดงผลแบบเรตินา) หน้าจอความละเอียดสูงระดับนี้ไม่ได้จำกัดอยู่แค่อุปกรณ์ระดับไฮเอนด์เสมอไป และได้รับความนิยมมากขึ้นเรื่อยๆ ในกรณีที่แนะนำให้ใช้แอปพลิเคชันขนาดเล็กกว่า การส่งรูปภาพที่มีความละเอียดต่ำ (1 เท่า) ไปยังหน้าจอเหล่านี้แทนที่จะส่งรูปแบบขนาดใหญ่กว่า (2 เท่า) ในการดำเนินการเมื่อมีส่วนหัว Save-Data
เราเพียงแค่แก้ไขมาร์กอัปที่เราส่งไปยังไคลเอ็นต์ ดังนี้
if ($saveData === true) {
// Send a low-resolution version of the image for clients specifying `Save-Data`.
?><img src="butterfly-1x.jpg" alt="A butterfly perched on a flower."><?php
}
else {
// Send the usual assets for everyone else.
?><img src="butterfly-1x.jpg" srcset="butterfly-2x.jpg 2x, butterfly-1x.jpg 1x" alt="A butterfly perched on a flower."><?php
}
กรณีการใช้งานนี้เป็นตัวอย่างที่ยอดเยี่ยมที่แสดงให้เห็นถึงความพยายามเพียงเล็กน้อยในการอำนวยความสะดวกให้กับผู้ที่ขอให้คุณส่งข้อมูลน้อยลง หากไม่ชอบการแก้ไขมาร์กอัปที่แบ็กเอนด์ คุณก็อาจได้รับผลลัพธ์เดียวกันโดยใช้โมดูลการเขียน URL ใหม่ เช่น Apache's mod_rewrite
ซึ่งมีตัวอย่างวิธีบรรลุเป้าหมายนี้โดยที่มีการกำหนดค่าเพียงเล็กน้อย
คุณยังสามารถขยายแนวคิดนี้ไปยังพร็อพเพอร์ตี้ background-image
ของ CSS ได้โดยการเพิ่มคลาสลงในองค์ประกอบ <html>
ดังนี้
<html class="<?php if ($saveData === true): ?>save-data<?php endif; ?>">
จากที่นี่ คุณกำหนดเป้าหมายคลาส save-data
บนองค์ประกอบ <html>
ใน CSS เพื่อเปลี่ยนวิธีนำส่งรูปภาพได้ คุณสามารถส่งภาพพื้นหลังความละเอียดต่ำไปยังหน้าจอความละเอียดสูงตามที่แสดงในตัวอย่าง HTML ด้านบน หรือไม่ก็เลือกข้ามทรัพยากรบางส่วนไปเลยก็ได้
ละเว้นรูปภาพที่ไม่จำเป็น
เนื้อหารูปภาพบางอย่างในเว็บเป็นเพียงสิ่งไม่จำเป็น แม้ว่าภาพดังกล่าวจะช่วยเสริมเนื้อหาได้ แต่ภาพเหล่านั้นอาจไม่เป็นที่ต้องการสำหรับคนที่พยายามบีบย่อเท่าที่จำเป็นจากแผนข้อมูลแบบจำกัด สำหรับกรณีการใช้งานที่ง่ายที่สุดของ Save-Data
เราสามารถใช้โค้ดตรวจจับ PHP จากก่อนหน้านี้และตัดมาร์กอัปรูปภาพที่ไม่จำเป็นออกไปโดยสิ้นเชิง
<p>This paragraph is essential content. The image below may be humorous, but it's not critical to the content.</p>
<?php
if ($saveData === false) {
// Only send this image if `Save-Data` hasn't been detected.
?><img src="meme.jpg" alt="One does not simply consume data."><?php
}
เทคนิคนี้จะให้ผลชัดเจน ดังที่เห็นในภาพด้านล่าง
แน่นอนว่าการข้ามรูปภาพไม่ใช่ทางเดียวที่ทำได้ นอกจากนี้คุณยังดำเนินการกับ Save-Data
ได้ว่าไม่ต้องส่งทรัพยากรอื่นๆ ที่ไม่สำคัญ เช่น ลักษณะแบบอักษรบางอย่าง
ละเว้นแบบอักษรเว็บที่ไม่จำเป็น
แม้ว่าแบบอักษรของเว็บมักจะไม่สร้างขึ้นมาเกือบเท่าๆ กับเพย์โหลดทั้งหมดของหน้าเว็บหนึ่งๆ แต่ก็ยังได้รับความนิยมอยู่ ไม่ต้องใช้ข้อมูลมากนักด้วย นอกจากนี้ วิธีที่เบราว์เซอร์ดึงข้อมูลและแสดงผลแบบอักษรมีความซับซ้อนกว่าที่คุณคิด ด้วยแนวคิดอย่าง FOIT, FOUT และการเรียนรู้ของเบราว์เซอร์ที่ทำให้การแสดงผลเป็นการดำเนินการที่ซับซ้อน
ซึ่งเหตุผลนั้นก็คือคุณอาจต้องการเลิกใช้แบบอักษรเว็บที่ไม่จำเป็นสำหรับผู้ใช้ที่ต้องการประสบการณ์ที่ง่ายขึ้น Save-Data
ทำให้เรื่องนี้เป็นเรื่อง
ที่ยุ่งยากและสมเหตุสมผล
ตัวอย่างเช่น สมมติว่าคุณใส่ Fira
Sans จาก Google
Fonts ไว้ในไซต์ Fira Sans เป็นแบบอักษรของข้อความเนื้อหา
ที่ยอดเยี่ยม แต่อาจไม่สำคัญมากนักต่อผู้ใช้ที่พยายามบันทึกข้อมูล การเพิ่มคลาสของ save-data
ลงในองค์ประกอบ <html>
เมื่อมีส่วนหัว Save-Data
จะทำให้เราสามารถเขียนรูปแบบที่เรียกใช้แบบอักษรที่ไม่จำเป็นในตอนแรก แต่หลังจากนั้นก็เลือกไม่ใช้ได้เมื่อมีส่วนหัว Save-Data
ดังต่อไปนี้
/* Opt into web fonts by default. */
p,
li {
font-family: 'Fira Sans', 'Arial', sans-serif;
}
/* Opt out of web fonts if the `save-Data` class is present. */
.save-data p,
.save-data li {
font-family: 'Arial', sans-serif;
}
เมื่อใช้วิธีนี้ คุณจะเก็บข้อมูลโค้ด <link>
จาก Google Fonts ไว้แทนได้ เนื่องจากเบราว์เซอร์โหลดทรัพยากร CSS (รวมถึงแบบอักษรเว็บ) แบบคาดเดาไว้ด้วยการใช้รูปแบบกับ DOM ก่อน จากนั้นตรวจสอบว่าองค์ประกอบ HTML เรียกใช้ทรัพยากรในสไตล์ชีตหรือไม่ หากผู้ใช้เปิด Save-Data
ไว้ Fira Sans จะไม่โหลดเนื่องจาก DOM ที่จัดรูปแบบไม่เรียกใช้ Arial จะเข้ามามีบทบาทแทน อาจไม่ดีเท่ากับ Fira Sans
แต่อาจดีกว่าสำหรับผู้ใช้ที่พยายามขยายแพ็กเกจอินเทอร์เน็ต
สรุป
ส่วนหัว Save-Data
ไม่ได้มีความแตกต่างเล็กๆ น้อยๆ มากนัก ทั้งที่เลือกเปิดหรือปิด และแอปพลิเคชันจะรับภาระในการมอบประสบการณ์ที่เหมาะสมตามการตั้งค่าของผู้ใช้ ไม่ว่าจะด้วยเหตุผลใดก็ตาม
ตัวอย่างเช่น ผู้ใช้บางรายอาจไม่อนุญาตให้ใช้โหมดประหยัดอินเทอร์เน็ตหากสงสัยว่าเนื้อหาหรือฟังก์ชันของแอปจะสูญหายไป แม้ในสถานการณ์ที่มีการเชื่อมต่อที่ไม่ดีก็ตาม ในทางกลับกัน ผู้ใช้บางคนอาจเปิดใช้เพื่อจะได้ทำให้หน้าเว็บมีขนาดเล็กและเรียบง่ายที่สุดเท่าที่จะเป็นไปได้ แม้ในสถานการณ์การเชื่อมต่อที่ดีก็ตาม วิธีที่ดีที่สุดคือให้แอปคิดว่าผู้ใช้ต้องการประสบการณ์เต็มรูปแบบที่ไม่มีขีดจำกัด จนกว่าคุณจะมีสัญญาณบอกสถานะที่ชัดเจนผ่านการดำเนินการของผู้ใช้อย่างชัดแจ้ง
ในฐานะเจ้าของเว็บไซต์และนักพัฒนาเว็บ เรามารับผิดชอบต่อการจัดการเนื้อหาของเราเพื่อปรับปรุงประสบการณ์ของผู้ใช้สำหรับผู้ใช้ที่ประหยัดค่าใช้จ่าย
ดูรายละเอียดเพิ่มเติมเกี่ยวกับ Save-Data
และตัวอย่างที่ยอดเยี่ยมที่นำไปใช้ได้จริงได้ที่ช่วยเหลือผู้ใช้Save Data