What is the page interaction point?
- The page interaction point is the moment a user can interact with the core functionality of a webpage.
- Interaction is seeing the content and being able to interact with it (click buttons, choose options, navigate, etc.)
- The page interaction point is a conceptual moment rather than a technical pageload event.
The real goal, the finish line, the entire point of making a page faster is to make it faster for people to interact with.
Let's book a hotel
A good example would be a hotel booking site, where you can see things on the page, but the place to actually book a hotel is not usable for a couple seconds after the page has loaded.
If the entire reason that a person uses a page is to book a hotel, then the page may well be "loaded and "visible" but may not be usable for the function the person is hoping to use that page for.
In such a case, there is no current distintion between the page loading and the page being usable.
That page may load in two seconds, but if a person that is using that page to book a hotel can not book a hotel for seven seconds, then it doesn't seem accurate to state that the page is loaded in two seconds.
The importance of the "page interaction point"
- It highlights that the experience a person has with a webpage is the core goal of pagespeed optimization.
- It is a useful and meaningful way to compare two scenarios based upon user experience rather than technical page load events.
- Alerts that the core functionality of the page is the most basic metric upon which to decide what is best for that page.
How to optimize for the page interaction point
- Determine the core functionality of the page
- Determine what can be removed from the critical rendering path without affecting the core functionality
- Defer everything that is not required for the core functionality
Making a decision using the page interaction point
Dealing with javascript is one of the most fundamental and basic tasks of page speed.
The way javascript should be dealt with is entirely dependant upon the core functionality of the page, yet best practices do not currently acknowledge that.
Using the page interaction point means we determine the core functionality of the page first and then our decisions become easier.
Below we will look at a descion made for javascript usage.
Javascript
How javascript should be used is completely and drastically different depending on what purpose that javascript has on that page.
Let's look at two pages. One page does not use javascript as part of the core functionality of the page, and the other page does.
Now let's look at each of those pages in more detail...
An article
If the core functionality of a page is to display an article to people and the javascript of the page is used for ads, social buttons etc. then it is important to understand that javascript is not part of the core functionality of that page.
- This means that javascript should be defered and completely removed from the critical rendering path
Removing the javascript from the critical rendering path in this case allows for the user to arrive at the page interaction point (user sees article) as quickly as possible.
If we were to instead use async javascript, then we would create added complexity, downloads, and time that delays the user from getting to the page interaction point.
A hotel booking page
If the core functionality of a page is to allow a user to book a hotel using a widget/app that depends on javascript then it is important to understand that javascript is absolutely part of the core functionality of that page.
- This means that javascript should be introduced as early as possible and async javascript within the critical rendering path is an absolute necessity.
Defering the javascript would only delay the page interaction point, keeping the user from booking a hotel.
In this case, the fastest way to get to the page interaction point is to include javascript in the critical render path, as it is needed for the core fuctionality of the page.
defer vs async?
It is not wise to consider one javascript recommendation over the other without first considering the page interaction point.
- If the core functionality requires javascript, async is best.
- If the core functionality does not require javascript, then javascript should be deferred outside of the critical render path.
The entire purpose of the page interaction point is to highlight that the pagespeed optimizations made should be based upon the core functionality of the page.
Everything should be based on one question: How does the user get to do what they want to do as fast as possible?
All page speed considerations are dependant on the page interaction point
Do not use any page speed recommendation without considering the core functionality of the page.
The overall goal should be to get to the page interaction point as quickly as possible (the user doing what they want to do as fast as possible).