フロントエンド最適化実践の概要_html/css_WEB-ITnose

元 Baidu エンジニアの Zhang Yunlong 氏が、ページのフロントエンドの最適化の問題は間違いなくページの高速化だけの問題ではなく、エンジニアリングの問題でもある、と述べたのを覚えています。興味のある学生は『フロントエンド エンジニアリングとパフォーマンス』を読んでください。最適化"。 Yahoo の 14 の最適化原則に基づいて整理された最適化の方向性、『高パフォーマンス ウェブサイト構築ガイド』および『高パフォーマンス ウェブサイト構築上級ガイド』で言及されている最適化のポイントについて言及しています。最適化の方向性が提案されてから 2 年が経過し、フロントエンド技術も急速に発展していますが、ここで述べたエンジニアリングのアイデアは依然としてフロントエンド最適化の一般的な方向性であり、大きな指針となる重要性を持っています。

もちろん、これは別の大きなトピックです。この記事では、かわいい女の子 Nuannuan が書いた「フロントエンド最適化のための完全なガイド」に従って、最適化ポイントを 1 つずつ列挙しているわけではありません (もちろん、それほど多くはありません。 -最適化の終了 決して終わらせることはできません、終わらせることはできません :-O) でも、

プロジェクトの概要を組み合わせることに重点を置いてください

この最適化では、

最適化ポイントを見つける方法

と、より大きな利益をもたらす一般的な方法に焦点を当てます。同様の問題に遭遇した学生を助けることができれば幸いです。フロントエンドマスターは微笑んで通り過ぎるだけで済むので、役に立ちます。 HD 画像の適応と最適化 私たちが高解像度画像と呼ぶものは、一般に少なくとも Retina スクリーンレベルの精度を持つ画像を指し、一般に「2x」画像と呼ばれます。ハイビジョン映像の適応については、映像の特性やプロジェクトの実情に応じて適応計画を策定するのが一般的です。

単色画像は通常、サイド ナビゲーションのタイトル アイコンなどの小さな装飾アイコンに適用されます:

このタイプのアイコンは単色で構成され、特定の描画ルールに従って iconfont アイコンにすることができますiconfont アイコンはベクトルであり、スタイルによってサイズと色を制御できます。

新しいホームページには 33 個の単色のアイコンがあり、これらのアイコンは再利用性が高く、画像が従来の方法で作成されている場合、同じアイコンが異なるサイズになります。それらをすべてスプライト画像に結合したとしても、画像の K 数は非常に大きくなります。そのため、このホームページでは、後で修正が必要になると、スプライト画像を再度結合する必要があります。改訂版では、すべての単色アイコンは高解像度に対応するために iconfont アイコンを使用します。 :

ICONFONT アイコン管理

この改訂版で使用される ICONFONT アイコンの生成と管理は、対応するオンライン サービスである「Alibaba Vector Icon Library」を選択しました。アイコンの SVG ファイルをアップロードすることでフォント ファイルが生成され、アイコンに応じて対応するフォント ファイルも生成できます。 サブプロジェクト管理:

アイコンが生成された後、サービスは必要なファイルを自動的にパッケージ化し、ローカル プレビュー用のデモ Web ページを作成して、アイコンに対応するフォント エンコーディングと使用方法を見つけます。

フロントエンドの学生を信じています。私は長い間 ICONFONT サービスを使用してきました。著者は THX 組織に心から感謝しています。 ICONFONT サービスを提供する THX は、ICONFONT サービスに加えて、業界に多くの良心フロントエンド ツール サービスを提供していることに感謝します。

非ソリッド カラー イメージ

非ピュア カラー イメージは、通常、「2X」イメージを使用して適応されます。適応スキームには、メディア クエリ、srcset 属性、イメージ セット属性、およびスクリプト コントロールなど、多くのオプションがあります。

メディア クエリ、srcset 属性、および image-set 属性は基本的にハイエンド ブラウザと正常に一致しますが、互換性はわずかに悪く、スクリプト コントロールの互換性は優れていますが、プロジェクトにどれを使用するかは「国の条件」によって異なります。

上の図は、私の国の PC オペレーティング システムの市場シェアのおおよその分布です。95% 以上のユーザーが Windows システムを使用していることがわかります。ユーザーは基本的に Mac OS システムを使用し、Mac OS システムのブラウザは主に Chrome と Safari であるため、Mac OS デバイスへの適応のみを考慮し、最終的に「srcset 属性」を選択します。 「画像セット属性」ソリューション: コンテンツ画像は srcset 属性を使用して適応し、背景画像は画像セット属性を使用して高解像度画像に適応します。

