طراحی سه‌بعدی سایت؛ معماری، عملکرد و دسترسی

یک صندلی سه‌بعدی که مشتری بتواند رنگ و زاویه‌اش را ببیند شاید ابهام خرید را کم کند؛ همان مدل اگر قبل از قیمت و موجودی، ۱۸ مگابایت دانلود و اسکرول را قفل کند، فقط یک مانع گران است. سؤال درست «چطور سایت را 3D کنیم؟» نیست؛ سؤال این است: کدام تصمیم کاربر با چه سطحی از Immersion بهتر می‌شود و هزینه شکست آن چقدر است؟

این راهنما طراحی سه‌بعدی سایت را به یک سیستم تولیدی تبدیل می‌کند: Business fit، قرارداد قابلیت، انتخاب CSS/model-viewer/WebGL/WebGPU/WebXR، Pipeline مدل glTF، بودجه Network/CPU/GPU/Memory، Adaptive quality، دسترسی‌پذیری، سئو، امنیت، صحت Variation فروشگاه، Observability، Runbook و TCO. Snapshot وضعیت استانداردها ۱۹ مرداد ۱۴۰۵ / ۱۰ اوت ۲۰۲۶ است؛ Compatibility باید پیش از هر Release روی Matrix واقعی پروژه دوباره سنجیده شود.

سه‌بعدی، Immersive و XR یکی نیستند

سه‌بعدی یک Media/Runtime است؛ Immersion یک Outcome تجربه. ممکن است یک عکس ۳۶۰ با Navigation خوب از Scene پیچیده‌ای که کاربر در آن گم می‌شود Immersiveتر باشد.

Outcome را پیش از فناوری بنویسید

هر Experience باید یک Decision contract داشته باشد. «افزایش Engagement» Outcome کافی نیست، چون چرخاندن بی‌هدف دوربین نیز Engagement تولید می‌کند.

برای تبدیل Assumption به Prototype و Evidence از راهنمای نمونه‌سازی سریع وب استفاده کنید؛ مقاله حاضر مالک Production engineering تجربه 3D است.

نردبان کمینه پیچیدگی

از پایین‌ترین سطحی شروع کنید که Decision را حل می‌کند. اگر شش عکس زاویه‌دار پاسخ می‌دهند، ساخت Configurator کامل توجیه ندارد. اگر Component آماده نیاز را پوشش می‌دهد، مالک‌شدن Engine سفارشی بدهی دائمی ایجاد می‌کند.

چه زمانی 3D مناسب است؟

• فرم، زاویه، اتصال، مقیاس یا پیکربندی برای تصمیم حیاتی است.
• کاربر باید رابطه اجزا را با Exploded view یا Hotspot بفهمد.
• دارایی منبع، مالکیت، Pipeline و تیم نگهداری وجود دارد.
• نسخه HTML/Image/Fallback همان Outcome پایه را حفظ می‌کند.
• اثر بر Task و Guardrail قابل‌اندازه‌گیری است.
• محصول/فضا به‌اندازه کافی پایدار است که هزینه Asset هدر نرود.

چه زمانی 3D را رد کنیم؟

• مسئله محتوا، قیمت، اعتماد یا Navigation است و جلوه بصری آن را حل نمی‌کند.
• کاربر برای انجام Task باید منتظر دانلود سنگین بماند.
• Asset source یا حق استفاده روشن نیست.
• تیم فقط Demo Desktop را بودجه داده و Mobile/Fallback/QA حذف شده‌اند.
• SKU و Variant سریع تغییر می‌کنند اما Pipeline به‌روزرسانی وجود ندارد.
• اطلاعات ضروری داخل Canvas محبوس می‌شود.
• Page از قبل Long task، Memory leak یا CWV ضعیف دارد.
• هیچ Owner و Kill rule برای تجربه وجود ندارد.

Proof of Concept با Acceptance contract

PoC نباید زیباترین مدل روی قوی‌ترین لپ‌تاپ باشد. سخت‌ترین Asset، ضعیف‌ترین دستگاه هدف و پرریسک‌ترین مسیر را انتخاب کنید.

انتخاب Runtime بر اساس Capability

انتخاب Library را فقط با Screenshot Demo انجام ندهید. Bundle/runtime، Accessibility API، Exportability، Release cadence، Security response، License، Vendor lock-in و قابلیت حذف را ارزیابی کنید.

<model-viewer> چه مسئله‌ای را حل می‌کند؟

