対象の記事はこちら👉<a style="background-color:#ffffff" href="https://web.dev/priority-hints/" target="_blank" rel="noopener noreferrer">Optimizing resource loading with Priority Hints</a> Priority Hints について分かり易い記事が web.dev で投稿されていたので、和訳をしてみる。 コンテキストが抜けている部分は補って意訳していく。それではスタート！ <h2 id="h038d6117c5">導入</h2>Priority Hints によって、ブラウザはリソースの読み込み優先度を知ることができるようになり、リソースの読みこみが適切に制御可能となった。それによりCore Web Vitalsのスコアが以前よりも改善しやすくなった。 ブラウザがウェブサイトを解析し、画像・JS・CSSのようなリソースをダウンロードし始めるわけだが、その際最適な順番で読み込みの順番を制御している。ではどのように制御されているのかだが、各リソースに対して fetch priority が割り当てられている。この priority は次の2つによって決められている。<ul><li>リソースの種類</li><li>リソースの位置 in document</li></ul>例えば、ビューポート内の画像であれば「High」priority、レンダーブロッキングな <code>head</code> 内のCSSについては「Very High」な priority といったように、ブラウザがよしなに付与してくれる。このようにブラウザは priority の付与を自動的にしてくれるわけだが、全てのケースにおいて最適な priority を付与してくれるかといえば、そうとはいえない。 この記事では、Priority Hints と <code>fetchpriority</code> 属性についてまとめていく。 <h2 id="h9707d3a59a">概要</h2>Priority Hints によってできること、以下３つ。<ul><li><code>fetchpriority="high"</code> を画像要素に付与することで、 LCP (メインコンテンツの読み込み時間をはかる指標。ユーザーがページコンテンツとインタラクションをとれるようになるまでの時間と関連している)の最適化が可能になる</li><li><code>async</code> script の priority を上げることができる。現在は <code>&lt;link rel="preload"&gt;</code> を <code>async</code> script に付与する hack が使われている</li><li>即時に読み込まなくても良いリソースの priority を下げることで、画像の読み込み順序を最適化する</li></ul> これまでリソースの priority の投機的取得には <code>preload</code> や <code>preconnect</code> という制限された手法を使わざるを得なかった。 Priority Hints はこれらの「Resource Hint」を補完することができるのだが、ここで一旦 <code>preload</code> と<code>preconnect</code> について復習しておこう。 <code>preload</code> : 先読みしておきたいクリティカルなリソースを、ブラウザに対して通知する機能である。<code>preload</code> を設定しない場合、読み込み順序の遅くなるリソース、例えば、スタイルシートの中のフォントや背景画像、JSから読み込まれる画像に対して価値を発揮することができる。 <code>preconnect</code> : コネクションを温めておき (=DNS の解決 + TCP の接続まで確立しておくことで、リクエストをすぐに送ることができる)、 Time-to-first-byte を改善できる。完全なリソースのURIは把握していないが、origin を知っている場合に有効な方法。 Priority Hints は <code>fetchpriority</code> を使って利用することができる。HTMLだけではなく、JSの fetch メソッドの priority プロパティでも制御は可能だ <code>例: fetch('/api/articles.json', { priority: 'high' }).then(/.../)</code> 。 Priority Hints は <code>preload</code> も補完することもできる。LCPの画像は <code>preload</code> された場合でも優先度が低くなってしまうが (←コメント: 仕様なのかは不明)、Priority Hints を使うことで読み込み順を早めることが可能となる。 <h2 id="h4facf89b69">リソースの優先度 (priority)</h2>priority に影響する要素について以下のようなものが挙げられる。<ul><li>CSS、フォント、JS、画像、サードパーティリソースには別々の priority が付与される </li><li>documentのどこにリソース対象のコンテンツが位置しているかによって priority が付与される</li><li><code>preload</code> を使うことで、ブラウザに対象のリソースの検知を促進する</li><li>priority の順序は <code>async</code> や <code>defer</code> によって影響を受ける</li></ul>それぞれのリソースに対する priority については、<a href="https://web.dev/priority-hints/#:~:text=The%20following-,table,-considers%20such%20factors" target="_blank" rel="noopener noreferrer">こちら</a>の参照をおすすめする（個人的には、納得感のある priority で設定されていると感じた）。priority が同じリソースについては、検知された順に読み込まれていくようだ。ちなみにChrome の Devtool で priority は確認できる。 <img src="https://images.microcms-assets.io/assets/1e1129a92bc841ccad1a43c6a2977d50/316a56b5c2564a59b3945b74a9a82234/image.png" alt=""> <h2 id="h19da9587c3">どこで Priority Hints を使うのか？</h2>リソースの読み込みについて、下記のようなことはご存知かとおもう。<ul><li>ブラウザが検知しづらいリソースについては <code>preload</code> を使うことで priority を上げることができる</li><li><code>async</code> <code>defer</code> をつかうことで他リソースのブロッキングを防ぐことができる</li><li>below-the-fold content (ファーストビューより下に位置するコンテンツのこと) についてはLazy Loadを使うことで、重要な above-the-fold content (ファーストビューのコンテンツ) に帯域幅を優先的に割り当てることができる</li></ul> 一方で、上記では不十分なケースについて次のようなものがある(= Priority Hints が出番となる)<ul><li>above-the-fold content に priority の異なる画像が複数ある。例えば、カルーセルの画像では先頭の画像の priority を高くしたい</li><li>ビューポートの中のヒーロー画像が「Low」priorityである。レイアウトが完成したのち、Chromeは画像がビューポートにあることを検知し、priority を高くする（Devtoolは最終的な priority のみを出力する – WebPageTestは両方出力してくれる
）。これにより大きな読み込み遅延が発生してしまう。画像に対して 「High」priority を付与することで、解決することができる。補足だが、<code>preload</code> で priority を高くするためには、LCP画像の早期検知と <code>fetchpriority='high'</code>が必要になる。その２つが満たされない場合、「Low」priority となってしまう。補足: ビューポート外の画像は「Low」priority が付与されるが、レイアウトでビューポート内に入ることがわかると「High」にブーストされる。</li><li><code>&lt;script&gt;</code> に <code>async</code> <code>defer</code> を付与することで、非同期の読み込みができるが、これらはデフォルトでは「Low」priority が付与される。つまり非同期でも優先度を上げて読み込みをしたい場合は Priority Hints が必要となる。</li><li>JSの <code>fetch</code> メソッドで読みこまれるリソースは「High」priority である。しかし、優先度を落としたいときは Priority Hints を使う必要がある。</li><li>CSSとフォントには「High」 priority が付与されるが、場合によっては LCP 画像を優先的に読み込ませたいときがある。</li></ul> <h2 id="h53e30ccf13">fetchpriority属性</h2><code>img</code> <code>script</code> <code>link</code> <code>iframe</code> に使うことができる。<pre><code>&lt;!-- We don't want a high priority for this above-the-fold image --&gt;
&lt;img src="/images/in_viewport_but_not_important.svg" fetchpriority="low" alt="I'm an unimportant image!"&gt;

