This checklist is a pre-launch reference for WebAR developers and producers. It covers every major category of performance optimisation: 3D assets, textures, loading, tracking, rendering, device testing, analytics, and post-launch monitoring. Work through each section before deploying a new experience, and return to it when investigating performance issues in the field.
For the underlying rationale and technical depth behind each item, see the companion guide: WebAR Performance Optimisation: The Complete Developer Guide.
Performance targets to benchmark against throughout:
| Metric | Target |
| Frame rate | 60fps target, 30fps minimum on mid-range devices |
| Time to first render | < 3 seconds on 4G connection |
| Total initial asset bundle | < 5MB (simple/standard experiences) |
| Total triangle count (scene) | < 100,000 triangles |
| Draw calls per frame | < 50 |
| Maximum texture resolution | 1024×1024 (2048×2048 for hero assets on high-end targets) |
1. 3D asset preparation
| Check | Target / Notes |
| □ Polygon/triangle count audited for all meshes | < 100k total scene; 10k–50k per hero object |
| □ Interior and invisible geometry removed | Delete any surface not visible to camera |
| □ Static meshes merged where appropriate | Reduces draw calls; merge objects that move together |
| □ Mesh decimation applied using appropriate tool | Blender Decimate, RapidCompact, or Simplygon |
| □ Level of Detail (LOD) implemented where supported | Multiple mesh resolutions at different view distances |
| □ File exported as glTF 2.0 (.glb) | Standard format for WebGL delivery |
| □ Draco geometry compression applied to .glb | Targets 70–80% file size reduction |
| □ File tested for import in target SDK/platform | Verify in Blippbuilder or WebAR SDK viewer before build |
2. Textures and materials
| Check | Target / Notes |
| □ All textures use power-of-two dimensions | 512, 1024, or 2048. This is required for mipmapping. |
| □ Maximum texture resolution enforced | 1024×1024 default; 2048×2048 only for hero assets |
| □ KTX2/Basis Universal compression applied | GPU-native compression; reduces runtime memory footprint |
| □ Texture atlas created for shared-material objects | Combine multiple textures into one atlas to cut draw calls |
| □ Number of unique materials minimised | Target ≤ 5 unique materials per scene |
| □ Lighting baked into textures where possible | Avoids real-time lighting cost; pre-bake ambient occlusion |
| □ Alpha transparency used sparingly | Avoid large alpha maps; use cutout alpha where possible |
| □ Normal maps compressed separately | Use BC5 or EAC compression for normal map channels |
| □ Texture memory budget estimated and within target | Estimate total uncompressed VRAM; stay under 256MB |
3. Loading and streaming
| Check | Target / Notes |
| □ Total initial asset bundle measured and within target | < 2MB simple; < 5MB standard; progressive loading for 5MB+ |
| □ Loading indicator implemented with progress feedback | Users tolerate waits; show branded progress UI |
| □ Tracking targets preloaded before 3D assets | Initialise tracking as early as possible in load sequence |
| □ Progressive/lazy loading for multi-state experiences | Defer loading of later-state assets until needed |
| □ Assets served via CDN with appropriate cache headers | Reduces repeat-visit load times significantly |
| □ HTTP/2 confirmed on hosting environment | Enables parallel asset loading over a single connection |
| □ WebP format used for 2D image assets | Better compression than PNG/JPEG for textures that can’t use KTX2 |
| □ Gzip or Brotli compression enabled on server | Applies to JavaScript, JSON, and uncompressed assets |
4. Tracking configuration
| Check | Target / Notes |
| □ Image target quality evaluated before finalising print | High contrast, complex pattern, asymmetric composition |
| □ Image target minimum on-screen size confirmed | 8cm × 8cm at expected scanning distance |
| □ Image targets tested under varied lighting conditions | Strong, dim, and mixed lighting; avoid pure reflective surfaces |
| □ Surface tracking tested on varied surface textures | Avoid blank walls, glass, uniform fabrics |
| □ Placement confirmation UI implemented for SLAM | Let users tap to place; avoids unstable auto-placement |
| □ Face tracking tested across skin tones and glasses | Check tracking stability for diverse users |
| □ Tracking loss recovery behaviour defined and implemented | Graceful UX response to tracking loss, not a blank screen |
| □ Tracking targets tested on final printed/displayed artwork | Digital preview ≠ print; test on physical material before launch |
5. Rendering and scene optimisation
| Check | Target / Notes |
| □ Draw call count profiled and within target | < 50 draw calls per frame for mobile |
| □ Real-time dynamic shadows disabled or replaced | Use baked shadows or blob shadows instead |
| □ Particle system counts capped | < 500 particles; use sprite sheets not 3D geometry |
| □ Post-processing effects removed or disabled for mobile | Bloom, depth of field, SSAO are expensive on mobile |
| □ Render loop reviewed for unnecessary per-frame computation | Move non-render work out of rAF loop |
| □ Web Workers used for heavy computation | Physics, analytics events, data fetching off main thread |
| □ Memory leaks profiled and resolved | Check for accumulating event listeners and unreleased textures |
| □ Frame rate profiled in Chrome DevTools Performance tab | Look for JavaScript long tasks and GPU overdraw |
| □ WebGL extensions used efficiently | Only request extensions the experience actually needs |
6. Device and browser testing
| Check | Target / Notes |
| □ Tested on iOS Safari (iPhone 11 or older (lower bound)) | A13 chip, 4GB RAM – typical mid-range iOS device |
| □ Tested on iOS Safari (iPhone SE 2nd gen (budget target)) | A13 chip, 3GB RAM – tests budget iOS users |
| □ Tested on Android Chrome (Snapdragon 695 or equivalent) | Representative mid-range Android device (Samsung A-series) |
| □ Tested under throttled network conditions | Chrome DevTools ‘Fast 4G’ preset; note load time |
| □ Tested on slow network (Slow 4G / 3G) where relevant | Check load failure and timeout behaviour |
| □ WebXR feature detection implemented with fallback | Graceful degradation on non-supporting browsers |
| □ iOS WKWebView limitations accounted for | No SharedArrayBuffer; limited WebGL2 support on older iOS |
| □ Android browser compatibility matrix confirmed | Chrome, Samsung Internet, Firefox; not all support WebXR |
| □ Memory usage profiled on low-spec device | Check for crash under 3GB RAM conditions |
| □ Experience tested in landscape and portrait orientations | Confirm UI and tracking behave correctly in both |
7. Analytics and instrumentation
| Check | Target / Notes |
| □ Blippar analytics dashboard enabled and verified | Confirms views, interactions, session data are recording |
| □ Custom load time metric implemented | Time from page load to first tracking acquisition |
| □ Frame rate drop events logged | Log events when frame rate falls below 25fps threshold |
| □ Loading stage abandonment tracked | Identifies asset size problems causing pre-render exits |
| □ Tracking failure / tracking loss events logged | Quantifies tracking quality issues in real-world conditions |
| □ Device/OS breakdown available in reporting | Ensures you can identify device-specific performance issues |
| □ Third-party analytics integration tested (if applicable) | GA4, Mixpanel, Amplitude – verify event schema and timing |
| □ Campaign UTM parameters present in experience URL | Enables attribution in downstream marketing analytics |
8. Post-launch monitoring
Performance does not end at launch. Real-world usage surfaces issues that testing cannot anticipate. Establish a monitoring cadence for the first two weeks of any major campaign.
| Check | Target / Notes |
| □ Analytics reviewed within 48 hours of launch | Check for unexpected drop-offs, loading failures, device issues |
| □ Frame rate and load time data reviewed against targets | Flag any metrics outside of pre-launch benchmarks |
| □ User feedback channels monitored | Social, support inbox, App Store equivalent (where applicable) |
| □ Device breakdown compared against campaign audience | If 40% of users are on Android, ensure Android is performing well |
| □ Any CDN or hosting issues identified and resolved | Cache invalidation, 404s on assets, CORS issues |
| □ Follow-up optimisation sprint scheduled if required | Don’t treat launch as final; performance improves iteratively |
How to Use This Checklist
This checklist is intended as a pre-launch gate, not a once-off document. Copy it into your project management tool of choice (Jira, Linear, Notion, Asana) and assign each section to the appropriate team member. Sections 1 to 5 are primarily for developers and 3D artists; sections 6 to 7 involve QA and analytics leads; section 8 is for producers and account managers.
For new teams adopting WebAR for the first time, working through sections 1 to 3 will typically surface the largest performance gains. For experienced teams, sections 5 and 6 are where the most common regressions are missed.
Building a WebAR experience?
If you’re ready to explore what WebAR can do for your next campaign, or want to understand what your first experience could look like, talk to the Blippar team.
Click here to book a discovery call with Blippar Studios to see how we can bring your campaign to life.
Sources & further reading
Blippar WebAR SDK Documentation