مستند رسمی model-viewer آن را برای نمایش مدل تعاملی و AR معرفی می‌کند و پشتیبانی دو نسخه اخیر Browserهای Evergreen و Safari را هدف می‌گیرد؛ قابلیت‌های AR به API و Platform وابسته‌اند. این Component می‌تواند هزینه Viewer پایه را کم کند، اما Asset quality، Variant state، Accessibility متن اطراف، Performance و QA را خودکار حل نمی‌کند.

WebGL و Engine abstraction

WebGL مسیر گسترده‌تر و بالغ‌تری برای Rendering 3D وب است. کتابخانه‌ای مانند Three.js Scene graph، Camera، Loader و Material را ساده می‌کند، اما مسئولیت Scene lifecycle، Resource disposal، Context loss، Device variation و Testing باقی می‌ماند. Engine abstraction وقتی ارزش دارد که تیم واقعاً از قابلیت آن استفاده و Upgradeهایش را نگهداری کند.

WebGPU در ۲۰۲۶؛ قدرتمند اما هنوز Baseline نیست

MDN WebGPU در به‌روزرسانی مه ۲۰۲۶ همچنان API را «Limited availability» و غیرBaseline معرفی می‌کند؛ WebGPU فقط در Secure Context در دسترس است. W3C نیز در ۲۰۲۶ آن را در مسیر Candidate Recommendation منتشر کرده است. پس «WebGPU جای WebGL را گرفته» قرارداد قابل‌اعتمادی برای وب عمومی نیست.

async function chooseRenderer() {
  if (window.isSecureContext && "gpu" in navigator) {
    try {
      const adapter = await navigator.gpu.requestAdapter();
      if (adapter) return { kind: "webgpu", adapter };
    } catch (error) {
      reportCapabilityError("webgpu", error);
    }
  }
  if (document.createElement("canvas").getContext("webgl2")) {
    return { kind: "webgl2" };
  }
  return { kind: "poster" };
}

این نمونه مفهوم Feature detection را نشان می‌دهد، نه Production implementation. Availability API با Performance کافی برابر نیست. Capability، Limit و Error را پس از دسترسی واقعی بسنجید؛ UA sniffing و روشن‌کردن Flag آزمایشی برای کاربران راه‌حل Production نیست.

WebXR؛ Consent و Privacy بخشی از معماری‌اند

WebXR Device API در مارس ۲۰۲۶ Candidate Recommendation Draft است و برای دسترسی فراتر از Inline پایه، Consent کاربر، Permission و ملاحظات Fingerprinting/Tracking دارد. AR/VR را خودکار شروع نکنید؛ Context، داده جمع‌آوری‌شده و راه خروج را روشن کنید.

Pipeline دارایی سه‌بعدی

فایل مناسب Blender/CAD لزوماً Asset مناسب Runtime نیست. Pipeline را Versioned و قابل‌بازتولید کنید:

1. Source intake: مالکیت، License، Scale، Coordinate و Revision.
2. Cleanup: Geometry پنهان، Normal، UV، Naming و Pivot.
3. Web authoring: Mesh/Material/Texture/Animation مناسب Task.
4. Optimization: Geometry و Texture compression با Quality target.
5. Validation: Schema/extension، Visual parity و Runtime load.
6. Packaging: GLB/glTF، Poster، Metadata و Integrity/Version.
7. Delivery: CDN/CORS/Cache و Rollback.
8. Retirement: Dependency check و حذف امن Revision قدیمی.

glTF/GLB؛ فرمت تحویل، نه تضمین بهینه‌بودن

Khronos glTF glTF را برای انتقال کارآمد Scene/Model سه‌بعدی Runtime طراحی کرده است. GLB می‌تواند JSON و Binary resource را در Container واحد بسته‌بندی کند؛ اما فایل glTF ممکن است همچنان Geometry اضافه، Texture عظیم، Animation بی‌مصرف یا Extension ناسازگار داشته باشد.

Geometry و Draw call را با Task هماهنگ کنید

Polygon کم به‌تنهایی Performance خوب نمی‌سازد. Material count، Node count، Skinning، Morph target، Transparency، Shadow و State change روی CPU/GPU اثر دارند. جزئیاتی که در اندازه واقعی Canvas دیده نمی‌شوند باید با Normal map، LOD یا حذف مدیریت شوند.

• Budget را برای Triangle، Node، Material، Draw call و Bone جدا ثبت کنید.
• اجزای Interactive را Naming پایدار و ID غیرنمایشی بدهید.
• Geometry پنهان داخل محصول را فقط اگر Exploded view لازم دارد نگه دارید.
• Transparent material و Shadow realtime را محدود و Device-test کنید.
• Bounding box، Pivot، Unit و Up-axis را در CI validate کنید.

