Improve estimated input latency

[milansimek]

I'm getting very inconsistent results regarding the 'Estimated input latency' statistic on the following page:

https://plugin.company/magento-extensions/custom-contact-forms.html

Most of the time it's around 16ms, but maybe 20% of the time it's suddenly 130-160ms.

Can anybody shed some light what might be causing this? It seems like an issue with lighthouse, since I'm testing in an incognito window and have a very fast internet connection.

Thanks!

[paulirish]

Interesting....

I've now run it 7 times with the lighthouse CLI and 2 times in DevTools and I always see an EIL that's over 200ms.
So i'm not seeing much inconsistency.

You can reproduce this in the perf panel with a throttling configuration like this:

I'm seeing a LOT of recalc & layout work. It appears to happen the DOM is being modified during load. (a few onload handles that toggle a class?), and also the fact that the DOM is >2000 nodes big. That's pretty sizeable and so any recalc & layout will just have to take a while.

[paulirish]

also, are you using the extension or devtools?

[milansimek]

Thanks for your fast reply!

I'm using devtools.

Are you using a mobile user agent / resolution like the default format in dev tools? A lot of scripts aren't loaded on the page when using a mobile user agent and resolution.

Not sure if this matters, but I cleared our varnish cache a couple of times the last 2 hours, which will increase the TTFB a lot.

I just ran Lighthouse in dev tools again, this time I also got a EIL of 219ms. Then I ran it a second time and got an EIL of 16ms..

[milansimek]

Thanks for the tip regarding the perf panel by the way, I'll do some testing there also. Still it's strange that I got this result on the second run just now:

[milansimek]

Now I got 174ms, then 87ms and then again 16ms.

Probably the higher number is correct, since the result gets better when I run the test again. It seems like something is cached in some way.

We're using CloudFlare on our website, I'll check what happens if I disable that for a moment.

I'm using chrome 65 by the way

[milansimek]

I did some more testing:

• CLI on Ubuntu 3x: 200ms+
• Devtools on Ubuntu 3x: 200ms+
• Devtools on Windows 10: Same flaky results
• Devtools Canary 67 win10 4x: 2x 16ms, 1x 160ms, 1x 212ms

I'm running Ubuntu in a virtual machine without GPU passthrough. So maybe the GPU acceleration on Windows 10 might be a factor?

I have no custom extensions enabled on Chrome Windows 10 (in incognito).

[milansimek]

FYI: Enabling or disabling CloudFlare made no difference

[milansimek]

Disabling hardware acceleration made no difference

[patrickhulce]

@milansimek note that estimated input latency is exclusively measuring the amount of main thread activity from First meaningful paint until the end of page load so network-only impacting changes shouldn't have any effect.

Also worth noting this incarnation of EIL is highly impacted by how long the trace is, something that should be improved by the 3.0 release

[milansimek]

@patrickhulce Great, thanks for the information. The TTFB won't make a difference then for this metric.

I was mainly mentioning cloudflare since their service includes on the fly image optimization (webp) and JS, CSS and HTML minification.

Do you think that maybe the amount of cores on my desktop impacts this result? Since I have an octa-core 2.6-3.2ghz xeon processor. If it's slowed down 4x, then it will still be a lot faster than most other CPUs.

My VM where I did the testing using Chrome on Ubuntu, has less cores assigned.

[patrickhulce]

Assigning fewer cores shouldn't have a huge impact unless Chrome is being juggled along with other processes or you have many other tabs running. If the clock speed/cycles is limited by your VM though then it could certainly have a large effect.

[milansimek]

Ah ok. The VM still has 8 virtual cores assigned to it though.

I was just thinking since my pc has 16 virtual cores, maybe that's the reason why I get a lot lower EIL scores.

Or is this score calculated using only a single core?

[patrickhulce]

Score is determined by main thread activity which, as the name implies, is the amount of time spent on the single main thread. There are some browser tasks that can be offloaded to a separate core (script streaming thread and workers for example), but for the most part yes work to render a page happens on a single thread/core.

[milansimek]

Well in that case I'm at a loss what might be causing this. You guys are the developers though, so I hope you can figure it out.

So far it seems the issue is only present in Chrome on Windows 10, although I can't test on OSX. If you'd like me to test on another Windows 10 machine to make sure, please let me know. Also, if you need any additional data from my side, please say so.

[patrickhulce]

thanks for all the data you've given us @milansimek! we'll address this with an overhaul of the audit in v3 release 👍

[brendankenny]

#8729 is making this fairly moot