Why doesn't google analytics code use AJAX - javascript

I was wondering how ga collected data and send it to their servers, then I found this answer on SO. Now I'm wondering why does GA uses this method rather than doing an AJAX request, is it cheaper?

It's not cheaper, per se, it is reliable. Unlike AJAX, you can include an image from any domain without running into cross-domain browser restrictions, this is why tracking pixels are used instead of ajax requests.

As Rob said, it's primarily to get around cross-domain issues not supported in older browsers. However, as of recently GA has added support for the navigator.sendBeacon() method, which actually is cheaper, allows for retries on error, and doesn't have the problem of failing when the page is being unloaded (like when trying to send an event when a user clicks on an outbound link). As browser support increases, this will likely become the default method for sending hits to GA.
Here's the documentation on how to use sendBeacon with analytics.js:
https://developers.google.com/analytics/devguides/collection/analyticsjs/field-reference#useBeacon

Related

Is it possible to prevent an unknown javascript script from being able to make a network call in a browser?

If I'm loading arbitrary external javascript code in a browser setting, is it possible to ensure it can't make the browser run make any ajax calls or network requests?
Can you prevent any resource calls? - No. (haven't explored the 'extension' route though)
Since even an <img src='any valid url'> creates a resource request which your code cannot prevent.
Can you prevent ajax calls? - Yes, to an extent.
Assuming that you want to ensure that any third party libraries shouldn't make any arbitrary ajax calls (cross domain), you will simply ensure that you don't enable CORS in your web server.
Your own application code can make ajax calls since they are in your domain only. However, you can filter those calls on server to check for specific properties like purpose, credentials, etc
It may be worth exploring google caja (haven't tried that myself)

Chrome Extension webRequest synchronous behavior for async calls

I've created a test web server that I'm using to act as a 'web filter' of sorts. I'm trying to create an extension that uses the webRequest API to make sure that my web server allows or blocks all incoming URL's.
To do this, I'm making an AJAX call from within webRequest to my web server and I'd like to use the response to determine whether to block or allow the specified URL. The problem is, the webRequest method is async, and AJAX calls are async, so I can't wait reliably wait for a response from my server.
I also can't store all blocked / allowed URL's in localStorage, because there could potentially be hundreds of thousands. I've tried using jQuery's async: false property in it's ajax implementation, but that makes the browser almost completely unusable when hundreds of requests are happening at the same time. Anyone have any ideas as to how I might be able to work around this?
EDIT: I know similar questions to this have been asked before, but there haven't been any viable solutions to this problem that I've seen.
I see only two good choices:
make that site a webproxy
use unlimitedStorage permission and store the urls in WebSQL database (it's also the fastest). Despite the general concern that it may be deprecated in Chrome after W3C stopped developing the specification in favor of IndexedDB I don't think it'll happen any time soon because all the other available storage options are either [much] slower or less functional.

Tracking http requests sent by the browser using javascript/jquery

Using javascript or jquery, is there a way to track the http requests(including headers, parameters, etc.), sent by a webpage? What I want to achieve is something similar to the functionality of the 'network' tab of Google Chrome's developer console. All the solutions I found was either tracking Ajax requests or requests made using javascript(using XMLHttpRequest Object). This functionality should also be cross browser compatible.
You have three choices.
Make sure you know all the places where a request can get fired, and attach an event to it, say RequestFired. And bind the onRequestFired event in your JavaScript / jQuery code.
Go through the Network Developers document or each browser and based on the browser, execute it. This feature may not be available in older browsers like Internet Explorer 7 and 8.
Google Developers Doc
Firefox Network Information API
NetworkInformation.connection
If it is for a particular server, read the Server Log using a server side script and access it using an endpoint. You can use long polling method and fetch the contents of the log, may be this way:
// jQuery
$(document).ready(function () {
setInterval (function () {
$("#log").load("/path/to/endpoint.log");
}, 5000);
});
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script>
<h3>Logs</h3>
<div id="log"></div>
You can't track everything.
For example some of the calls in Xmlhttprequest are transparent (301 HTTP codes) and can't be handle by javascript client side.
see the XMLHTTrequest specs: http://www.w3.org/TR/XMLHttpRequest/#infrastructure-for-the-send-method
This among a few other reasons. if you want to track the requests of a "webpage" it's better to use the development tools of that browser or packet capturing.
On the userExperience side you can only do very limited things.
It can be done, if you are implementing a single page web-application with a framework like AngularJS. There you can do that using HTTP interceptors.
Other than that, you can only track Ajax requests, but not JavaScript requests.

javascript which makes cross domain GET requests and assigns it to a variable

for quite a long time i am looking for a javascript code which can make cross domain GET requests..
i want to make a javascript which makes a GET request to google and fetches the page source and assigns it to a variable..
note:the get requests must be generated from the clients computer and to a different server(eg:google)
Not possible due to the same origin policy which restricts AJAX and iFrames.
However, afaik Google offers a very own AJAX API to fetch search results, thats maybe enough for your needs.
But unless the Google servers don't allow for cross-domain calls (which I don't believe) there is no way in fetching data via a pure client-side AJAX connection.
Disclaimer: it might be possible in some browsers by changing some core settings

Why does Google Analytics use a one-pixel picture to transfer data?

Google Analytics embeds a one pixel GIF with a URL like this:
http://www.google-analytics.com/__utm.gif?utmwv=5.1.5&utms=5&utmn=1532897343&utmhn=www.douban.com&utmcs=UTF-8&utmsr=1440x900&utmsc=24-bit&utmul=en-us&utmje=1&utmfl=10.3%20r181&utmdt=%E8%B1%86%E7%93%A3&utmhid=571356425&utmr=-&utmp=%2F&utmac=UA-7019765-1&utmcc=__utma%3D30149280.1785629903.1314674330.1315290610.1315452707.10%3B%2B__utmz%3D30149280.1315452707.10.7.utmcsr%3Dbiaodianfu.com%7Cutmccn%3D(referral)%7Cutmcmd%3Dreferral%7Cutmcct%3D%2Fgoogle-analytics-architecture.html%3B%2B__utmv%3D30149280.162%3B&utmu=qBM~
Why not use an AJAX call? What's the benefit of using a one-pixel GIF?
Because you can't really do cross domain AJAX (with the exception of CORS, but that's a different story, and a recent phenomenon with less than universal support.) AJAX is for same origin requests. Also, Google Analytics forks from Urchin, which actually predates AJAX technology's adoption.
Requesting an image is pretty standard practice for analytics services "requesting" something as a means of sending something to a third party server. The reason AJAX/CORS doesn't really make sense is that you're not actually requesting an important resource for use on the page, so you want the request itself to be as quick and overhead-less as possible.
The other two ways analytics services occasionally handle sending data from the client is:
Including an invisible iframe, with the query string on the iframe src passing the analytics data
Requesting an image, and instead of returning an image, returning an empty response with a HTTP 204 header.
To maximize compatability. A cell phone browser may not support AJAX, for example, and thus may provide inadequate results. But hey, Google does a lot of funky stuff that nobody can explain.

Categories