フロントエンド最適化に関する不完全なガイド | Aotu.io 'Aotu Lab'_html/css

フロントエンド担当者として、推奨ブラウザはもちろん Chrome です。いくつかの基本機能からいくつかの高度なパフォーマンスアナライザー (タイムライン、プロファイル) までの一連の記事である「Chrome 開発者ツールの不完全ガイド」を読むことをお勧めします。Chrome に精通していることは、開発作業に大きな役割を果たします。

1.2.3 その他の一般的に使用されるツール

切削ツール: photoshop cc Cutting、Smart Cutting、Cutterman

色測定および距離測定ツール: FastStone Capture 、Mark Eel - デザインドラフトアノテーション

画像圧縮: tinypng、スマートイメージ

スプライト画像の生成: spritebox、CSS Sprite Generator、cssgaga

デバッグツール: Fiddler、weinre、WeChat デバッグツール;

1.2.4 フロントエンドエンジニアリング

重複はツールを使用して自動的に完了する必要があります。

ツールはたくさんあるので、スプライト画像の自動生成やCSS圧縮、画像圧縮などを行えるツールはないだろうか、ということでフロントエンドエンジニアリングが登場しました。フロントエンドエンジニアリングは一般に 5 つのステップに分けることができます:

(1) 最初に、基本的なディレクトリ構造とスタイルライブラリを生成します。

(2) 開発、リアルタイムプレビュー、プリコンパイル。

(3) ビルド、プリコンパイル、マージ、圧縮。

(4) 公開、構築された静的ファイルをオンラインで公開します。

(5) パッケージ化、リソースパス変換、ソースコードのパッケージ化。

フロントエンド開発における自動化ツール、パフォーマンスの最適化、モジュラーフレームワーク、開発仕様、コードのデプロイメント、開発プロセスなどの問題を解決するために推奨されるツールを紹介します。また、O2Team が開発したプロジェクトプロセスツールである athena もあり、対応するディレクトリとコードを生成し、同時にプロジェクトをコンパイルし、一度インストールすればどこでも実行できます。

1.3 経験と経験

私が理解しているプログラマーは、知性と「怠惰」の精神を兼ね備えており、怠惰な開発を提唱しています。つまり、問題を明確に理解し、作成するコードが本当に実行できることを保証します。問題を解決するいわゆる「怠惰」が効率をもたらすため、これにより、将来的に無駄なコードを大量に作成することがなくなります。

私たちの経験と経験により、最適なソリューションを選択するためにコードを考える時間が大幅に向上します。そのため、コードをより速く書くことができ、コードの長さもより短くなります。この問題により、コードのデバッグが容易になり、速度も向上します。

経験や経験に基づいて、または他の人の助けを借りて、私たちはそれを整理して自分自身またはチームの標準を形成し、コーディング速度を大幅に向上させることができます。

1.4 新しいテクノロジーの使用

新しいテクノロジーを使用して作業効率を向上させる方法。私たちは常に使い慣れたテクノロジーを使用して技術ソリューションを開発してきましたが、結局のところ、新しいテクノロジーの学習には依然として時間のコストがかかります。ただし、一般に、新しいテクノロジには、多くの複雑な操作をより簡単に実装し、開発者の効率を向上させるいくつかの優れた新機能が含まれています (ES6 など)。 洞察力を活用して新しいテクノロジーを蓄積すると、役立ちます。

2 スピードパフォーマンス

なぜフロントエンドパフォーマンスの最適化が必要なのでしょうか?パフォーマンスを最適化するにはどのような側面から始めればよいでしょうか?

5 秒間ロードされなかったページが回転したり、ページが完全に空白になったりすると、人々は単純に気が狂ってしまいます。ユーザーエクスペリエンスの観点から、フロントエンドのパフォーマンスの最適化は非常に必要です。通常、Web ページの最大読み込み時間は 3 秒を超えることはできません。

まず、Web ページのパフォーマンス指標を決定する必要があります。定量化可能な目標と継続的に追跡される最適化データは、継続的なパフォーマンスの最適化作業を保証するものであり、モチベーションの源でもあります。例:

最初の画面読み込み時間
DOM 読み込み時間
ページの白画面時間

通常、 3 Web ページのパフォーマンスを確認するには、いくつかの方法があります。