&lt;!-- We want to initiate an early fetch for a resource, but also deprioritize it --&gt;
&lt;link rel="preload" href="/js/script.js" as="script" fetchpriority="low"&gt;

&lt;script&gt;
 fetch('https://example.com/', {priority: 'low'})
 .then(data =&gt; {
 // Trigger a low priority fetch
 });
&lt;/script&gt;

&lt;!-- The third-party contents of this iframe can load with a low priority --&gt;
&lt;iframe src="https://example.com" width="600" height="400" fetchpriority="low"&gt;&lt;/iframe&gt;</code></pre> <code>fetchpriority</code> を適用した場合のユースケースについては<a href="https://web.dev/priority-hints/#use-cases" target="_blank" rel="noopener noreferrer">元記事</a>を参照 <h2 id="h90281063e8">Priority Hints利用時の留意点</h2><ul><li><code>fetchpriority</code> はヒントであり、ディレクティブではない。ブラウザはディベロッパーの設定を尊重はするが、かならずしもそれに従うわけではない</li><li>Priority Hints と preload の違いを理解しよう。<ul><li>preload は強制的な fetch であり、ヒントではない</li><li>preload はブラウザにリソースの早期検知を促すものの、fetch についてはデフォルトの priority に従う。Priority Hints についてはリソースの検知は促さないが、priority を調整できる。</li><li>preload のほうが検証しやすい</li></ul></li><li>Priority Hints を使うことで priority を調整し preload を補完することができる。すでにLCPの画像を <code>&lt;head&gt;</code> で preload 指定している場合、「High」priority は大きな効果をもたらさないだろう。しかしもし、preload 対象のリソースがdocumentの下部に記載されている場合 (ビューポートの外)、「High」priorityは効果を発揮する。</li></ul>

Optimizing resource loading with Priority Hints の和訳

