CSS

ブラウザは、CSSルールの特異性に応じて、要素に表示するスタイルを決定します。ブラウザが特定の要素に一致するルールをすでに決定していると仮定します。一致するルールの中で、各ルールに対して、次の基準に基づいて4つのカンマ区切りの値a, b, c, dで特異性が計算されます。

1. aはインラインスタイルが使用されているかどうかです。プロパティ宣言が要素上のインラインスタイルである場合、aは1、それ以外の場合は0です。
2. bはIDセレクタの数です。
3. cはクラス、属性、および擬似クラスセレクタの数です。
4. dはタグおよび擬似要素セレクタの数です。

結果として得られる特異性はスコアではなく、列ごとに比較できる値の行列です。セレクタを比較して最高の特異性を持つものを決定する場合、左から右に見て、各列で最高値を比較します。したがって、b列の値は、c列とd列の値が何であっても、それらの値を上書きします。そのため、0,1,0,0の特異性は0,0,10,10の特異性よりも大きくなります。

特異性が等しい場合：最新のルールが優先されます。スタイルシート（内部または外部に関係なく）に同じルールを2回記述した場合、スタイルシートのより下にあるルールは、スタイルが適用される要素に近いため、より特異であると見なされ、適用されます。

私は、必要に応じて簡単に上書きできるように、特異性の低いCSSルールを記述します。CSS UIコンポーネントライブラリのコードを記述する場合、ライブラリのユーザーが特異性を高めるためだけに複雑すぎるCSSルールを使用したり、!importantに頼ったりすることなく、それらを上書きできるように、特異性を低く保つことが重要です。

• リセット - リセットは、要素のすべてのデフォルトブラウザースタイルを剥奪することを意図しています。例えば、すべての要素のmargin、padding、font-sizeは同じになるようにリセットされます。一般的なタイポグラフィック要素のスタイルを再宣言する必要があります。
• 正規化（ノーマライズ） - 正規化は、すべてを「非スタイル化」するのではなく、便利なデフォルトスタイルを保持します。また、一般的なブラウザ依存関係のバグも修正します。

私は、非常にカスタマイズされた、または型破りなサイトデザインで、多くの独自のスタイルを設定する必要があり、デフォルトスタイルを保持する必要がない場合にリセットを選択します。

FloatはCSSの配置プロパティです。Floatされた要素はページのフローの一部として残り、他の要素の配置に影響を与えます（例：テキストはfloatされた要素の周りを回り込みます）。これは、ページのフローから削除されるposition: absolute要素とは異なります。

CSSのclearプロパティは、left/right/bothにfloatされた要素の下に配置するために使用できます。

親要素がfloatされた要素のみを含んでいる場合、その高さはゼロに折りたたまれます。これは、コンテナ内のfloatされた要素の後、ただしコンテナの閉じタグの前にfloatをクリアすることで修正できます。

.clearfixハックは、巧妙なCSSの擬似セレクタ（::after）を使用してfloatをクリアします。親要素にoverflowを設定する代わりに、追加のクラスclearfixを適用します。そして、以下のCSSを適用します。

.clearfix::after {
  content: ' ';
  visibility: hidden;
  display: block;
  height: 0;
  clear: both;
}

または、親要素にoverflow: autoまたはoverflow: hiddenプロパティを付与すると、子要素の内部に新しいブロック整形コンテキストが確立され、子要素を含むように拡張されます。

CSSのz-indexプロパティは、重なり合う要素の垂直方向の重なり順序を制御します。z-indexは、position値がstaticでない要素にのみ影響します。

z-index値がない場合、要素はDOMに表示される順序で積み重ねられます（同じ階層レベルで最も下にある要素が一番上に表示されます）。非静的配置の要素（とその子要素）は、HTMLの階層に関係なく、常にデフォルトの静的配置の要素の上に表示されます。

