This is an incorrect assumption. A webpage loads as follows in generic terms:
- Server content is received by the browser.
- Rendering begins starting with objects and then styles from a layout as in all at once and if you slowed it down you would see a pixelated progression as it took shape starting with the content areas and then the objects and then the styles for those objects.
- On Load events fire during this process as well
- Post load events fire right after this. When you have alot of javascript it comes over in one bulk file and then most of the time on-load and post-load events fire to fully bring in the content. This allows for the browser to load the content for the eye to see and then javascript calls finish the content while the user is focused on the page, thus giving the appearance that it loads faster than it actually does.
All of the above is by application specific design, except 1 & 2, so it's really hard to say what is the final "loading complete". What I usually do is open up dev tools and start the traffic monitoring for the browser and then load the page. This should break out the server communication, then the rendering, then any javascript calls. The last items in the load traffic I dig into and see if there is a specific piece of the page that this corresponds to. Once I have that then I put an explicit wait on that object as my "page load complete" test before executing anything else.
You can just wait on the general page load, but it's not guaranteed to be the final loaded element on the page. If you have access to the code or dev help I recommend reverse tracing each page like that to be sure you have the last loaded element.