Merge pull request #214 from openreplay/timings

Author: estradino

src/i18n/en/nav.ts

@@ -375,6 +375,7 @@ const nav: NavItem = {
         { text: 'Sourcemaps Issues', slug: 'troubleshooting/sourcemaps', children: [] },
         { text: 'Supported Browsers', slug: 'troubleshooting/supported-browsers', children: [] },
         { text: 'Deployment Issues', slug: 'troubleshooting/deployment-issues', children: [] },
+				{ text: 'Network Resources', slug: 'troubleshooting/network-resources', children: [] },
       ]
     },
     {

src/pages/en/troubleshooting/network-resources.mdx

@@ -0,0 +1,19 @@
+---
+title: "Network Resources Issues"
+metaTitle: "Network Resources Issues"
+metaDescription: "Issues with recording network resources."
+---
+
+When CORS is in effect, many of the timing properties' values are returned as zero unless the server's access policy permits these values to be shared. This requires the server providing the resource to send the Timing-Allow-Origin HTTP response header with a value specifying the origin or origins which are allowed to get the restricted timestamp values.
+
+This is particularly important for cross-origin resources, such as those loaded from a different domain than the one serving the main page. If the Timing-Allow-Origin header is not set correctly, OpenReplay will not be able to record the timing information for these resources.
+
+For example, to allow https://app.openreplay.com to see resource timing information, the cross-origin resource should send:
+
+```http
+Timing-Allow-Origin: https://app.openreplay.com
+```
+
+## Have questions?
+
+If you have any questions about this process, feel free to reach out to us on our [Slack](https://slack.openreplay.com) or check out our [Forum](https://forum.openreplay.com).