Texture؛ حجم دانلود با حافظه GPU یکی نیست

JPEG/WebP فشرده روی شبکه پس از Decode می‌تواند حافظه بسیار بیشتری مصرف کند. Mipmap و Channel نیز هزینه دارند. KTX 2.0 Container و Texture compression قابل‌انتقال را برای GPU هدف می‌گیرد، اما Encoding setting، Transcode support و کیفیت باید روی Device واقعی سنجیده شوند.

برای Poster و Media عمومی صفحه، راهنمای تصویر و ویدئو وب مرز Format، Responsive delivery، Accessibility و SEO را پوشش می‌دهد.

Color، Scale و Coordinate قرارداد داده‌اند

یک Configurator که رنگ یا اندازه را نادرست نشان می‌دهد ممکن است فروش بسازد اما اعتماد و مرجوعی را خراب کند. Unit، Color space، Tone mapping، Lighting environment و Camera را Version کنید.

بودجه عملکرد چهارمنبعی

بودجه 3D را فقط «فایل زیر X مگابایت» ننویسید. Network، Main thread، GPU و Memory می‌توانند مستقل شکست بخورند.

عدد ثابت جهانی پیشنهاد نکنید. Budget را از Baseline سایت، سخت‌ترین Device، اندازه Canvas و Task بسازید؛ سپس P50/P75/P95 و Failure rate را گزارش کنید. LCP/INP/CLS عمومی و RUM در راهنمای Core Web Vitals تفصیل داده شده‌اند.

زمان‌های مهم تجربه 3D

load مرورگر یا Promise دانلود با آماده‌بودن Interaction یکی نیست. Error code و Stage را همراه Timing ثبت کنید.

Poster-first و Load on intent

Poster باید نماینده همان Variant و Camera باشد، ابعاد Canvas را رزرو کند و محتوای اصلی را سریع نشان دهد. سه الگوی Load:

• Explicit: کاربر «نمایش سه‌بعدی» را می‌زند؛ مناسب Asset سنگین.
• Near viewport: پس از نزدیک‌شدن، با Budget و Cancel؛ مناسب صفحه محصول.
• Idle: فقط وقتی Network/CPU اجازه می‌دهد؛ هیچ تضمینی ندارد.

Preload کور همه مدل‌ها روی Category page ممنوع است. Abort، Timeout، Retry محدود و Fallback را طراحی کنید.

Adaptive quality یک State machine است

Adaptation را بر Hardware label تنها بنا نکنید؛ اندازه Canvas، Frame time پایدار، Memory pressure proxy، Visibility و Preference را در نظر بگیرید. Hysteresis بگذارید تا Quality بین دو سطح مدام نپرد. تغییر کیفیت نباید Variant یا Progress کاربر را ریست کند.

Pixel ratio و Drawing buffer

تلفن با Device Pixel Ratio بالا می‌تواند چند برابر پیکسل CSS را رندر کند. راهنمای Responsive رسمی Three.js درباره هزینه HD-DPI و محدودکردن Drawing buffer بر اساس حداکثر Pixel count هشدار می‌دهد. Pixel ratio کامل را Default کیفیت ندانید.

const maxPixels = quality === "low" ? 900_000 : 2_000_000;
const cssWidth = canvas.clientWidth;
const cssHeight = canvas.clientHeight;
const desiredRatio = Math.min(devicePixelRatio, quality === "high" ? 2 : 1.25);
const desiredPixels = cssWidth * cssHeight * desiredRatio ** 2;
const scale = desiredPixels > maxPixels
  ? Math.sqrt(maxPixels / desiredPixels)
  : 1;
resizeDrawingBuffer(cssWidth, cssHeight, desiredRatio * scale);

عددها مثال‌اند و باید با Visual/Performance test پروژه جایگزین شوند.

Render loop را فقط وقتی لازم است اجرا کنید

• خارج Viewport، Tab پنهان یا Experience بسته است: Pause.
• Scene ثابت است: render-on-demand، نه 60fps دائمی.
• Animation تمام شده: Frame request را لغو کنید.
• Resize/visibility/input listener در Unmount پاک شود.
• Page lifecycle و بازگشت از Background تست شود.
• Reduced motion باید Animation غیرضروری را حذف یا محدود کند.

Memory و Resource disposal