世の中、SPAベースの開発が完全に主流になりつつあるように謳われているが、レガシーページの対応などで相当な数のページがVanilla JSをつかってゴリゴリDOM操作をしているのではと思っている。その際、どうやって描画処理を実行するかについてとても簡単ではあるが、コードの可読性をあげる個人的なTipsを紹介したいと思う。（←もっとベターな方法があれば知りたいです） 例えば、ポップアップを表示/非表示を切り替える処理を考えてみる（簡単のため <code>display</code> プロパティで制御）。 下記では <code>.popup-open-button</code> をクリックすると、ポップアップが開き、 <code>.popup-close-button</code> をクリックすると閉じる処理を想定している。<pre><code>const popup = querySelector('.popup')
const openButton = querySelector('.popup-open-button')
const closeButton = querySelector('.popup-close-button')

openButton.addEventListener('click', () =&gt; {
 popup.style.display = 'block'
})

closeButton.addEventListener('click', () =&gt; {
 popup.style.display = 'none'
})</code></pre> まあこんな感じでかける。シンプルな実装であればこんな感じでいいと思うが、実際は表示する条件が追加されることがほとんどだ。そのとき、イベントハンドラー内で <code>if</code> 文を追加してしまうと、あっというまに可読性・メンテナンス性が失われてしまう。<pre><code>openButton.addEventListener('click', () =&gt; {
 if (条件A) {
 popup.style.display = 'block'
 } else {
 popup.style.display = 'none'
 }
})</code></pre> そこで使える考え方が、処理の分解だ (「責務の分解」とか言われてますね。小難しく聞こえるので、個人的にはあまり好きではない)。つまり表示・非表示の状態は別のオブジェクトで管理し、画面描画についても別のメソッドに切り替えてあげることで、読みやすいコードにすることができる。 <pre><code>const state = {
 isOpen: false,
}

function render (state) {
 const { isOpen } = state;
 if (isOpen) {
 popup.style.display = 'block'
 } else {
 popup.style.display = 'none'
 }
}
 
openButton.addEventListener('click', () =&gt; {
 state.isOpen = true;
 render(state)
})</code></pre>もっとベターな方法があるかもしれないが、簡易的な実装であれば上記のような分解で、処理の管理もしやすくなる。

画面描画メソッドの実行について

ポップアップ系のUIをコーディングするとき、画面の中央に表示するためにCSSを触ったことのある方は多いと思う。 <code>position: fixed;</code> を使うケースが多いが、そのときは昔から次のようなコードを書いて対応してきた。<pre><code>.popup {
 position: fixed;
 margin: auto; 
 top: 0;
 bottom: 0;
 right: 0;
 left: 0;
}</code></pre> 冗長な書き方だけど、これを使ったことのある方は多いだろう。この配置を短く書く方法が <code>inset</code> である。iOS: 14.1以降の対応であるため、レガシーデバイスの対応には時期尚早だったりもするが、とりあえず下記のように書くことができるようになった。<pre><code>.popup{
&nbsp;&nbsp;position: fixed;
&nbsp;&nbsp;inset: 0;
&nbsp;&nbsp;margin: auto;
}</code></pre> 注意点としては、上２つの書き方は、ポップアップのサイズが指定されていないときは画面全体にポップアップが広がってしまうことだ。そのため、我々はまだ次の書き方を続ける必要がありそうだなと思った次第です。 <pre><code>.popup{
&nbsp;&nbsp;position: fixed;
&nbsp;&nbsp;left: 50%;
&nbsp;&nbsp;top: 50%;
&nbsp;&nbsp;transform: translateX(-50%)
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; translateY(-50%);
}</code></pre>

position: fixed;を使ったときの上下左右の中央配置について

