Frontend Performance Monitoring in Production

Front-end performance monitoring is a basic task that must be done. Its core lies in monitoring key indicators, collecting and reporting data, analyzing and positioning problems, and deploying them reasonably. 1. Monitor Core Web Vitals indicators such as FP, FCP, LCP, CLS, FID to reflect loading speed and interactive experience; 2. Collect data through Performance API or third-party SDKs, and control reporting frequency, protect privacy, and perform sampling; 3. Analyze performance bottlenecks according to pages, devices, networks, etc., establish baseline and alarm mechanisms, and view trend charts to evaluate optimization results; 4. Conduct grayscale tests during deployment, use lightweight SDKs, asynchronous loading scripts, and control retry mechanisms. SPA projects need to process routing changes and re-collect data.

Front-end performance monitoring is actually not an optional "plus" in the production environment, but a basic work that must be done. When users visit your website, the page loads quickly and the interaction is smooth, which directly affects the experience and conversion rate. And you can't just rely on testing these in the development stage, you have to rely on continuous monitoring after going online.

1. What core indicators are monitored?

There are many things to monitor, but there are several really key indicators: FP (First Paint), FCP (First Contentful Paint), LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift), FID (First Input Delay), etc. These are all contents in Core Web Vitals proposed by Google, which can basically reflect the page loading speed and interactive experience.

• FP/FCP : Tell you when the browser starts rendering content
• LCP : reflects the time when the main content is loaded. If it is too slow, users will feel stuck.
• CLS : Too much jitter on the page layout will affect the user experience, especially the jump caused by advertising or asynchronous resource loading
• FID : How long does the page response delay when the user clicks a button or input box for the first time

These metrics can be collected on the browser side through the Performance API, or combined with third-party SDKs for aggregation analysis.

2. How to collect data and report it?

Front-end performance data collection mainly relies on the API provided by the browser, such as performance.getEntries() and PerformanceObserver . You can listen to various types of resource loading events, such as paint , largest-contentful-paint , layout-shift , etc.

Let's give a simple example:

 new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    console.log('LCP:', entry.startTime);
    // It can be sent to your log service here}
}).observe({ type: 'largest-contentful-paint', buffered: true });

Some points to pay attention to in actual use:

• Report frequency control, do not affect the normal use of users
• Consider privacy issues and do not transmit sensitive information
• Try to make sampling and reporting, such as 10% traffic, to avoid excessive server pressure

In addition, you can also use some ready-made tools, such as Google's Web Vitals library, Sentry, Datadog, etc., which have encapsulated most of the logic and are easy to access.

3. How to analyze and locate problems?

With the data, the next step is analysis. You need to split the performance data by dimensions such as page, device type, network status, etc. to see where the bottleneck is.

Frequently asked questions may include:

• The picture is too large and not compressed, slowing down LCP
• JS execution time is too long, resulting in high FID
• Dynamic insertion of content causes CLS fluctuations
• In some areas, CDN cache hits low, and the first byte time becomes longer

Suggested practices:

• Establish a performance baseline, such as LCP control within 2.5 seconds
• Set up an alarm mechanism to notify you in time when the performance of a certain page decreases significantly on a certain day.
• Check the performance trend chart regularly to see if the optimization takes effect

If you find that some users have particularly high FIDs, it may be that third-party scripts block the main thread, you have to consider lazy loading or replacement solutions.

4. What should you pay attention to when actually deploying?

Before launching the performance monitoring code, it is best to do grayscale testing first. Because some APIs are not supported on old browsers, or if the reporting logic itself is written too heavily, it will affect performance.

The following points can be noted during deployment:

• Use lightweight SDKs to avoid the introduction of additional performance burden
• Control the frequency of reporting, such as reporting only once per user per day or random sampling
• Reasonably set the error retry mechanism to prevent unlimited retransmission after failure
• Avoid placing monitoring scripts on page critical paths, preferably asynchronously loading

In addition, if your project is a SPA (single-page application), remember to regain performance data when processing routing changes, otherwise you can only get the data on the homepage.

Basically that's it. Front-end performance monitoring sounds simple, but to be done well, it is necessary to form a closed loop from collection, transmission, analysis to feedback, and to continuously adjust strategies in combination with business scenarios.

The above is the detailed content of Frontend Performance Monitoring in Production. For more information, please follow other related articles on the PHP Chinese website!