Requests per View
environmental
social
direct
This metric measures the number of HTTP requests triggered per page view. It captures how many network calls are required to load and render a page, making frontend and backend overhead visible.
In a Green Agile context, Requests per View highlights the relationship between frontend architecture, performance, and energy efficiency. A high number of requests often indicates fragmented assets, excessive third‑party integrations, or insufficient bundling and caching strategies, all of which increase latency, energy consumption, and operational overhead.
Classification
- Category: UX, Accessibility & Frontend Performance
- Measurement Frequency: per release
- Responsibility: Engineering Team
Impact
Reducing the number of requests per view improves loading performance and lowers network and server overhead. Fewer requests reduce connection setup costs, TLS handshakes, and repeated server processing, which directly contributes to lower energy consumption and more resilient performance, especially on slow or unstable networks.
Because this metric reflects the overhead generated by frontend and integration design choices, it represents a direct-impact metric. Improvements typically result from asset bundling, effective caching, API consolidation, and careful evaluation of third‑party services.
Calculation
Requests per View are calculated as the average number of HTTP requests per page view:
\[\text{Requests per View} = \frac{\sum \text{HTTP Requests}}{\text{Number of Views}}\]Teams typically define a request budget rather than a fixed threshold. The goal is to keep the number as low as reasonably possible while maintaining functionality, accessibility, and maintainability.
Example
Assume monitoring data for a page shows 400 page views during a release cycle. Across these views, the page triggered a total of 14,000 HTTP requests.
Using the formula:
\[\frac{14\,000}{400} = 35 \text{ requests per view}\]If previous releases averaged 50 requests per view, the reduction indicates successful consolidation of assets and removal of unnecessary third‑party calls. If the value increases, the team may investigate newly introduced dependencies, unbundled assets, or missing caching headers.