CSS Animation関連で <code>will-change</code> について２つのドキュメントを読んでみたので、その概要と一部和訳をしてみた。 <h2 id="h9a69984c5a">mdn</h2><h3 id="h9707d3a59a">概要</h3><a href="https://developer.mozilla.org/en-US/docs/Web/CSS/will-change" target="_blank" rel="noopener noreferrer">https://developer.mozilla.org/en-US/docs/Web/CSS/will-change</a> まず一文目で本質的な説明がされている。<blockquote>The&nbsp;<code>will-change</code>&nbsp;<a style="background-color:#ffffff" href="https://developer.mozilla.org/en-US/docs/Web/CSS" target="_blank" rel="noopener noreferrer">CSS</a>&nbsp;property hints to browsers how an element is expected to change.&nbsp;Browsers may set up optimizations before an element is actually changed. These kinds of optimizations can increase the responsiveness of a page by doing potentially expensive work before they are actually required.</blockquote><code>will-change</code>を使うことで、ある要素がどのように変化するのか、をブラウザにヒントとして渡すことができるようだ。それによって、その要素が変わる前に、ブラウザが最適なパフォーマンスをだすために準備ができ、最終的にUXの向上につながる、とのこと。これらのことから <code>will-change</code> について、以下の2つが推測される。<ul><li>UIの表層に出てくるプロパティではないこと (例外として、「使い方の注意ポイント」の最後の要素を参照)</li><li>ブラウザのパフォーマンスに関与する</li></ul> <h3 id="h9a4a7d4adc">使い方の注意ポイント</h3><blockquote>Proper usage of this property can be a bit tricky:</blockquote><code>will-change</code> の使い方は「つまづきやすい (= tricky)」と表現しており、以下に具体的な留意点がリストアップされている。<ul><li><code>will-change</code> を多くの要素に使わないこと。ブラウザはすでにさまざまな最適化を自動的に行なっているが、 <code>will-change</code> のような「強い最適化」が多発するとブラウザのリソースを消費し、ブラウジング体験に悪い影響を与えてしまう。</li><li><code>will-change</code> が不要になったら、削除すること。ブラウザが自動でおこなっている最適化は、対応が不要になれば最適化に関連する処理を削除するが、 <code>will-change</code> は明示的にエンジニア側で指定するものなので、利用する時だけ「生かす」ようにすること。</li><li>ある程度パフォーマンスの良いページには<code>will-change</code> を使って速度改善をしようとしないこと。つまり、他にもボトルネックとなっている改善点があるのであれば、そちらを優先的に対応すべきである。<code>will-change</code> は「last resort」とはこのことを言っている。</li><li>対象の要素が変化する前に<code>will-change</code> を付与すること。このプロパティが適用されると、ブラウザ側で最適化処理が走るため、変化の発生する要素にあらかじめ適用しておくこと。</li><li><code>will-change</code> はビジュアルの点でもページに影響することがある。付与された要素は stacking-context が生成されるが、あらかじめ別のプロパティが付与されて stacking-context が生成されている場合は変化なし。(*stacking contextについては<a href="https://ics.media/entry/200609/" target="_blank" rel="noopener noreferrer">こちらのページ</a>が非常にわかりやすくまとめられておりました)</li></ul> <h3 id="h512de7d259">使用例</h3>JS経由で <code>will-change</code> のプロパティを設定しており、アニメーションが完了したら <code>auto</code> を指定することで、メモリを解放している。<pre><code>var el = document.getElementById('element');

// 要素がホバーされたとき、will-change を設定する
el.addEventListener('mouseenter', hintBrowser);
el.addEventListener('animationEnd', removeHint);

function hintBrowser() {
 // アニメーションのキーフレームブロックで
 // 変更されるであろう最適化可能なプロパティ
 this.style.willChange = 'transform, opacity';
}