حذف Object از Scene لزوماً Buffer/Texture را آزاد نمی‌کند. راهنمای Dispose رسمی Three.js می‌گوید Geometry، Material، Texture، Render target و Resourceهای وابسته باید آگاهانه آزاد شوند؛ Texture و Material lifecycle جدا دارند.

WebGL context loss را تمرین کنید

Browser ممکن است Drawing context را از دست بدهد. رویداد webglcontextlost برای تشخیص وجود دارد. UI نباید سفید و بی‌توضیح بماند.

1. Animation loop را متوقف و Error stage را ثبت کنید.
2. Poster و پیام قابل‌فهم نشان دهید؛ Task پایه را حفظ کنید.
3. Restore را فقط اگر State/Resourceها قابل‌بازیابی‌اند انجام دهید.
4. تلاش تکراری بی‌نهایت نکنید؛ Circuit breaker داشته باشید.
5. با Extension تست، Context loss را در QA شبیه‌سازی کنید.

معماری Interaction و Orientation

کاربر باید بداند چه چیزی Interactive است، چگونه Reset/Exit کند و نتیجه انتخاب کجاست.

برای ساختن فرضیه UX، Instrumentation و تصمیم مبتنی بر شواهد از راهنمای طراحی UX داده‌آگاه استفاده کنید.

Gesture و Scroll را با هم نجنگانید

• Drag تنها پس از Intent روشن روی Viewer فعال شود.
• Pinch/Zoom، Page zoom و Accessibility را بی‌دلیل مسدود نکنید.
• Touch target، Reset، Fullscreen و Exit اندازه کافی داشته باشند.
• Control جایگزین Button/Slider برای Gesture حیاتی ارائه شود.
• Rotation device تنها مسیر کنترل نباشد.
• Landscape، Keyboard باز، تماس ورودی و بازگشت Tab تست شوند.

دسترسی‌پذیری؛ Canvas تنها منبع حقیقت نیست

مدل داخل Canvas به‌خودی‌خود ساختار معنایی کافی برای Assistive technology نمی‌سازد. نام، هدف، گزینه‌ها، وضعیت و نتیجه Task باید در DOM یا Alternative معادل حضور داشته باشند.

W3C در راهنمای Animation from interactions بر امکان غیرفعال‌کردن Motion غیرضروری تأکید دارد؛ Device motion نیز نباید تنها روش کنترل باشد. برنامه ممیزی کامل در راهنمای تست دسترس‌پذیری و WCAG آمده است.

SEO و HTML fallback

Google و کاربر باید بدون اجرای Renderer موضوع و ارزش صفحه را بفهمند. Canvas جای Product description، Specification، Price، FAQ و Link نیست.

• Title، Heading، متن، Dimensions و Variationهای مهم در HTML واقعی باشند.
• Poster مرتبط، Alt دقیق و Dimension رزروشده داشته باشد.
• Hotspotهای اطلاعاتی Alternative متنی و Link قابل Crawl داشته باشند.
• SSR/HTML اصلی منتظر Bundle 3D نماند.
• Structured data با Price/Availability قابل‌مشاهده و Backend منطبق باشد.
• URL مستقل فقط برای Intent/Content مستقل؛ Camera state را بی‌هدف URL نسازید.
• Share preview بدون Interaction معنی‌دار باشد.

Security و Supply chain

Asset آپلودشده کاربر یا Vendor را Trusted input فرض نکنید. Processing را از Web server جدا، Parser/Decoder را به‌روز و Output را Manifestدار کنید. CI/CD، Artifact و Provenance عمومی در راهنمای CI/CD امن پوشش داده شده‌اند.

صحت Configurator و Commerce

Scene نباید Source of truth قیمت یا موجودی شود. UI state باید به Variant ID معتبر Backend نگاشت و پاسخ Server پیش از خرید تأیید شود.

AR و 3D در فروشگاه، Measurement و مرزبندی تجاری در راهنمای واقعیت افزوده تجارت الکترونیک تکمیل شده است.

Event contract؛ هر حرکت دوربین Analytics نیست

مختصات دقیق، هر Frame یا Gesture خام را بدون Purpose جمع نکنید. Assignment، Exposure، Consent و Dedup را تعریف کنید؛ Engagement time را Outcome خرید ننامید.

Observability تجربه 3D

Logها باید Asset revision، Runtime، Quality level و Failure stage را پیوند دهند. الگوی SLI/SLO، Trace و Incident عمومی در راهنمای Observability وب‌سایت آمده است.

Matrix تست تولید

شرایط کاربران ایرانی

