We’re experiencing significant performance issues with our production dashboard on CT32 handhelds running HM 2022.2. When operators access the performance metrics screen, there’s a 15-20 second delay before data appears, and refresh cycles take another 10-12 seconds. This wasn’t an issue on our old desktop terminals.
The dashboard pulls real-time OEE data, downtime events, and production counts. We have about 35 operators using these devices simultaneously during peak shifts. I’m wondering if this is related to mobile browser resource limits on the CT32 or if our API payload size is too large for these devices. The server-side pagination isn’t configured yet - we’re pulling full datasets.
Operators are frustrated because they need quick access to metrics for shift handoffs. Has anyone optimized dashboard performance for mobile devices? Should we be monitoring device management metrics differently?
Thanks for the suggestions. I checked our API responses and we’re pulling about 850KB of data per refresh, which includes the last 48 hours of events. That’s definitely too much. How granular should the pagination be for mobile? And should we implement different dashboard views for mobile versus desktop?
Don’t forget about the device management monitoring aspect. CT32 handhelds have limited CPU and memory compared to modern smartphones. You should be tracking device performance metrics through your MDM solution - CPU usage, memory consumption, and network latency. We discovered that our devices were running background processes that competed with the browser for resources. After optimizing the device configuration and disabling unnecessary services, dashboard performance improved by 30% even before we fixed the API issues.
For CT32 devices, I recommend a mobile-optimized view that shows only current shift data by default with an option to expand to previous shifts. Pagination should be 25-50 rows max per page. Also consider implementing lazy loading for charts and graphs - load the summary numbers first, then render visualizations after the critical data is displayed. We use separate API endpoints for mobile and desktop to control payload size at the server level rather than filtering client-side.
Your performance issue stems from multiple factors that need to be addressed systematically. Let me walk you through the complete optimization approach based on your specific scenario.
Mobile Browser Resource Limits: The CT32 handhelds have approximately 2GB RAM and limited browser heap memory (typically 256-512MB). Your 850KB payload per refresh is consuming significant resources, especially when combined with DOM rendering for charts and tables. Implement a mobile-specific dashboard that limits initial data load to current shift only (last 8-12 hours maximum). Use progressive enhancement - load critical metrics first, then secondary data asynchronously.
API Payload Optimization: Your current approach of pulling 48 hours of events is designed for desktop consumption. Create a new API endpoint specifically for mobile devices: /api/mobile/dashboard/summary that returns only aggregated metrics (current OEE, active downtime events, shift production count) in a lightweight format. This should reduce payload to under 100KB. For detailed drill-downs, implement on-demand loading with separate API calls rather than pre-loading all data.
Server-Side Pagination: Implement cursor-based pagination rather than offset-based for better performance with large datasets. Configure page size at 25 rows for mobile devices. Add response headers that indicate total records and current page position. On the mobile UI, use infinite scroll or explicit “Load More” buttons rather than traditional pagination controls - this works better on touch interfaces and reduces memory pressure.
Device Management Monitoring: Enable performance monitoring through your MDM solution to track CT32 device health. Key metrics to monitor: browser memory usage (alert if exceeds 400MB), CPU utilization during dashboard access (should stay below 70%), network request latency (baseline and compare), and crash reports. We’ve found that devices with outdated firmware or excessive background apps can show 40-50% performance degradation. Schedule regular device maintenance windows to clear cache and restart services.
Additional Recommendations: Implement client-side caching using localStorage for reference data (work centers, product definitions, operator lists) that doesn’t change frequently. Enable HTTP compression (gzip) on your API responses - this typically reduces payload size by 60-70%. Consider using WebSockets for real-time updates instead of polling, which reduces network overhead and provides instant updates. Finally, add performance timing instrumentation to your mobile dashboard using the Navigation Timing API to identify specific bottlenecks in your loading sequence.
Test these changes incrementally and measure impact at each step. You should see dashboard load times drop to 3-5 seconds initially, with refresh cycles under 2 seconds once caching is established.