محلل أداء 3D للويب

اعرف سبب بطء النموذج قبل أن تبدأ بتعديله

نادرًا ما يكون النموذج ثلاثي الأبعاد الذي يبدو ثقيلًا على الويب ثقيلًا للسبب الذي يفترضه الجميع. الكل ينظر إلى حجم الملف، لأنه الرقم الذي يعرضه نظام التشغيل. لكن حجم الملف واحد من أربعة عوامل تحدّد المدة التي يستغرقها ظهور النموذج، وغالبًا ليس العامل المهيمن. يقيس هذا المحلل العوامل الأربعة جميعها ويخبرك أيها يكلفك فعلًا.

المراحل الأربع لتحميل النموذج

التنزيل هو البايتات المارّة عبر الشبكة، وهو المرحلة الوحيدة التي تتحسّن عند ضغط الملف. التحليل هو JSON وعروض المخازن وفكّ ترميز الكوديك. فكّ ترميز القوام يحوّل الصور المضغوطة إلى بكسلات RGBA ويبني سلاسل Mip. الرفع إلى المعالج الرسومي يدفع بيانات الرؤوس والقوام عبر الناقل.

على الألياف، يستغرق نموذج بحجم 12 ميغابايت يضم ثماني خرائط قوام بدقة 4K أقل من ثانية في التنزيل، وعدة ثوانٍ في فكّ ترميز القوام. زيادة ضغط ملف GLB لن تفيد هذا النموذج إطلاقًا، بينما تنصيف دقة القوام سيفيد. تسمّي الأداة المرحلة المهيمنة عند كل سرعة اتصال حتى تستطيع التمييز بين هاتين الحالتين.

حجم الملف وذاكرة المعالج الرسومي ليسا الرقم نفسه

هذا أكثر سوء فهم شيوعًا في مجال 3D على الويب. قد تُشحن خريطة قوام بأبعاد 4096 × 4096 على هيئة JPEG بحجم 2 ميغابايت، لكنها على المعالج الرسومي تساوي 4096 × 4096 × 4 بايت من RGBA — نحو 67 ميغابايت، أو قرابة 89 ميغابايت بعد بناء سلسلة Mip. ثماني خرائط كهذه تكفي لاستنفاد ذاكرة هاتف متوسط الفئة مهما كان حجم التنزيل صغيرًا.

يعرض المحلل ذاكرة القوام على المعالج الرسومي وذاكرة سمات الرؤوس بمعزل عن حجم الملف، ويقيّمها بمعزل عنه كذلك، لأنها تُخفق لأسباب مختلفة وتُعالَج بوسائل مختلفة.

تقييم مقابل ثلاثة أهداف في آن واحد

يُقيَّم كل مقياس في الوقت نفسه مقابل ميزانيات سطح المكتب والهاتف وWebXR، فلا يكون الجواب نعم أو لا بل أين: هذا النموذج جيد على سطح المكتب، وعلى الحدّ على الهاتف، وميؤوس منه داخل نظارة. يحصل كل هدف على درجة، ويحصل كل مقياس على نجاح أو تحذير أو إخفاق، ويولّد كل إخفاق نصيحة واحدة محددة تسمّي التحويل الذي يعالجه.

للقراءة فقط بحكم التصميم

لا تكتب هذه الأداة أي ملف أبدًا. وحين تعرف ما ينبغي إصلاحه، يطبّق محسّن 3D للويب الخطة ويعيد تقييم النتيجة. كل شيء يجري محليًا — ولا تُرفع نماذجك إطلاقًا.