ขนาดไฟล์โมเดลสินค้า 3D: มือถือโหลดอะไจจริง

ขนาดไฟล์โมเดลสินค้า 3D ที่ 5 MB ถือว่าหนักเกินไปแล้วสำหรับหน้าสินค้าที่ผู้ซื้อเปิดบนมือถือ น้ำหนักที่มือถือ Android ระดับกลางและเน็ตมือถือทั่วไปรับไหวอยู่ที่ราว 2 MB และเหตุผลไม่ใช่รสนิยมแต่เป็นเลขคณิต: ที่ 5 Mbps ทุก 1 MB ใช้เวลา 1.6 วินาทีก่อนที่ตัวแสดงโมเดลจะวาดภาพแรกได้

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

ตารางขนาดไฟล์โมเดลสินค้า 3D: มือถือโหลดอะไอก่อน

เวลาดาวน์โหลด = ขนาดไฟล์ × 8 ÷ ความเร็วเน็ต สูตรนี้ไม่มีการเรนเดอร์ การหมุน หรือภาพแรกอยู่เลย ตารางสมมติว่าเน็ตเสถียรและไม่นับ TLS handshake กับ latency ไปกลับ ดังนั้นมือถือจริงจะช้ากว่านี้

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

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

ทำไมโมเดลทั้งก้อนต้องมาถึงก่อน

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

คอนเทนเนอร์มีผล GLB รวมคำอธิบายฉากแบบ JSON กับบัฟเฟอร์ไบนารีไว้ในไฟล์เดียวโดยไม่มี base64 บวม จึงมีประสิทธิภาพเมื่อใช้คำขอเดียว แต่ผู้ซื้อต้องรอทั้งแพ็กเกจ ไฟล์ .gltf แยกที่มี .bin และเท็กซ์เจอร์แยก ช่วยให้ตัวแสดงโหลดทีละส่วนและเริ่มได้เร็วขึ้น แลกกับการมีคำขอมากขึ้นและจุดที่พังได้มากขึ้น สำหรับสินค้า SKU เดียว GLB ไฟล์เดียวมักเป็นคำตอบที่ถูก สำหรับซีรีส์ 60 SKU การแยกไฟล์ที่ใช้ร่วมกันมักรวมแล้วเบากว่า

เรื่องนี้ไม่ปรากฏในช่องภาพของรายงานประสิทธิภาพ จึงถูกละเลย องค์ประกอบ Largest Contentful Paint ของหน้าสินค้ามักเป็นภาพหลักหรือบล็อกข้อความ ไม่ใช่แคนวาส WebGL เกณฑ์ของ Google คือ LCP 2.5 วินาทีหรือน้อยกว่าที่เปอร์เซ็นไทล์ที่ 75 หากสคริปต์ของตัวแสดงและดาวน์โหลดโมเดลแย่งแบนด์วิดท์กับภาพหลัก หน้าจะพลาดเกณฑ์นี้ ขณะที่ทีม 3D รายงานว่า "โมเดลเรนเดอร์ปกติ"

หน้าทั้งหน้าเหลือน้ำหนักให้โมเดลแค่ไหน

ข้อมูล HTTP Archive ปี 2024 ที่อ้างใน Web Almanac ระบุหน้าคอมพิวเตอร์มัธยฐาน 2,312 KB และหน้ามือถือ 2,037 KB บนมือถือ ภาพอย่างเดียวกินราว 900 KB ของค่านั้น

เทียบโมเดลกับตัวเลขเหล่านี้:

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

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

ไบต์หายไปไหน และการบีบอัดแบบไหนแก้ส่วนไหน

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

ส่วนขยายสองตัวที่ Khronos ให้สัตยาบันแล้วทำงานบีบอัดหลัก และแก้ปัญหาต่างกัน KHR_draco_mesh_compression ส่งเรขาคณิตที่บีบอัดแล้วแทนข้อมูลจุดยอดดิบ KHR_texture_basisu เก็บเท็กซ์เจอร์เป็น KTX2 ด้วย Basis Universal supercompression ซึ่งลดทั้งขนาดที่ส่งและหน่วยความจำ GPU

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

หกข้อตรวจก่อนส่งลิงก์ภาพ 3D

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

• ไฟล์เป็น .glb ไฟล์เดียวที่ส่งออกสำหรับเว็บ ไม่ใช่ .blend .step หรือ .obj ที่มีเท็กซ์เจอร์กระจัดกระจาย
• .glb นี้อยู่ในงบน้ำหนักของเน็ตที่ผู้ซื้อใช้จริง
• ภาพนิ่งโหลดก่อน และตัวแสดงเริ่มทำงานเมื่อผู้ซื้อแตะหรือเลื่อนมาถึงเท่านั้น
• หนึ่งนิ้วหมุนได้ หยิกซูมได้ และโมเดลไม่กระโดดหรือหมุนเลยขอบ
• ทรง จำนวนชิ้นส่วน และฮาร์ดแวร์ยังตรงกับสินค้าและแบบที่มีขนาดกำกับ
• ผู้ซื้อที่ไม่มี WebGL หรือถูกนโยบายบริษัทบล็อก ยังได้ภาพถ่ายและตารางสเปก

