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?
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
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.
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?
<rdar://problem/63997043>
Also, could you share how DOMContentLoadedStart and DOMContentLoadedEnd are recorded (or share a code snippet)?
Also what domComplete means.
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
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.
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/
(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?
Additional question: is there anything like this observed for Mac Safari, or only iOS?
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.
@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.
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.
(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.
Created attachment 401155 [details] Page load times across different iOS versions and trend for MAC Safari browser
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.
(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.
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.
Hi Support Team, Can you please advise on the next steps for this issue?
We are actively investigating.
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! 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.
(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/
Created attachment 401758 [details] p75 iPhone - loadeventstart - customer A - US Retailer - SpeedCurve LUX
Created attachment 401759 [details] p75 iPhone - loadeventstart - customer B - US Retailer - SpeedCurve LUX
Created attachment 401760 [details] p75 iPhone - loadeventstart - customer C - US Retailer - SpeedCurve LUX
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.
We believe we've identified the change that caused this. We will look into addressing the issue shortly.
(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
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?
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.
(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.
(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.
(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.
Do you know if this fix will be shipped with Safari 14?
This fix already shipped in iOS 13.6 and macOS 10.15.6.
Awesome, thanks!
Created attachment 405951 [details] iOS13.6_iOS14.0 response time improved.
Hi Alexey, Thanks! iOS13.6 and iOS 14.0 - Response time improved and comparable to iOS13.3 Hence, closing this issue.