<img src="images/bg_eco_v2_@1x.png" srcset="images/bg_eco_v2_@1x.png 1x, images/bg_eco_v2_@2x.png 2x" alt="">

デザイン フォント

JD Cloud の新しいバージョンが登場しました 新しい JD Cloud ホームページのセクション タイトルに使用されるフォントなど、通常非システム フォントと呼ばれるものである多くのデザイン フォント - 「Founder Lanting 超極細ブラックボディ」

デザインフォントについては、フロントエンドとビジョンが合意に達します このタイプのフォントは画像を使用するか、または経由でのみ実装できるため、大規模には使用されませんスタイル @font-face 属性:

画像ソリューション: 高精度で復元でき、強い互換性がありますが、変更されるたびに、すべての画像を変更する必要があり、メンテナンスが不便で、コンテンツも変更されます。また、高精細機器に対応させたい場合は、追加の画像セットが必要になります。

@font-face 属性スキーム: フォントはベクターであり、高解像度のデバイスに簡単に適応できます。コンテンツは拡張性が高くなりますが、ブラウザーごとにレンダリングに違いがあり、@font-face フォントの互換性はわずかに弱くなります。ファイル サイズ 通常、これは M レベルであり、ページの読み込みエクスペリエンスにさまざまな程度の影響を与えます。

非システム フォントが使用されているタイトルが少数で、頻繁に変更されない場合は、画像ソリューションを使用することをお勧めしますが、JD Cloud の新しいバージョンは他のフォントのホームページでも使用されます。チャンネルにはコンテンツが多く、高解像度の画像に適合させる必要があるため、画像スキームは適切ではなく、@font-face 属性スキームの方が適しています。

「@font-face属性スキーム」のファイルサイズが大きいとブラウザレンダリングの違いの2つの欠点を考慮して、ブラウザレンダリングの差異が視覚的に許容できる範囲内でのみ妥協する解決策が採用されます。使用するフォントが抽出されて、比較的小さなフォント ファイルが生成されます。

Junmer が作成した Fontmin ツールは、この需要に大きく応えます。フォント ソースと生成するテキスト コンテンツをツールに追加するだけで、対応するフォント ファイルを生成できます。生成されるフォント ファイルはわずか 11KB で、フォント ファイル サイズは 99% 削減されます

画像リソースの最適化

既存の問題

追加リクエストが多すぎます

古いバージョンのホームページが読み込まれると、合計 40 件のリクエストのうち、31 件の写真リクエストがあり、リクエスト総数の 77% を占めました

結合できる一部の写真は処理されません:

少なくとも 11 枚を 1 つの写真に結合できますつまり、追加リクエストが少なくとも 27% 増加します

リソースの無駄

最初の画面に 31 個の画像リソースがロードされますが、表示される画像は 2 枚だけで、画像リソースの 100% がロードされ、最初の画面の画像リソースはわずか 6% です

ユーザーが Web ページを完全に閲覧する前に他のページにジャンプする限り、リソースの無駄が発生します。

画像の読み込みエクスペリエンスが低い

最初の画面での大きな画像の長時間にわたる読み込みプロセスには、プレースホルダー画像の読み込みプロンプトが表示されず、カルーセル画像領域が長時間空白になる可能性があります:

上の図は、ページの読み込みに 1.8 秒かかっていることを示していますが、それでもバナーの背景画像が表示されません。インターネット速度が速いユーザーはこの状況に遭遇しない可能性がありますが、ネットワークが遅いユーザーがこの状況に遭遇する可能性は否定できません。

さらに、画像の読み込みに失敗した場合、フォールト トレランス処理が行われないため、画像の読み込み失敗のシステムのデフォルトのアイコン スタイルが表示される可能性があり、ページの美しさに影響します。計画

新しいバージョンのホームページでは、画像リソースのレイアウトとコンテンツが異なりますが、少なくとも 3 つの方向で改善できる可能性があります: 古いバージョンには大量の追加リクエスト、リソースの無駄、読み込みエクスペリエンスが不十分です。

余分なリクエストの数を減らす

画像に対する余分なリクエストの数を減らすには、通常、画像の結合、iconfont アイコン、Base64 という明らかな利点を持つ 3 つの方法があり、それぞれに独自の長所と短所があります。

画像の結合

利点: 強力な互換性、キャッシュ可能、ポリモーフィックな画像を事前に読み込むことができ、画像の読み込みと表示エクスペリエンスを向上させることができます

短所: メンテナンスが不十分、画像タイプとサイズ制御の結合に高い制限があり、場合によってはリソースの無駄を引き起こす

適したもの: 修正と更新が少ない常駐タイプ カラービットが少ない小さな装飾画像

