Optimized project dashboard loading for multi-project environment

PLM Aras Innovator
, , , , , , , ,
1

We recently optimized our project tracking dashboard that was struggling with 200+ active projects. Initial load times were hitting 45-60 seconds, making it unusable for project managers who needed quick status updates.

Our approach focused on summary-first data loading and API payload optimization. Instead of fetching complete project details upfront, we implemented a two-tier loading strategy. The dashboard now loads essential summary data first (project name, status, health indicators) via a streamlined API call:

const summaryData = await fetch('/api/projects/summary', {
  method: 'POST',
  body: JSON.stringify({ fields: ['name', 'status', 'health', 'id'] })
});

We also added dashboard query caching at the server level with 5-minute TTL for summary data, and implemented on-demand detail fetching when users expand specific projects. This reduced initial payload from 8MB to 320KB and cut load time to under 4 seconds. The combination of lazy loading detailed project data and aggressive caching for frequently accessed summaries made the dashboard responsive even during peak usage hours.

2

Impressive results! The summary-first approach is solid. Have you considered implementing virtual scrolling for the project list? With 200+ projects, rendering all DOM elements upfront could still cause browser performance issues even with optimized data loading. Libraries like react-window can render only visible rows, further reducing initial render time. Also, are you using any client-side state management to avoid redundant API calls when users navigate back to the dashboard?

3

Good question. We implemented selective cache invalidation. When critical fields change (status, health), we clear that specific project’s cache entry immediately. For less critical updates like description changes, we let TTL handle it. We added event listeners on the Project ItemType that trigger cache invalidation through our custom API middleware. This keeps the dashboard responsive while ensuring critical updates appear immediately.

4

This is exactly what we need! Our dashboard is crawling with just 80 projects. Quick question - how did you handle the caching invalidation? When a project status changes, do you immediately clear the cache or wait for TTL expiration?

5

Excellent feedback from everyone. Let me provide a comprehensive summary of our complete implementation approach for anyone looking to replicate this.

Summary-First Data Loading Implementation: We restructured our API endpoints to separate summary and detail data. The summary endpoint returns only 8 essential fields per project, while detail endpoints are called on-demand. This reduced initial payload by 96% (from 8MB to 320KB). The summary API uses Aras’s select attribute in AML queries to fetch only required properties:

<Item type="Project" action="get" select="name,status,health_indicator,id,owned_by_id,start_date,target_date,actual_cost">
  <state>Active</state>
</Item>

API Payload Optimization: Beyond field selection, we implemented response compression at the IIS level (gzip/brotli) and switched from XML to JSON responses for dashboard APIs. We also batch related data - instead of separate calls for project managers and teams, we include minimal manager info (id, name) in the summary response and fetch full team details only when needed.

Dashboard Query Caching: We implemented a two-layer caching strategy. Server-side uses Aras’s Cache service with 5-minute TTL for summary data and 15-minute TTL for relatively static data like project templates and workflow definitions. Client-side uses Redux with session persistence and implements stale-while-revalidate pattern - shows cached data immediately while fetching fresh data in background. Cache keys include user identity to handle permission-filtered results correctly.

On-Demand Detail Fetching: When users expand a project, we fetch detailed information including full team roster, milestone details, risk assessments, and recent activity logs. We implemented intelligent prefetching using Intersection Observer API - when a project row enters the viewport (user scrolling), we prefetch its details with low priority. By the time users actually click to expand, data is usually already loaded. This creates a 90% “instant expansion” experience.

Additional Optimizations: Implemented virtual scrolling with react-window (renders ~20 visible rows), debounced search/filter inputs (300ms), and added loading skeletons for better perceived performance. Database indexes on frequently queried Project fields (status, owned_by_id, start_date) reduced query time from 2.1s to 180ms.

Results:

  • Initial load: 45-60s → 3.8s (92% reduction)
  • Project expansion: 3-5s → 0.2s with prefetch (95% reduction)
  • Dashboard refresh: 45s → 0.8s with cache (98% reduction)
  • User satisfaction: 3.2/10 → 8.7/10
  • Server load during peak: reduced by 67% due to caching

Implementation Tips:

  1. Start with API optimization - it provides the biggest win
  2. Implement caching incrementally and monitor hit rates
  3. Use browser DevTools Network tab to identify payload bottlenecks
  4. Consider user behavior patterns when deciding what to prefetch
  5. Always implement cache invalidation strategy before deploying caching
  6. Test with realistic data volumes and concurrent users

The key insight was recognizing that project managers rarely need all details for all projects simultaneously. By aligning our data loading strategy with actual usage patterns, we achieved dramatic performance improvements without requiring infrastructure upgrades.