function removeHint() {
 this.style.willChange = 'auto';
}</code></pre> <h1 id="h44184115e8">Everything You Need to Know About the CSS&nbsp;<code>will-change</code>&nbsp;Property</h1><a href="https://dev.opera.com/articles/css-will-change-property/" target="_blank" rel="noopener noreferrer">https://dev.opera.com/articles/css-will-change-property/</a>の和訳をしてみようと思う。2014年に書かれた記事だが、非常に濃い内容だった。 <blockquote>In a nutshell,&nbsp;Hardware Acceleration&nbsp;means that the&nbsp;Graphics Processing Unit&nbsp;(GPU) will assist your browser in rendering a page by doing some of the heavy lifting, instead of throwing it all onto the&nbsp;Central Processing Unit&nbsp;(CPU) to do. When a CSS operation is hardware-accelerated, it usually gets a speed boost as the page rendering gets faster.</blockquote>（"In a nutshell ..." と結論から完結に書いていて素晴らしい） CSS transformsを使うと利用される "Hardware Acceleration"について言及されており、”Hardware Acceleration" を使うと重たい描画処理をGPUが行ってくれるので、処理が早くなる、と書かれているが、まあこの辺りは皆さんの記憶のどこかにあると思う。 <blockquote>Hardware acceleration (a.k.a. GPU acceleration) relies on a&nbsp;layering model&nbsp;used by the browser as it renders a page. When certain operations (such as 3D transforms) are performed on an element on a page, that element is moved to its own “layer”, where it can render independently from the rest of the page and be&nbsp;composited in&nbsp;(drawn onto the screen) later. This isolates the rendering of the content so that the rest of the page doesn’t have to be rerendered if the element’s transform is the only thing that changes between frames, and often provides significant speed benefits. It is worth mentioning here that only 3D transforms qualify for their own layer; 2D transforms don’t.</blockquote>GPU acceleration (= 以降、GPU)は、レイヤーモデルを利用している。3D transformのような特定の処理が、ページ内の要素に対して行われる時、その要素は自分自身の「レイヤー」に移動する。そうすると、ページ内の他の要素とは独立して描画されることが可能になる。独立されるということは、この要素に変化が発生してもページ内の他の要素のレイアウトには影響せず、ムダな再描画を防ぐことができることを意味している。注意すべき点は、この仕様は3D transformationのみに適用され、2D transformationには適用されない。。昔、<code>transform: translate3d(0, 0, 0);</code> のようなおまじない的なものがあったが、それはこの理由に関連していたみたいだ。つまり強制的にGPUに処理をさせるためのハックですね。とはいえ注意する点として、GPUの処理はメモリを多く消費してしまう、特にモバイル端末 (追記: この記事が書かれたのが2014年なので、現在は定かではないが非力デバイスでの利用には要注意といったところかな)。 <blockquote>In order to avoid layer-creation hacks, a new CSS property has been introduced, that allows us to inform the browser ahead of time of what kinds of changes we are likely to make to an element, thus allowing it to optimize how it handles the element ahead of time, performing potentially-expensive work preparing for an operation such as an animation, for example, before the animation actually begins. This property is the new&nbsp;<code>will-change</code>&nbsp;property.</blockquote>こうしたハックを防ぐために、 <code>will-change</code> が生まれた。 <blockquote>In order to avoid this delay, you can inform the browser about the changes some time&nbsp;before&nbsp;they actually happen. That way, it will have some time to prepare for these changes, so that when these changes occur, the element’s layer will be ready and the transform animation can be performed and then the element can be rendered and the page updated in quickly.</blockquote>これから発生する「変化」についてブラウザに知らせておくことで、ブラウザ側は事前に準備をしてアニメーションのような処理もスムーズに行うことができる。 <blockquote>will-change: transform, opacity;</blockquote>例えば、上記の記述によって、 <code>transform</code> と <code>opacity</code> のアニメーションの最適化をおこなってくれる。 <h4 id="h86c1eb6dfa">注意点</h4>1. 特定の要素のみに適用すべきなので、下記のような記述はNG<pre><code>*,
*::before,
*::after {
	will-change: all;
}</code></pre> 2. 準備する時間をブラウザに与えましょう <code>will-change</code> の仕様についてもう一度確認をしましょう。<blockquote>The&nbsp;<code>will-change</code>&nbsp;property is named like that for an obvious reason: informing the browser about changes that&nbsp;will&nbsp;occur, not changes that&nbsp;are&nbsp;occuring.</blockquote>ウィル (will) という点がポイント。are ではなく will。つまり <code>will-change</code> を使うことで、我々が与えようとしている「変化」を最適なパフォーマンスで実行してください、とブラウザに指示をしている。さらに、 <code>will-change</code> という指示による最適なパフォーマンスをするためにはブラウザにとって、少し時間が要る点も忘れてはいけない。つまり変化が起こる直前に <code>will-change</code> を渡しても、効果はないどころか悪い影響をあたえてしまうこともある（不要なレイヤーを作成してしまう）。 <pre><code>.element:hover {
	will-change: transform;
	transition: transform 2s;
	transform: rotate(30deg) scale(1.5);
}</code></pre>上記はブラウザに対して、このような指示をしていることと同じだ。「今起こっている変化に対して、あらかじめメモリを確保して準備をしてくれ」変な日本語になってしまったが、 <code>will-change</code> の本来の用途は「これから起こる変化に対して、あらかじめメモリを確保して準備をしてくれ」なのだ。つまり、上のコードの例はナンセンスということになる。正しく使うためには、先に <code>will-change</code> を指定しておき、その後変化を与える必要がある。 例えば、要素がクリックされたときに rotate させたい場合、CSS的には <code>:hover</code> のあとに <code>:active</code> が適用されるとすると下記のようなコードが正しい <code>will-change</code> の使い方になる。hover時に <code>will-change</code> を適用させることで、その次のインタラクション (= <code>:active</code>) 実行までに <code>transform</code> の準備を指示することができる。<pre><code>.element {
	/* style rules */
	transition: transform 1s ease-out;
}
.element:hover {
	will-change: transform;
}
.element:active {
	transform: rotateY(180deg);
}</code></pre> <h4 id="h8c8727fac3">Change が完了したら <code>will-change</code> は削除しよう</h4>すでに述べたことだが、 <code>will-change</code> は、描画処理をスムーズに行うために明示的にメモリを確保しておく仕様なので、使い終わったあとは削除することで、いわゆるメモリを解放してあげる必要がある。スタイルシートに直書きしてしまうと、当然ながら削除することはできないためJSを使う必要がある。例外としてスタイルシートに書いても良いケースとしては、ユーザーが何度も操作する可能性のあるUI（メニューなど）でかつ要素数が少ないものが挙げられる。そもそも <code>will-change</code> を削除する必要はないため。

