Reload, reloaded: simplifying the loading behaviors in Chrome for a better Loading experience

[Kenji Baheux]

Hi,

Chrome is apparently performing a lot of unwarranted revalidations. While it might not explain it all, we found out a couple of contributing factors in the way we reload pages.

What might have been reasonable behaviors before the rise of mobile devices, now seems inefficient. 

As we looked into the code to find more causes, we couldn’t help but noticed the multitude of Reloading flavors.

We want to simplify this.

Here are our thoughts: Reload, reloaded (comments welcomed).

[Kenji Baheux]

An update on this,

We enabled the new Reload behavior via field trials on a couple of milestones over different channels and across platforms.

The results are simply astonishing!

High level summary of the results

HTTP response codes

The less 304s, the faster the page loads, the less data we use.

• 50% less 304s (network revalidations) on Android stable 51
• 39% less 304s on Windows beta/dev

Note: No Mac data in this summary, the impact appears to be less impressive but it's probably best to wait for stable data before making any conclusion.

Improvement to Time To first Contentful Paint

Android Beta:

• 2G median improved by 1s (other percentiles: significance not reached)
  
• 3G median improved by 160ms, 90%ile by 1.6s, 99%ile by 7s
  
• Wifi median improved by ~160ms, 90%ile by 590ms, 99%ile by 1.7s

Note: Chrome for Android stable is omitted in this summary because it didn't have Loading metrics that were constrained to Reloaded pages.

Windows Beta:

• median improved by ~230ms, 90%ile by ~930ms, 99%ile by 4.4s
  
• Percentiles have tighter margin errors on most configurations: the performance of reloads are more consistent, contributing to a better user experience.

Health signals

We looked at the following metrics to determine if the new behavior broke user expectations:

• Volume of page loads: no significant differences (within the acceptable range of variance)
• Relative volume of Reload user actions: unchanged
• Relative volume of page load triggered by reload: no significant changes
• Relative volume of Abort via Reloads: no significant changes.
• We haven't found any report of issues in the wild.

Given these great results, we are moving forward with the change.

Best,

PS: you can try the new behavior by enabling these flags:

• Android: chrome://flags/#enable-non-validating-reload-on-refresh-content
• All platforms: chrome://flags/#enable-non-validating-reload-on-normal-reload

[Ben Maurer]

Amazing! Quick question are the first contentful paint numbers for reloads or global across all navigations. Also are you guys going to roll out the exp to users on on the current chrome stable like we did with brotli?

Sent from my iPhone

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.
To post to this group, send email to loadi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/b95e00f0-4c43-4715-85f8-05014206f818%40chromium.org.

[Kenji Baheux]

On Thu, Aug 25, 2016 at 1:43 PM Ben Maurer <ben.m...@gmail.com> wrote:

Amazing! Quick question are the first contentful paint numbers for reloads or global across all navigations.

The first contentful paint numbers are for reloaded pages which represent from 9% to 13% of the page loads that make it to first contentful paint.

 

Also are you guys going to roll out the exp to users on on the current chrome stable like we did with brotli?

I think we want go for a full launch, waiting on approvals.

Will update.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/8CCBD563-A46C-4B68-9322-7D45BD8AD2BD%40gmail.com.