search

GoogleChrome / lighthouse

Automated auditing, performance metrics, and best practices for the web.
https://developer.chrome.com/docs/lighthouse/overview/
Apache License 2.0
28.48k stars 9.39k forks source link

DBW: suggestion will-change usage #742

Open ebidel opened 8 years ago

ebidel commented 8 years ago

Best I've come up with:

Should also be clear in the helpText that developers should not will-change all the things!

https://developer.mozilla.org/en-US/docs/Web/CSS/will-change

wardpeet commented 8 years ago

what about if you do both? Because for older browsers you will need the fallback?

paulirish commented 8 years ago
  1. if transition is used on transform or opacity. wouldn't do anything for others. also its not guaranteed to be better, but its worth profiling and trying.
  2. instead of translateZ or translate3d.... however safari doesn't support will-change and the layer promotion may still make sense for them. but you'd have to use their devtools to find out.
  3. overflow-auto/scroll on large page elements currently need will-change for lo-dpi (ie. google play and gmail). However, they're about to fix this so we probably dont need to flag these.
  4. position fixed elements on lo-dpi. I don't think above bug also fixed fixed position elements. This is a safer one for the recommendations.
wardpeet commented 8 years ago

@paulirish

2) correct but in your css you will still have set both if you want to support more than 1 browser. Do we punish them for it or just give them feedback that they need to add will-change as well. 3) is pretty nice to know :p 4) Position fixed offers a really bad experience on mobile (ios)...

Something like this? 1) look for translateZ -> do we also have will-change (it's ok) 2) if only translateZ warn user for layer promotion? 3) if they do animation and have translateZ or translate3d but no will-change warn them?

paulirish commented 8 years ago

...you will still have set both if you want to support more than 1 browser.

2) aye. if they're already using translateZ or 3d, they might as well add will-change to it. So that's probably rule #2. :)

proposed approach:

  1. if using transition or keyframe animation on transform, opacity, or filter.
    • worth profiling, adding will-change and looking for improvement
  2. if a rule has the null transform hack already, they might as well add will-change (and not remove the existing hack)
  3. Apply to elements that are position:fixed but only in the desktop case