In web analytics, a hit is the most atomic unit of activity: a single HTTP request to a server or endpoint. Load one HTML page? That’s one hit. The page then requests a CSS file, a JS bundle, eight images, and fires two tracking endpoints—each of those is also a hit. Hits measure server load, not people.
This is why “hits” can’t tell you how many users you had or how many pages they viewed. Those behavior metrics are covered by other concepts like a pageview, a session, a unique visitor, or an event.
Why hits are misleading for reporting
Front-end stacks are noisy. Modern pages commonly request dozens of assets and make background calls (A/B, ads, widgets). One “simple” pageview can explode into 50+ hits. Therefore, hits are poor KPI material; they scale with asset count, caching strategy, and third-party scripts, not with user engagement.
Quick comparison
| Metric | What it counts | Good for |
|---|---|---|
| Hit | Any request (file or endpoint) | Server/CDN load, log analytics |
| Pageview | A rendered page | Content performance |
| Event | A defined action (click, play, submit) | Interaction tracking |
Mini example
A landing page requests: 1 HTML + 1 CSS + 2 JS + 8 images + 1 font + 1 analytics endpoint.
Hits for one pageview:1 + 1 + 2 + 8 + 1 + 1 = 14 hits
If you preload two images and your analytics sends an extra engagement ping, that same pageview might jump to 17 hits—without any extra real-world engagement.
When to use the hit metric
- Capacity planning & cost: sizing servers/CDN, spotting asset bloat.
- Performance work: fewer requests generally mean faster loads.
- Log-based analysis: raw server logs are hit-centric by design.
Best practice
Report behavior with pageviews, sessions, and events; use hits for infrastructure health. If you see hits rising while pageviews are flat, you likely shipped heavier pages or added third-party calls—time to audit requests, trim assets, and bundle smarter.