مدل تصمیم را با «Mobile-first» کلی نبندید؛ Device، Operator، WebView، Network، دسترسی CDN/Package و هزینه داده را اندازه بگیرید.

• Android میان‌رده و WebViewهای رایج را جدا از Chrome Desktop تست کنید.
• فایل/Decoder/CDN را از چند ISP و اپراتور Fetch کنید؛ DNS/TLS/Range/CORS را ثبت کنید.
• هزینه Download و گزینه «نسخه سبک» پیش از Asset سنگین روشن باشد.
• RTL، متن فارسی Hotspot، عدد، ریال/تومان و BiDi در UI تست شوند.
• AR mode و Permission را روی Device واقعی تأیید کنید؛ فرض Platform نکنید.
• Mirror/Exit plan برای Package، CDN یا SaaS خارجی داشته باشید.
• Source file، License و امکان ادامه کار با Vendor دیگر در قرارداد بماند.

TCO؛ هزینه فقط ساخت مدل نیست

هزینه را در Range و به‌ازای SKU/Revision/Session گزارش کنید. صرفه‌جویی احتمالی Support یا Return را با Baseline و دوره مشاهده بسنجید؛ «3D فروش را افزایش می‌دهد» فرضیه است، نه ورودی قطعی ROI.

RACI

Runbook: Asset لود نمی‌شود

1. Poster و HTML Task را حفظ؛ Loader بی‌پایان را متوقف کنید.
2. Stage را جدا کنید: DNS/TLS/HTTP/CORS/cache/download/decode/parse/scene.
3. Asset revision/hash/MIME/content-length و Manifest را بررسی کنید.
4. Retry محدود با Backoff؛ 4xx/schema error را کور Retry نکنید.
5. اگر Incident سراسری است، Circuit breaker و Poster-only mode فعال کنید.
6. پس از Fix، Device/ISPهای متاثر و Cache invalidation را تأیید کنید.

Runbook: Frame rate افت یا دستگاه داغ می‌شود

1. Canvas size/render scale، visibility و loop دائمی را بررسی کنید.
2. Quality را Step-down کنید: Shadow/postprocess/AA/LOD/texture.
3. CPU/Long task را از GPU frame time جدا کنید.
4. Draw call/material/transparent object و Overdraw را Profile کنید.
5. رندر خارج Viewport/Tab و Animation تمام‌شده را Pause کنید.
6. اگر Guardrail برنمی‌گردد، Poster mode و Rollback را فعال کنید.

Runbook: Memory رشد می‌کند

1. مسیر open→switch SKU→close را تکرار و Trend بگیرید.
2. Scene reference، listener، RAF، loader و cacheهای سفارشی را Audit کنید.
3. Geometry/Material/Texture/Render target/ImageBitmap را طبق Ownership آزاد کنید.
4. Shared resource را با Reference count یا Lifecycle روشن مدیریت کنید.
5. پس از Cleanup، plateau را روی Session طولانی و Device ضعیف تأیید کنید.

Runbook: Variant تصویرشده با سفارش فرق دارد

1. افزودن به Cart را برای Mapping معیوب موقتاً متوقف کنید.
2. UI option، rule version، variant ID، asset revision و Backend response را Join کنید.
3. Scope سفارش‌های متاثر و پیام/پشتیبانی را تعیین کنید.
4. Manifest/Rule را Rollback و Cache را Purge کنید.
5. Contract test برای ترکیب خطادار اضافه و Compensation process را اجرا کنید.

برنامه ۹۰روزه

روز ۱ تا ۳۰: Outcome و Baseline

• یک Task با ابهام واقعی و یک Cohort هدف انتخاب کنید.
• Baseline تصمیم، Performance، Error، Support و Outcome را ثبت کنید.
• Capability ladder، Fallback، Device/Network matrix و Kill rule را تصویب کنید.
• سخت‌ترین Asset و حقوق/Source/Scale/Variant contract را آماده کنید.

روز ۳۱ تا ۶۰: PoC سخت‌گیرانه

• PoC را روی Device ضعیف و Network واقعی اجرا کنید.
• Asset pipeline، Poster-first، Timing marks و Adaptive quality بسازید.
• Keyboard/Screen reader/reduced motion، Fallback و Context loss را تست کنید.
• Variant mapping، Price/Inventory validation و Event contract را تکمیل کنید.

روز ۶۱ تا ۹۰: Pilot و تصمیم

