Bug 212757 – REGRESSION (r253616): Slower page load speed on sites with many media queries (including a number of sites on Akamai)

• Component: DOM
• Status: CLOSED FIXED

[Gaurav Saxena]

Hi Team,

We do real time user performance monitoring and found out that from 10th May onwards response time degraded by 1.2 to 1.7 secs on Iphone Mobile Safari browser. 
From 10th May majority of the user traffic switched to iOS 13.4 or up. Seems Mobile Safari 13.1 was shipped with iOS 13.4. 

Seems more time is taken between DOMContentLoadedStart and DOMContentLoadedEnd event. 

We see similar issues/trend across other webistes also. 

Can you please investigate and provide more details on this issue?

[Paul Calvano]

Hello. I'm seeing this performance degradation across 37% of sites measured w/ our real user measurement service. This includes many large e-commerce and media websites. 

I've shared some details in this twitter thread - https://twitter.com/paulcalvano/status/1268114487426666496

The slowdown became apparent once 13.1 was the majority of Mobile Safari traffic. However I can see that 13.1 was consistently slower for those sites.  The slowdown appears to be occurring between the DOM Content Loaded End time and the DOM Complete time. 

Please let me know if there are any additional details I can provide to help triage this.

- Paul

[Gaurav Saxena]

Created attachment 401062 [details]
graph for iOS13.3 and iOS 13.4 - user traffic vs page load time

Adding graph showing user traffic vs pageload time for iOS 13.3 and iOS 13.4.

[Maciej Stachowiak]

Can you share some websites that are affected? Is it possible to reproduce the slowdown testing devices with older and newer OS side by side?

[Radar WebKit Bug Importer]

<rdar://problem/63997043>

[Geoffrey Garen]

Also, could you share how DOMContentLoadedStart and DOMContentLoadedEnd are recorded (or share a code snippet)?

[Maciej Stachowiak]

Also what domComplete means.

[Maciej Stachowiak]

Answering my own question regarding domfomplete:

It's defined in Navigation Timing as being right before document.readyState is set to "complete":
https://w3c.github.io/navigation-timing/#dom-performancenavigationtiming-domcomplete

Which in turn happens right before firing the "load" event:
https://html.spec.whatwg.org/multipage/parsing.html#the-end:current-document-readiness-2

So basically this all suggests that, given the data here, there is a significant delay additional between the end of DOMContnetLoaded and the start of the load event.

https://twitter.com/paulcalvano/status/1268114491499261952

[Paul Calvano]

Thanks for looking into this.   

As Maciej noted, all of these times are defined in the Navigation Timing specification.  https://www.w3.org/TR/navigation-timing/.  

We're using real user measurement data from Akamai's mPulse service to measure the performance real users are experiencing.

I've encouraged impacted sites to comment on this bug report. I'm also reaching out to a few and will share some examples once I have permission to do so.

[Gaurav Saxena]

Thanks for looking in to this issue. 

Few website urls where we see the impact:
https://www.bell.ca/mobility
https://www.bell.ca/Mobility/Smartphones_and_mobile_internet_devices
https://support.bell.ca/

[Maciej Stachowiak]

