[Preference] How to avoid Forced Synchronous Layout or FSL to improve site preference

When tigger site updates the layout, it always follow this order:

Javascript trigger style changes, then layout changes then broswer do the paint and composite.

All those five steps should be finished in 60fps, or 16ms. Then users will have a smooth and good user experience.

For "layout", "style" and "composite", please check this site: https://csstriggers.com/

From the site, you can see that, ‘transform‘ and ‘opacity‘ has good preference, because they only trigger "composite", save lot of works for the broswer.

Also you can see that the method for "left", "right", they triggers all "layout", "paint", "composite"

Now let see "style" and "layout".

In general, "style" should happen before "layout", otherwise, broswer need to rerender "layout"->"style"->"layout" all over again, which is a waste for the perfermence.

To see which opreation will cause "layout" recalcuation, please checkout http://gent.ilcore.com/2011/03/how-not-to-trigger-layout-in-webkit.html, basiclly, be careful with those:

clientHeight, clientLeft, clientTop, clientWidth, focus(), getBoundingClientRect(), getClientRects(), innerText, offsetHeight, offsetLeft, offsetParent, offsetTop, offsetWidth, outerText, scrollByLines(), scrollByPages(), scrollHeight, scrollIntoView(), scrollIntoViewIfNeeded(), scrollLeft, scrollTop, scrollWidth

Let‘s see an example how bad it can affect our site prefermence. Example site

In this bad example, you can see taht Recalculation for "style" -> "layout" -> "style" .... "layout", it repeat number of times.

Let‘s see the code causes this:

        function firstRun() {
          divs.forEach(function(elem, index, arr) {
            if (window.scrollY < 200) {
              elem.style.opacity = 0.5;
            }
          })
        }

As you can see in a forEach loop, every time you call "scollY" will cause a layout update, then we call "style.opacity" to trigger style update, but after style updated, layout will be updated again because the order, remember?

Let‘s see how to fix the problem:

        function thirdRun() {
          var newWidth = container.offsetWidth;
          divs.forEach(function(elem, index, arr) {
            elem.style.width = newWidth + "px";
          })
        }

We can simply move ‘layout‘ update code out of forEach loop. Now the timeline looks much better!

原文地址:https://www.cnblogs.com/Answer1215/p/8728615.html

时间: 2024-11-06 22:10:52

[Preference] How to avoid Forced Synchronous Layout or FSL to improve site preference的相关文章

浏览器渲染性能优化

染性能 页面不仅要快速加载,而且要顺畅地运行:滚动应与手指的滑动一样快,并且动画和交互应如丝绸般顺滑. 60fps 与设备刷新率 目前大多数设备的屏幕刷新率为 60 次/秒.因此,如果在页面中有一个动画或渐变效果,或者用户正在滚动页面,那么浏览器渲染动画或页面的每一帧的速率也需要跟设备屏幕的刷新率保持一致. 其中每个帧的预算时间仅比 16 毫秒多一点 (1 秒/ 60 = 16.66 毫秒).但实际上,浏览器有整理工作要做,因此所有工作需要在 10 毫秒内完成.如果无法符合此预算,帧率将下降,并

提高scroll性能

在DevTools中开始渲染,向下滑动一点点滚动条,然后停止滚动. 在结果中,注意frames总是在30ftps线上面,甚至都木有很接近69ftps线的(事实上帧执行的太缓慢以致于60ftps线在图上都不显示) 打开一个帧可以看见在scrol事件之后是一个函数回调,然很多分离的layout事件,每个分离的layout事件都有一个红色的小三角形,红色小三角形是强制同步layout( a forced synchronous layout )执行的标记. Note 被强制的synchronous l

【译】使用requestIdleCallback

英文原文:https://developers.google.com/web/updates/2015/08/27/using-requestidlecallback(备好梯子) 如有不当之处,还请指正. 概览: requestIdleCallback是一个当浏览器处于闲置状态时,调度工作的新的性能相关的API 正文: 如今,大多数的站点和app都需要执行很多的js脚本.你的js通常需要尽可能快地执行,而且,你又不希望通过获取用户行为的方式来达成目的.如果当用户滚动页面的时候,你的JS开始上报数

Xamarin.iOS:iOS Layout Gotchas Redux(转载)

原文地址:http://blog.adamkemp.com/2014/12/ios-layout-gotchas-redux.html iOS Layout Gotchas Redux Since my last post on iOS Layout GotchasI have encountered a few more basic layout mistakes that can lead to bugs and brittle code. Some of these are things

Android偏好设置(7)自定义Preference,和PreferenceDialog

Building a Custom Preference The Android framework includes a variety of Preference subclasses that allow you to build a UI for several different types of settings. However, you might discover a setting you need for which there’s no built-in solution

Android应用Preference相关及源码浅析(Preference组件家族篇)

1 前言 前一篇(点我阅读前一篇<Android应用Preference相关及源码浅析(SharePreferences篇)>)我们讨论分析使用了Android的SharePreferences,相信看过的朋友都有了自己的感悟与理解,这一篇我们继续乘热打铁来说说SharePreferences的衍生品--Preference组件. 其实Preference组件大家一定不陌生,因为Android系统的Setting应用及我们市面上一些符合Android设计思想的应用的设置界面一般都会用它来实现,

Android进阶——Preference详解之Preference系的基本应用和管理(二)

引言 前面一篇文章Android进阶--Preference详解之初识Preference及Preference系(一)简单描述下了Preference的家族构成和基本知识,相信对于Preference早已不会陌生,肯定也跃跃欲试了吧,这篇文章就给大家总结下Preference.PreferenceActivity.PreferenceGroup.RingtonePreference的普通应用和管理,还有通过一些测试来验证一些机制和原理. 一.PreferenceActivity 1.Prefe

安卓Preference详解

Preference 用来管理应用程序的偏好设置和保证使用这些的每个应用程序的所有参数 拥有同样的方式和用户体验   并且系统和其他应用程序的UI保持偏一致. 一个应用程序的偏好部分应作为一个独立的活动扩展preferenceactivity类 类中的对象应该是preferencescreen ,preferencescreen包含偏好等元素的布局的根元素 比如checkboxpreference EditTextPreference, ListPreference, PreferenceCat

Android中Preference的使用以及监听事件分析

> 在Android系统源码中,绝大多数应用程序的UI布局采用了Preference的布局结构,而不是我们平时在模拟器中构建应用程序时使用的View布局结构,例如,Setting模块中布局.当然,凡事都有例外,FMRadio应用程序中则使用了View布局结构(可能是该应用程序是marvel公司提供的,如果由google公司做,那可说不准).归根到底,Preference布局结构和View的布局结构本质上还是大同小异,Preference的优点在于布局界面的可控性和高效率以及可存储值的简洁性(每个