アイコンフォント

• 長所: キャッシュ可能なベクターと強力な制御性

  短所: ブラウザのレンダリングの違い、単色のみ、わずかにファイルサイズが大きくなります

  適したもの: 単色のアイコン

Base64

• 長所: 追加リクエストなし

  短所: キャッシュ不可、互換性が低い、コードの冗長性、可読性が低い、メンテナンスが不便、CPU メモリの消費量が多い

  次の用途に適しています: サイズが小さく再利用率が低い背景装飾アイコン

新しいホームページには合計 70 個の画像リソースがあり、そのうち 49 個が単色のアイコン、16 個が低色の非単色画像、5 個が高色のアイコンです-カラービットマップ。

• 49 個の単色アイコンすべてが Iconfont メソッドを使用して処理され、13 個の低色の非単色画像がマージ メソッドを使用して処理され、追加のリクエストを減らすために合計 62 個の画像が処理され、画像リソース リクエストの最終的な数はわずか 14 件で、そのうち単色画像のリクエスト数は 2 件、低色非単色画像のリクエスト数は 6 件でした。画像リクエストの総数は 80% 減少し、追加のリクエスト数は 80% 減少しました。画像結合と Iconfont のリクエスト処理率はそれぞれ 56% と 96% に達しました

  Iconfont のアプリケーションに適したオブジェクトの特性が比較的単純であり、画像結合はマージされたイメージの形式、リソース配分、モジュール配分などの影響を受けるため、追加のリクエスト処理速度は比較的低くなります。

  画像を最適化するための追加リクエストについて、小さな結論を得ることができます: 単色アイコンの場合は Iconfont が優先され、低色の非単色画像はプロジェクトの実際のニーズに応じてマージされ、最適化されます。Base64 の非特殊画像は使用されません

リソースはオンデマンドでロードされます

新しいバージョン ホームページにロードする必要がある画像リソースは合計 14 個あります (最初の画面の 8 個の画像リソースと、表示されている 5 個の画像を含む)。最初の画面の画像リソースの使用率はわずか 35% です

如果进行资源按需加载，在非首屏的图片资源实行懒加载，将轮播图不可见的两张图片做触发加载处理，这样首屏的加载图片资源只有 8 个，首屏图片资源利用率则可达到 60%，提高了 70% 的图片资源利用率， 资源按需加载不失为一种避免资源浪费的最挂实践方法

占位提示图提高加载体验

图片加载的时间长短由很多因素决定，如服务器响应时间、用户所用网络带宽、图片大小等，但无论是哪一种情况，总有一个等待的过程，在这过程总会有一个空白时间，特别是占屏面积比较大的首屏轮播大图和采取懒加载的图片，即使图片空白时间很短，用户也会有不同程度的感知，会给用户带来一种唐突或漫长等待的感觉，如果加载过程给图片加上体积比较小的占位提示图，则会让用户有一个图片加载预知，当图片加载完成后再呈现给用户看，这样用户在图片加载过程中看到的都是完整的图片

当图片加载失败的时候，展示占位图，避免系统默认的图片加载失败图标出现

渐进增强优化

渐进增强是指从最基本的功能出发，在保证系统在任何环境中的可用性基础上，逐步增加功能，提高用户体验，

动画性能渐进增强

出现在页面比较重要位置的模块，如轮播图、导航等，如果需要做动画效果的话，在高低端浏览器上都应该能统一实现出来，新旧版首页首屏都以轮播图为主，轮播图切换都使用了渐隐渐现的动画效果。

旧版的动画实现在高低端浏览器都使用了 JQ 第三方动画库

...<script type="text/javascript" src="js/jcloud_new/jquery.SuperSlide.2.1.1.js"></script>..<script>//banner$(".banner-slider").slide({mainCell:".bd ul",effect:"fold",autoPlay:true,interTime:4000,delayTime:1000});$(".box-slider").slide({mainCell: ".bd ul", effect: "left", autoPlay: true, interTime: 5000, scroll: 6, vis: 6});...</script>

其实渐隐渐现的效果 CSS3 动画也能实现。新版首页的轮播图动画设置了 CSS3 动画后，再利用脚本控制样变化以触发 CSS3 动画，这样支持动画属性的浏览器就能以 CSS3 动画实现效果，而不支持的浏览器则通过脚本的属性判断，用 JQ 动画实现：