(In reply to Gaurav Saxena from comment #9)
> Thanks for looking in to this issue. 
> 
> Few website urls where we see the impact:
> https://www.bell.ca/mobility
> https://www.bell.ca/Mobility/Smartphones_and_mobile_internet_devices
> https://support.bell.ca/

Thanks for sharing some URLs. Are you able to reproduce this locally? Does visiting these pages with older and newer iOS show a visible difference in page load speed?

[Maciej Stachowiak]

Additional question: is there anything like this observed for Mac Safari, or only iOS?

[Paul Calvano]

Created attachment 401149 [details]
iOS and Mac OSX Browser Performance Comparison

This series of graphs compares the page load times on Mobile Safari (iOS), Chrome Mobile (Android), and Safari/Chrome/Firefox on Mac OSX for an e-commerce site. The performance degradation for Mobile Safari 13.1 appears to be impacted both in the browser as well as the WKWebView.  The performance in Chrome Mobile is shown as well so that you can see that the site performance remained consistent.

I do not see any degradation on Mac.

[Paul Calvano]

@Maciej - I'm still working on getting you some URLs.   In the meantime, I've uploaded a graph from an e-commerce site showing comparisons across different browsers.   This appears to affect Mobile Safari and WKWebView on iOS, but not Safari on Mac OS X.

[Paul Calvano]

Created attachment 401152 [details]
iOS and Mac OSX Browser Performance Comparison

Actually it does look like OS X is impacted for some sites.   Here's the same graphs from a different e-commerce site.

[Gaurav Saxena]

(In reply to Maciej Stachowiak from comment #10)
> (In reply to Gaurav Saxena from comment #9)
> > Thanks for looking in to this issue. 
> > 
> > Few website urls where we see the impact:
> > https://www.bell.ca/mobility
> > https://www.bell.ca/Mobility/Smartphones_and_mobile_internet_devices
> > https://support.bell.ca/
> 
> Thanks for sharing some URLs. Are you able to reproduce this locally? Does
> visiting these pages with older and newer iOS show a visible difference in
> page load speed?

Welcome Maciej!

Attaching graphs (attachment_v0605_1010) which shows page load times for different iOS versions. 

Desktop MAC Safari page load time impact/degradation is up to 0.7 secs.

[Gaurav Saxena]

Created attachment 401155 [details]
Page load times across different iOS versions and trend for MAC Safari browser

[Maciej Stachowiak]

Thanks for sharing the data. What I'm really wondering is, if you try this yourself from iOS devices or Macs, can you reproduce the slowdown? It seems dramatic enough in the telemetry that it should be visible. I'm assuming these graphs are for load complete, not anything intermediate like first paint.

[Gaurav Saxena]

(In reply to Maciej Stachowiak from comment #17)
> Thanks for sharing the data. What I'm really wondering is, if you try this
> yourself from iOS devices or Macs, can you reproduce the slowdown? It seems
> dramatic enough in the telemetry that it should be visible. I'm assuming
> these graphs are for load complete, not anything intermediate like first
> paint.

Welcome!
Yes, these graphs are for page load times.

[Paul Calvano]

Here's a few more sites that are affected.

  www.michaelkors.com
  www.michaelkors.co.uk

The performance regression is similar to the one Guarav @ Bell Canada shared, as well as some of the anonymous examples I shared last week.

[Gaurav Saxena]

Hi Support Team,

Can you please advise on the next steps for this issue?

[Chris Dumez]

We are actively investigating.

[Maciej Stachowiak]

We've been able to reproduce the issue internally. In our testing, this seems to affect subsequent visits much more than the first visit. Is anyone able to confirm that in their telemetry?

Also, sites powered by Akamai the only sites affected? If there's non-Akamai examples, it would be valuable to know.

[Paul Calvano]

Thanks!  Great to hear that you've been able to reproduce it internally! 

mPulse doesn't track across sessions, so I don't have the ability to confirm whether this affects subsequent visits more than the first visit.

I don't believe that this issue only affects sites using Akamai, although I don't have examples to quantify that. The examples provided so far were using data from Akamai's real user measurement service, but other RUM services should be able to measure the degradation we are seeing.

[Gaurav Saxena]

(In reply to Maciej Stachowiak from comment #22)
> We've been able to reproduce the issue internally. In our testing, this
> seems to affect subsequent visits much more than the first visit. Is anyone
> able to confirm that in their telemetry?
> 
> Also, sites powered by Akamai the only sites affected? If there's non-Akamai
> examples, it would be valuable to know.

Thanks team for the update.
Glad to hear that you are able to reproduce this performance degradation internally. 

Below website is not monitored via Akamai and we can still see same performance degradation. 
https://support.bell.ca/

[Cliff Crocker]

Created attachment 401758 [details]
p75 iPhone - loadeventstart - customer A - US Retailer - SpeedCurve LUX

[Cliff Crocker]

Created attachment 401759 [details]
p75 iPhone - loadeventstart - customer B - US Retailer - SpeedCurve LUX

[Cliff Crocker]

Created attachment 401760 [details]
p75 iPhone - loadeventstart - customer C - US Retailer - SpeedCurve LUX

[Cliff Crocker]

Thanks to Paul/all for identifying this. While we don't see teh degradation for all of our customers, we have seen similar behavior for some of our US retailers as shown in attachments.

[Chris Dumez]

We believe we've identified the change that caused this. We will look into addressing the issue shortly.

[Gaurav Saxena]

(In reply to Chris Dumez from comment #29)
> We believe we've identified the change that caused this. We will look into
> addressing the issue shortly.

Thanks Chris!

This is great news. Glad that we could help in identifying and reporting the issue. 

Looking forward for the fix. 

-Gaurav

[Paul Calvano]

Hello!  I noticed that the subject was updated to reflect that this affects sites that use many media queries. Looking at the HTTP Archive, we can see that as of last year the median website has 14 media queries. The p90 was 45. (see https://almanac.httparchive.org/en/2019/css#media-queries) 

Would it be helpful if I run a query against the HTTP Archive to get you a list of websites that currently contain a large number of media queries?

[Chris Dumez]

Antti fixed this in <https://trac.webkit.org/changeset/263092>. I just did a side-by-side comparison on michaelkors.com after the fix and the regression looked fully recovered.

[Gaurav Saxena]

(In reply to Chris Dumez from comment #32)
> Antti fixed this in <https://trac.webkit.org/changeset/263092>. I just did a
> side-by-side comparison on michaelkors.com after the fix and the regression
> looked fully recovered.

Thanks Chris! 

We will monitor performance on our websites and update the results.

[Chris Dumez]

(In reply to Gaurav Saxena from comment #33)
> (In reply to Chris Dumez from comment #32)
> > Antti fixed this in <https://trac.webkit.org/changeset/263092>. I just did a
> > side-by-side comparison on michaelkors.com after the fix and the regression
> > looked fully recovered.
> 
> Thanks Chris! 
> 
> We will monitor performance on our websites and update the results.

It may take a little while for the fix to ship. We cannot comment on when the fix will ship but we will try to update this bug when it does ship.

[Gaurav Saxena]

(In reply to Chris Dumez from comment #34)
> (In reply to Gaurav Saxena from comment #33)
> > (In reply to Chris Dumez from comment #32)
> > > Antti fixed this in <https://trac.webkit.org/changeset/263092>. I just did a
> > > side-by-side comparison on michaelkors.com after the fix and the regression
> > > looked fully recovered.
> > 
> > Thanks Chris! 
> > 
> > We will monitor performance on our websites and update the results.
> 
> It may take a little while for the fix to ship. We cannot comment on when
> the fix will ship but we will try to update this bug when it does ship.

Thanks! 

Once the fix is shipped we will monitor performance of Bell Canada website and update this thread.

[Paul Calvano]

Do you know if this fix will be shipped with Safari 14?

[Alexey Proskuryakov]

This fix already shipped in iOS 13.6 and macOS 10.15.6.

[Paul Calvano]

Awesome, thanks!

[Gaurav Saxena]

Created attachment 405951 [details]
iOS13.6_iOS14.0 response time improved.

[Gaurav Saxena]

Hi Alexey,

Thanks! 

iOS13.6 and iOS 14.0 - Response time improved and comparable to iOS13.3

Hence, closing this issue.