ข้อ 1: เป็นไฟล์ส่งออกสำหรับเว็บ ไม่ใช่ไฟล์ทำงาน

.blend หรือ .step เป็นเอกสารสำหรับสร้างงาน มีประวัติ กล้อง วัสดุ และบางครั้งอ้างเท็กซ์เจอร์ในโฟลเดอร์บนแล็ปท็อปของใครคนหนึ่ง คอนเทนเนอร์เว็บคือ GLB และฉากควรมีสินค้าหนึ่งชิ้น กล้องหนึ่งตัว และวัสดุที่ตัวแสดงอ่านได้ ถ้าไดอะล็อกส่งออกถามเรื่อง "apply modifiers" หรือ "include hidden objects" ให้ตอบใช่ข้อแรก และไม่ใช่ข้อหลัง

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

ข้อ 2: น้ำหนักตรงกับเน็ตของผู้ซื้อ ไม่ใช่ของสตูดิโอ

เปิดคุณสมบัติของไฟล์ที่ส่งออก อ่านขนาดไฟล์โมเดลสินค้า 3D เป็น MB แล้วเทียบกับตารางด้านบน ต้องดูไฟล์ที่ส่งออก ไม่ใช่โปรเจกต์ ไฟล์ทำงาน 40 MB อาจส่งออกได้ 3 MB และไฟล์ 3 MB อาจกลายเป็น 30 MB เมื่อรวมเท็กซ์เจอร์

ถ้าเกินงบ แก้ก้อนที่ใหญ่ที่สุดก่อน เปลี่ยน PNG 4096 พิกเซลสี่แผ่นเป็น JPEG 1024 หนึ่งหรือสองแผ่นมักลดได้มากกว่าการแก้เรขาคณิต Draco และ KTX2 ใช้ทีหลัง เพราะทำหน้าที่ลดขนาดสินทรัพย์ที่สมเหตุสมผล ไม่ใช่ทำให้สินทรัพย์ที่หนักเกินกลายเป็นที่ยอมรับได้

ข้อ 3: ภาพแรกเป็นโปสเตอร์ ไม่ใช่แคนวาสว่าง

โหลดตัวแสดงแบบเลื่อน และแสดงภาพนิ่ง (ควรเป็นมุมเดียวกับที่โมเดลเปิด) จนกว่าผู้ซื้อจะโต้ตอบ วิธีนี้ทำให้แคนวาส 3D ออกจากเส้นทางวิกฤต และหน้ายังมีผู้สมัคร LCP จริง

จุดที่พลาดบ่อยถัดมาคือการตอบสนองต่อการสัมผัส เกณฑ์ Interaction to Next Paint ของ Google คือ 200 มิลลิวินาทีที่เปอร์เซ็นไทล์ที่ 75 และเกิน 500 มิลลิวินาทีถือว่าแย่ โมเดลหนักบวกฟิสิกส์และเงา ทำให้การแตะแล้วหมุนเกินเส้นนี้บนมือถือระดับกลางได้ แม้หน้าโหลดเร็ว

ข้อ 4: หมุนด้วยนิ้วโป้งข้างเดียว

ถือมือถือมือเดียวแล้วหมุนโมเดลด้วยนิ้วโป้ง ถ้าต้องใช้สองนิ้ว ถ้าปล่อยแล้วโมเดลไหลต่อ หรือซูมแล้วจุดหมุนเลื่อน ผู้ซื้อจะต่อสู้กับตัวแสดงแทนที่จะอ่านสินค้า

ทดสอบขอบด้วย: ด้านบน ด้านล่าง ด้านหลัง ตัวแสดงที่จำกัดการหมุนที่ ±45 องศา ซ่อนพื้นผิวที่ผู้ซื้ออยากดูที่สุด คือด้านที่สตูดิโอไม่เคยถ่าย

ข้อ 5: ทรงยังตรงกับสินค้า

หมุนโมเดลเทียบกับของจริงและแบบที่มีขนาดกำกับ ดูทรง ฮาร์ดแวร์ รอยต่อ และความหนาของขอบแผ่น แล้วดูจุดที่ผู้ซื้อจะตรวจ: บานพับ ขา มือจับ และหน้าตัดของเส้นคิ้ว

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

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

ข้อ 6: มีทางสำรองสำหรับคนที่มองไม่เห็น

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

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

ภาพ 3D พิสูจน์อะไรได้ และพิสูจน์อะไรไม่ได้

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