スタッキングコンテキストとは、一連のレイヤーを含む要素です。ローカルスタッキングコンテキスト内では、その子要素のz-index値は、ドキュメントルートに対してではなく、その要素に対して相対的に設定されます。そのコンテキストの外側のレイヤー、つまりローカルスタッキングコンテキストの兄弟要素は、その内部のレイヤーの間に配置することはできません。要素Bが要素Aの上に配置されている場合、要素Aの子要素Cは、要素Cが要素Bよりも高いz-indexを持っていても、要素Bよりも高くなることはありません。

各スタッキングコンテキストは自己完結型です。要素のコンテンツが積み重ねられた後、要素全体は親スタッキングコンテキストのスタッキング順序で考慮されます。opacityが1未満、filterがnoneでない、transformがnoneでないなどのCSSプロパティのいくつかが新しいスタッキングコンテキストをトリガーします。

_注：要素がスタッキングコンテキストを作成するために正確に何を満たすかは、この長い[ルールセット]にリストされています。

ブロック整形コンテキスト（BFC）は、ブロックボックスがレイアウトされるウェブページの視覚的なCSSレンダリングの一部です。フロート、絶対位置指定要素、inline-block、table-cell、table-caption、およびoverflowがvisible以外の値の要素（ただし、その値がビューポートに伝播されている場合を除く）は、新しいブロック整形コンテキストを確立します。

ブロック整形コンテキストを確立する方法を知ることは重要です。そうしないと、包含ボックスがフロートされた子要素を[含まない]ためです。これはマージンの相殺に似ていますが、ボックス全体が奇妙な形で相殺されるため、より厄介です。

BFCは、次の条件の少なくとも1つを満たすHTMLボックスです。

• floatの値がnoneではない。
• positionの値がstaticでもrelativeでもない。
• displayの値がtable-cell、table-caption、inline-block、flex、inline-flex、grid、またはinline-gridである。
• overflowの値がvisibleではない。

BFCでは、各ボックスの左外縁が包含ブロックの左縁に接します（右から左への書式設定の場合、右縁が接します）。

BFC内の隣接するブロックレベルボックス間の垂直マージンは相殺されます。[マージンの相殺]について詳しく読む。

• 空のdivメソッド - <div style="clear:both;"></div>。
• Clearfixメソッド - 上記の.clearfixクラスを参照してください。
• overflow: autoまたはoverflow: hiddenメソッド - 親要素は新しいブロック整形コンテキストを確立し、そのフロートされた子要素を含むように拡張されます。

大規模なプロジェクトでは、ユーティリティ.clearfixクラスを記述し、必要な場所で使用します。overflow: hiddenは、子要素が親要素よりも高い場合に子要素をクリップする可能性があり、あまり理想的ではありません。

CSSスプライトは複数の画像を1つの大きな画像に結合します。これはアイコンによく使用される技術です（Gmailも使用しています）。実装方法は次のとおりです。

1. 複数の画像を1つにまとめ、それに応じたCSSを生成するスプライトジェネレーターを使用します。
2. 各画像には、background-image、background-position、background-sizeプロパティが定義された対応するCSSクラスがあります。
3. その画像を使用するには、対応するクラスを要素に追加します。

利点:

• 複数の画像に対するHTTPリクエストの数を削減します（スプライトシートあたり1つのリクエストのみが必要です）。しかし、HTTP2では、複数の画像をロードすることはもはや大きな問題ではありません。
• :hover擬似状態でのみ表示される画像など、必要になるまでダウンロードされないアセットの先行ダウンロード。点滅が見えなくなります。

• 問題と原因となっているブラウザを特定した後、その特定のブラウザが使用されているときにのみ読み込まれる別のスタイルシートを使用します。ただし、この手法にはサーバーサイドレンダリングが必要です。
• Bootstrapのように、これらのスタイリングの問題をすでに処理してくれるライブラリを使用します。
• autoprefixerを使用して、コードにベンダープレフィックスを自動的に追加します。
• Reset CSSまたはNormalize.cssを使用します。
• Postcss（または同様のトランスパイルライブラリ）を使用している場合、最新のCSS構文（およびW3Cの提案さえも）を使用できるようにするプラグインがあるかもしれません。これにより、コードのそれらのセクションが、使用したターゲットで機能する対応する安全なコードに変換されます。

