These are the metrics that would be used by the engineering team to evaluate effectiveness of front-end optimizations, and shouldn’t be communicated to stakeholders. Emily’s 90% page loaded metric is a way better model for measurable progress of “page load time”.
The purpose of this document is to outline the main metrics we use when discussing various end-user performance measurements such as "page speed".
Fig 1) A diagram we have been using in conversations to help illustrate the various events and how they inter-relate.
- FIRST BYTE
- DOC READY/DOM CONTENT EVENT
- SCRIPTS END
- MODEL FETCHES
- LOAD EVENT
What is it?
First byte loaded (or Time to First Byte) is the moment when the browser receives its first byte from the server in response to a request for a given URL.
How does it work? The browser uses a URL to open a network connection to a server; the server then sends back data in the form of an HTML document. The time at which the first byte is received by the browser is what we're interested in.
How can it be measured?
By measuring the time at which we make a request until the first byte of the response is received.
With curl:
curl -o /dev/null -w "Connect: %{time_connect} TTFB: %{time_starttransfer} Total time: %{time_total} \n" https://www.modcloth.com
With js: window.performance.timing.responseStart
How can it be optimized?
We can optimize time to first byte by using new relic metrics to optimize application response time as well as potentially network-level optimizations.
What is it?
When the browser has received the full HTML contents of the page from the server and instantiated the DOM.
How does it work?
There is no standard cross-browser way of doing this so it's a little different between browsers and even JS frameworks. In jQuery it listens out for the DOMContentLoaded event to come from the browser. Some browsers fire a onreadystatechange event instead. BUT!!! jQuery merely just uses this event as an opportunity to check if document.body exists. If it does, then jQuery's internal state is changed to be "ready". If not, it checks again every 1ms.
See REF
How can it be measured?
window.performance.timing.domContentLoadedEventStart or window.performance.timing.domContentLoadedEventEnd
How can we optimize it?
We can optimize time to dom.ready by cleaning up unnecessary dom elements (html, css?, javascript?) and ensuring that the content on our site is lean and quick to deliver from the server.
What is it?
The point at which all the javascript we wanted to run at document.ready has been both evaluated and executed. At this point, critical functionality on the site should be functional (click bindings, hovers, etc..), even though all ajax requests and 3rd party javascripts haven't finished loading. I.e. some third party scripts important to the business might not have loaded, but everything needed for the end user should be present and ready to go.
How does it work?
No "event" exists. This is wholly dependent on how much javascript we run at document.ready and can arguably only be relevant if we're only executing critical javascript on document.ready.
How can it be measured?
As no actual event is fired by the browser, we would have to write our javascript in a way that it could signal when the last piece of critical javascript code has executed.
How can we optimize it?
We can optimize this metric by
- only running JS code that is absolutely critical for user interaction on document.ready and deferring everything to later.
- identifying parts of our critical javascript that consistently takes long to process and reducing execution time of our JS codebase.
- We can also optimize this by doing less in javascript and moving things to the backend and into a cache.
What is it?
In order to enable full page cacheing on our site, we use ajax to load "page personalizations", or dynamic data that is typically session-based, like the current user, the inventory counts of the current product, etc. Upon completion of this action, the UI is updated to show this personalization information and then the modcloth User Experience is considered fully loaded.
How does it work?
No "event" exists. This is somewhat arbitrary and specific to our own site.
How can it be measured?
As no actual event is fired by the browser we would have to write our javascript in a way that when all the ajax calls are completed, we would signal an event.
How can it be optimized?
We can optimize this by:
- ensuring that the api endpoints that these ajax requests hit are responding quickly and transporting light json loads.
- firing the ajax request as early as possible. (ex: in )
- We can also, moving forward, ensure that these ajax calls are batched together into a single request and save the time for multiple transports.
What is it?
The point at which the browser has finished processing requests (ours and third parties) to load, fetch, (and possibly execute) assets such as images, stylesheets and scripts.
How does it work?
Similar to how doc ready works. The browser fires a 'load' event when all javascript, css and image files are completed. This event will often be pushed back later by scripts that insert image tags and/or script tags into the dom before the last asset is returned and evaluated.
How can it be measured?
window.performance.timing.loadEventStart
How can we optimize this?
We can optimize this by
- optimizing our asset delivery mechanisms; move things to CDNs, ensure that we leverage client-side cacheing, and ideally localStorage.
- Deferring non-essential javascripts, images and css files will also have a positive impact on the user experience by ensuring all asset delivery slots are reserved and used for the most essential files first.
- Loading assets after the window.load event. Many of them can be deffered with minimal, if non-existent, impact on the user experience.