ブラウザ開発者ツールやブラウザプラグイン、Fiddler、Charles などを使用して、ページの読み込みステータスを確認します。原則は、HTTP リクエストと応答時間を追跡することで、すべてのリソースのダウンロードステータスをグラフィカルにリストすることです。欠点は、手動操作ではバッチテストと統計を達成することが困難であることです。
時間やその他の関連データを記録するために、ページに追加のコードフックを導入します。欠点は、開発者とテスターの負担が増えることと、検出コード自体の潜在的な問題によりページのパフォーマンスに影響を与える可能性があることです。より良い場合は、パフォーマンスデータ収集システムに接続してデータを収集および分析します。
Page Speed、YSlow、WebPagetest などのサードパーティツールを使用すると、さまざまなブラウザやさまざまな地域でのテストを選択し、さまざまな側面でスコアを与え、最適化の提案を提供できます。ただし、一部のサービスは列に並んで待つ必要があり、バッチテストと統計を達成するのが困難です。以下は JD ホームページをテストするための WebPagetest の使用です:

幸いなことに、W3C は開発者のWeb サイトのパフォーマンスを正確に分析および制御し、最終的にパフォーマンスの向上を達成するプロセス。たとえば、ナビゲーションタイミングによって記録された主要な時点を使用して、ページを完了するまでにかかる時間をカウントします。いくつかの使用方法:

var timing = window.performance.timingtiming.domLoading  //浏览器开始解析 HTML 文档第一批收到的字节timing.domInteractive  // 浏览器完成解析并且所有 HTML 和 DOM 构建完毕timing.domContentLoadedEventStart //DOM 解析完成后，网页内资源加载开始的时间timing.domContentLoadedEventEnd // DOM 解析完成后，网页内资源加载完成的时间（如 JS 脚本加载执行完毕）timing.domComplete //网页上所有资源（图片等）下载完成,且准备就绪的时间

ログイン後にコピー

継続的に追跡します。パフォーマンスデータを選択し、適切なものを選択すると、履歴データの参照可能性を確保するためにページパフォーマンス測定ツールまたは API は置き換えられません。また、意識を形成し、重要なビジネスやページについては、パフォーマンスの観点から問題を検討し、フロントエンドのパフォーマンスを損なうビジネス要件や変更を合理的な証拠に基づいて拒否する必要があります。

Yahoo のルールは誰もが知っているので、スクリーンショットを撮らせてください。

以下では、サーバー、ネットワーク、クライアントの 3 つの側面から速度とパフォーマンスの向上をブレークスルーします。

2.1 何もすることがなければ気にしないでください - サーバー

2.1.1 コンテンツ配信ネットワーク (CDN) を使用します

既存のインターネットにレイヤーを追加することによって新しいネットワークアーキテクチャでは、Web サイトのコンテンツをユーザーに最も近いキャッシュサーバーに公開します。DNS 負荷分散テクノロジを通じて、

はユーザーのソースを特定し、近くのキャッシュサーバーにアクセスして必要なコンテンツ

を取得します。確かに、深センのユーザーが米国のリモートサーバーにアクセスするのは理想的ではありません。静的コンテンツを CDN に配布すると、ユーザーの応答時間を 20% 以上短縮できます。 2.1.2 静的リソースキャッシュ、モバイルオフラインキャッシュ

アプリケーションの実行時にサーバーの負荷が軽減され、リソースが使用されたり、リソースの読み込みが速くなったりできたら素晴らしいと思いませんか?オフライン？キャッシュの使用には、Expires ヘッダーの追加、ETag の構成、Ajax のキャッシュ可能化などが含まれます。実際、キャッシュを適切に設定すると、HTTP リクエストが大幅に削減され、帯域幅が節約されます。

ETag を設定します: If-None-Match: 最後の ETag の内容。ブラウザは、リソースの有効期限が切れているかどうかを尋ねるリクエストをサーバーに送信し、サーバーはリソースの有効期限が切れていないことを確認し、ステータスコード 304 と空の本文を含む応答を直接返し、ブラウザにローカルキャッシュを使用するように指示します。 ; リソースが更新されている場合、サーバーはステータスコード 200、Etag、およびテキストを返します。このプロセスは HTTP ネゴシエーションキャッシュと呼ばれ、しばしば弱いキャッシュとも呼ばれます。
Expires ヘッダーの追加: サーバーは、応答ヘッダーを通じて、何時まで (Expires) またはどのくらいの期間 (Cache-Control: Max-age=xxx) 以内にサーバーを再度リクエストしないことをブラウザーに伝えます。このメカニズムは通常、HTTP 強力なキャッシュと呼ばれます。一般に、CSS、JS、画像などのリソースには強力なキャッシュが使用されますが、エントリファイル (HTML) ではネゴシエートされたキャッシュが使用されるか、キャッシュなしが使用されます。
AppCache:

AppCache は主にマニフェストテキストファイルを使用して、キャッシュされたコンテンツとキャッシュできないコンテンツをブラウザーに通知します。

マニフェストファイルは 3 つの部分に分割できます:

(1) キャッシュマニフェスト - この見出しの下にリストされているファイルは、最初のダウンロード後にキャッシュされます。 CACHE

(2) NETWORK - この見出しの下にリストされているファイルはサーバーへの接続が必要であり、キャッシュされません

(3) FALLBACK - この見出しの下にリストされているファイルはフォールバックを指定しますページにアクセスできない場合のページ

AppCache ソリューションを使用する手順:

(1) juqery など、キャッシュする必要がある静的ファイルのリストを整理します。 jsとgb.css。

(2) サーバーのサポートを構成します。

(3) コンテンツ更新メカニズムとブラウザ互換性ソリューションを決定します。

LocalStorage: データがアクティブに削除されない限り、永続化に使用されるローカルストレージ。

2.2 お金の節約 - ネットワーク

2.2.1 リクエストの数を減らす

次の方法でリクエストの数を減らすことができます:

小さな画像はスプライト画像にマージされます。
JS ファイルと CSS ファイルは選択的にマージされます。
繰り返しのリソース要求を回避します。

リクエストの数を減らすことは、特にネットワーク接続が弱いユーザーにとって、速度の最適化にとって最も重要かつ効果的です。完全なリクエストは、ドメイン名解決と DNS アドレス指定のプロセスを経て、サーバーとの接続を確立し、データを送信し、サーバーの応答を待ち、データを受信する必要があります。各リクエストはデータを運ぶ必要があるため、各リクエストが占有する必要があります。帯域幅、ブラウザが実行する同時リクエスト数には上限があります。リクエストが多すぎると、Web ページの応答時間が明らかに長くなります。ページは複数のモジュールで構成されます。同じリソースが複数のモジュールで要求されると、リソースの要求が繰り返されることになります。

2.2.2 ファイルサイズの削減 (リクエスト帯域幅の削減)

CSS、JS、および画像を圧縮します。
DOM ノードの数を可能な限り制御します。 ;
CSS と JavaScript を合理化し、コメント、スペース、繰り返しの CSS とスクリプトを削除します。
Gzip をオンにします。Gzip の考え方は、まずサーバー側でファイルを圧縮し、圧縮率が 85% に達してから送信が完了すると、ブラウザが再送信します。 -圧縮されたコンテンツを解凍して実装します。。 Gzip の利点は、サポートが充実しており、圧縮率が 66% ～ 85% に達するため、ファイル転送のサイズが大幅に削減されることです。さらに、gzip は PDF ファイルの圧縮にはほとんど効果がなく、CPU を無駄に消費します。

2.2.3 静的リソースのドメイン名の適切な使用

ドメイン名は短く、独立している必要があります。

ドメイン名が短いほど、リクエストヘッダーの開始行の URI も短くなるため、短くするとヘッダーのオーバーヘッドが削減されます。独立性が必要な理由は、独立したドメイン名がメインドメインの Cookie を共有しないため、この戦略は一般に Cookie フリードメインと呼ばれ、もう 1 つの理由はブラウザーが同時接続の数を制限するためです。通常、同じドメイン名に対して 6 ～ 8 の同時接続が許可されるため、各ドメイン名の最初の接続には一定の時間がかかります。ドメイン名の使用を 2 ～ 4 の範囲内で制御します。また、同じ静的リソースが異なるページの異なるサブドメインにハッシュされるため、HTTP キャッシュを利用できなくなることに注意してください。

2.2.4 HTTP 2 の使用

HTTP 1.1 と比較した HTTP 2 の更新点は主に次の点に焦点を当てています。

