This topic describes common issues, possible causes, and solutions for web and H5 monitoring.
JS errors
1. Some reported errors show "Script error" with no specific details
Browser security restrictions prevent errors from cross-domain scripts from being caught. Only the message "Script error" is displayed. To resolve this, add the `crossorigin` attribute to the <script> tag. For more information, see Script-error.
2. Some "unhandledrejection" errors lack other relevant information
If your code calls `reject` within a Promise and passes an empty parameter or a string, the plugin cannot collect the error stack or other related information.
3. Some errors do not have an exception stack
In some scenarios, the browser does not return an exception stack, so it cannot be collected. Common scenarios include the following:
The two scenarios described above.
A syntax error. This error occurs during script parsing and does not have a stack. In this case, the error name is SyntaxError.
Errors caused by browser extensions.
White screen issues
1. A white screen is reported every time a complex page is opened
The white screen plugin has a default timeout of 3 seconds. This means that 3 seconds after a page starts loading, the plugin checks for a white screen. If a page is complex and requires more time to load, the check may run while the page is still loading, which causes a white screen to be reported.
For these pages, you can configure the `timeout` value for the white screen plugin accordingly. This helps you monitor if the page fails to load within the expected time and results in a white screen. For more information, see the SDK API.
Page performance
1. For some pages, metrics such as LOAD and TTFB are always empty
If a page has a redirection or a sub-page does not exist, the page automatically redirects to the site's default homepage. This causes metrics such as load time (Load) and time to first byte (TTFB) to be empty.
2. Some metrics are empty for SPAs and micro-applications
Currently, performance data collection for these types of applications is only supported for the initial load. Support for performance monitoring during internal page switches will be added in a future release.
Requests
1. The console reports an HTTP status code of 0
When a fetch request fails, the status code cannot be obtained and is then set to 0.
When a cross-origin request fails, the returned status code is 0.
In some cases, such as a request timeout or abort, the returned status code is also 0.
2. Some requests are not collected
If a fetch request has `method=HEAD` or `mode=no-cors`, it is skipped during data collection. JSONP requests are not currently supported.
Static resources
1. The console reports an HTTP status code of 0 or --
A status code of 0 indicates an unknown status. The status code cannot be obtained for reasons such as a cross-origin request. For more information, see the MDN documentation. The -- symbol is equivalent to 0. When a request is confirmed as an error, the status code is set to --.
2. Some resources fail to load, but the HTTP status code is 200
This can be caused by a resource type mismatch. For example, an <img> tag loads an HTML document, or an empty `src` attribute is used. In these cases, the browser resolves the empty address to the URL of the current main document. Although the status code for these resources is 200, they are still classified as loading errors.
3. A large volume of resources with request-like URIs are reported
You may have integrated other third-party plugins that make network requests by loading resources. Requests sent by these plugins during runtime are reported as multiple resources. If you do not need to monitor their resource loading, you can configure the SDK reporting settings for specific resources to avoid unnecessary event overhead.
Other information
1. Enable debug logs in the production environment
If data collection is abnormal in the production environment, you can use the SDK debug logs to troubleshoot the issue. To manually enable debug logs, run the following code in the browser console.
localStorage.setItem('emas_apm_log_debug', 'debug')