CSSのwill-changeについて

ローカルサーバーを建てた場合にポート番号が被ってしまった場合に、エラーが出てしまうことがあると思います。 <pre><code>// ポート番号8080の場合
Error: listen EADDRINUSE: address already in use :::8080</code></pre> これを一回落とす(killする)方法をメモとして残しておきます。 1. プロセスID(PID)を取得: ポートをkillするにはPIDが必要となるため、下記のコマンドで被っている対応したPIDを表示します。この場合は`8080`を例にしています。 <pre><code>lsof -i -P | grep 8080</code></pre> すると、下記のような出力がされます。 <img src="https://images.microcms-assets.io/assets/1e1129a92bc841ccad1a43c6a2977d50/1541c6c2d72a4c188338c8f58c6e2fef/aaae4a41-20cd-892b-09ff-741fe8190d79.png" alt=""> 2. killする: 上のスクリーンショットを見ると、左から２番目の行がPIDになるので、下記のコマンドを叩きます。`-9`も必要です。 <pre><code>kill -9 9384</code></pre> これで同じポートで環境を立ち上げられます。

ポートをkillする

GoogleのCore Web VitalsがSEO評価の指標となって数年経ちましたが、CLS (Cumulative Layout Shift)の調整でハマったところを解決策を書きます。(WordPressを使ったサイトの話です) <h2 id="hc69c85bcf9">背景</h2><code>img</code> タグに高さが指定されていない場合、画像が読み込まれた時点で下のコンテンツの位置に変更が発生し、CLSが加算されてしまいます。そのため画像の高さを指定する必要があります。 あらかじめ <code>img</code> タグに<code>height</code>が指定されていたり、CMSの投稿画像のサイズルールが定められていればこの問題は簡単に回避できます。しかし、長年運用されているサイトで、投稿画像のサイズがばらばらだったりすると「困った！」となるわけです。さらに添付画像のように画像が100%幅のときは、 ウィンドウサイズを変更するたびに画像の高さが変わるため「高さ指定無理じゃね？」となりました。 <img src="https://images.microcms-assets.io/assets/1e1129a92bc841ccad1a43c6a2977d50/683b45d34e0447468e845dc1433c5b4e/27cd46af-b52f-e9e7-1b93-77218146c099.png" alt=""> <h2 id="hc4c05c18f9">解決策</h2>結論から言えば、CSSの <code>100vw</code> を使います。 WordPressの <code>wp_get_attachment_image_src</code>では、画像の幅、高さを取得できます。 <pre><code>$featured_image = wp_get_attachment_image_src( get_post_thumbnail_id( $post-&gt;ID ) , 'thumbnail' );

// $featured_image[0]: 画像のURL
// $featured_image[1]: 画像の幅
// $featured_image[2]: 画像の高さ</code></pre> そこで画像の縦横比を取得します。 <pre><code>$ratio = $featured_image[2] / $featured_image[1];</code></pre> あとは <code>img</code> タグに指定するだけです。 <pre><code>&lt;img
&nbsp;&nbsp;&nbsp;src="&lt;?php echo $featured_image[0]; ?&gt;"
&nbsp;&nbsp;&nbsp;style="
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;width: 100%;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;height: calc(100vw * &lt;?php echo $ratio ;?&gt;);
&nbsp;&nbsp;&nbsp;"
/&gt;</code></pre> 以上。 追記: DevToolで確かめた限りだと、CLSに関しては <code>img</code> への<code>height</code>指定ではなく、CSS側の対応でもCLS加算は発生しませんでした。

画像サイズのCLS対応

ブラウザの戻るボタンを押した時に、ある処理を実装することがあった。そのときに立ちはだかるHistory APIなるもの。。 さくっとググってみた。 「ふむふむ、pushStateには引数を３つとるんだな。」 「引数にnullが２つ。第３引数にURLを設定？」となんとなく近寄り難い印象。 せっかくなので調べてやろうじゃないか。 <a href="https://developer.mozilla.org/ja/docs/Web/API/History_API" target="_blank" rel="noopener noreferrer">https://developer.mozilla.org/ja/docs/Web/API/History_API</a> MDNによると、Windowオブジェクトは、ブラウザのセッション履歴を <code>history</code> を使って管理しているとのこと。 前ページや次のページ移動は、このような感じでかける。<pre><code>window.history.back() 

👇このようにも書ける
window.history.go(-1)</code></pre> <pre><code>window.history.forward()

👇このようにも書ける
window.history.go(1)</code></pre> 現在のページを再読み込みする、こんな感じ。<pre><code>window.history.go(0)