多重化: 多重化は、重要なリソースをできるだけ早くロードする方法の問題に対する優れた解決策です。同じドメイン名または異なるドメインの下で、同じ IP の 2 つの条件を満たし、同じ証明書を使用するすべての通信は、単一の接続 で完了し、任意の数の双方向データストリームがこの接続上で開かれます。 (HTTP 1.1 には接続数に制限があります)。同じ IP と証明書を持つ複数のドメイン名を使用して Web サービスを展開することには特別な意味があります。つまり、HTTP/2 をサポートする端末は 1 つの接続のみを確立し、HTTP/1.1 のみをサポートしながら HTTP/2 プロトコルによってもたらされるさまざまな利点を利用できるようになります。端末は、より多くの同時リクエストを同時に達成するために複数の接続を確立します。
HEAD 圧縮: HTTP/2 は、リクエストデータと応答データをより小さなフレームに分割し、それらにバイナリエンコード (バイナリフレーミング) を使用します。 HTTP/1 では、HTTP リクエストとレスポンスは、ステータス行、リクエスト/レスポンスヘッダー、メッセージ本文の 3 つの部分で構成されます。ステータス行とヘッダーは圧縮されず、プレーンテキストで直接送信されます。次の図を比較してください:

HTTP/2 では、各データストリームはメッセージの形式で送信され、メッセージは 1 つ以上のフレームで構成されます。複数のフレームは、フレームヘッダー内のストリーム識別子に基づいて再組み立てできるため、順序を間違えて送信することができます。
リクエストの優先度: サーバーはフローの優先度に応じてリソース割り当て (CPU、メモリ、帯域幅) を制御でき、応答データの準備ができた後、最も優先度の高いフレームが優先されます。優先的にクライアントに送信されます。
サーバープッシュ: サーバープッシュを開始します。これは、サーバーがページ HTML を送信するときに他のリソースをアクティブにプッシュできることを意味し、独自の URL を持ち、ブラウザーによってキャッシュできます。サーバーがプッシュするリソースはブラウザーによってキャッシュされており、ブラウザーは RST_STREAM フレームを送信することでリソースを拒否できます。

2.2 家を運営し、シンプルで美しい家にする方法を学ぶ - クライアント

