App server requests greatly outnumber browser PageView transactions

You do not instrument every page of your app, or not every page uses auto-instrumentation.

Webpages are not text/html. (To avoid harming data, browser does not instrument non-HTML pages, because they are not intended to be parsed by a browser.)

Some requests to your backend are made through AJAX. AJAX throughput is tracked separately in browser's AJAX page.

Some requests do not come from fully functional web browsers. For example, they are API calls, or they come from devices that do not interpret JavaScript, such as RSS feed readers or search engine indexers.

Some requests come from very old browsers (earlier than IE 7), or they come from browsers that block cookies or JavaScript. For example, the Ghostery extension for Firefox will block page load timing.

A cache exists between your app server and your end users. Depending on whether cached pages are properly instrumented, this may cause balance to skew the other direction, with more browser throughput than app server.

Users navigate away from the page before it finishes loading or before it hits the window.onload() event.

Your New Relic weekly performance report includes the number of page views. This is the total number of page loads that we have recorded over the time period. After an end user's browser loads a page that includes page load timing, the JavaScript loads and reports its timing data. If the user navigates away from the page before the JavaScript executes, data is not sent for that page, and it is not included in the total page views report.