How do you count the length of time a user stays on a page?

First of all, on the server side of the statistics, I personally feel that should not be, because the HTTP protocol is stateless, the browser and the server does not establish a persistent connection. This means that when a client makes a request to the server and then the Web server returns a response, the connection is closed.
So you cannot count the length of time a user accesses a page on the server side, but only the specific time a user accesses a page.

Excuse me, how can we achieve this demand?
Note: In the case of non-applicable third party traffic statistics

Reply content:

First of all, on the server side of the statistics, I personally feel that should not be, because the HTTP protocol is stateless, the browser and the server does not establish a persistent connection. This means that when a client makes a request to the server and then the Web server returns a response, the connection is closed.
So you cannot count the length of time a user accesses a page on the server side, but only the specific time a user accesses a page.

Excuse me, how can we achieve this demand?
Note: In the case of non-applicable third party traffic statistics

See what granularity you're going to get.

Solution 1:websocket
The front end has a long connection, background statistics long connection time.

Scenario 2:ajax Polling
Every few seconds to send a query, background records first and last query interval time

The general method is to record each request log (including UV markers, current URL, source URL, browser information, IP, access time, etc.), these initial logs can be analyzed how long a user stays on a URL (the next page request time-when the page time), Of course the finer things to consider are tab pages or new window issues. If it is the last page access, it is difficult to know the duration of the stay.
Ajax timing commits can of course be solved, just for a dwell time data (the data is relatively less important, the error is large), each page to do a timed Ajax feeling or a fuss. Of course, if your Ajax also commits other information (such as a user scrolling through a page), that's a good way to try.

The problem is simple: when the user initiates an HTTP request to record the URL and timestamp, and then you calculate the different types of (that is, the same URL, the parameters are not the same) time interval, and finally the user on the different types of pages to stay time.
Some apps now have just one page, but you can also use the hash in the URL to differentiate and calculate the different request types, so you can count how long the user is staying on a page.
If all the Ajax-loaded flowers can only be used to calculate the different request addresses.
The premise is that you want to use a high-concurrency cache system, and the caching system can do some simple mathematical calculations for you, fortunately, the market has already, you choose the best to match your outstanding task of the product bar.

I don't know much about that, but isn't Ajax able to hang on when the web is switched on? Can't send data to the server?

http://www.bangfx.com/research/?p=651
This link seems a bit similar and gives a solution to the idea

Unload in the window can do something, in Localstorage.
Window.load (send the last time to generate a start point record)
Window.unload (Generate an end point, calculate the dwell time, and save to Localstorage)
Such a user has only one last visit without a record, not one last time for each session

1, close the window or jump when the Window.onbeforeunload function will be triggered, you can do the function of processing (compatibility issues)
2, statistical data recorded to the local cookies, a period of time after the unified send
But I still think Ajax and WebSocket are a little more reliable.

