CSS のパフォーマンスを最適化するにはどうすればよいですか?最適化のヒントの共有

CSS のパフォーマンスを最適化するにはどうすればよいですか?次の記事では、CSS のパフォーマンス最適化のヒントをいくつか紹介します。お役に立てば幸いです。

インターネットの発展に伴い、Web サイトのパフォーマンスの重要性がますます高まっています。CSS は、ページのレンダリングとコンテンツのプレゼンテーションの重要な部分として、ユーザーの理解に影響を与えます。ウェブサイト全体を初めて体験する。したがって、CSS に関連するパフォーマンスの最適化に注意を払う必要があります。 [推奨学習: css ビデオ チュートリアル ]

プロジェクト開発の初期段階では、さまざまな理由が考えられます (理由の大部分はプロジェクトの期間によるもので、 (製品のせいでプロジェクトの立ち上げ時間が遅れることがよくあります)、パフォーマンスの最適化についてはあなたの言うことさえ聞きません)、自分がやりやすいと思うことを何でも書いてください。パフォーマンスの最適化については、プロジェクトが完了してから検討することが多く、延期されることがよくあります。プロジェクトの最後まで、または重大なパフォーマンス上の問題が明らかになった場合でも、パフォーマンスの最適化を実行します。

この状況を回避するには、まずパフォーマンスの最適化に関連する作業に注目し、それを製品の設計と開発全体に組み込む必要があります。 2 つ目は、パフォーマンスに関連する内容を理解し、プロジェクトの開発プロセス中にパフォーマンスの最適化を自然に実行できるようにすることです。

css レンダリング ルール

CSS のパフォーマンスを最適化するには、まず CSS のレンダリング ルールを理解する必要があります。CSS セレクターは右から左に一致します

例を見てみましょう:

.nav h3 a{font-size: 14px;}复制代码

レンダリング プロセスは次のようになります: まず最初にすべての a を検索し、次に a## の親要素に沿って h3## を検索します。 # # を入力し、h3 に沿って .nav を検索します。一致ルールを満たすノードが途中で見つかった場合は、結果セットに追加されます。ルート要素 html に一致するものがない場合、パスは走査されなくなり、次の a から検索が繰り返されます (右端のノードが複数ある限り)。 a のページ)。

ヒント: CSS セレクターはなぜ右から左に一致するのでしょうか?

CSS 内のセレクターがさらに多くなると一致しなくなるため、パフォーマンスの問題を考慮する場合、考慮する必要があるのは、セレクターが一致しない場合に効率を向上させる方法です。右から左に一致させることでこの目的を達成することができ、この戦略により、一致しない場合の CSS セレクターの効率を高めることができます。このように考えると、マッチング中にパフォーマンスをより多く消費するのは理にかなっています。

インラインの最初の画面クリティカル CSS (Critical CSS)

パフォーマンスの最適化には重要な指標があります -

(First Meaningful Paint、と呼ばれます) FMP) は、ページの主要なコンテンツが画面に表示される時間を指します。このインジケーターは、ユーザーがページを表示するまでに必要な待ち時間に影響します。最初の画面にインライン クリティカル CSS (つまり、最初の画面ではクリティカル CSS と呼ぶことができます) を使用すると、これを短縮できます。時間。 多くの人は、

タグを通じて外部の CSS ファイル を参照することを好みます。ただし、知っておく必要があるのは、 CSS を HTML ドキュメントに直接インライン化すると、CSS のダウンロードが 高速になる可能性があるということです。外部 CSS ファイルを使用する場合は、HTML 文書をダウンロードした後に参照する CSS ファイルを把握してダウンロードする必要があります。したがって、 インライン CSS は、HTML のダウンロードが完了した後にレンダリングできるため、ブラウザーがページのレンダリングを より早く開始できるようになります。 ただし、[初期輻輳ウィンドウ]

には制限があるため、HTML ドキュメント内のすべての CSS をインライン化するべきではありません。 CSS のインライン化がこの制限を超えると、システムはサーバーとブラウザーの間でより多くの往復を行う必要があり、ページのレンダリング時間は短縮されません。したがって、スクロールせずに見えるコンテンツ を HTML にレンダリングするために必要な重要な CSS のみを インライン化する必要があります。 ⚠️もう 1 つ注意すべき点は、インライン CSS はキャッシュされず、HTML が読み込まれるたびに再ダウンロードされることですが、インラインの最初の画面の主要な CSS は

ファーストスクリーン以外の CSS の非同期読み込み

Theseブラウザでのインタビューの質問については、「あなたが答えられる答えの数を確認してください?」を参照してください。

は
• DOM の解析をブロックしませんが、ブロックします。 DOM CSS
のレンダリングは
• JS の実行をブロックしますが、JS ファイル# のダウンロードはブロックしません## CSS が原因で DOM のレンダリングがブロックされるため、最初の画面に主要な CSS をインライン化した後、最初の画面の外側にある残りの CSS コンテンツは外部 CSS を使用して非同期に読み込まれるため、最初の画面の外側にある CSS コンテンツがページのレンダリングをブロックしないようにします。

