--- title: Browser monitoring and performance impact source: https://docs.newrelic.com/docs/browser/new-relic-browser/performance-quality/browser-monitoring-performance-impact --- The browser monitoring's JavaScript snippet introduces a nearly invisible impact on website performance and user perception of the time it takes a page to load. The JavaScript is included in a packet of webpage data that is sent anyway. In addition, it immediately begins monitoring for errors and events as the rest of the webpage executes. The negligible amount of overhead required to load the JavaScript results in a significant return of actionable data. ## Overall impact [#overall] The JavaScript's overhead takes into consideration both the impact on the user and the impact on your systems' performance: - **User perception:** Typically users cannot detect performance degradations on a website of less than 200ms. Browser's JavaScript adds less than 15ms in aggregated time per page load. This is split up over time, so at no point would a user be able to perceive any performance impact due to the JavaScript. - **Webserver and systems:** Browser app monitoring occurs on the user's browser, not on the server. Processing time does not have an impact on your CPU consumption. In addition, we take additional steps to minimize any potential impact on the apps and webpages being monitored. For example, the "loader" script is loaded synchronously in the `` in order to ensure monitoring is enabled for the entire life cycle of the page. This script is included inline, which eliminates the need for another roundtrip network request to a [content delivery network (CDN)](https://docs.newrelic.com/docs/browser/new-relic-browser/performance-quality/security-new-relic-browser#cdn). The "loader" comes with the initial page load. Later in the life cycle of the page, New Relic loads additional monitoring scripts asynchronously. These scripts should not have any perceivable effect to the user and is included in the overall overhead of less than 15ms per page. ## Network impact [#network] Browser monitoring also minimizes network traffic for the end user by aggregating data locally (in the client) and sending it back to New Relic at periodic intervals and on page lifecycle events `load`, `unload`, `pageshow`, and `pagehide`. (During the browser session's idle periods, transmissions may not be required.) ### Browser agent scripts [#agent-scripts] The agent consists of multiple scripts to reduce the initial size of the "loader" and to support loading only the JavaScript necessary to support the agent features that are enabled. The first script, the "loader", is inserted inline into the HTML document. The remaining scripts are downloaded from the content delivery network (js-agent.newrelic.com) when the `load` page lifecycle event happens. The number of scripts loaded is dependent upon the type of agent being use. Find out about [browser agent types here](https://docs.newrelic.com/docs/browser/browser-monitoring/installation/install-browser-monitoring-agent/#agent-types). | Script | Lite | Pro | Pro + SPA | | ---------------------- | ------- | ------- | --------- | | Inline script size | 10.2 kB | 15.5 kB | 17.5 kB | | Downloaded script size | 15.3 kB | 21 kB | 25.4 kB | Sizes are based on minified scripts using gzip compression. ### Browser agent harvests [#agent-harvests] Browser events are first harvested after the PageView event is successfully collected, and then every 30 seconds thereafter. If any event type exceeds 16 kB of data before the next scheduled harvest, an early harvest is triggered for that event. Additionally, a final harvest occurs whenever the document transitions to `hidden` via a `visibilitychange` event (e.g. when a user navigates away, switches tabs, closes the tab, minimizes or closes the browser, or switches from the browser to another app if they're on a mobile device). | Data type | Lite | Pro | Pro + SPA | Harvest frequency | | ---------------------------------------------------------------------------- | ---- | --- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [PageView](/attribute-dictionary/?event=PageView) events | yes | yes | yes | `PageView` events are harvested once immediately after the `load` page lifecycle event. This data is responsible for generating the page view metrics in the New Relic UI Browser dashboard. This is a JSONP call to `bam.nr-data.net` or `bam-cell.nr-data.net`. All agents are **required** to collect a `PageView` event. | | [PageViewTiming](/attribute-dictionary/?event=PageViewTiming) events | yes | yes | yes | `PageViewTiming` events are harvested by all agents and includes timing data like core web vitals measurements. See the [PageViewTiming docs](https://docs.newrelic.com/docs/browser/new-relic-browser/page-load-timing-resources/pageviewtiming-async-or-dynamic-page-details/#interactivity-metrics) for a list of reported events. | | [JavaScriptError](/attribute-dictionary/?event=JavaScriptError) metrics | no | yes | yes | `JavaScriptError` metrics are sent together with Ajax metrics as timeslice data. | | Ajax metrics | no | yes | yes | Sent together with JavaScriptError metrics as timeslice data. | | [AjaxRequest](/attribute-dictionary/?event=AjaxRequest) events | no | yes | yes | `AjaxRequest` events follows the 30 seconds harvest cycle unless the `SPA` agent is in use. If using the `SPA` agent, the first harvest will happen after the `load` page lifecycle event and additional harvests will either happen every 30 seconds or when the `SPA` agent notices a route change. | | Session traces | no | yes | yes | Session traces can generate a large amount of data, but that can be controlled by sampling. By default, only about 90 page views per hour will be sampled to send session trace data. There is also an option to set a custom sampling rate. | | Session replay | no | yes | yes | In addition to the the general harvest cycles, session replay harvests that include snapshots and metadata payloads will be harvested immediately. The endpoint can differ depending on the locale, but an example for US would be `https://bam.nr-data.net/browser/blobs`. | | [PageAction](/attribute-dictionary/?event=PageAction) events | no | yes | yes | | | [BrowserInteraction](/attribute-dictionary/?event=BrowserInteraction) events | no | no | yes | `BrowserInteraction` events are harvested immediately after the interaction finishes. There will always be at least one interaction that represents the initial page load. Additional interactions are collected only if the URL changes (representing route change). `AjaxRequest` events are also harvested at the same time if they occur during an interaction. | | Browser logs | no | yes | yes | | | [UserAction](/attribute-dictionary/?event=UserAction) events | no | yes | yes | | | [BrowserPerformance](/attribute-dictionary/?event=BrowserPerformance) events | no | yes | yes | |