• Canary محدود با Feature flag و Rollback منتشر کنید.
• Outcome را کنار Guardrailهای CWV/Error/Memory/Support بسنجید.
• Runbookهای Load/Frame/Memory/Variant را Drill کنید.
• Scale، Iterate یا Kill را با Evidence و TCO تصمیم بگیرید.

اشتباه‌های پرتکرار

چک‌لیست پیش از انتشار

• Outcome، Success، Guardrail، Fallback و Kill rule نوشته شده‌اند.
• کمینه سطح فناوری انتخاب و Compatibility snapshot ثبت شده است.
• Source/License/Scale/Axis/Color و Asset revision قابل‌ممیزی‌اند.
• Geometry/Material/Texture/Animation برای Task بهینه و validate شده‌اند.
• Poster-first، Load on intent، Abort/Timeout و Fallback کار می‌کنند.
• Network/CPU/GPU/Memory/Energy budget روی Device هدف سنجیده شده‌اند.
• Adaptive quality، visibility pause، dispose و context loss تست شده‌اند.
• Keyboard، Screen reader، Reduced motion، Device-motion alternative و Error قابل‌دسترسی‌اند.
• محتوای اصلی، Price، Availability و Hotspotهای ضروری در HTML هستند.
• Asset/Decoder/CDN/XR/Analytics security و privacy بررسی شده‌اند.
• Variant mapping و Server validation با حالت out-of-stock/price change تست شده‌اند.
• Timing/Error/Quality/Asset revision و Task outcome Observable هستند.
• Device/Browser/Operator/ISP/RTL ایران در Matrix حضور دارند.
• Canary، Feature flag، Rollback، Runbook، RACI و TCO تصویب شده‌اند.

پرسش‌های متداول

طراحی سه‌بعدی سایت چه زمانی ارزش دارد؟

وقتی فرم، زاویه، اتصال، مقیاس یا پیکربندی واقعاً ابهام تصمیم کاربر را کم کند و Outcome آن کنار Guardrailهای سرعت، خطا و هزینه سنجیده شود. اگر تصویر، ویدئو یا جدول همان Task را حل می‌کند، راه ساده‌تر معمولاً انتخاب بهتری است.

آیا WebGPU جای WebGL را گرفته است؟

خیر. در Snapshot اوت ۲۰۲۶، MDN هنوز WebGPU را غیرBaseline و با دسترسی محدود معرفی می‌کند. برای وب عمومی Feature/Capability detection، WebGL یا Engine fallback و در نهایت Poster/HTML لازم است.

بهترین فرمت مدل سه‌بعدی برای وب چیست؟

glTF/GLB انتخاب رایجی برای Runtime delivery است، اما «بهترین» به Engine، AR، Animation، Extension و Cache strategy بستگی دارد. خود فرمت تضمین نمی‌کند Geometry، Texture، Material یا Memory بهینه باشند؛ Pipeline و Device test ضروری‌اند.

چگونه 3D را بدون خراب‌کردن سرعت سایت اجرا کنیم؟

Poster را اول نشان دهید، Asset را پس از Intent با قابلیت Cancel لود کنید، Drawing buffer و Texture/Geometry را Budget کنید، Quality تطبیقی و Render-on-demand بسازید، خارج Viewport رندر را متوقف و Memory/Context loss را تست کنید. CWV و Task outcome باید کنار Frame/Memory سنجیده شوند.

آیا محتوای داخل Canvas برای سئو و دسترسی کافی است؟

خیر. نام، توضیح، مشخصات، Price/Availability، کنترل‌ها و اطلاعات ضروری باید در HTML/DOM یا Alternative معادل باشند. Canvas مکمل تجربه است، نه تنها منبع حقیقت برای Search engine، Screen reader یا کاربرِ بدون Runtime.

جمع‌بندی: Immersion باید از Complexity سود بیشتری بسازد

تجربه سه‌بعدی Production یک فایل GLB و چند خط Three.js نیست؛ زنجیره‌ای از Outcome، Asset data، Runtime capability، GPU/Memory، Accessibility، Commerce truth و Operations است. هر حلقه‌ای که بی‌مالک بماند می‌تواند Demo زیبا را به صفحه کند، سفارش غلط یا تجربه غیرقابل‌دسترسی تبدیل کند.

برای شروع، یک SKU و یک Task انتخاب کنید. Poster/HTML سالم را خط پایه بگذارید، سخت‌ترین Asset را روی ضعیف‌ترین Device هدف آزمایش کنید و تنها وقتی Scale کنید که Outcome بهتر شده و Guardrailها، TCO و Runbook قابل‌قبول‌اند.