CSS の非同期読み込み方法

最初の方法は動的に作成する方法です。

// 创建link标签
const myCSS = document.createElement( "link" );
myCSS.rel = "stylesheet";
myCSS.href = "mystyles.css";
// 插入到header的最后位置
document.head.insertBefore( myCSS, document.head.childNodes[ document.head.childNodes.length - 1 ].nextSibling );

第二种方法是将link元素的media属性设置为用户浏览器不匹配的媒体类型（或媒体查询）

对浏览器来说，如果样式表不适用于当前媒体类型，其优先级会被放低，会在不阻塞页面渲染的情况下再进行下载。在首屏文件加载完成之后，将media的值设为screen或all，从而让浏览器开始解析CSS。

<link rel="stylesheet" href="mystyles.css" media="noexist" onload="this.media=&#39;all&#39;">

第三种方法是通过rel属性将link元素标记为alternate可选样式表

<link rel="alternate stylesheet" href="mystyles.css" onload="this.rel=&#39;stylesheet&#39;">

第四种方法是使用rel=preload来异步加载CSS

<link rel="preload" href="mystyles.css" as="style" onload="this.rel=&#39;stylesheet&#39;">

注意，as是必须的。忽略as属性，或者错误的as属性会使preload等同于XHR请求，浏览器不知道加载的是什么内容，因此此类资源加载优先级会非常低。as的可选值可以参考上述标准文档。

看起来，rel="preload"的用法和上面两种没什么区别，都是通过更改某些属性，使得浏览器异步加载CSS文件但不解析，直到加载完成并将修改还原，然后开始解析。

但是它们之间其实有一个很重要的不同点，那就是使用preload，比使用不匹配的media方法能够更早地开始加载CSS。所以尽管这一标准的支持度还不完善，仍建议优先使用该方法。

CSS文件压缩

这应该是最容易想到的一个方法了，通过压缩CSS文件大小来提高页面加载速度。现在的构建工具，如webpack、gulp/grunt、rollup等也都支持CSS压缩功能。压缩后的文件能够明显减小，可以大大降低了浏览器的加载时间。

CSS层级嵌套最好不要超过3层

一般情况下，元素的嵌套层级不能超过3级，过度的嵌套会导致代码变得臃肿，沉余，复杂。导致css文件体积变大，造成性能浪费，影响渲染的速度！而且过于依赖HTML文档结构。这样的css样式，维护起来，极度麻烦，如果以后要修改样式，可能要使用!important覆盖。尽量保持简单，不要使用嵌套过多过于复杂的选择器。

删除无用CSS代码

一般情况下，会存在这两种无用的CSS代码：一种是不同元素或者其他情况下的重复代码，一种是整个页面内没有生效的CSS代码。

对于前者，在编写的代码时候，我们应该尽可能地提取公共类，减少重复。对于后者，在不同开发者进行代码维护的过程中，总会产生不再使用的CSS的代码，当然一个人编写时也有可能出现这一问题。而这些无用的CSS代码不仅会增加浏览器的下载量，还会增加浏览器的解析时间，这对性能来说是很大的消耗。所以我们需要找到并去除这些无用代码。

那么我们如何知道哪些CSS代码是无用代码呢？

谷歌的Chrome浏览器就有这种开箱即用的功能。只需转到查看>开发人员>开发人员工具，并在最近的版本中打开Sources选项卡，然后打开命令菜单。然后，点击Coverage，在Coverage analysis窗口中高亮显示当前页面上未使用的代码。

慎用*通配符

我们有时候可能会写下面这种代码来消除一些标签的默认样式或统一浏览器对标签渲染的差异化：

*{
  margin：0；
  padding：0;
}

这样虽然代码量少，但它的性能可不是最佳的，我们最好还是写对应的标签选择器：

body,dl,dd,h1,h2,h3,h4,h5,h6,p,form,ol,ul{
  margin：0；
  padding：0;
}

开发时尽量避免使用通配符选择器

小图片处理方式

一般来讲一个网站上肯定会有很多个小图标，对于这些小图标，目前的主流的解决方案有三个，cssSprite(雪碧图)，字体图标，把图片转成base64。

• cssSprite： 把所有icon图片合成一张png图片，使用时对节点设置宽高，加上bacgroud-position进行背景定位。以背景图方式显展示需要的icon，如果一个网站有20图标，那么就要请求20次，使用cssSprite，只需要请求一次，大大的减少了http请求。缺点就是管理不灵活，如果需要新增一个图标，都需要改合并图片的源文件，图标定位也要规范，不然容易干扰图片之间的定位。
• 字体图标： 简单粗暴的理解就是把所有的图标当成一个字体处理！这样不用去请求图片。一般是使用class来定义图标，要替换图标时，只需更换样式名，管理方便，语意明确，灵活放大缩小，并且不会造成失真。但是只支持单色的图片。
• base64： 另一种方案就是把小的icon图片转成base64编码，这样可以不用去请求图片，把base64编码直接整合到js或者css里面，可以防止因为一些相对路径，或者图片被不小删除了等问题导致图片404错误。但是找个方式会生成一大串的base64编码。一般来说，8K以下的图片才转换成base64编码。如果把一张50K的图片转成base64编码，那么会生成超过65000个字符的base64编码，字符的大小就已经是将近70K了！建议就是：8K以下的图片才转换成base64编码。

