# How to Test 3D & AR on Your Product Pages Before Launch > Source: https://blog.pixlnexs.com/how-to-test-3d-and-ar-product-pages-before/ > Published: 2026-10-07 · Author: kishore > Quick answer: How to test 3D and AR on your product pages before launch, run a structured QA pass that checks model file weight, mobile load speed, AR placement scale, material accuracy, controls and device fallbacks before a single customer sees it. The failure point is rarely launch day itself it is the thing nobody […] --- > **Quick answer:** How to test 3D and AR on your product pages before launch, run a structured QA pass that checks model file weight, mobile load speed, AR placement scale, material accuracy, controls and device fallbacks before a single customer sees it. The failure point is rarely launch day itself it is the thing nobody checked: a sofa that loads at doll size in AR, a 40MB model that stalls on 4G or a “View in your space” button that does nothing on an older Android. This is the pre-launch checklist that catches those failures before your customers do. By Bali Balaji, Pixlnexs Studio. Pixlnexs builds, optimizes and stress-tests 3D and AR product experiences for ecommerce brands across furniture, fashion, electronics and packaged goods and this checklist is the exact QA pass our production team runs before any product page with 3D or AR goes live. Table of Contents [Toggle](#) - [Key Takeaways](#Key_Takeaways) - [Why the QA Stage Is Where Conversions Are Won or Lost](#Why_the_QA_Stage_Is_Where_Conversions_Are_Won_or_Lost) [The Cost of a Broken 3D Launch Is Invisible Until It Isn’t](#The_Cost_of_a_Broken_3D_Launch_Is_Invisible_Until_It_Isnt) - [What a Passing QA Actually Looks Like](#What_a_Passing_QA_Actually_Looks_Like) - [How to Test 3D and AR: The Full Pre-Launch Checklist](#How_to_Test_3D_and_AR_The_Full_Pre-Launch_Checklist) [Why Order Matters in This Checklist](#Why_Order_Matters_in_This_Checklist) - [When to Retest After Changes](#When_to_Retest_After_Changes) - [How to Test 3D and AR Across the Right Device Matrix](#How_to_Test_3D_and_AR_Across_the_Right_Device_Matrix) [Why the Oldest Device in the Matrix Decides Whether You Ship](#Why_the_Oldest_Device_in_the_Matrix_Decides_Whether_You_Ship) - [How to Source Older Test Devices Without a Device Lab](#How_to_Source_Older_Test_Devices_Without_a_Device_Lab) - [Getting AR Placement Scale Right Before Launch](#Getting_AR_Placement_Scale_Right_Before_Launch) [A Scale Test That Holds Across Product Categories](#A_Scale_Test_That_Holds_Across_Product_Categories) - [When Scale Fails: What It Means and How to Fix It](#When_Scale_Fails_What_It_Means_and_How_to_Fix_It) - [Testing Materials, Lighting and Controls Before 3D Goes Live](#Testing_Materials_Lighting_and_Controls_Before_3D_Goes_Live) [Testing Material Accuracy Without a Trained Eye](#Testing_Material_Accuracy_Without_a_Trained_Eye) - [What a Broken Control Scheme Looks Like in Practice](#What_a_Broken_Control_Scheme_Looks_Like_in_Practice) - [Page Speed and Core Web Vitals: Keep 3D from Dragging the Page Down](#Page_Speed_and_Core_Web_Vitals_Keep_3D_from_Dragging_the_Page_Down) [The Three Core Web Vitals Checks Specific to 3D](#The_Three_Core_Web_Vitals_Checks_Specific_to_3D) - [Measuring Before and After With Lighthouse](#Measuring_Before_and_After_With_Lighthouse) - [From Build to Launch: Where 3D and AR Testing Fits](#From_Build_to_Launch_Where_3D_and_AR_Testing_Fits) [What Happens When a Model Fails QA](#What_Happens_When_a_Model_Fails_QA) - [The QA Sign-Off Document](#The_QA_Sign-Off_Document) - [Common Failures to Watch for When You Test 3D and AR](#Common_Failures_to_Watch_for_When_You_Test_3D_and_AR) - [Conclusion](#Conclusion) [Ready to Launch 3D and AR With Confidence?](#Ready_to_Launch_3D_and_AR_With_Confidence) - [Frequently Asked Questions](#Frequently_Asked_Questions) [How Many Devices Do I Actually Need to Test 3D and AR On?](#How_Many_Devices_Do_I_Actually_Need_to_Test_3D_and_AR_On) - [Why Does AR Work on iPhone but Not Android or the Reverse?](#Why_Does_AR_Work_on_iPhone_but_Not_Android_or_the_Reverse) - [How Do I Check AR Placement Scale Is Correct?](#How_Do_I_Check_AR_Placement_Scale_Is_Correct) - [Will a 3D Viewer Hurt My Page Speed?](#Will_a_3D_Viewer_Hurt_My_Page_Speed) - [Can I Automate Any Part of This Testing Process?](#Can_I_Automate_Any_Part_of_This_Testing_Process) - [What Is the Single Most Common Reason a 3D Product Page Fails QA?](#What_Is_the_Single_Most_Common_Reason_a_3D_Product_Page_Fails_QA) - [Should I Retest After Every Product Update or Just at Initial Launch?](#Should_I_Retest_After_Every_Product_Update_or_Just_at_Initial_Launch) - [What Should the Fallback Look Like on Unsupported Devices?](#What_Should_the_Fallback_Look_Like_on_Unsupported_Devices) ## Key Takeaways - Test on real devices, not just your dev laptop a recent iPhone, an older iPhone, a recent Android, an older Android and desktop. - Scale accuracy is the make-or-break AR check a sofa must appear sofa-sized in the room, measured against something real. - Model weight drives everything keep files lean so mobile data users are not staring at a spinner. - Verify both AR paths USDZ via AR Quick Look on iOS, GLB via Scene Viewer on Android, plus a clean fallback for unsupported devices. - Watch Core Web Vitals a 3D viewer should enhance the page, not tank your page speed scores. - A failed QA check is a fast feedback loop back into production, not the end of the project catching issues before launch is always cheaper than catching them through customer returns or abandoned sessions. ## Why the QA Stage Is Where Conversions Are Won or Lost ![how to test 3D and AR](https://blog.pixlnexs.com/wp-content/uploads/2026/10/Why-the-QA-Stage-Is-Where-Conversions-Are-Won-or-Lost-1024x683.png) When a 3D viewer breaks on a product detail page, the customer does not file a bug report. They leave. That is the quiet cost of skipping QA: not angry emails but a slow bleed of abandoned sessions and a drip of support tickets asking why the “spin the product” thing is frozen. We treat testing as the stage that protects the work everyone already did. The modeling team, the brand team and the developers all invested hours into interactive 3D on the product page. A bad first load on a mid-range phone erases that investment in three seconds. Done right, testing is cheap insurance. Skipped, it becomes the most expensive part of the launch. ### The Cost of a Broken 3D Launch Is Invisible Until It Isn’t The hard part about QA for 3D and AR is that failures don’t throw errors the way broken checkout flows do. A model that loads too slowly doesn’t crash the page it just sits there as a spinner while the shopper quietly closes the tab. An AR object placed at the wrong scale doesn’t trigger a console warning it just makes the customer trust your product page a little less, right at the moment they were closest to buying. Analytics will eventually surface the symptom: a drop in conversion on pages with 3D or a spike in returns for SKUs with AR enabled. But by then you are debugging weeks-old data instead of catching the problem on day one. The QA pass is what closes that gap. ### What a Passing QA Actually Looks Like A passing QA is not “it worked on my phone.” It is a documented pass across every row of your device matrix, with a specific human confirming each checklist item on each device. It means the viewer loaded within an acceptable time on a throttled 4G connection on an older phone. It means AR placement showed the product at true-to-life scale next to a physical reference object. It means the variant swap loaded the correct material without resetting the camera angle. Anything less is a partial pass and needs to go back into production before the page goes live. ## How to Test 3D and AR: The Full Pre-Launch Checklist ![How to Test 3D and AR: The Full Pre-Launch Checklist](https://blog.pixlnexs.com/wp-content/uploads/2026/10/How-to-Test-3D-and-AR-The-Full-Pre-Launch-Checklist-1024x683.png) Here is the practical checklist to run on every product page before it goes live. Work through it top to bottom, on each device in your test matrix, before publishing anything. - **Model file weight** confirm the GLB is optimized; aim for a lean file so first paint is fast. If it is heavy, send it back for optimization that preserves quality while cutting size. - **Mobile load speed on cellular data** throttle to 4G in dev tools, then test on a real phone on real data, not office Wi-Fi. - **Controls** rotate, zoom, pinch and reset all respond smoothly; no jank, no runaway spin. - **Variants and hotspots** color and material swaps load the correct asset and do not reset the camera awkwardly. - **Material and lighting** metals look metallic, fabric reads as fabric and the lighting matches the rest of your photography. - **AR placement scale** the object appears true-to-life in a room, measured against a known reference object. - **iOS AR path** “View in your space” launches [AR Quick Look with the USDZ file correctly.](https://blog.pixlnexs.com/usdz-files-ar-quick-look/) - **Android AR path** the same button opens Scene Viewer with the GLB correctly. - **Fallback** on unsupported or low-end devices, the viewer degrades to a clean image or the standard gallery, never a broken button. - **Core Web Vitals** the viewer loads without shoving layout around or blowing up your LCP score. ### Why Order Matters in This Checklist This list is not arbitrary. File weight comes first because nearly every downstream problem slow mobile load, janky controls, poor Core Web Vitals traces back to a model that is heavier than it needs to be. Fix the weight first and several of the later checks often pass on their own. AR placement scale comes before the individual iOS and Android AR path checks, because scale is a property of the source file itself. If scale is wrong, it will be wrong on both platforms and testing each AR path individually before confirming scale just means debugging the same problem twice. ### When to Retest After Changes A passed QA check covers the model as it was at the time of testing. Retest any time the GLB or USDZ file itself changes including a re-export, a material update or a new variant added to an existing product. A change to pricing or description text does not require a new 3D QA pass but any change to the actual model file does, since export settings and compression can shift between versions even when the visual difference looks minor. ## How to Test 3D and AR Across the Right Device Matrix Testing on one shiny flagship phone is the trap. Your customers are on a spread of hardware and the older devices are exactly where 3D struggles first. Test across a small but deliberate matrix that covers both ends of the range and both operating systems. The table below is the matrix we hand to clients. Run every row, note pass or fail and do not publish until the older devices clear too. Device | What to Check | AR Engine | Pass Criteria | Recent iPhone (iOS) | Load speed, controls, AR placement, scale | AR Quick Look (USDZ) | Loads under a few seconds; AR opens; object is true-to-life size | Older iPhone (2–3 yrs) | Load speed, frame rate, AR launch | AR Quick Look (USDZ) | No stutter; AR button still works; no crash on heavy models | Recent Android | Load speed, controls, AR placement, scale | Scene Viewer (GLB) | Loads cleanly; AR opens; correct real-world scale | Older / mid-range Android | Load on 4G, fallback behaviour | Scene Viewer (GLB) | Either AR works or fallback shows; no dead button | Desktop (Chrome / Safari) | Rotate, zoom, variants, lighting | No AR (viewer only) | Smooth controls; materials accurate; no console errors | ### Why the Oldest Device in the Matrix Decides Whether You Ship It is tempting to test on the newest phone in the office and call it done, since that is usually the best-performing hardware available. But that phone is not representative of your actual traffic. A meaningful share of ecommerce visitors are on devices two or three years old, with less GPU headroom and slower memory, often on a mobile network rather than Wi-Fi. If a model only performs acceptably on this year’s flagship, it will visibly stutter, delay or fail outright for a real portion of your customers. The rule we hold ourselves to: if it does not pass on the oldest device in the matrix, it does not go live. That one rule prevents the bulk of post-launch support tickets we have ever seen on 3D product pages. ### How to Source Older Test Devices Without a Device Lab Most teams do not have a formal device lab. The practical approach is a small pool of personal devices supplemented by browser-based device simulators for initial load testing. Chrome DevTools’ device emulation is useful for confirming responsive layout and throttled network behavior but it is not a substitute for real hardware for AR testing AR Quick Look and Scene Viewer only run on real iOS and Android devices, not in a browser simulator. For genuine AR path testing, you need physical hardware. If your team does not have an older Android device, a refurbished mid-range Android phone from two or three years ago costs a small amount and pays for itself immediately as a permanent QA asset. It is the cheapest way to find the problems that flagship testing misses. ## Getting AR Placement Scale Right Before Launch Scale is the single AR check that customers notice instantly. A sofa that drops into the room at coffee-table size destroys trust and a ring that appears the size of a bracelet does the same. Test placement against a real-world reference: stand the AR object next to an actual chair, a door frame or a tape measure on the floor and confirm the proportions hold. Both AR engines read scale from the source file, so when you test 3D and AR for sizing, you are really validating that the model was exported in correct real-world units. If the iOS USDZ and the Android GLB disagree on size, the export pipeline is the culprit. See our breakdown of [GLB vs USDZ for your store](https://blog.pixlnexs.com/glb-vs-usdz/) for why both files need to match and how to confirm they do before launch. ### A Scale Test That Holds Across Product Categories The specific reference object changes by category but the principle does not. For furniture, place the AR model next to a doorway or a chair you can measure directly. For jewelry, compare against a coin or a ruler held at the same distance from the camera. For packaging and beverage products, stand the model next to a real can or bottle of known dimensions. In every case the test is the same: a physical, measurable object in the same AR scene as the digital one, so any scale error is visible immediately rather than something a customer discovers only after the product arrives. ### When Scale Fails: What It Means and How to Fix It Scale failures always trace back to the export, not the geometry. A model that looks correct in Blender or in your modeling tool but renders oversized or undersized in AR was exported in the wrong unit system centimeters when the engine expected meters or vice versa. The fix is a re-export with the correct unit settings, not a rebuild of the model. This is a fast fix in production, which is exactly why catching it in QA before launch costs almost nothing, while catching it after launch through customer complaints costs the brand’s credibility in AR as a feature. ## Testing Materials, Lighting and Controls Before 3D Goes Live Beyond AR, the in-page viewer has to look right and feel right. Check that materials render as intended on each device phone GPUs handle reflections differently from desktop and a brushed-metal finish that sings on your monitor can go flat on a budget Android. Then test the controls a shopper will actually use: a slow drag to rotate, a pinch to zoom into stitching or a logo and a tap to swap a variant. These micro-interactions are what make interactive 3D lift sales and a clunky control scheme quietly undoes the whole effect. For the bigger picture on what a polished viewer should do, our [interactive 3D product visualization guide](https://blog.pixlnexs.com/interactive-3d-product-visualization-ecommerce/) covers it end to end. ### Testing Material Accuracy Without a Trained Eye You do not need a 3D artist on staff to catch most material problems. Put the product viewer side by side with your existing studio photography of the same product and ask one question: does this look like the same item? Metals that look plastic, fabric that looks glossy or a surface that is noticeably too dark or too bright compared to the real photos are the most common and most obvious failures and they are catchable by anyone on the team, not just whoever built the model. The one failure mode that is harder to spot without a technical eye is baked-in lighting in the albedo texture a model whose color texture already contains shadows and highlights from a render will look wrong the moment the engine lights it from a different angle. This produces double shadows and a flat, plastic appearance where there should be depth. If your model looked gorgeous in the asset preview but looks off in the live viewer, this is the first thing to check. ### What a Broken Control Scheme Looks Like in Practice The most common control failures are not dramatic crashes they are small frictions that add up. A rotation that overshoots and keeps spinning after the user lifts their finger. A pinch-to-zoom that zooms in but will not zoom back out past a certain point. A variant swap that resets the camera to the default angle instead of keeping the shopper’s current view. None of these show up in automated tests they only surface when a real person interacts with the viewer the way a shopper actually would, which is why this step belongs in a manual QA pass and not only in an automated pre-launch script. ## Page Speed and Core Web Vitals: Keep 3D from Dragging the Page Down ![Page Speed and Core Web Vitals: Keep 3D from Dragging the Page Down](https://blog.pixlnexs.com/wp-content/uploads/2026/10/Page-Speed-and-Core-Web-Vitals-Keep-3D-from-Dragging-the-Page-Down-1024x683.png) A 3D viewer is heavier than a JPEG, so it has to be loaded with discipline. Lazy-load the viewer below the fold, defer the model until interaction or until the element scrolls into view and reserve its space in the layout so nothing jumps. That keeps Largest Contentful Paint and Cumulative Layout Shift in good shape. Run Lighthouse or PageSpeed Insights on the page before and after adding 3D. If the score drops meaningfully, the model is too heavy or it is loading too eagerly. This is also where briefing matters: getting the right export specs up front, as covered in our guide on [how to brief a 3D studio](https://blog.pixlnexs.com/how-to-brief-a-3d-studio-checklist/), prevents most page-speed regressions before they ever reach QA. ### The Three Core Web Vitals Checks Specific to 3D **Largest Contentful Paint (LCP):** confirm the 3D viewer is not the element Lighthouse flags as your LCP candidate. If it is, the viewer is loading too early and competing with your actual hero content for the browser’s attention. The viewer should be below the fold on initial load and lazy-loaded into the viewport only when the shopper reaches it. **Cumulative Layout Shift (CLS):** reserve the exact pixel dimensions the viewer will occupy before the model itself has loaded, using a placeholder or skeleton frame, so the page does not jump when the 3D content finally appears. An unreserved viewer container is one of the most common CLS sources on product pages with 3D. **Total Blocking Time (TBT):** a heavy model that decompresses and initializes on the main thread can block user interaction elsewhere on the page for a noticeable moment, especially on slower devices. Check this score specifically rather than assuming a visually smooth viewer means a technically light one. ### Measuring Before and After With Lighthouse The most reliable approach is a Lighthouse run on the product page without the 3D viewer, then a second run with it, using the same throttling settings both times. The delta between the two runs tells you exactly what the viewer costs in page-speed terms. If LCP increases significantly, the model is loading too eagerly. If CLS increases, the viewer container is not sized before the model loads. If TBT increases significantly, the model decode is blocking the main thread and needs further optimization or a lighter compression target before it goes live. ## From Build to Launch: Where 3D and AR Testing Fits Testing is not a bolt-on it is the gate at the end of the build. Once the model is created and exported and once you have gathered the right inputs, the QA pass decides whether it ships. For the full process of getting from a product brief to a finished, testable model, see our guide on [how to create an interactive 3D product model.](https://blog.pixlnexs.com/how-to-create-interactive-3d-product-model/) Our rule is simple: if it does not pass on the oldest device in the matrix, it does not go live. That one rule prevents the bulk of post-launch support tickets we have ever seen on 3D pages. ### What Happens When a Model Fails QA A failed QA check is not the end of the project it is a fast feedback loop back into production. A model that is too heavy goes back for optimization, not a full rebuild. A scale mismatch between the GLB and USDZ almost always traces back to export settings, not the geometry itself, so it is a quick re-export rather than new modeling work. Catching these issues in QA, before a customer ever sees the page, keeps a failed check cheap. The same issue caught after launch through a spike in returns or a drop in conversion costs far more to diagnose and fix. ### The QA Sign-Off Document Before any 3D product page goes live, we sign off on a simple document that lists every device in the matrix, every checklist item and a pass/fail with a note for any item that needed a fix. This is not bureaucracy it is the paper trail that tells you, three months after launch, exactly what was tested and on which device, so that when something changes in a platform update or AR engine update, you know exactly which test to rerun. ## Common Failures to Watch for When You Test 3D and AR These are the failures we see most often on 3D product pages, listed in roughly the order they are discovered during a QA pass. **Oversized or undersized AR placement.** Usually a unit-system mismatch in the export. Fix is a re-export, not a geometry rebuild. **Dead AR button on older Android.** The device either does not support Scene Viewer or the GLB was not served over HTTPS. Both have straightforward fixes; neither requires a new model. **Model loads on Wi-Fi but stalls on 4G.** The GLB is heavier than the geometry requires. Send back for optimization with a tighter polygon budget and compressed textures. **Variant swap resets camera to default view.** A viewer implementation issue, not a model issue. The viewer state should persist through a material swap and only reset when the user explicitly requests it. **Materials look correct on desktop but flat on mid-range Android.** Phone GPU limitations on specular calculations. The material setup needs adjustment for real-time rendering, not just offline preview quality. **Viewer causes a layout shift on page load.** The viewer container was not sized before the model loaded. Reserve the dimensions explicitly in CSS before the model initializes. **iOS and Android show different scale.** The USDZ and GLB were exported with different unit settings. Both files need to come from the same source with the same real-world unit configuration. ## Conclusion A 3D and AR product experience that fails on a real customer’s device is worse than no 3D at all it signals a broken page at the exact moment a shopper is closest to buying. The QA pass described in this guide is what stands between that outcome and a launch that works the way everyone intended. The checklist is not long. Five devices, ten checklist items, run once before launch and again any time a model file changes. The cost of doing it is an afternoon. The cost of skipping it is measured in abandoned sessions, support tickets and returns. If your model does not pass on the oldest device in the matrix, it does not go live. That rule, applied consistently, prevents the vast majority of post-launch 3D failures we have seen across ecommerce brands at every scale. ### Ready to Launch 3D and AR With Confidence? Pixlnexs builds, optimizes and stress-tests 3D and AR product experiences across real devices before they ever reach a customer. Talk to us about launching 3D on your product pages. [Talk to Pixlnexs About 3D Launch](https://pixlnexs.com/interactive-3d-ecommerce/) [Get in Touch](https://pixlnexs.com/contact/) ## Frequently Asked Questions ### How Many Devices Do I Actually Need to Test 3D and AR On? Five is enough for most stores: a recent iPhone, an older iPhone, a recent Android, an older or mid-range Android and one desktop browser. The older phones matter most, because that is where heavy models and AR launches tend to fail first. If you can only get access to three devices, prioritize an older mid-range Android, a recent iPhone and a desktop those three cover the majority of real-world failure scenarios in one pass. ### Why Does AR Work on iPhone but Not Android or the Reverse? iOS and Android use different AR engines and file formats AR Quick Look with USDZ on iOS, Scene Viewer with GLB on Android. If one works and the other does not, you are usually missing one of the two files or the device does not support AR, in which case a fallback should appear instead of a dead button. Confirm that both the GLB and the USDZ are being served and that the viewer is correctly linking each format to the right platform. ### How Do I Check AR Placement Scale Is Correct? Place the AR object next to a real reference a chair, a door frame or a tape measure and confirm the proportions match. If the object is too big or too small, the model was exported in the wrong real-world units and needs re-export, not a code fix. Both the GLB and USDZ need to match each other as well as the real-world dimensions, so check the scale on both platforms in the same session. ### Will a 3D Viewer Hurt My Page Speed? Only if it is loaded carelessly. Lazy-load the viewer, optimize the model file, reserve its layout space and the impact on Core Web Vitals stays minimal. Always measure with Lighthouse before and after adding the viewer to confirm. A correctly implemented, well-optimized 3D viewer adds no meaningful page speed cost for shoppers who do not scroll to the product section, since it never loads for them at all. ### Can I Automate Any Part of This Testing Process? Parts of it, yes. File weight checks, Lighthouse scores and basic load-time measurements can run as automated checks before a page goes live. AR placement scale, control feel and material accuracy still need a human looking at a real device, since those are judgment calls about how something looks and feels rather than pass/fail numeric thresholds. Automate what you can but do not skip the manual pass. ### What Is the Single Most Common Reason a 3D Product Page Fails QA? An oversized, unoptimized model file. It is the root cause behind most of the other failures on this checklist: slow mobile load, poor Core Web Vitals and sluggish AR launches on older devices all trace back to a GLB that is heavier than it needs to be for the detail level the product actually requires. The fix is always optimization and catching it in QA is always cheaper than catching it in production. ### Should I Retest After Every Product Update or Just at Initial Launch? Retest any time the model file itself changes a re-export, a material update or a new variant added to an existing product. A change to pricing or description text does not require a new 3D QA pass but any change to the GLB or USDZ file does, since export settings and compression can shift between versions even when the visual difference looks minor. ### What Should the Fallback Look Like on Unsupported Devices? The fallback should be seamless and invisible to the shopper a clean product image gallery or the standard photo set, with no broken button and no error message. The 3D or AR trigger button should either not appear at all on unsupported devices (capability detection before render) or appear as a disabled state with a clear “not available on this device” message. A button that appears but does nothing is the worst possible fallback, because it looks like a broken page rather than an unsupported feature.