• 優雅な劣化（Graceful degradation） - 最新のブラウザ向けにアプリケーションを構築しつつ、古いブラウザでも機能するようにするプラクティス。
• 段階的な機能強化（Progressive enhancement） - 基本的なユーザーエクスペリエンスレベルでアプリケーションを構築し、ブラウザがサポートする場合は機能強化を追加するプラクティス。
• 機能サポートを確認するために[caniuse.com]を使用する。
• ベンダープレフィックスの自動挿入のためのAutoprefixer。
• [Modernizr]を使用した機能検出。
• CSS機能クエリ[@support]を使用する。

これらの技術はアクセシビリティ（a11y）に関連しています。

• width: 0; height: 0。要素が画面上で全くスペースを占有しないようにし、結果として表示しないようにします。
• position: absolute; left: -99999px。画面外に配置します。
• text-indent: -9999px。これはblock要素内のテキストにのみ機能します。これは広く使われている有名なトリックですが、パフォーマンスの問題を引き起こすなど[いくつかの欠点]があるため、代わりにtext-indent: 100%を使用することを検討するかもしれません。
• メタタグ。例えば、Schema.org、RDF、JSON-LDを使用します。
• WAI-ARIA。ウェブページのアクセシビリティを高める方法を規定するW3C技術仕様。

WAI-ARIAが理想的な解決策であるとしても、私はabsolute配置アプローチを選択します。これは最も制約が少なく、ほとんどの要素で機能し、簡単な技術だからです。

Flexが普及する前（2014年頃）は、floatベースのグリッドシステムが最も信頼性が高かったです。これは、既存の代替システム（Flex、Grid）の中で最もブラウザサポートがあったためです。BootstrapはBootstrap 4でflexベースのアプローチに切り替えるまで、floatアプローチを使用していました。執筆時点（2020年）では、flexがグリッドシステムを構築するための推奨されるアプローチであり、[適切なブラウザサポート]があります。

冒険心のある方は、[CSS Grid Layout]を試してみることができます。これは、新しいgridプロパティを使用しています。グリッドレイアウトを構築する上ではflexよりもさらに優れており、将来的には事実上の標準となるでしょう。

はい。例えば、特定のブレイクポイントを超えると、積み重ねられたピルナビゲーションを固定下部のタブナビゲーションに変換するなどが挙げられます。

はい、インラインCSS、埋め込みCSSセクション、または外部CSSファイルを使用して、図形を色付けする方法（オブジェクトに属性を指定することも含む）がいくつかあります。ウェブ上で見かけるほとんどのSVGはインラインCSSを使用していますが、それぞれのタイプには長所と短所があります。

基本的な色付けは、ノードにfillとstrokeという2つの属性を設定することで行えます。fillはオブジェクト内部の色を設定し、strokeはオブジェクトの周りに描かれる線の色を設定します。HTMLで使用するのと同じCSSカラー命名規則を使用できます。例えば、カラー名（red）、RGB値（rgb(255,0,0)）、Hex値、RGBA値などです。

<rect
  x="10"
  y="10"
  width="100"
  height="100"
  stroke="blue"
  fill="purple"
  fill-opacity="0.5"
  stroke-opacity="0.8" />

上記のfill="purple"は、_プレゼンテーション属性_の例です。興味深いことに、style="fill: purple"のようなインラインスタイル（これも属性ですが）とは異なり、プレゼンテーション属性はスタイルシートで定義されたCSSスタイルによって[上書きできます]。したがって、svg { fill: blue; }のようなことを行うと、定義した紫色の塗りつぶしが上書きされます。

はい、@mediaプロパティには4つのタイプがあります（_screen_を含む）。