👇このようにも書ける
window.history.go()</code></pre> 「あれ、以外と直感的に書けるじゃないか。」と少し気が楽になってきた！ ちなみに、 <code>length</code> で履歴スタックの中のページ数を取得できる。<pre><code>window.history.length</code></pre> ここまでは順調！と思ったら、いきなり先ほどの <code>pushState</code> のサンプルコードが。。 そこで、<a href="https://developer.mozilla.org/ja/docs/Web/API/History" target="_blank" rel="noopener noreferrer">History インターフェースのページ</a>をみます。 <h2 id="h97ada4377e"><code>History</code> のプロパティ</h2><code>length</code> : integer 閲覧しているページを含むセッション履歴の数を <code>integer</code> で返す。新しくタブでページを読み込んだとき、 <code>length</code> の値は <code>1</code> となる。 <code>scrollRestoration</code> : 'auto' | 'manual' 戻る、進む操作のときスクロールの位置を復元するときの設定する。 	<code>auto</code> 	ユーザーがスクロールしたページ上のスクロールの位置が復元されます。 	<code>manual</code> 	ページ上のスクロール位置は復元されません。ユーザーが手動でその位置までスクロールする必要があります <code>state</code> : any 履歴スタックの最上位にあるものの状態を返す。履歴スタックの一番上の状態です。 この値は <code>pushState()</code> や <code>replaceState()</code> が使われない限り <code>null</code> です。 <h2 id="ha2907af1b5"><code>History</code> のメソッド</h2><code>back</code> ユーザーがブラウザーの戻るボタンをクリックしたときと同じく、セッション履歴の一つ前のページへ移動します。&nbsp;<code>history.go(-1)</code>&nbsp;と同等です。 <code>forward</code> ユーザーがブラウザーの次へボタンをクリックしたときと同じく、セッション履歴の一つ次のページへ移動します。これは&nbsp;<code>history.go(1)</code>&nbsp;と同等です。 <code>go</code> 現在のページからの相対位置で識別されるページを非同期に読み出します。たとえば、&nbsp;<code>-1</code>&nbsp;は前のページで&nbsp;<code>1</code>&nbsp;は次のページです。範囲外の値を指定した場合 (例えば、セッション履歴に以前訪問したページがないときに&nbsp;<code>-1</code>&nbsp;を指定した場合)、このメソッドは暗黙に何もしません。&nbsp;<code>go()</code>&nbsp;を引数なし、または&nbsp;<code>0</code>&nbsp;の値で呼び出すと、現在のページを再読み込みします。 <code>pushState</code> : (state, unused, url?) 指定したタイトルとURLをセッション履歴に追加する。 <code>state</code> <code>pushState()</code> によって作られる新しい履歴項目に関連したJavaScriptオブジェクト。ユーザーが新規のstateに移動した時はいつも、 <code>popstate</code> が発行され、イベントのstateプロパティは、履歴のstateオブジェクトのコピーを含む。 <code>url</code> 新しい履歴項目のURLは、この値で与えられる。 <code>replaceState</code> 履歴スタックの最新の項目が、指定したデータ、タイトル、指定されていれば URL になるよう更新します。

History APIについて備忘録

