Menu
We have Google Analytics and Azure Application Insights analytics scripts in our HTML, including Google Analytics. They are in <script> tags in <head>. They are causing an error when we are watching with Browsersync, particularly with browser-sync-brunch, since we are using brunch as our build system. Upon watching, however, this error is printed to the console twice (interestingly we have two analytics tags):
XMLHttpRequest cannot load http://localhost:3000/browser-sync/socket.io/?EIO=3&transport=polling&t=1494358571902-4&sid=rhGMlOFa_MbRrYbLAAAD. Request header field x-ms-request-id is not allowed by Access-Control-Allow-Headers in preflight response.
and this error set repeatedly every few seconds:
OPTIONS http://localhost:3000/browser-sync/socket.io/?EIO=3&transport=polling&t=1494358572782-5 400 (Bad Request)
OPTIONS http://localhost:3000/browser-sync/socket.io/?EIO=3&transport=polling&t=1494358572782-5 400 (Bad Request)
XMLHttpRequest cannot load http://localhost:3000/browser-sync/socket.io/?EIO=3&transport=polling&t=1494358572782-5. Response for preflight has invalid HTTP status code 400
I'm fairly certain these analytics scripts are causing the problem because blocking them with uBlock Origin makes it work just fine.
I wondered if it had to do with these script tags being before where the Browsersync tag was injected (immediately inside <body> tag, see documentation). But moving them to the end of the <body> tag did not fix the issue.
What is causing this and how can it be mitigated?
243
NOTE: this is not an 'answer' but is too long to be a comment.
Using both Firefox web developer toolbar's javascript console debugger, and Chrome's, I checked our pages, which use google analytics, I believe you can largely exclude the google analytics from the suspect list, they usually do an ok job with their js.
Your errors also all point clearly to browser-sync, so that's probably the culprit. Your local dev site however is suspect, why didn't you make a proper virtual host for it, and not use localhost? I don't know anything about browser-sync so I'll just note this to exclude possibilities in your case.
I doubt your live site is running as localhost, so you might want to correct that issue to remove a possible point where small differences can creep in. I always try to use as close to live production on everything on any site I do, which would mean you'd never see a localhost anywhere in the actual running code of the site, you'd see the site either dev or real domain name, like: http://our-dev-site/ or whatever.
144
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