• all - すべてのメディアタイプデバイス用
• print - プリンタ用
• speech - ページを音声で「読み上げる」スクリーンリーダー用
• screen - コンピュータ画面、タブレット、スマートフォンなど用

printメディアタイプの使用例を次に示します。

@media print {
  body {
    color: black;
  }
}

まず、ブラウザがセレクタを右端（キーセレクタ）から左に一致させることを理解してください。ブラウザはキーセレクタに従ってDOM内の要素をフィルタリングし、一致を決定するためにその親要素を上方向にたどります。セレクタチェーンの長さが短いほど、ブラウザはその要素がセレクタに一致するかどうかをより速く判断できます。したがって、タグセレクタやユニバーサルセレクタのようなキーセレクタは避けてください。これらは多数の要素に一致し、ブラウザは親が一致するかどうかを判断するために多くの作業を行う必要があります。

[BEM（Block Element Modifier）]手法では、すべてが単一のクラスを持ち、階層が必要な場合でも、それがクラス名に組み込まれることを推奨しています。これにより、セレクタは自然と効率的になり、上書きしやすくなります。

どのCSSプロパティがリフロー、リペイント、コンポジットを[トリガー]するかを認識してください。可能な限りレイアウトを変更するスタイル（リフローをトリガーする）の記述は避けてください。

利点:

• CSSの保守性が向上します。
• ネストされたセレクタを簡単に記述できます。
• 一貫したテーマ設定のための変数。異なるプロジェクト間でテーマファイルを共有できます。
• 繰り返されるCSSを生成するMixin。
• ループ、リスト、マップなどのSass機能により、設定がより簡単になり、冗長性が減少します。
• コードを複数のファイルに分割できます。CSSファイルも分割できますが、その場合、各CSSファイルをダウンロードするためにHTTPリクエストが必要になります。

欠点:

• 前処理のためのツールが必要です。再コンパイルに時間がかかる場合があります。
• 現在および将来的に使用可能なCSSを記述していない。例えば、[webpack]で[postcss-loader]のようなものを使用すると、将来的に互換性のあるCSSを記述でき、Sass変数ではなくCSS変数などを使用できます。したがって、標準化された場合、あるいは標準化される可能性がある場合に役立つ新しいスキルを習得することになります。

好きな点:

• ほとんどが上記で述べた利点です。
• JavaScriptで書かれる部分が少なく、Nodeとの相性が良いです。

嫌いな点:

• C++で書かれたLibSassのバインディングであるnode-sassを介してSassを使用しています。Nodeのバージョンを切り替える際に、頻繁に再コンパイルしなければなりません。
• Lessでは、変数名が@で始まるため、@media、@import、@font-faceルールなどのネイティブCSSキーワードと混同される可能性があります。

@font-faceを使用して、異なるfont-weightsのfont-familyを定義します。

この部分は、効率的なCSSの記述に関する上記の内容と関連しています。ブラウザはセレクタを右端（キーセレクタ）から左に一致させます。ブラウザはキーセレクタに従ってDOM内の要素をフィルタリングし、一致を決定するためにその親要素を上方向にたどります。セレクタチェーンの長さが短いほど、ブラウザはその要素がセレクタに一致するかどうかをより速く判断できます。

たとえば、p spanというセレクタの場合、ブラウザはまずすべての<span>要素を見つけ、親要素をルートまで遡って<p>要素を探します。特定の<span>について、<p>を見つけたらすぐに、その<span>が一致すると判断し、一致の検索を停止できます。

CSS擬似要素は、選択された要素の特定のスタイルを設定するためにセレクタに追加されるキーワードです。装飾（:first-line、:first-letter）や、マークアップを変更することなく要素をマークアップに追加する（content: ...と組み合わせて）ために使用できます（:before、:after）。

• :first-lineと:first-letterはテキストを装飾するために使用できます。
• 上記の.clearfixハックで使用され、clear: bothを持つゼロスペース要素を追加します。
• ツールチップの三角形の矢印は:beforeと:afterを使用します。三角形はスタイリングの一部と見なされ、DOMとはみなされないため、関心の分離を促進します。

