พิจารณาทั้งเนื้อหา รวมถึงเลย์เอาต์และการออกแบบกราฟิกเมื่อสร้างสำหรับผู้ใช้และอุปกรณ์ที่หลากหลาย
วิธีที่ผู้คนอ่านบนเว็บ
คำแนะนำด้านการเขียนของรัฐบาลสหรัฐอเมริกาสรุปสิ่งที่ผู้คนต้องการจากการเขียนบนเว็บไว้ดังนี้
งานวิจัยแสดงให้เห็นว่าผู้คนไม่ได้อ่านหน้าเว็บ แต่จะสแกน โดยเฉลี่ยแล้ว ผู้คนอ่านเนื้อหาในหน้าเว็บเพียง 20-28% เท่านั้น การอ่านจากหน้าจอจะช้ากว่าการอ่านจากกระดาษมาก ผู้ใช้จะยอมแพ้และออกจากเว็บไซต์หากเข้าถึงและทำความเข้าใจข้อมูลได้ยาก
วิธีเขียนสำหรับอุปกรณ์เคลื่อนที่
มุ่งเน้นที่หัวข้อที่กำลังพูดถึงและเล่าเรื่องราวตั้งแต่ต้น หากต้องการให้การเขียนใช้งานได้ในอุปกรณ์และวิวพอร์ตที่หลากหลาย โปรดตรวจสอบว่าได้ระบุประเด็นหลักไว้ที่ตอนต้น โดยปกติแล้วควรอยู่ใน 4 ย่อหน้าแรกและมีคำประมาณ 70 คำ
ถามตัวเองว่าผู้ใช้ต้องการอะไรจากเว็บไซต์ของคุณ พวกเขากำลังพยายามค้นหาอะไรอยู่ใช่ไหม หากผู้เข้าชมเข้าชมเว็บไซต์เพื่อดูข้อมูล โปรดตรวจสอบว่าข้อความทั้งหมดมุ่งเน้นที่การช่วยให้ผู้เข้าชมบรรลุเป้าหมาย เขียนโดยใช้ประโยคที่ประธานเป็นผู้กระทำกริยาโดยตรง เสนอการดำเนินการและวิธีแก้ปัญหา
เผยแพร่เฉพาะสิ่งที่ผู้เข้าชมต้องการเท่านั้น
การวิจัยของรัฐบาลสหราชอาณาจักรยังแสดงให้เห็นว่า
กล่าวคือ ใช้ภาษาที่เข้าใจง่าย คำที่สั้นลง และโครงสร้างประโยคที่เรียบง่าย แม้แต่สำหรับกลุ่มเป้าหมายที่มีความรู้และมีความเชี่ยวชาญด้านเทคนิค หากไม่มีเหตุผลที่ดีที่จะไม่ทำ ให้ใช้ภาษาที่ใช้ในการสนทนา กฎเก่าแก่ของการเขียนข่าวคือการเขียนราวกับว่าคุณกำลังพูดกับเด็กอายุ 11 ปีที่มีสติปัญญา
ผู้ใช้พันล้านคนต่อไป
การเขียนแบบกระชับมีความสำคัญอย่างยิ่งสำหรับผู้อ่านบนอุปกรณ์เคลื่อนที่ และเป็นสิ่งสำคัญเมื่อสร้างเนื้อหาสำหรับโทรศัพท์ราคาถูกที่มี Viewport ขนาดเล็กซึ่งต้องเลื่อนมากขึ้น รวมถึงอาจมีจอแสดงผลคุณภาพต่ำและหน้าจอที่ตอบสนองน้อยกว่า
ผู้ใช้พันล้านคนต่อไปที่กำลังจะออนไลน์ส่วนใหญ่จะมีอุปกรณ์ราคาถูก ผู้ใช้ไม่ต้องการใช้งบประมาณอินเทอร์เน็ตไปกับการเลื่อนดูเนื้อหาที่ยาวเหยียด และอาจไม่ได้อ่านในภาษาแรกของตนเอง ตัดข้อความ: ใช้ประโยคสั้นๆ เครื่องหมายวรรคตอนให้น้อยที่สุด ย่อหน้าไม่เกิน 5 บรรทัด และหัวเรื่องบรรทัดเดียว พิจารณาใช้ข้อความที่ปรับเปลี่ยนตามพื้นที่โฆษณา (เช่น ใช้พาดหัวที่สั้นลงสำหรับช่องแสดงผลขนาดเล็ก) แต่ระวังข้อเสีย
นอกจากนี้ การใช้ข้อความให้น้อยที่สุดยังช่วยให้แปลและปรับเนื้อหาให้เหมาะกับผู้ชมทั่วโลกได้ง่ายขึ้น รวมถึงเพิ่มโอกาสที่เนื้อหาของคุณจะได้รับการอ้างอิงในโซเชียลมีเดียด้วย
สรุป
- ทำให้เรียบง่าย
- ลดความไม่เป็นระเบียบ
- เข้าประเด็นทันที
นำเนื้อหาที่ไม่จำเป็นออก
ในแง่ของขนาดไบต์ หน้าเว็บมีขนาดใหญ่และมีขนาดใหญ่ขึ้นเรื่อยๆ
เทคนิคการออกแบบที่ปรับเปลี่ยนตามอุปกรณ์ช่วยให้แสดงเนื้อหาที่แตกต่างกันสำหรับวิวพอร์ตขนาดเล็กได้ แต่ควรเริ่มด้วยการเพิ่มประสิทธิภาพข้อความ รูปภาพ และเนื้อหาอื่นๆ เสมอ
ผู้ใช้เว็บมักจะมุ่งเน้นการดำเนินการ "โน้มตัวไปข้างหน้า" เพื่อค้นหาคำตอบสำหรับคำถามที่ตนเองมีอยู่ แทนที่จะเอนหลังเพื่ออ่านหนังสือดีๆ
Jackob Nielsen
ลองถามตัวเองว่าผู้ใช้ต้องการทำอะไรเมื่อเข้าชมเว็บไซต์ของฉัน
คอมโพเนนต์ทุกรายการในหน้าเว็บช่วยให้ผู้ใช้บรรลุเป้าหมายได้หรือไม่
นำองค์ประกอบหน้าเว็บที่ซ้ำซ้อนออก
ไฟล์ HTML มีขนาดเกือบ 70, 000 ไบต์และมีคำขอมากกว่า 9 รายการสำหรับหน้าเว็บโดยเฉลี่ย ตามข้อมูลจาก HTTP Archive
เว็บไซต์ยอดนิยมหลายแห่งใช้องค์ประกอบ HTML หลายพันรายการต่อหน้าเว็บ และโค้ดหลายพันบรรทัด แม้แต่ในอุปกรณ์เคลื่อนที่ ขนาดไฟล์ HTML ที่มากเกินไปอาจไม่ได้ทำให้หน้าเว็บโหลดช้าลง แต่เพย์โหลด HTML ที่มีขนาดใหญ่เป็นสัญญาณว่าเนื้อหาอาจมีขนาดใหญ่เกินไป เนื่องจากไฟล์ .html ที่ใหญ่ขึ้นหมายถึงมีองค์ประกอบมากขึ้น มีเนื้อหาข้อความมากขึ้น หรือทั้ง 2 อย่าง
การลดความซับซ้อนของ HTML จะช่วยลดน้ำหนักหน้าเว็บ ช่วยให้เปิดใช้การแปลและการปรับให้เหมาะกับนานาชาติได้ และทำให้การวางแผนและแก้ไขข้อบกพร่องของการออกแบบที่ปรับเปลี่ยนตามอุปกรณ์ง่ายขึ้น ดูข้อมูลเกี่ยวกับการเขียน HTML ที่มีประสิทธิภาพมากขึ้นได้ที่HTML ที่มีประสิทธิภาพสูง
ทุกขั้นตอนที่คุณให้ผู้ใช้ทำก่อนที่จะได้รับคุณค่าจากแอปจะทำให้คุณเสียผู้ใช้ไป 20%
Gabor Cselle, Twitter
ซึ่งก็เช่นเดียวกับเนื้อหาที่ควรช่วยให้ผู้ใช้ไปยังสิ่งที่ต้องการได้เร็วที่สุด
อย่าเพียงแค่ซ่อนเนื้อหาจากผู้ใช้บนอุปกรณ์เคลื่อนที่ มุ่งเน้นความเท่าเทียมของเนื้อหา เนื่องจากคุณไม่สามารถคาดเดาได้ว่าผู้ใช้บนอุปกรณ์เคลื่อนที่จะไม่พลาดฟีเจอร์ใด หากมีทรัพยากร ให้สร้างเนื้อหาเดียวกันในเวอร์ชันอื่นสำหรับขนาดวิวพอร์ตต่างๆ แม้ว่าจะเป็นเพียงองค์ประกอบหน้าเว็บที่มีลำดับความสำคัญสูงก็ตาม
พิจารณาการจัดการเนื้อหาและเวิร์กโฟลว์: ระบบเดิมส่งผลให้มีเนื้อหาเดิมหรือไม่
ทำให้ข้อความเข้าใจง่าย
เมื่อเว็บเปลี่ยนไปเป็นอุปกรณ์เคลื่อนที่ คุณก็ต้องเปลี่ยนวิธีเขียนด้วย ทำให้เรียบง่าย ลดความยุ่งเหยิง และเข้าประเด็น
นำรูปภาพที่ซ้ำซ้อนออก
รูปภาพอาจสวยงาม สนุกสนาน และให้ข้อมูล แต่ก็ใช้พื้นที่ในหน้าเว็บ เพิ่มน้ำหนักหน้าเว็บ และเพิ่มจำนวนคำขอไฟล์ด้วย เวลาในการตอบสนองจะแย่ลงเมื่อการเชื่อมต่อแย่ลง ซึ่งหมายความว่าการส่งคำขอไฟล์รูปภาพมากเกินไปเป็นปัญหาที่เพิ่มขึ้นเมื่อเว็บเข้าสู่แพลตฟอร์มอุปกรณ์เคลื่อนที่
รูปภาพยังใช้พลังงานด้วย หลังจากหน้าจอแล้ว วิทยุเป็นสิ่งที่ทำให้แบตเตอรี่หมดเร็วเป็นอันดับ 2 คำขอรูปภาพมากขึ้น การใช้คลื่นวิทยุมากขึ้น แบตเตอรี่หมดเร็วขึ้น แม้เพียงแค่การแสดงรูปภาพก็ต้องใช้พลังงาน ซึ่งจะแปรผันตามขนาดและจำนวน ดูรายงานของ Stanford เรื่อง Who Killed My Battery?
หากทำได้ ให้กำจัดรูปภาพออก
ต่อไปนี้คือคำแนะนำบางส่วน
- พิจารณาการออกแบบที่หลีกเลี่ยงการใช้รูปภาพโดยสิ้นเชิง หรือใช้รูปภาพเท่าที่จำเป็น ข้อความอย่างเดียวก็สวยได้ ลองถามตัวเองว่า "ผู้เข้าชมเว็บไซต์ของฉันต้องการทำอะไร รูปภาพช่วยในกระบวนการนั้นไหม"
- ในสมัยก่อน การบันทึกส่วนหัวและข้อความอื่นๆ เป็นกราฟิกเป็นเรื่องปกติ วิธีดังกล่าวไม่ตอบสนองต่อการเปลี่ยนแปลงขนาดวิวพอร์ต และยังเพิ่มน้ำหนักหน้าเว็บและเวลาในการตอบสนองด้วย การใช้ข้อความเป็นกราฟิกยังหมายความว่าเครื่องมือค้นหาจะค้นหาข้อความไม่ได้ และโปรแกรมอ่านหน้าจอและเทคโนโลยีความช่วยเหลืออื่นๆ จะเข้าถึงข้อความไม่ได้ ใช้ข้อความ "จริง" หากเป็นไปได้ เนื่องจากเว็บฟอนต์และ CSS ช่วยให้การจัดรูปแบบข้อความสวยงามได้
- ใช้ CSS แทนรูปภาพสำหรับไล่ระดับสี เงา มุมโค้ง และพื้นผิวพื้นหลัง ซึ่งเป็นฟีเจอร์ที่เบราว์เซอร์ที่ทันสมัยทั้งหมดรองรับ อย่างไรก็ตาม โปรดทราบว่า CSS อาจดีกว่ารูปภาพ แต่ก็ยังอาจมีโทษด้านการประมวลผลและการแสดงผล โดยเฉพาะอย่างยิ่งในอุปกรณ์เคลื่อนที่
- รูปภาพพื้นหลังมักจะใช้งานได้ไม่ดีบนอุปกรณ์เคลื่อนที่ คุณใช้ Media Queries เพื่อหลีกเลี่ยงการใช้ภาพพื้นหลังในวิวพอร์ตขนาดเล็กได้
- หลีกเลี่ยงรูปภาพหน้าจอเริ่มต้น
- ใช้ CSS สำหรับภาพเคลื่อนไหวของ UI
- ทำความรู้จักกับกลีฟ ใช้สัญลักษณ์และไอคอน Unicode แทนรูปภาพ และใช้แบบอักษรบนเว็บหากจำเป็น
- ลองใช้แบบอักษรไอคอน ซึ่งเป็นกราฟิกแบบเวกเตอร์ที่ปรับขนาดได้ไม่จำกัด และดาวน์โหลดชุดรูปภาพทั้งหมดได้ในแบบอักษรเดียว (อย่างไรก็ตาม โปรดคำนึงถึงข้อกังวลเหล่านี้)
- องค์ประกอบ
<canvas>สามารถใช้สร้างรูปภาพใน JavaScript จากเส้น โค้ง ข้อความ และรูปภาพอื่นๆ - รูปภาพ SVG หรือ Data URI แบบอินไลน์จะไม่ลดน้ำหนักหน้าเว็บ แต่จะช่วยลดเวลาในการตอบสนองได้โดยลดจำนวนคำขอทรัพยากร SVG แบบอินไลน์รองรับได้ดีในเบราว์เซอร์บนอุปกรณ์เคลื่อนที่และเดสก์ท็อป และเครื่องมือเพิ่มประสิทธิภาพช่วยลดขนาด SVG ได้อย่างมาก ในทำนองเดียวกัน ระบบก็รองรับ URI ข้อมูลด้วย ทั้ง 2 อย่างสามารถฝังใน CSS ได้
- ลองใช้
<video>แทน GIF แบบเคลื่อนไหว เบราว์เซอร์ทั้งหมดในอุปกรณ์เคลื่อนที่รองรับองค์ประกอบวิดีโอ (ยกเว้น Opera Mini)
ดูข้อมูลเพิ่มเติมได้ที่การเพิ่มประสิทธิภาพรูปภาพและการนำรูปภาพออกและแทนที่
ออกแบบเนื้อหาให้ทำงานได้ดีในวิวพอร์ตขนาดต่างๆ
"สร้างผลิตภัณฑ์ ไม่ใช่สร้างผลิตภัณฑ์ใหม่สำหรับหน้าจอขนาดเล็ก ผลิตภัณฑ์ที่ยอดเยี่ยมสำหรับอุปกรณ์เคลื่อนที่ สร้างขึ้นมา ไม่ใช่พอร์ตมา"
Mobile Design and Development โดย Brian Fling
นักออกแบบที่ยอดเยี่ยมไม่ได้ "เพิ่มประสิทธิภาพสำหรับอุปกรณ์เคลื่อนที่" แต่จะคิดถึงการออกแบบที่ปรับเปลี่ยนตามพื้นที่โฆษณาเป็นหลักเพื่อสร้างเว็บไซต์ที่ทำงานได้ในอุปกรณ์หลากหลายประเภท โครงสร้างของข้อความและเนื้อหาอื่นๆ ในหน้าเว็บเป็นสิ่งสำคัญต่อความสำเร็จแบบข้ามอุปกรณ์
ผู้ใช้พันล้านคนต่อไปที่จะเข้ามาใช้งานบนโลกออนไลน์จำนวนมากใช้อุปกรณ์ราคาถูกที่มีวิวพอร์ตขนาดเล็ก การอ่านบนหน้าจอขนาด 3.5 หรือ 4 นิ้วที่มีความละเอียดต่ำอาจเป็นเรื่องยาก
นี่คือภาพถ่ายของทั้ง 2 คน
ในหน้าจอขนาดใหญ่ ข้อความจะมีขนาดเล็กแต่ยังอ่านได้
ในหน้าจอขนาดเล็ก เบราว์เซอร์จะแสดงเลย์เอาต์อย่างถูกต้อง แต่ข้อความจะอ่านไม่ออกแม้จะซูมเข้าแล้วก็ตาม จอแสดงผลเบลอและมี "สีเปื้อน" กล่าวคือ สีขาวไม่ดูเป็นสีขาว ทำให้เนื้อหาอ่านยาก
ออกแบบเนื้อหาสำหรับอุปกรณ์เคลื่อนที่
เมื่อสร้างสำหรับช่วงขนาดวิวพอร์ต ให้พิจารณาเนื้อหา รวมถึงเลย์เอาต์และการออกแบบกราฟิก ออกแบบโดยใช้ข้อความและรูปภาพจริง ไม่ใช่เนื้อหาตัวยึดตำแหน่ง
"เนื้อหามาก่อนการออกแบบ การออกแบบที่ไม่มีเนื้อหาไม่ใช่การออกแบบ แต่เป็นการตกแต่ง"
Jeffrey Zeldman
- วางเนื้อหาที่สำคัญที่สุดไว้ด้านบน เนื่องจากผู้ใช้มักจะอ่านหน้าเว็บในรูปแบบตัว F
- ผู้ใช้เข้าชมเว็บไซต์ของคุณเพื่อบรรลุเป้าหมาย ถามตัวเองว่าผู้ใช้ต้องการอะไรเพื่อให้บรรลุเป้าหมายนั้น แล้วกำจัดทุกอย่างที่ไม่เกี่ยวข้องออก เข้มงวดกับภาพและข้อความที่ตกแต่ง เนื้อหาเดิม ลิงก์มากเกินไป และสิ่งอื่นๆ ที่รก
- โปรดระมัดระวังในการใช้ไอคอนการแชร์ในโซเชียล เนื่องจากอาจทำให้เลย์เอาต์รก และโค้ดของไอคอนอาจทำให้การโหลดหน้าเว็บช้าลง
- ออกแบบเลย์เอาต์ที่ปรับเปลี่ยนตามอุปกรณ์สำหรับเนื้อหา ไม่ใช่ขนาดอุปกรณ์ที่คงที่
เนื้อหาทดสอบ
- ตรวจสอบความสามารถในการอ่านใน Viewport ขนาดเล็กโดยใช้เครื่องมือสำหรับนักพัฒนาเว็บใน Chrome และเครื่องมือจำลองอื่นๆ
- ทดสอบเนื้อหาในสภาวะที่มีแบนด์วิดท์ต่ำและเวลาในการตอบสนองสูง ลองใช้เนื้อหาในสถานการณ์การเชื่อมต่อที่หลากหลาย
- ลองอ่านและโต้ตอบกับเนื้อหาบนโทรศัพท์ราคาประหยัด
- ขอให้เพื่อนและเพื่อนร่วมงานลองใช้แอปหรือเว็บไซต์ของคุณ
- สร้างห้องทดสอบอุปกรณ์อย่างง่าย ที่เก็บ GitHub สำหรับห้องทดลองอุปกรณ์เคลื่อนที่ขนาดเล็กของ Google มีวิธีการสร้างห้องทดลองของคุณเอง OpenSTF เป็นเว็บแอปพลิเคชันที่ใช้งานง่ายสำหรับการทดสอบเว็บไซต์บนอุปกรณ์ Android หลายเครื่อง
ตัวอย่างการใช้งาน OpenSTF มีดังนี้
ผู้คนใช้อุปกรณ์เคลื่อนที่เพื่อบริโภคเนื้อหาและรับข้อมูลมากขึ้นเรื่อยๆ ไม่ใช่แค่อุปกรณ์สำหรับการสื่อสาร เกม และสื่อ
ด้วยเหตุนี้ การวางแผนเนื้อหาให้ทำงานได้ดีในขนาดวิวพอร์ตต่างๆ จึงมีความสำคัญมากขึ้นเรื่อยๆ และควรจัดลำดับความสำคัญของเนื้อหาเมื่อพิจารณาการออกแบบเลย์เอาต์ อินเทอร์เฟซ และการโต้ตอบข้ามอุปกรณ์
ทำความเข้าใจค่าใช้จ่ายในการใช้ข้อมูล
หน้าเว็บมีขนาดใหญ่ขึ้น
HTTP Archive ระบุว่าปัจจุบันน้ำหนักหน้าเว็บโดยเฉลี่ยของเว็บไซต์ยอดนิยม 1 ล้านเว็บไซต์มีขนาดมากกว่า 2 MB
ผู้ใช้จะหลีกเลี่ยงเว็บไซต์หรือแอปที่รับรู้ว่าช้าหรือมีค่าใช้จ่ายสูง ดังนั้นการทำความเข้าใจต้นทุนในการโหลดคอมโพเนนต์ของหน้าเว็บและแอปจึงเป็นสิ่งสำคัญ
การลดน้ำหนักหน้าเว็บยังอาจสร้างผลกำไรได้ด้วย Chris Zacharias จาก YouTube พบว่าเมื่อลดขนาดหน้าสำหรับดูจาก 1.2 MB เป็น 250 KB
กล่าวคือ การลดน้ำหนักหน้าเว็บอาจเปิดตลาดใหม่ๆ ขึ้นมา
คำนวณน้ำหนักหน้าเว็บ
มีเครื่องมือมากมายที่ใช้คำนวณน้ำหนักหน้าเว็บ แผงเครือข่ายของเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome จะแสดงขนาดไบต์ทั้งหมดของทรัพยากรทั้งหมด และใช้เพื่อตรวจสอบน้ำหนักของชิ้นงานแต่ละประเภทได้ นอกจากนี้ คุณยังตรวจสอบได้ด้วยว่ามีการดึงข้อมูลรายการใดจากแคชของเบราว์เซอร์
Firefox และเบราว์เซอร์อื่นๆ มีเครื่องมือที่คล้ายกัน
WebPagetest ช่วยให้คุณทดสอบการโหลดหน้าเว็บครั้งแรกและครั้งต่อๆ ไปได้ คุณสามารถทำการทดสอบโดยอัตโนมัติด้วยสคริปต์ (เช่น เพื่อเข้าสู่ระบบเว็บไซต์) หรือโดยใช้ RESTful API ตัวอย่างต่อไปนี้ (การโหลด developers.google.com/web) แสดงให้เห็นว่าการแคชสำเร็จ และการโหลดหน้าเว็บในภายหลังไม่จำเป็นต้องใช้ทรัพยากรเพิ่มเติม
WebPagetest ยังแสดงรายละเอียดขนาดและคำขอตามประเภท MIME ด้วย
คำนวณต้นทุนหน้าเว็บ
สำหรับผู้ใช้จำนวนมาก ข้อมูลไม่ได้มีค่าแค่ไบต์และประสิทธิภาพ แต่ยังมีค่าเป็นเงินด้วย
เว็บไซต์ What Does My Site Cost? ช่วยให้คุณประมาณต้นทุนทางการเงินที่แท้จริงของการโหลดเว็บไซต์ได้ ฮิสโทแกรมด้านล่างแสดงค่าใช้จ่าย (เมื่อใช้แพ็กเกจอินเทอร์เน็ตแบบชำระล่วงหน้า) ในการโหลด amazon.com
โปรดทราบว่าการดำเนินการนี้ไม่ได้พิจารณาถึงความสามารถในการซื้อเมื่อเทียบกับรายได้ ข้อมูลจาก blog.jana.com แสดงค่าใช้จ่ายของข้อมูล
| ค่าแพ็กเกจอินเทอร์เน็ต 500 MB (USD) |
ค่าแรงขั้นต่ำรายชั่วโมง (USD) |
ชั่วโมงการทำงานที่ต้องจ่าย สำหรับแพ็กเกจอินเทอร์เน็ต 500 MB |
|
| อินเดีย | $3.38 | $0.20 | 17 ชั่วโมง |
| อินโดนีเซีย | $2.39 | 12.90 บาท | 6 ชั่วโมง |
| บราซิล | $13.77 | $1.04 | 13 ชั่วโมง |
น้ำหนักหน้าเว็บไม่ได้เป็นปัญหาเฉพาะในตลาดเกิดใหม่ ในหลายประเทศ ผู้คนใช้แพ็กเกจมือถือที่มีการจำกัดปริมาณข้อมูล และจะหลีกเลี่ยงเว็บไซต์หรือแอปของคุณหากเห็นว่ามีขนาดใหญ่และมีราคาแพง แม้ว่าแพ็กเกจอินเทอร์เน็ตมือถือและ Wi-Fi แบบ "ไม่จำกัด" โดยทั่วไปก็ยังมีขีดจำกัดของข้อมูล ซึ่งจะถูกบล็อกหรือจำกัดความเร็วหากใช้งานเกิน ด้วยเหตุนี้ คุณจึงควรโปร่งใสมากที่สุดเกี่ยวกับปริมาณข้อมูลที่หน้าเว็บใช้ บล็อกโพสต์ต่อไปนี้มีแนวทางปฏิบัติแนะนำที่เฉพาะเจาะจง สร้างความไว้วางใจผ่านความโปร่งใสด้านต้นทุน
สรุปแล้ว น้ำหนักหน้าเว็บส่งผลต่อประสิทธิภาพและมีค่าใช้จ่าย การเพิ่มประสิทธิภาพเนื้อหาแสดงวิธีลดต้นทุนดังกล่าว