New issue
Advanced search Search tips

Issue 890291 link

Starred by 3 users

Issue metadata

Status: Untriaged
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows
Pri: 2
Type: Compat



Sign in to add a comment

Habrahabr is exteremely slow in Chrome

Project Member Reported by khim@google.com, Sep 28

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36

Example URL:
https://habr.com/post/423889/

Steps to reproduce the problem:
1. Load page (it takes about 3 times longer in Chrome than in Firefox)
2. Try to scroll the page (it does that slowly and with high CPU consumption), it's painful to enter comments
3. Compare to Firefox (page is loaded slowly because it's large one, but scrolling is fast and it's very easy to enter comments

P.S. You cound't enter comments without registration but the problem is the same as with scrolling: timeout after keypress is uneven and sometimes few seconds pass after you click the button and see anything on screen.

What is the expected behavior?
You could use page normally

What went wrong?
People on that same page discuss how Chrome is the new IE (slow and unreliable), but that's not relevant to the issue on hand.

Does it occur on multiple sites: N/A

Is it a problem with a plugin? No 

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 69.0.3497.100  Channel: stable
OS Version: 
Flash Version: 

I have tested everything on Glinux desktop, but comments imply that Chrome is always slow and Firefox is always fast
 
Expected: responsive scrolling and updating of bluish marks on the left when quickly hovering different comments
Observed: lags

Bisect info: 438872 (good) - 438878 (bad)
https://chromium.googlesource.com/chromium/src/+log/21025291..e63ccacf?pretty=fuller
Suspecting r438875 "Remove all refs to touchEventFeatureDetection in ScrollingCoordinator."
Landed in 57.0.2953.0

====================

Another 20% drop of page opening speed was in this range:
https://chromium.googlesource.com/chromium/src/+log/077e9d75..f17bbaf2?pretty=fuller
Suspecting r406348 "Add page coordinates to the ViewportAPI"
Landed in 54.0.2802.0
Labels: Needs-Triage-M69
Cc: sunyunjia@chromium.org phanindra.mandapaka@chromium.org
Components: UI
Labels: Triaged-ET Target-71 M-71 FoundIn-71 FoundIn-70 FoundIn-69 OS-Windows
Able to reproduce the issue on reported chrome version 69.0.3497.100 also on latest chrome 71.0.3569.0 using Windows 10 and Ubuntu 14.04.  

Same behavior is seen on M60(60.0.3112.113) hence considering it as non-regression and marking it as Untriaged.

Note: Issue not seen on Mac 10.13.6. and CC'ing Dev for further inputs on it as per comment #1.

Thanks!
Status: Untriaged (was: Unconfirmed)
Labels: Hotlist-DesktopUIChecked Hotlist-DesktopUIValid
** Mass UI Triage **

Able to reproduce the issue on Windows 10 & Debian with chrome #72.0.3610.0 

Sign in to add a comment