CSSボックスモデルは、ドキュメントツリーで生成され、視覚整形モデルに従ってレイアウトされる長方形のボックスを記述します。各ボックスには、コンテンツ領域（テキスト、画像など）と、オプションで周囲のpadding、border、margin領域があります。

CSSボックスモデルは、次の計算を担当します。

• ブロック要素が占めるスペースの量。
• 境界線やマージンが重なるか、または相殺されるかどうか。
• ボックスの寸法。

ボックスモデルには次のルールがあります。

• ブロック要素の寸法は、width、height、padding、border、marginによって計算されます。
• heightが指定されていない場合、ブロック要素は含まれるコンテンツの高さにpaddingを加えた高さになります（フロートがある場合を除く。これについては以下を参照）。
• widthが指定されていない場合、フロートされていないブロック要素は、親要素の幅からpaddingを引いた幅に合うように拡張されます。
• 要素のheightは、コンテンツのheightによって計算されます。
• 要素のwidthは、コンテンツのwidthによって計算されます。
• デフォルトでは、paddingとborderは要素のwidthとheightの一部ではありません。

• デフォルトでは、要素にはbox-sizing: content-boxが適用され、コンテンツのサイズのみが考慮されます。
• box-sizing: border-boxは、要素のwidthとheightの計算方法を変更し、borderとpaddingも計算に含まれるようになります。
• 要素のheightは、コンテンツのheight + 垂直padding + 垂直border幅によって計算されるようになりました。
• 要素のwidthは、コンテンツのwidth + 水平padding + 水平border幅によって計算されるようになりました。
• paddingとborderをボックスモデルの一部として考慮することは、デザイナーがグリッド内のコンテンツを実際にどのように想像するかとより一致します。

• none、block、inline、inline-block、flex、grid、table、table-row、table-cell、list-item。

| display | 説明 | | :-- | :-- | | none | 要素を表示しません（要素はドキュメントのレイアウトに影響しなくなります）。すべての子要素も表示されなくなります。ドキュメントは要素がドキュメントツリーに存在しないかのようにレンダリングされます | | block | 要素はブロック方向（通常は水平方向）の行全体を消費します | | inline | 要素は互いに隣接してレイアウトできます | | inline-block | inlineに似ていますが、widthやheightの設定など、一部のblockプロパティを許可します | | table | <table>要素のように振る舞います | | table-row | <tr>要素のように振る舞います | | table-cell | <td>要素のように振る舞います | | list-item | <li>要素のように振る舞い、list-style-typeとlist-style-positionを定義できます |

blockとの比較も加えて説明します。

| | block | inline-block | inline | | --- | --- | --- | --- | | サイズ | 親コンテナの幅いっぱいに広がります。 | コンテンツに依存します。 | コンテンツに依存します。 | | 配置 | 新しい行から始まり、その隣にHTML要素を許容しません（floatを追加する場合を除く）。 | 他のコンテンツと並んで流れ、その隣に他の要素を許容します。 | 他のコンテンツと並んで流れ、その隣に他の要素を許容します。 | | widthとheightを指定できるか | はい | はい | いいえ。設定しても無視されます。 | | vertical-alignで配置できるか | いいえ | はい | はい | | マージンとパディング | 全ての辺が尊重されます。 | 全ての辺が尊重されます。 | 水平方向の辺のみが尊重されます。垂直方向の辺は、指定されてもレイアウトに影響しません。視覚的にはコンテンツの周りにborderとpaddingが表示されますが、占有する垂直方向のスペースはline-heightに依存します。 | | Float | - | - | 垂直方向のマージンとパディングを設定できるblock要素のようになります。 |

位置指定要素とは、計算されたpositionプロパティがrelative、absolute、fixed、またはstickyのいずれかである要素です。