.fc_item{    position: absolute;    left: 0;    top: 0;    right: 0;    bottom: 0;    filter: alpha(opacity=0);    opacity: 0;    background: #fff;    @include trst(opacity 0.8s linear);}

 // 轮播图切换function imgChange(opt){      ...       // 如果支持 transform 属性，使用CSS3动画    if(supports('transform')){      $imgList.eq(opt).addClass('active').css('opacity','1').siblings().removeClass('active').css('opacity','0');    }else{    // 如果不支持 transform 属性，使用JQ动画      $imgList.eq(opt).stop().animate({        'opacity': '1'      },800).addClass('active').siblings().stop().animate({        'opacity': '0'      },800).removeClass('active');    }    ...}...

JQ 动画虽然兼容性好，但其动画性能远远不及 CSS3 动画， 因此我们可以用以下的方法对动画性能实现渐进增强：高端浏览器可以通过触发 CSS3 动画实现效果，低端浏览器则使用 JQ 动画实现。

视觉渐进增强

视觉渐进增强通常可以通过 CSS3 属性和增加 CSS3 动画来实现，现主流的网站基本都会对视觉做渐进增强处理。本次首页改版主要在多态元素、切换元素上做了处理

支持 CSS3 动画的 SexyGuy

不支持 CSS3 动画的 PoorGuy

Tab 键锚点聚焦优化

浏览页面的时候，通过 Tab 键可以聚焦页面上的链接锚点，这时候浏览器会在锚点增加一个系统默认边框样式告诉用户锚点已选中，按 Enter 就可以打开选中的锚点，如 Chrome 浏览器上 google 首页的语音搜索按钮：

即使用户在浏览页面的时候鼠标突然失灵了也可以通过键盘操作继续完成浏览网页，这样的设计显然是为了增强页面的可用性。

但很多时候，在一些重要位置的内容，如全站的导航，产品经理或视觉设计师会要求将这个系统的样式去掉，于是很多同学可能会选择设置 outline:none 去掉边框样式，有些甚至会在全局 a 标签上设置，如旧版的京东云首页：

outline:none 设置之后，页面上的所有链接虽然能通过 Tab 键聚焦，但链接并没有被选中的样式，没有办法直观辨出选中的链接

虽然并非所有用户都会用到 Tab 键，但还是会有少数用户会用到，如键盘党，而这种降低可用性的体验存在表明页面并没有健全，因此并不建议去掉 outline 样式。

如果真的有去掉 outline 样式的需求怎么办？其实，页面链接一般都会被设计为多态的，利用链接的多态样式，为链接加上 :focus 伪类选中样式，Tab 选中链接后就会展示 :focus 伪类样式了，如新版首页的导航：

可以为链接加上 :focus 伪类样式

.mod_hd_nav_sub_col{	...	a{		color: #fff;		text-decoration: none;		outline: none;		&:hover,&:focus{			color: #ffe400;			text-decoration: none;		}	}	...}

当选中链接还绑定有事件的时候，也应该为之绑定相应事件

...$navBox.on({	'mouseenter': function () {		...	},		'focus': function(){		$(this).trigger('mouseenter'); // Tab 操作支持	},	'mouseleave': function () {		...	},		'blur': function(){		$(this).trigger('mouseleave'); // Tab 操作支持	}}, '.mod_hd_nav_item');...

处理完，虽然 outline 样式去掉了，但依然可以用 Tab 键完成链接的选中

静态资源更新发布

旧版首页所有的静态资源的更新发布方式都是采用覆盖式更新：

...<script type="text/javascript" src="js/jcloud_new/jquery-1.7.2.min.js"></script><script type="text/javascript" src="js/jcloud_new/jquery.SuperSlide.2.1.1.js"></script><script type="text/javascript" src="js/jcloud_new/login_w.js"></script><script type="text/javascript" src="http://jcms.jd.com/resource/js/cms.js"></script>...

覆盖式更新发布有机会遇到缓存问题以及在发布的时候导致页面错乱问题，详情可以看一下张云龙前辈在知乎对问题『 大公司里怎样开发和部署前端代码？ 』的回答，解决覆盖式更新产生的问题，现主流方法就是使用 MD5 文件名进行非覆盖式发布，京东云新版首页所有的静态资源的更新发布都采用了这种方式。

...<script src="//labs.qiang.it/pc/jcloud/gb/js/lib.min_2f4dab0c.js"></script><script src="//labs.qiang.it/pc/jcloud/gb/js/gb.min_b599b860.js"></script><script src="//labs.qiang.it/pc/jcloud/home/js/index.min_9d957a15.js"></script>...

OK，优化永远说不完的，以上所说的只是前端优化的冰山一角，业界绝不缺高大上的优秀优化方案，但从业务实际规模出发的话，这些小优化在本次改版中已得到很明显的收益，期待以后有更具规模的项目可以挥霍高大上的优化方案，最后把新旧版的页面都放到预览服务器上了