ประโยคนี้ควรเขียนไว้บนหน้าด้วยซ้ำ หนึ่งบรรทัด — "ขนาดวัดจากสินค้าจริง ภาพ 3D แสดงเพียงทรง" — กันความเข้าใจผิดที่แพงที่สุดในกระบวนการนี้ คือผู้ซื้อที่คิดว่าโมเดลคือแบบมีขนาดแล้วสั่งซื้อตามนั้น

เมื่อไหร่ที่ภาพ 3D ไม่คุ้มน้ำหนัก

3D ไม่ใช่คำตอบเริ่มต้นของทุกคำถามผู้ซื้อ และหน้าที่ใส่ทุกรูปแบบจะช้ากว่าหน้าที่ใส่แค่รูปแบบที่ถูก ใช้กฎนี้

ถ้าคำถามมีแค่ "จะส่งรูปแบบไหน" ทางเลือกจริงมักอยู่ระหว่างภาพ 3D กับชุดภาพถ่าย ไม่ใช่ระหว่าง 3D กับไม่ส่งอะไร ข้อแลกเปลี่ยนคือน้ำหนักไฟล์ การโต้ตอบ และอิสระที่ผู้ซื้อต้องใช้ ตัวแสดง 3D กับภาพ 360 องศาอธิบายความต่างนี้ละเอียดกว่า

เมื่อ 3D คุ้มพื้นที่จริง วางไว้ในที่ที่มองเห็น: ภาพ 3D ของสินค้าที่เปิดข้างขนาดที่วัดไว้ ในการ์ดที่ผู้ซื้อส่งต่อภายในทีม ดีกว่าตัวแสดงที่ซ่อนอยู่สามคลิกในแคตตาล็อก

คำถามที่พบบ่อย

โมเดลสินค้า 3D บนเว็บไซต์ควรมีขนาดเท่าไร

ต่ำกว่า 5 MB และต่ำกว่า 2 MB ถ้าผู้ซื้อมีโอกาสเปิดบนมือถือ เพดานมาจากเลขคณิตไม่ใช่ความชอบ: ที่ 5 Mbps โมเดล 5 MB ใช้ 8 วินาทีถึงภาพแรก และยังไม่นับเวลารันสคริปต์ของตัวแสดง ดูที่ GLB ที่ส่งออก ไม่ใช่โปรเจกต์

โมเดล 3D ทำให้หน้าสินค้าช้าลงไหม

ช้าลง และมักสองจุด ดาวน์โหลดแย่งแบนด์วิดท์กับภาพหลัก ดัน Largest Contentful Paint เกินเกณฑ์ 2.5 วินาทีของ Google จากนั้นสคริปต์ตัวแสดงแย่ง main thread ดันเวลาโต้ตอบเข้าใกล้เกณฑ์ INP 200 มิลลิวินาที วัดทั้งสองอย่างใน PageSpeed Insights โดยมีโมเดลอยู่จริง ไม่ใช่ภาพแทน

GLB กับ glTF ต่างกันอย่างไร

GLB คือคอนเทนเนอร์ไบนารี glTF คือรูปแบบ .gltf เป็น JSON ที่ชี้ไปยัง .bin และไฟล์ภาพแยก .glb รวม JSON กับบัฟเฟอร์ไบนารีไว้ในไฟล์เดียวโดยไม่ใช้ base64 จึงเป็นคำขอเดียวและเล็กกว่า JSON ที่ฝังข้อมูลเล็กน้อย ทั้งคู่เป็น glTF 2.0 และโหลดได้ในตัวแสดงที่ได้มาตรฐาน

ลดขนาดไฟล์โมเดล 3D โดยไม่เสียทรงได้ไหม

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

ผู้ซื้อวัดขนาดสินค้าจากภาพ 3D ได้ไหม

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

แหล่งอ้างอิง

• web.dev — Largest Contentful Paint (LCP): เกณฑ์ดี 2.5 วินาที แย่เกิน 4.0 วินาที วัดที่เปอร์เซ็นไทล์ที่ 75
• web.dev — Interaction to Next Paint (INP): เกณฑ์ดี 200 มิลลิวินาที แย่เกิน 500 มิลลิวินาที
• HTTP Archive Web Almanac 2024 — บท Page Weight: หน้ามือถือมัธยฐาน 2,037 KB เดสก์ท็อป 2,312 KB ภาพบนมือถือราว 900 KB
• Khronos Group — ข้อกำหนด glTF 2.0: โครงสร้างคอนเทนเนอร์ GLB บัฟเฟอร์ไบนารี และข้อความว่า glTF ไม่ใช่รูปแบบสตรีมมิ่ง
• Khronos Group — ส่วนขยาย KHR_draco_mesh_compression: ส่งเรขาคณิตที่บีบอัดแทนข้อมูลจุดยอดดิบ
• Khronos Group — ส่วนขยาย KHR_texture_basisu: เท็กซ์เจอร์ KTX2 ด้วย Basis Universal supercompression