• static - デフォルトの位置。要素は通常通りページ内に流し込まれます。top、right、bottom、left、z-indexプロパティは適用されません。
• relative - 要素の位置が自分自身に対して調整されますが、レイアウトは変更されません（そのため、要素が配置されていなかった場合にあったはずの場所に隙間が残ります）。
• absolute - 要素はページのフローから削除され、最も近い位置指定された祖先（もしあれば）に対して、またはそれ以外の場合は初期包含ブロックに対して、指定された位置に配置されます。絶対位置指定されたボックスはマージンを持つことができ、他のマージンと相殺されません。これらの要素は他の要素の位置に影響を与えません。
• fixed - 要素はページのフローから削除され、ビューポートに対して指定された位置に配置され、スクロールしても移動しません。
• sticky - スティッキー配置は、相対配置と固定配置のハイブリッドです。要素は、指定されたしきい値を超えるまでrelative配置として扱われ、その時点でfixed配置として扱われます。

• Bootstrap - リリースサイクルが遅いです。Bootstrap 4はほぼ2年間アルファ版でした。スピナーボタンコンポーネントを追加します。これは広く使用されているためです。
• Semantic UI - ソースコードの構造がテーマのカスタマイズを非常に理解しにくくしています。その型破りなテーマシステムはカスタマイズが面倒です。ベンダーライブラリ内に設定パスがハードコードされています。Bootstrapとは異なり、変数を上書きするようにうまく設計されていません。
• Bulma - 多くの非セマンティックで冗長なクラスとマークアップが必要です。後方互換性がありません。バージョンをアップグレードすると、アプリが微妙な方法で壊れます。

はい。Flexboxは主に1次元レイアウト向けであり、Gridは2次元レイアウト向けです。

Flexboxは、コンテナ内の要素の垂直方向の中央揃え、sticky footerなど、CSSの多くの一般的な問題を解決します。BootstrapとBulmaはFlexboxに基づいており、最近のレイアウト作成の推奨される方法でしょう。以前Flexboxを試しましたが、flex-growの使用でブラウザの互換性問題（Safari）に遭遇し、inline-blockと数学を使用して幅をパーセンテージで計算するようにコードを書き直さなければならず、良い経験ではありませんでした。

Gridは、グリッドベースのレイアウトを作成するための最も直感的なアプローチですが（そうであるべきです！）、現時点ではブラウザサポートは広くありません。

これら2つのアプローチは排他的ではないことに注意してください。

ウェブサイトをレスポンシブにするとは、CSSメディアクエリを介して、要素の一部がデバイスの画面サイズ（通常はビューポートの幅）に応じてサイズやその他の機能を調整して応答することです。例えば、小さなデバイスでフォントサイズを小さくするなどです。

@media (min-width: 601px) {
  .my-class {
    font-size: 24px;
  }
}

@media (max-width: 600px) {
  .my-class {
    font-size: 12px;
  }
}

モバイルファースト戦略もレスポンシブですが、モバイルデバイス用のすべてのスタイルをデフォルトで定義し、その後、他のデバイスに固有のレスポンシブなルールを追加すべきだと考えています。前述の例に従って：

.my-class {
  font-size: 12px;
}

@media (min-width: 600px) {
  .my-class {
    font-size: 24px;
  }
}

モバイルファースト戦略には2つの主な利点があります。

• モバイルデバイスではパフォーマンスが向上します。適用されるすべてのルールがメディアクエリに対して検証される必要がないためです。
• レスポンシブCSSルールに関して、よりクリーンなコードを書くことを強制します。

レスポンシブデザインとアダプティブデザインはどちらも、異なるデバイスでユーザーエクスペリエンスを最適化しようとします。異なるビューポートサイズ、解像度、使用コンテキスト、制御メカニズムなどに合わせて調整します。

