eValid™ -- Automated Web Quality Solution Browser-Based, Client-Side, Functional Testing & Validation, Load & Performance Tuning, Page Timing, Website Analysis, and Rich Internet Application Monitoring.

Introduction
Many people ask, "When can a person use a web page and when is it completely loaded?" While simple enough to state, for a web browser this can turn out to be a very problematic question.

This page provides answers to these questions, and investigates timing of such important page properties as availability, readiness for action, components exist, navigation complete, etc.

Browser Architecture Affects Readiness
The problem is, in most browsers there is no intrinsic way to unambiguously detect DOM readiness. Or page readiness. This is due in part to browser architecture, which permits multiple threads to operate in parallel to achieve high performance (quick response) for the user, at the expense of creating ambiguity on when

• Internal Page Completion Signals
  When you see "Done" on the task bar on your browser, that indicates that a "document complete" signal has been issued by the browser.

  Unfortunately, when you see "Done" there it does not really mean done! What it usually means is that the DOM has reached an intermediate state and that the page probably is ready for user input. That signal is sent by the browser when the incoming HTML has been sufficiently parsed to allow rendering of the first visible page on the browser screen.

  There are several other signals or triggers that bounce around in the browser that have related meanings. They have names like "document complete", "document ready", "interactive," "onload", "beforeload," and "document active".

  To make it more complicated, there often is a DOM attribute named "ready state" which returns "loading" when the document is loading, "interactive" once it is finished parsing bu is still loading sub-resources, and "complete" once it has loaded.

  Still another indicator of page completeness is when each thread launched by the browser to obtain a page component via the HTTP/S protocol has completed. This indicator may apply when the page is static, with no active content, but not otherwise

• eValid Proprietary Algorithm
  What eValid does when executing commands to the browser is use a proprietary algorithm that monitors multiple signals in parallel to determine if the page is downloaded sufficiently for the test engine to go on to the next command in the sequence.

  In addition to considering all of the factors listed above, eValid also monitors an internal measure of the state of the JavaScript interpreter. (JavaScript runs on a separate -- and solitary -- browser execution thread.)

• The Impact of AJAX
  

• AJAX Synchronization
  When AJAX code is running there is communication between the browser and the web server that is handled by the [unitary] browser thread devoted to the JavaScript interpreter. This communication is asynchronous and may, depending on the application, involve activity in the browser that is not sensed by any of the regular browser DOM signals

• Effect of Synchronizaton Rate
  The fastest rate is 100 Hz, that is, a retry interval of 10 msec. Above that eValid tends to consume more than 1% of the CPU [on slower machines] and therefore would fail to achieve the 1% precision target.

• Dynamic Page Update
  

• Relation to HTTP/S Traffic Monitoring
  Tracking HTTP/S traffic is an indicator of the browser's progress of assembling and rendering a page ready for use. In the case when the web page is static -- there is no active content via JavaScript or by means of any other type of activity such as AJAX -- then it is certainly true that the last-arriving packet of HTTP/S traffic signals "page download complete".

  But, if there IS active content, then there may never be a "last packet" because the active content is alway

• Caveats & Recommendataions
  Everything gets more complex when there are frames and/or iframes.

  Where there is tight client/server JavaScript interaction.

  Let's not even talk about "focus" issues.

  If you want to see how complex this gets, just run search for "DOM ready state" and study what it finds.

  Better yet, use eValid in paused mode with Detailed Timings on and visible on the screen to see what may be going on as you type on your aplicatio

  Even if you have a sync, the value you just got may change after that.

  Also, there is a risk that the sync target will change to the required value then be changed back, and NOT be caught by the sync command. We've never seen this, but it is possible.

What is "ElapsedTime" measuring?
	Time between commands
		No, it isn't 100% perfect
			Nearest 10 msec is eValid's goal/promise

Timing based on asynchronous page item arrival?

How to time when an element is ready for input?
	Find the element by id or other characteristic
	Sync on it showing up in the DOM

-----------------------------------------------------------------------------------------
Key reference pages

  http://www.e-Valid.com/Products/Documentation.9/Testing/sync.on.dom.html

Usually you use the PageMap to search around for a DOM element to sync on.

  http://www.e-Valid.com/Products/Documentation.9/PageMap/pagemap.gui.html