避免使用@import

不建议使用@import主要有以下两点原因：

• 使用@import引入CSS会影响浏览器的并行下载。使用@import引用的CSS文件只有在引用它的那个css文件被下载、解析之后，浏览器才会知道还有另外一个css需要下载，这时才去下载，然后下载后开始解析、构建render tree等一系列操作。这就导致浏览器无法并行下载所需的样式文件。

• 多个@import会导致下载顺序紊乱。在IE中，@import会引发资源文件的下载顺序被打乱，即排列在@import后面的js文件先于@import下载，并且打乱甚至破坏@import自身的并行下载。

不要在ID选择器前面进行嵌套其它选择器

在ID选择器前面嵌套其它选择器纯粹是多余的

• ID选择器本来就是唯一的而且人家权值那么大，前面嵌套（.content #text）完全是浪费性能。
• 除了嵌套，在ID选择器前面也不需要加标签或者其它选择器。比如 div#text或者.box#text。这两种方式完全是多余的，理由就是ID在页面就是唯一的。前面加任何东西都是多余的！

删除不必要的单位和零

CSS 支持多种单位和数字格式，可以删除尾随和跟随的零，零始终是零，添加维度不会为包含的信息附带任何价值。

.box {
  padding: .2px;
  margin: 20px;
  avalue: 0;
}

优化回流与重绘

在网站的使用过程中，某些操作会导致样式的改变，这时浏览器需要检测这些改变并重新渲染，其中有些操作所耗费的性能更多。我们都知道，当FPS为60时，用户使用网站时才会感到流畅。这也就是说，我们需要在16.67ms内完成每次渲染相关的所有操作，所以我们要尽量减少耗费更多的操作。

减少回流与重绘

合并对DOM样式的修改，采用css class来修改

const el = document.querySelector('.box')
el.style.margin = '5px'
el.style.borderRadius = '12px'
el.style.boxShadow = '1px 3px 4px #ccc'

建议使用css class

.update{
  margin: 5px;
  border-dadius: 12px;
  box-shadow: 1px 3px 4px #ccc
}
const el = document.querySelector('.box')
el.classList.add('update')

如果需要对DOM进行多次访问，尽量使用局部变量缓存该DOM

避免使用table布局，可能很⼩的⼀个⼩改动会造成整个table的重新布局

CSS选择符从右往左匹配查找，避免节点层级过多

DOM离线处理，减少回流重绘次数

离线的DOM不属于当前DOM树中的任何一部分，这也就意味着我们对离线DOM处理就不会引起页面的回流与重绘。

• 使用display: none，上面我们说到了 (display: none) 将元素从渲染树中完全移除，元素既不可见，也不是布局的组成部分，之后在该DOM上的操作不会触发回流与重绘，操作完之后再将display属性改为显示，只会触发这一次回流与重绘。

提醒⏰：visibility : hidden 的元素只对重绘有影响，不影响重排。

• 通过 documentFragment 创建一个 dom 文档片段,在它上面批量操作 dom，操作完成之后，再添加到文档中，这样只会触发一次重排。

const el = document.querySelector('.box')
const fruits = ['front', 'nanjiu', 'study', 'code'];
const fragment = document.createDocumentFragment();
fruits.forEach(item => {
  const li = document.createElement('li');
  li.innerHTML = item;
  fragment.appendChild(li);
});
el.appendChild(fragment);

• 克隆节点，修改完再替换原始节点

const el = document.querySelector('.box')
const fruits = ['front', 'nanjiu', 'study', 'code'];
const cloneEl = el.cloneNode(true)
fruits.forEach(item => {
  const li = document.createElement('li');
  li.innerHTML = item;
  cloneEl.appendChild(li);
});
el.parentElement.replaceChild(cloneEl,el)

DOM脱离普通文档流

使用absoult或fixed让元素脱离普通文档流，使用绝对定位会使的该元素单独成为渲染树中 body 的一个子元素，重排开销比较小，不会对其它节点造成太多影响。

CSS3硬件加速（GPU加速）

使用css3硬件加速，可以让transform、opacity、filters这些动画不会引起回流重绘 。但是对于动画的其它属性，比如background-color这些，还是会引起回流重绘的，不过它还是可以提升这些动画的性能。

常见的触发硬件加速的css属性：

• transform
• opacity
• filters
• Will-change

将节点设置为图层

图层能够阻⽌该节点的渲染⾏为影响别的节点。⽐如对于video标签来说，浏览器会⾃动将该节点变为图层。

具体回流与重绘知识点可以看我这篇文章：https://juejin.cn/post/7064077572132323365

（学习视频分享：web前端）

以上がCSS のパフォーマンスを最適化するにはどうすればよいですか?最適化のヒントの共有の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。