レスポンシブデザインは柔軟性の原則に基づいて機能します。つまり、どのデバイスでも見栄えの良い単一の流動的なウェブサイトです。レスポンシブウェブサイトは、メディアクエリ、柔軟なグリッド、レスポンシブ画像を使用して、多数の要因に基づいて柔軟に変化するユーザーエクスペリエンスを作成します。これは、複数の異なるフープを通るために膨張したり縮小したりする単一のボールのようなものです。

アダプティブデザインは、プログレッシブエンハンスメントの現代的な定義に近いものです。単一の柔軟なデザインの代わりに、アダプティブデザインはデバイスやその他の機能を検出し、事前に定義されたビューポートサイズやその他の特性に基づいて適切な機能とレイアウトを提供します。サイトは使用されているデバイスの種類を検出し、そのデバイス用の事前に設定されたレイアウトを提供します。これは、異なるサイズのフープを通る単一のボールの代わりに、フープのサイズに応じて使用するいくつかの異なるボールがあるようなものです。

これらの両方の方法には、考慮すべきいくつかの問題があります。

• レスポンシブデザインは非常に難しい場合があります。基本的に、すべての状況に適合させるために、単一の柔軟なレイアウトを使用しているからです。メディアクエリのブレイクポイントをどのように設定するかは、そのような課題の1つです。標準化されたブレイクポイント値を使用しますか？それとも、特定のレイアウトに意味のあるブレイクポイントを使用しますか？そのレイアウトが変更された場合はどうなりますか？
• アダプティブデザインは通常、ユーザーエージェントスニッフィングやDPI検出などが必要であり、これらはすべて信頼できないことが判明する可能性があります。

_Retina_は、ピクセル比が1より大きい高解像度スクリーンを指す単なるマーケティング用語です。重要なのは、ピクセル比を使用するということは、これらのディスプレイが要素を同じサイズで表示するために低解像度スクリーンをエミュレートしているということです。今日では、すべてのモバイルデバイスが事実上_Retina_ディスプレイであると考えられています。

ブラウザはデフォルトで、画像を除いて、デバイスの解像度に応じてDOM要素をレンダリングします。

Retinaディスプレイを最大限に活用する、鮮明で美しいグラフィックを表示するには、可能な限り高解像度の画像を使用する必要があります。ただし、常に最高の解像度の画像を使用すると、より多くのバイトが回線を介して送信される必要があるため、パフォーマンスに影響を与えます。

この問題を克服するために、HTML5で指定されているレスポンシブ画像を使用できます。これは、同じ画像の異なる解像度ファイルをブラウザに利用可能にし、ブラウザがHTML属性srcsetとオプションでsizesを使用して、どの画像が最適かを判断させることを必要とします。例えば、次のようになります。

<div responsive-background-image>
  <img
    src="/images/test-1600.jpg"
    sizes="
      (min-width: 768px) 50vw,
      (min-width: 1024px) 66vw,
      100vw"
    srcset="
      /images/test-400.jpg   400w,
      /images/test-800.jpg   800w,
      /images/test-1200.jpg 1200w
    " />
</div>

HTML5のsrcsetをサポートしていないブラウザ（IE11など）は、それを無視して代わりにsrcを使用することに注意することが重要です。IE11をサポートする必要があり、パフォーマンス上の理由からこの機能を提供したい場合は、JavaScriptポリフィルを使用できます。

アイコンについては、解像度に関係なく非常に鮮明にレンダリングされるため、可能な場合はSVGとアイコンフォントを使用することを選択します。

translate()はCSSのtransformの値です。transformまたはopacityを変更しても、ブラウザのリフローやリペイントはトリガーされませんが、コンポジットはトリガーされます。一方、絶対位置指定を変更するとリフローがトリガーされます。transformはブラウザに要素のGPUレイヤーを作成させますが、絶対位置指定プロパティを変更するとCPUを使用します。したがって、translate()の方が効率的であり、より滑らかなアニメーションのための描画時間を短縮できます。

translate()を使用する場合、要素は元のスペースを占有したままになります（position: relativeのようなもの）。これは絶対位置指定を変更する場合とは異なります。