<h2 id="hc69c85bcf9">背景</h2>外部ライブラリを特定のサイトに組み込むとき、リクエストが飛んでいないことがあった。コンソールをみると "Content Security Policy"なるエラーがでていた。実は以前"Content Security Policy"関連のレスポンス表示を見たことがあったのだけど、あまり調べずにそのまま放置していた。いい機会なので今回CSP (Content Security Policy) について少し調べてみた。<h2 id="haad0f131a8">CSPとは？</h2><blockquote>コンテンツセキュリティポリシー (<a href="https://developer.mozilla.org/ja/docs/Glossary/CSP" target="_blank" rel="noopener noreferrer">CSP</a>) は、クロスサイトスクリプティング (<a href="https://developer.mozilla.org/ja/docs/Glossary/Cross-site_scripting" target="_blank" rel="noopener noreferrer">Cross-site-scripting</a>) やデータインジェクション攻撃などのような、特定の種類の攻撃を検知し、影響を軽減するために追加できるセキュリティレイヤーです。これらの攻撃はデータの窃取からサイトの改ざん、マルウェアの拡散に至るまで、様々な目的に用いられます。</blockquote>引用: https://developer.mozilla.org/ja/docs/Web/HTTP/CSPつまり、特定のサイトに下記のような制約を加えることで、CSSやJavaScriptの実行方法とリソースの読み込み先をホワイトリスト的に管理することができるようだ。<ul><li>外部リソース (JavaScript, CSS, 画像など) の読み込み</li><li>inlineスクリプトの実行</li><li>evalの実行</li><li>inlineスタイルの適用</li></ul> <h2 id="h293f170a56">仕組み</h2><h3 id="he0317d56bd">1. ヘッダーの指定によるリクエストの制御</h3><img src="https://images.microcms-assets.io/assets/1e1129a92bc841ccad1a43c6a2977d50/3c503eb9791c4edf8315b5c0759632ee/Group%205%20(2)%20(1).png?w=800&amp;h=551" alt=""><h3 id="h683a12a36c">2. 設定方法</h3>HTTP Response Headerに下記を追加する <code>ポリシー</code> には、サイトに適用するCSPディレクティブ (CSPの内容を指定するための要素) から構成される文字列を指定する<pre><code>Content-Security-Policy: ポリシー</code></pre><h4 id="h9039af0ceb">CSP HTTP Header</h4><pre><code>Content-Security-Policy: ディレクティブ名 ソース; ディレクティブ名 ソース;</code></pre><code>;</code> で区切られている点がポイント。<h4 id="hc39c40c90f">CSP HTTP Headerの記述例</h4><pre><code>Content-Security-Policy: img-src 'self' https://example.com</code></pre>上記の場合は、画像リソース用ディレクティブ <code>img-src</code> に対しての設定例。サイト自身のオリジン <code>self</code> と <code>https://example.com</code> からの画像かfaviconのみが有効となり、それ以外のオリジンからは、コンテンツとして受けつけないようになる。 <h2 id="hd1744469ec">ディレクティブ例 <code>script-src</code> </h2><code>&lt;script&gt;</code> で読み込まれる外部リソースの制御だけでなく、inline等の <code>onclick</code> などの実行も制御する。<pre><code>&lt;script src="https://not-example.com/js/library.js"&gt;&lt;/script&gt;

&lt;button id="btn" onclick="doSomething()"&gt;&lt;/button&gt;
🖕上記はブロックされるため、下記のように記述する必要がある
document.getElementById("btn").addEventListener("click", doSomething);</code></pre> リソースや <code>unsafe-inline</code> 以外にも <code>nonce</code> も利用できる。<pre><code>Content-Security-Policy: script-src 'nonce-2726c7f26c'</code></pre> 上記ディレクティブの場合は、下記の処理は実行できる (同一のnonce値である場合に許可される)<pre><code>&lt;script nonce="2726c7f26c"&gt;
 const inline = 1;
 // …
&lt;/script&gt;</code></pre> また、今後増えつつありそうなWASMの処理も下記のように明示的に許可をする必要がある<pre><code>Content-Security-Policy: script-src 'wasm-unsafe-eval'</code></pre> <h2 id="h1269d2a126"><code>connect-src</code> </h2><code>a</code> や JS のfetch等のメソッドによって読み込まれるリソースを制限。例として、下記はブロックされ、実行できない。<pre><code>&lt;a ping="https://not-example.com"&gt;
&lt;script&gt;
 const xhr = new XMLHttpRequest();
 xhr.open("GET", "https://not-example.com/");
 xhr.send();

 const ws = new WebSocket("https://not-example.com/");

 const es = new EventSource("https://not-example.com/");

 navigator.sendBeacon("https://not-example.com/", {
 /* … */
 });
&lt;/script&gt;&lt;/a&gt;</code></pre><h2 id="hddf3f89448"><code>img-src</code> </h2>画像やfaviconに対する有効なソースを定義する <h2 id="h77745cadab"><code>style-src</code></h2>CSS関連のリソース制御<pre><code>Content-Security-Policy: style-src https://example.com/</code></pre> 上記ディレクティブの場合、下記はブロックされる<pre><code>&lt;link href="https://not-example.com/styles/main.css" rel="stylesheet" /&gt;

&lt;style&gt;
 #inline-style {
 background: red;
 }
&lt;/style&gt;

&lt;style&gt;
 @import url("https://not-example.com/styles/print.css") print;
&lt;/style&gt;

&lt;div style="display:none"&gt;Foo&lt;/div&gt;

document.querySelector('div').setAttribute('style', 'display:none;');
document.querySelector('div').style.cssText = 'display:none;';
🖕上記はブロックされるため、下記のように記述する必要がある
document.querySelector('div').style.display = 'none';</code></pre><code>script-src</code> と同様に <code>&lt;style&gt;</code> に<code>nonce</code> を利用することも可能。 <h2 id="hc9e88a820f"><code>default-src</code></h2> 別のディレクティブに対するフォールバックとして機能する。例えば、 <code>script-src</code> が明示的に指定されていないとき本ディレクティブが制御する。

記憶に残ったことを忘れないために色々メモとしてのこしていきます