外部リンク CSS と JS を使用し、先頭に CSS、最後に JS を置きます。ブロッキングを防止して同時ダウンロードへの影響を軽減し、ドキュメント出力をできるだけ早くフラッシュします。
HTML コードの最適化 (例:
- 空の画像ソースを回避します。
- プロトコルの適応、HTML ファイルサイズの削減、https:// と http:// の変換、すべて置換)と //。
以下のような CSS コードの最適化:
- アクセスを高速化するには、クラスセレクターを使用することをお勧めします。
- 非常に長いものは使用しないでください。 Base64;
- CSS 式を避けます。
- フィルターの使用を避けます。
次のような js コードの最適化:
- eval と width の使用を回避します。
- DOM を削減します。アクセスして DOM をキャッシュしてみます。
- イベント委任を最大限に活用します。
- 要素を更新してリフローの回数を減らすのが最善です。クラスの設定などのバッチでクラスはスタイルを均一に更新します。複数の li
- 要素を追加すると複数のページリフローがトリガーされる場合は、DOM fargment を使用してメモリ内に完全な DOM ノードを作成し、それらを一度に DOM に追加します。
画像形式の選択:
色が豊富で比較的大きなファイル (40KB ～ 200KB) の画像、またはコンテンツを含む画像は、jpg やその他の色で優先されます。比較的シンプルで、ファイルサイズが小さく、装飾に使用される画像の場合は、PNG8 形式が推奨されます。色が豊富でファイルサイズが大きすぎない (40 KB 未満)、または半透明の画像の場合は、PNG24 形式が推奨されます。効果。
- 条件が許せば、新しい形式の WEBP および BPG を使用します。
- 単純なアイコンを SVG と ICONFONT に置き換えます。
- Zi Spider を使用して芸術的なフォントのカットを置き換えると、未使用の文字が削除され、それによって大きすぎる中国語フォントの問題が解決され、クロスプラットフォーム互換形式にエンコードされます。
CSS、JS ファイル、画像、ビジネスモジュールなどを含むリソースの読み込み時間とロードオンデマンドを合理的に割り当てます。他のコンテンツの遅延読み込みは、Web ページの初期読み込みに必要な最小限のコンテンツのセットに基づいて推測されます。公開コンテンツの事前の無条件読み込み、またはユーザーの行動に基づいた特定のコンテンツの事前読み込みの推測 (読み込まれたコンテンツの判断など)。検索ボックスに入力されたテキスト。ロードメカニズムは次のとおりです:
プリロード
- Dom Ready 後のロード
- onLoad 後のロード
- ローリングロード
DNS クエリの削減: DNS クエリには通常、数ミリ秒から数百ミリ秒かかりますが、モバイル環境ではさらに遅くなります。 DNSを事前に読み取ることができ、ユーザーの待ち時間を短縮します。

安定性の最初の要件は可用性です。最低要件はページが表示できることです。そうでない場合は使用できなくなります。

2 番目に注意すべきことは、ページがダウンした場合に回復にどのくらいの時間がかかるか、また、ページがダウンしている期間に静的ページ処理が使用できるかどうかです。ページがダウンしています。

ページの安定性は実はフロントエンドのセキュリティに関係しており、たとえページが公開できたとしてもハッキングされないという保証はありません。安全。

3.1 常见攻击：

XSS (Cross Site Script) ，跨站脚本攻击，往Web页面里插入恶意html代码。特点是攻击者的代码必须能获取用户浏览器端的执行权限，要杜绝此类攻击出现可以在入口和出口进行严格的过滤。

三种类型：

（1）反射型XSS：一次性；将包含注入脚本的恶意链接发送给受害者。

（2）持久型XSS：用户输入的数据“存储”在服务器端，比如一条包含XSS代码的留言。

（3） DOM XSS：使用一些eval等有输出的语句意味着多了一份被XSS的风险。

应对策略：
- 当恶意代码值被作为某一标签的内容显示：在不需要html输入的地方对html 标签及一些特殊字符( ” < > & 等等 )做过滤，将其转化为不被浏览器解释执行的字符。
- 当恶意代码被作为某一标签的属性显示，通过用 “将属性截断来开辟新的属性或恶意方法：属性本身存在的单引号和双引号都需要进行转码；对用户输入的html 标签及标签属性做白名单过滤，也可以对一些存在漏洞的标签和属性进行专门过滤。

CSRF(Cross Site Request Forgery)，跨站点伪造请求，通过伪造连接请求在用户不知情的情况下，让用户以自己的身份来完成攻击者需要达到的一些目的。
cookie劫持，通过获取页面的权限，在页面中写一个简单的到恶意站点的请求，并获取用户的cookie登录某些站点。

对于crsf 和cookie 劫持的策略：

通过 referer、token 或者验证码来检测用户提交。
尽量不要在页面的链接中暴露用户隐私信息。
对于用户修改删除等操作最好都使用post 操作。
避免全站通用的cookie，严格设置cookie的域。

3.2 数据通道安全

国内的众多网站都没有实现全站HTTPS。这是目前为止最重要的一步，所有的数据在发送之前就会被加密，攻击者无法查看或篡改数据包的内容。HTTPS可以理解为HTTP+SSL/TLS，通过数据加密、校验数据完整性和身份认证三种机制来保障安全。HTTPS的缺点是网站在加上TLS证书时，可能导致RTT往返时延增加，并且 HTTPS通信过程的非对称和对称加解密计算会产生更多的服务器性能和时间上的消耗，但是这是可以优化的，这里就不细说了。

3.3浏览器安全

3.3.1 同源策略

首先了解一下同源策略：

源指的是有相同的HOST、相同的协议、相同的端口。
同源策略以源为单位，把资源天然分隔，保护了用户的信息安全。
绕过同源策略让javascript访问其他源的资源的方法，如：JSONP、CORS、flash等。
同源策略不是绝对安全的，面对很多攻击是无能为力的，比如XSS，因为此时攻击者就在同源之内。

不建议使用JSONP，因为JSONP通常在脚本中写一个回调函数，然后把回调函数的名字写在请求的URL中，因此如果请求数据的服务器被黑了，那么黑客就能在返回的数据中植入恶意代码，从而窃取用户的隐私信息。

跨域资源共享CORS允许资源提供方在响应头中加入一个特殊的标记，使你能通过XHR来获取、解析并验证数据。这样就能避免恶意代码在你的应用中执行。在响应头中加入的标记如下：

Access-Control-Allow-Origin: allowed origins

ログイン後にコピー

如果对Access–Control-Allow-Origin设置为*其实是比较危险的，如果没有携带会话认证意味着信息被公开在全网，建议设置具体的域名，而且跨域的时候记得带上session id；严格审查请求信息，比如请求参数，还有http头信息，因为 http头可以伪造。

3.3.2 CSP(Content Security Policy)

CSP指定网站上所有脚本和图片等资源的源站点，也能阻止所有内联（inline）的脚本和样式。即使有人在页面评论或者留言中嵌入了脚本标签，这些脚本代码也不会被执行。可通过两种方式设置，如果 HTTP 头与 Meta 定义同时存在，则优先采用 HTTP 头中的定义：

通过 HTTP 头，比如只允许脚本从本源加载：Content-Security-Policy: script-src ‘self’，其中script-src ‘self’是策略。

通过HTML的Meta标签，比如只允许脚本从本源加载：

&lt;meta http-equiv=&quot;Content-Security-Policy&quot; content=&quot;script-src 'self'&quot;&gt;

ログイン後にコピー

其他策略：

script-src – 设置可以接受的JavaScript代码的源站点
style-src – 设置可以接受的CSS样式代码的源站点
connect-src – 定义浏览器可以通过XHR、WebSocket或者 EventSource访问哪些站点
font-src – 设置可以接受的字体文件的源站点
frame-src – 定义浏览器可以通过iframe访问哪些站点
img-src – 设置可以接受的图片的源站点
media-src – 设置可以接受的音频和视频文件的源站点
object-src – 设置可以接受的Flash和其它插件的源站点

缺点：

默认情况下，所有的内联JavaScript脚本都不会被执行，因为浏览器无法区分自己的内联脚本和黑客注入的脚本。

CSP还会默认阻止所有eval()风格的代码的执行，包括setInterval/setTimeout中的字符串和类似于new Function(‘return false’)之类的代码。

3.3.3 iframe 沙箱环境

利用iframe进行跨源：HTML5为iframe提供了安全属性 sandbox，iframe的能力将会被限制。

3.3.4 Secure和HttpOnly属性

Secure能确保cookie的内容只能通过SSL连接进行传输。Secure和HttpOnly属性告诉浏览器cookie的内容只能分别通过HTTP(S)协议进行访问，从而避免了被轻易窃取，比如禁止从JavaScript中的document.cookie访问，因此cookie在浏览器document中不可见了。如果单独使用的话，无法全面抵御跨站点脚本攻击，通常和其他技术组合使用。使用方法如下：

Set-Cookie: &lt;name&gt;=&lt;value&gt;[; &lt;name&gt;=&lt;value&gt;] [; expires=&lt;date&gt;][; domain=&lt;domain_name&gt;][; path=&lt;some_path&gt;][; secure][; HttpOnly]

ログイン後にコピー

3.3.5 其他安全相关的HTTP 头

X-Content-Type-Options 告诉浏览器相信此服务器下发的资源的类型，防止类型嗅探攻击。
HPKP(Public Key Pinning) Public Key Pinning 是一个response 头，用来检测一个证书的公钥是否发生了改变，防止中间人攻击。
HSTS (HTTP Strict-Transport-Security) 强制使用TSL作为数据通道。

3.4 HTML5 对web安全的影响

html5有很多新的特性能力，然而能力越大，被攻破后的危险就越大。HTML5 对xss的影响主要体现在:

攻击面更大，html5带来更多的标签和更多的属性如 <video>,<audio>,<canvas> 等；
危害更大，HTML5更多的资源可以被xss利用。黑客可以利用浏览器的一切权限，比如本地存储、GEO、服务器推送机制WebSocket，js多线程执行Webworker等。

比如localstorage只能通过js设置和获取，导致的结果是不能像cookie一样设置httponly等属性，所以localstorage中不能存放敏感信息，最好能够在服务端进行加密，可以配合CORS来获取网站的localstorage的信息。

4 响应式

响应式布局简而言之，就是一个网站能够兼容多个终端，可以为不同终端的用户提供更加舒适的界面和更好的用户体验。

基于栅格布局规划响应式设计，每个模块尽可能严格遵循栅格布局，符合栅格的小模块能很灵活的适应多个分辨率的展示。
拥抱flexbox。
使用动态的字体大小单位+rem单位使用。
使用CSS3 mediaQuery 技术响应用户设备。
利用百分比。
对低版本浏览器使用JS动态响应。
一套“自适应”素材兼容各种分辨率，提升页面性能，比如自适应的图片/视频素材。

比如凹凸实验室博客页面在PC端、iPad、手机端的排版：

PC端：

iPad：

手机端：

5 兼容性

估计很多人对这句话都有体会：IE虐我千百遍，我待IE如初恋。当然，除了 IE 上有兼容性问题，其他浏览器比如 Android 上的低版本浏览器也有较多问题。是否继续保持对低端浏览器的兼容性，我们可以用数据跟产品经理或者老板说话，减少我们的工作量，最好在项目之前就定下来支持最低支持的版本是什么，然后设计一个对应兼容方案。以下是百度统计的2015年的浏览器市场份额数据：

兼容性的原则： 渐进增强与平稳退化 。就是说，在低级浏览器能够保证其可用性和可访问性；渐进增强，在保证代码、页面在低级浏览器中的可用性及可访问性的基础上，逐步增加功能及用户体验。

互換性の問題が発生した場合の対処方法:

問題が発生する原因となるシナリオ、ブラウザ、バージョン、および問題が発生する状況を確認し、安定した再現を保証します。。
問題の原因と、なぜそのような問題が発生するのかを調べます (自分で考えたり、オンラインで検索したり、同僚に尋ねたりします)。
解決策を決定します。使用できない属性やハッキングへの対処方法など、既成の仕様を参照してください。
互換処理メソッドを蓄積します。

淘宝網のホームページは、互換性において小さな革新をもたらしました。HTML フックにより、オペレーティングシステム、ブラウザカーネル、ブラウザの種類、CSS3 アニメーションのサポート、および IE バージョンが HTML に追加されるという利点があります。

段階的な強化により、さまざまなブラウザーで差別化されたエクスペリエンスを実現できます。
ブラウザ内の特定のバグをすばやく見つけて修正できます。

淘宝網ホームページの HTML フック:

互換性の問題は、チームが協力してバグ互換性の蓄積ドキュメントを作成するのが最も効果的です。これ以上に素晴らしいことはありません。

6 検索 SEO

6.1 セマンティクス

タグのセマンティクスは検索エンジンにとって親しみやすく、優れた構造とセマンティクスは検索エンジンによってクロールされやすくなります。
タイトル h1、h2、h3、h4、h5、h6、特に h1 と h2 をうまく活用し、ランキングを向上させるために H(x) タグ内のキーワードを使用します。体重減少を避けるために、rel="nofollow" も設定します。
HTML5 で Microdata を使用して、Web ページ上にすでに存在するデータに追加のセマンティクスを提供します。マイクロデータは名前と値のペアで構成され、各語彙は名前付きプロパティのセットを定義します。 Microdata のサポートは、検索結果の表示に影響を与え、表示結果がより豊富になる可能性がありますが、検索結果のランキングには影響しませんが、Web サイトのトラフィックが増加する可能性があります。同様のテクノロジーには、リソース記述フレームワーク RDF や Microformat などがあります。

6.2 サイトのキーワードの最適化を測定する

サイトのコンテンツとキーワードの選択。
説明タグ、キーワードタグ、置換属性。
ロングテールキーワード: ターゲットではないキーワードですが、検索トラフィックをもたらす可能性のあるキーワード。たとえば、ターゲットキーワードは衣料品であり、ロングテールキーワードには紳士服、防寒着、アウトドアスポーツウェアなどがあります。等。ロングテールキーワードの基本的な属性は、拡張性、強力な関連性、広い範囲です。
キーワードの分布。
キーワードの密度と強調: キーワードの密度が適度であれば上位の順位を得ることができますが、過度の密度は逆の効果をもたらします。一般に、ほとんどの検索エンジンでは、キーワード密度 2% ～ 8% がより適切な範囲であり、検索エンジンでの Web サイトのランキングに有益です。
不正行為はありますか?

6.3 リンク

ファイルのディレクトリ構造と URL を最適化します。 URL はセマンティックで短く、理解しやすいものである必要があります。
独自のリンクを宣伝して信頼を高めます。リンクは、アウトバウンドリンクとインバウンドリンク（逆リンク）に分かれており、アウトバウンドリンクはこのサイトから他のサイトへ、インバウンドリンクは他のサイトから私のサイトへのリンクです。または、ソフト記事を書いたり、機密情報を公開したり、ブログ記事を公開したりして、Web サイトを宣伝します。
アンカーテキスト: 他の Web ページを指すリンクとしてキーワードを使用します。この形式のリンクはアンカーテキストと呼ばれます。検索エンジンは、Web ページを指すリンクのアンカーテキストの説明に基づいて、Web ページのコンテンツ属性を判断できます。

6.4 優れた Web サイトのナビゲーションとサイトマップ

Web サイトには、適切なナビゲーションが必要であり、ルートディレクトリと各サブディレクトリのキーを制御する必要があります。サイトマップは、Web サイトの所有者が Web サイトの構造を理解するのに役立ちます。また、検索エンジンがサイト全体を含めやすくなります。

7 その他の最適化

7.1 情報アクセシビリティ

情報アクセシビリティは通常、次の点から開始できます。

ランドマークの役割を追加します。説明のために、ページの主要な操作領域 (検索ボックス、ログインボックス、リストコンテンツ) に「role」タグを追加します。ランドマーク値には通常、banner (バナー)、complementary (補助コンテンツ領域)、contentinfo (Web サイト情報と著作権)、form (フォーム)、main (メインコンテンツ領域)、navigation (ナビゲーション領域)、search (検索領域) が含まれます。例:
代替テキストを提供します。たとえば、画像やその他の要素に適切な alt 属性または title 属性値を指定します。
フォームでは label タグが使用されています。
情報アーキテクチャの見出しを使用します。画面読み上げソフトには、ヘッダーを切り替えるためのショートカットキーが用意されており、関係者は画面読み上げソフトを通じて当社ウェブサイトの情報構造を理解することができます。
ページ上の重要なブロックと機能にアクセスキーを追加して、それらをすばやく見つけます。
インターフェイスの遷移をトリガーするには、フォーカスを設定する必要があります。たとえば、フローティングレイヤーの場合は、「タブ」によるフォーカスの中断を避けるために注意する必要があります。
高齢者の老眼を考慮すると、フォントサイズを十分に大きくするか、ウェブサイトを拡大縮小できるようにする必要があります。

詳細については、アクセシブルな読書を参照してください。

7.2 マイクロアニメーション

次のようなフロントエンドアニメーションテクノロジを使用してページを最適化します。

商品画像のホバー効果
小さなアイコンの回転効果
ショッピングカートのマイクロアニメーション
アニメーションの読み込み、ページの読み込みに一定の時間がかかります特にモバイルデバイスでは、興味深い読み込みアニメーションを通じてユーザーを引き付けることができます。

7.3 requireJs

requireJs フレームワークの機能:

フロントエンド設計と開発者はコード標準を統一します。
オンデマンドでロードします。
AMD 仕様: JavaScript のモジュール定義と読み込みメカニズムをシンプルかつエレガントな方法で統合し、さまざまなフレームワークの学習と使用の敷居を下げ、統一された方法でモジュールを定義して使用できるようにし、開発効率を向上させます。アプリケーションのメンテナンスコストも削減できます。
Grunt と組み合わせてワンストップのワークフローを実現します。

7.4 マルチタブのステータス同期

シナリオは次のとおりです:

ページ 1: Web サイトにアクセスして何かを購入し、ログインせずにホームページ;

ページ 2: 次に、新しいウィンドウで任意のページを開き、ログインして正常に戻ります。

もう一度ページ 1 にアクセスすると、ページがまだログインしていないことがわかります。実際、ユーザーはすでにログインしています。このエクスペリエンスは非常に悪いです。マルチタグステータスの同期を実現する方法はありますか?はい、ページ可視性を使用します:

ページ可視性 API は、Web ページが表示されるか非表示になるかを示します。ページ可視性 API には、次の 2 つの属性と 1 つのイベントがあります。
- document.hidden: 現在のページが表示されるか非表示であるかを示すブール値
- document.visibilityState: 可視性ステータスを返します。現在のページのステータス値には、非表示、表示、事前レンダリング、プレビューが含まれます。
- visibilitychange: 可視性ステータスが変更されたときにトリガーされるイベント。
ブラウザのサポート: IE10+、Chrome、FireFox。
マルチタブのステータス同期デモ: Web ページ可視性 API とログイン同期