<p><a href="https://greensock.com/gsap/" target="_blank" rel="noopener noreferrer">GSAP</a><br>GreenSock社が開発したアニメーションライブラリ。<br>個人的な肌感ではアワード系サイトに載ってるサイトのうち6,7割ぐらいは使ってるので、アニメーションするときは、とりあえず入れていいライブラリだと思います。<br>2019年11月にGSAP 2からGSAP 3に移行したため、web上ではGSAP2の書き方の情報が混在していて注意が必要です。<br>従来はTweenLite, TweenMax, TimelineLite, TimelineMaxと分割してたので、 これらが記述されてる記事はGSAP2の書き方と思っていいです。<br>使い方は公式や、いろんなサイトで紹介されてるので、ここではざっと概要を。<br></p><h2 id="h0669eefa7c">目次</h2><ul><li>簡単なデモとGSAPの使い所</li><li>メリット<ul><li>複雑な動きの実装をスッキリかける</li><li>GSAPのプラグインを使うことで拡張できる</li><li>スクロールイベントの間引き処理がされていてパフォーマンスがいい</li><li>軽量</li></ul></li><li>npm経由で使う</li><li>ライセンス</li><li>ドキュメントなど</li><li>有料プラグイン</li></ul><p><br></p><h2 id="h9137fb0e8d">簡単なデモ</h2><p>簡単なデモを作りました。最後の動きは有料プラグインです（Codepen用にお試しで使えるコードを使ってます）</p><iframe class="embedly-embed" src="https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fcodepen.io%2Fmismith0227%2Fembed%2Fpreview%2FJjyEdEZ%3Fdefault-tabs%3Dhtml%252Cresult%26height%3D600%26host%3Dhttps%253A%252F%252Fcodepen.io%26slug-hash%3DJjyEdEZ&display_name=CodePen&url=https%3A%2F%2Fcodepen.io%2Fmismith0227%2Ffull%2FJjyEdEZ&key=d640a20a3b02484e94b4b0a08440f627&type=text%2Fhtml&schema=codepen" width="800" height="600" scrolling="no" title="CodePen embed" frameborder="0" allow="autoplay; fullscreen" allowfullscreen="true"></iframe><p><br>使い所としては、デモのようにスクロールして要素が表示された時に、何かアニメーションしたいとき、スクロールに応じて要素を動かしたい時、複数のアニメーションを順番に動かしたい時など。<br>ただ、こういった動きは自分で実装しようと思えばできるし、他にもライブラリがあるのにGSAPが多くのサイトで使われてるのは何故でしょう？<br></p><h2 id="h3ab24f6f50">メリット</h2><h3 id="h0347ba2df1">複雑な動きの実装をスッキリかける</h3><p>例えば、連続的なアニメーションの実装は、GSAPのtimelineを使えば見やすく書けます。</p><pre><code>// スクロールして.sectionの上部が、ブラウザのtopに到達したときに、
// 1. div1をy方向に200%、2秒かけて動かす
// 2. div1をy方向に100%、1秒かけて動かす
// 3. 3秒待つ
// 4. div2をy方向に-200%、2秒かけて動かす
gsap
    .timeline({
      scrollTrigger: {
        trigger: '.section'
        start: 'top top',
      }
    })
    .from('.div1', { yPercent: 200, duration: 2 })
    .to('.div1', { xPercent: 100, duration: 1 })
    .to('.div2', { duration: 3 })
    .to('.div2', { yPercent: -200, duration: 2 })</code></pre><h3 id="hfab9869f8d">GSAPのプラグインを使うことで拡張できる</h3><p>プラグインを使うことでさらにアニメーションの幅が広がります。<br>有料のもあるので注意</p><h3 id="h55cc58e8fb">スクロールイベントの間引き処理がされていてパフォーマンスがいい</h3><p>スクロールイベントを普通に書くとスクロールの度にすごい頻度でイベントが発火してしてしまいます（他にもマウスを動かした時や、リサイズ処理など）。<br>そのスクロールの負荷対策としてdebounce（デバウンス）処理をするのですが、これをGSAP側でやってくれてます。スクロールイベントを一定間隔で間引いてくれてます。<br></p><h3 id="hd4662dd09d">軽量</h3><p>ファイルサイズが軽いらしいです。GSAP2よりも3はさらに半分軽くなったとか。<br>どれぐらい軽いかを書いてるところが見つからないので、情報得たら書きます。<br></p><h2 id="he5ea0086cd">npm経由で使う</h2><p>CDNで使う方法はよくブログで紹介されてますが、実制作では <code>npm install</code>して使うと思うので書いておきます。</p><pre><code>npm i gsap
or
yarn add gsap</code></pre><p>importとプラグインを使う</p><pre><code>import { gsap } from 'gsap'
import { ScrollTrigger } from 'gsap/ScrollTrigger.js'

gsap.registerPlugin(ScrollTrigger)

// 複数プラグインを使う場合
// gsap.registerPlugin(MotionPathPlugin, TextPlugin);</code></pre><p><br></p><h2 id="hc1b2f1de01">ライセンス</h2><p>GSAPはMITやGPLではなく、独自ライセンスのため注意。<br>無料で公開されているサイトであれば無料ですが、有料なコンテンツがある場合は有料のライセンス登録が必要です。<br>普通のwebサイトなら大丈夫ですが、何か課金があったり、販売するサイトはライセンス料を払う必要があります。<br><a href="https://greensock.com/licensing/" target="_blank" rel="noopener noreferrer">https://greensock.com/licensing/</a><br></p><h2 id="hde05627694">ドキュメントなど</h2><p>公式ドキュメントのどこ見たらいいかなどのまとめ</p><h3 id="h2aeb2fa1e8">プラグイン一覧</h3><p><a href="https://greensock.com/products/" target="_blank" rel="noopener noreferrer">https://greensock.com/products/</a></p><h3 id="h8f27fbddf6">ドキュメント</h3><p><a href="https://greensock.com/docs/v3/GSAP" target="_blank" rel="noopener noreferrer">https://greensock.com/docs/v3/GSAP</a></p><h3 id="hf82cc7e56f">フォーラム</h3><p>コミュニティもあるので、何か分からなければ質問もできます。ただし英語。<br><a href="https://greensock.com/forums/" target="_blank" rel="noopener noreferrer">https://greensock.com/forums/</a></p><h3 id="h85b634cb63">Easing</h3><p>easinの指定をしたいときはここで実際の動きを見れる<br><a href="https://greensock.com/docs/v3/Eases" target="_blank" rel="noopener noreferrer">https://greensock.com/docs/v3/Eases</a><br></p><h2 id="hc07a99f4a6">有料プラグイン</h2><p>GreenSock会員になれば使える有料プラグインがあります。<br>プラグインをフルに使うには「Shockingly」プライン以上が必要です。<br>Codepenではサンプルで使えるようにしてくれてるので、有料プラグインを試したいときはCodepenを使うといいです。<br><a href="https://greensock.com/club/" target="_blank" rel="noopener noreferrer">https://greensock.com/club/</a><br></p>

デファクトスタンダードになっているアニメーションライブラリGSAPについて

アニメーションライブラリGSAPについて

<p>このサイトはNext.js + microCMS + Vercelで作っていて、Jamstackなサイト高速だし、個人で使う分にはお金かからないしいいなと思ってますが、深くメリット・デメリットを知らなかったので、改めて調べてみました。<br></p><pre><code>より良いパフォーマンスを提供するウェブサイトとアプリを構築するための最新の方法</code></pre><p><a href="https://jamstack.org/" target="_blank" rel="noopener noreferrer">https://jamstack.org/</a><br>webサイトのまとめサイトに載ってるサイトの技術をchrome拡張機能で見ると、Jamstackなサイトは増えてきてます。<br>CDNの詳しい仕組みはよく分からんですが、今どきのフロントエンド技術で、高速なサイト作れるというイメージ持っといて、とりあえず何か作ってみるといいと思います<br></p><h2 id="h0669eefa7c">目次</h2><ul><li>Jamstackとは</li><li>WordPressなどのCMSとどう違うのか</li><li>データはどうしてるのか</li><li>メリット</li><li>デメリット</li><li>Jamstackでよく使われるサービスや技術</li><li>Jamstackで始めるほぼ0円ブログ生活</li></ul><h2 id="h70ace14742">Jamstackとは</h2><p>JavaScript、API、Markupの組み合わせで作るアーキテクチャのこと。JAMはそれぞれの頭文字。<br>対比としてWordPressなどのCMSを使ったサイトが挙げられます<br>最初はJavaScript、API、Markupの構成を指していたが、「HTMLを事前にレンダリングしているサイト」や「サーバーサイドとクライアントサイドが分離してるサイト」など定義の範囲は広がっていってるらしい<br></p><h2 id="ha117653a1f">WordPressなどのCMSとどう違うのか</h2><p>WordPressのメリットはブログや新着情報など、webサイトに更新する機能を持たせられることです。サイトにアクセスがあった時に、そのURLに応じてデータを取得して、動的にサイトを表示できます。<br>WordPressで作られたサイトにアクセスした時に画面が表示するまでの流れはこうなっています。</p><pre><code>1. サイトへアクセス
2. webサーバーが該当のデータをデータベースから取得
3. 取得したデータをもとにページを構築
4. webサーバーがHTMLを返す</code></pre><p>この方式の問題点は</p><ol><li>webサーバーが必要になるため、サーバーが停止した時にサイトが表示できなくなる</li><li>大量のアクセスに弱い。アクセスが集中してサーバーがダウンということも起こり得る。それに備えてに事前にサーバーを増強するなどのコストも必要になってくる</li><li>セキュリティの懸念。この辺は詳しくないですが、webサイトへの攻撃者はwebサーバーの処理の穴をつくらしいです。</li></ol><p>一方、Jamstackではこうなります。データベースがなくHTMLを返すだけなので、表示が高速になります</p><pre><code>1. サイトへアクセス
2. CDNがHTMLを返す</code></pre><p>CDNについてはこちら（<a href="https://developer.mozilla.org/ja/docs/Glossary/CDN" target="_blank" rel="noopener noreferrer">https://developer.mozilla.org/ja/docs/Glossary/CDN</a>）<br></p><h2 id="hb9d4ed6ddf">データはどうしてるのか</h2><p>じゃあWordPressで表示する動的なコンテンツはどうしてるのかというと、事前にビルドしてHTMLを生成しています。<br>例えば、新しい記事を書いたり、過去の記事を更新したのをきっかけに、ビルドを開始させて、サイト全体のHTMLを生成しています。<br></p><h2 id="h3ab24f6f50">メリット</h2><ul><li>基本的にはNetlifyやVercel、Firebase HostingといったCDN（コンテンツデリバリネットワーク）を使ってデータを返してるので高速になる<ul><li>ビルドしたHTMLを置ければいいので、レンサバでも可能だけど、上記サービスを使った方が恩恵受けられる</li></ul></li><li>大量のアクセスに強い<ul><li>CDNにはアクセスが集中したときに自動的に分散する仕組みがある</li></ul></li><li>フロントとAPIが分離することで技術選定の幅が広がったり、フロント、APIそれぞれ独立して技術の切り替えが可能。</li><li>事前にビルドしてHTMLをCDNに置いてるだけなので、セキュリティを気にする範囲が限定的になり比較的安全（管理画面はサイトとは全く別のところにある）</li></ul><p><br></p><h2 id="h7e4a670898">デメリット</h2><ul><li>クライアントワークでは、理解を得られづらいかもしれない<ul><li>使い慣れた管理画面のWordPressがいいってなる</li></ul></li><li>ビルドでどれぐらい時間かかるか読めないので、特定の時間ぴったりに記事を公開しづらい。<ul><li>ページが増えるほどビルド時間が長くなることもあったが、差分がある画面だけをビルドする仕組みもある</li></ul></li><li>WordPressならプラグインで簡単にできたことを、自分で頑張る必要がある<ul><li>人気記事の表示とか</li></ul></li><li>ちょっとしたデザインやサイトの表示設定などの変更をWordPressなら管理画面でできていたことが、必ずエンジニアの手を借りる必要が出てくる</li><li>記事を書くときのプレビュー機能がない（ただし、後述のHeadless CMSを使うことがほとんどで、これらのサービスはプレビュー機能を提供してるのでデメリットではなくなってきてる）</li></ul><p><br></p><h2 id="h0daede3c7a">Jamstackでよく使われるサービスや技術</h2><h3 id="h795f036a6e">Headless CMS</h3><p>JamstackのAPIにあたる部分のサービス。訳すと頭がないCMSで、表示部分以外を提供してくれています。WordPressのように管理画面とデータベースは提供してくれてますが、表示に関しては自分でAPIを取得して表示することになります。<br>代表的なもの。個人で使うぐらいなら無料で使えるサービスもあります。</p><ul><li>microCMS（日本製）</li><li>Contentful</li><li>Shifter（WordPressをHeadless CMSとして使えるサービス）</li><li>NetlifyCMS</li></ul><p>こういったサービスを使わなくても、WordPressをAPIとして使うこともできますし、このNotionをAPIにしてブログを作ったという記事もあります。<br>サービスを使ったら楽というだけで、APIを返してくれるものならなんでもOK（なはず）。</p><h3 id="h55a3cd035f">静的サイトジェネレーター</h3><p>APIからデータを取得して、HTMLを生成するライブラリです。<br>代表的なものはこちら</p><ul><li>Next.js（React製）</li><li>Gatsby（React製）</li><li>Nuxt.js（Vue製）</li><li>Gridsome（Vue製）</li></ul><h3 id="hc3f4aa8cd8">ホスティングサービス（CDNプロバイダ）</h3><p>生成したHTMLをweb上で公開するための置き場です。<br>代表的なものはこちら。これらも個人で無料枠で不自由なく使えます。</p><ul><li>Netlify</li><li>Vercel</li><li>Firebase Hosting</li></ul><h2 id="h1e4772854f">Jamstackで始めるほぼ0円ブログ生活</h2><p>上記のサービスを使えばほぼ0円でサイトを運用できます。<br>WordPressでブログを運用する場合は、レンタルサーバー代や、ドメイン代が必要でしたが、ホスティングはNetlifyやVercelを使うと不要になるので、必要なのはドメイン代だけになります。</p><pre><code>例
## フロントエンド
Next.js（0円）

## API（ブログ書くところ）
microCMS（0円）

## ホスティング
Vercel（0円）

## ドメイン
ムームードメイン（初年数十円のドメインを買う）</code></pre><p>ドメインは取得初年は数十円で、更新以降は1000円ちょいみたいなドメインを使えば、格安でブログや個人サイトを持つことができます。</p>

Jamstackについていろいろ調べてみた

Jamstackなサイトとは

<p>結論から書くと、pxかremならどっちでもいいです。<br>どっちでもいいですが、違いはあるので知った上でどちらを使うか判断しましょう<br></p><h2 id="h0669eefa7c">目次</h2><ul><li>単位いろいろ<ul><li>px</li><li>em</li><li>rem</li><li>%</li><li>vw</li></ul></li><li>px vs rem</li><li>remのルート指定いろいろ</li><li>em の使いどころ</li><li>有名なサイトではどうなってるか</li></ul><p><br></p><h2 id="he16d20db91">単位別の特徴</h2><pre><code>絶対値・・・どんな環境でも一定の値
相対値・・・他の値を基準にして決まる値</code></pre><h3 id="hce39fe1662">px</h3><ul><li>絶対値指定</li><li>ブラウザのフォントサイズの設定が効かなくなる<ul><li>chromeだと「設定→デザイン→フォントサイズ」</li></ul></li><li>ただし、ブラウザのズーム機能では拡大される</li></ul><h3 id="h99dc44cf09">em</h3><ul><li>相対値指定</li><li>親要素のフォントサイズを継承する</li><li>emの中にemがあると複利計算されていく</li></ul><pre><code>&lt;div&gt;
  &lt;p&gt;こんにちは&lt;span&gt;あああああ&lt;/span&gt;&lt;/p&gt;
&lt;/div&gt;

// CSS
div {
	font-size: 16px;
}

p {
	font-size: 2em; // これは32pxになる
}

span {
	font-size: 2em; // これは64pxになる
}</code></pre><h3 id="hedfc6405f0">rem</h3><ul><li>相対値指定</li><li>root emの略でroot（html）のフォントサイズから計算される</li></ul><pre><code>&lt;p&gt;こんにちは&lt;span&gt;あああああ&lt;/span&gt;&lt;/p&gt;

// CSS
html {
	font-size: 16px;
}

p {
	font-size: 2em; // これは32pxになる
}

span {
	font-size: 2em; // これも32pxになる
}</code></pre><h3 id="h5ef620ffb2">%</h3><p>フォントサイズにおいて%の挙動はemと同じなので割愛</p><h3 id="h58808d197f">vw</h3><ul><li>ビューポート（画面幅）を基準にしたサイズ指定</li><li>例えば320pxのデバイスで16pxにしたい時は5vwになる。（16/320 ×100）</li><li>デバイス幅によって発生する改行位置の違いや左右マージンの余白の違いなど、デバイス幅による差異が生まれにくくなるため、使われることがある。</li><li>ただし、上記の例の場合375pxのデバイスでは18.75px相当になり、デザインと違ってくる可能性があるため、注意が必要</li></ul><h2 id="h6bcb0e43d3">px vs rem</h2><p>pxかremかはたびたびTwitterなどで論争が起こります。<br>違いはブラウザのフォントサイズ設定が効くかどうかです。</p><ul><li>ユーザーのフォントサイズ設定をちゃんと反映させてあげたいならrem</li><li>フォントサイズ設定無視しても、ブラウザズームで拡大できるし、開発のしやすさ選ぶならpx</li></ul><p>という大筋だと思います。<br>以下はpx or remの時によく出る話</p><h3 id="h8c1b0fc7eb">remは計算が必要なところ以外特に悪いところはない</h3><p>remを使えばフォントサイズの設定も反映されるし特に悪いとこはないです<br>使わない場合の理由は、どちらかというと開発側の事情です</p><ul><li>計算が必要（ルートの指定方法やSassで緩和できる：後述）</li><li>確認者のフォントサイズ設定が異なる場合にデザインと違うと指摘される可能性がある</li><li>納品後にCSSを触る可能性がある場合、rem計算のことを伝える必要がある</li><li>外部のCSSがremだった場合、ルートの指定が合ってるか注意する必要がある（聞いたことないけどあるかもしれない）</li></ul><h3 id="haedba668de">pxは設定のフォントサイズを無効にするからアクセシビリティ的に悪い？</h3><p>視力が悪くフォントサイズ設定を大きくしてる人にとってpx指定はよくないのでは、という話です。<br>ただし、ズーム機能という選択肢がありますし、これだけでアクセシビリティ的に悪いとは断定できません。アクセシビリティで訴訟が起こるアメリカの大手サイトでさえpxを使ってますし。</p><h3 id="h95aac300b6">remを使えばレスポンシブ対応しやすい？</h3><p>ルートのフォントサイズを変えれば全てが変わるので、メディアクエリでルートのフォントサイズを変えるだけでレスポンシブ対応できるという考えです。</p><pre><code>// つまりこういうこと
html {
  /* デフォルト（SPサイズ）ではベースのfont-sizeは12px相当 */
  font-size: 75%;
}

@media screen and (min-width:768px) {
  html {
    /* 768px以上ではベースのfont-sizeは16px相当 */
    font-size: 100%;
  }
}</code></pre><p>でも、実際の現場で一括でフォントサイズを変えて対応できるデザインなんてないと思います。<br>それならSassの変数で管理する方がずっとメンテナンス性高いです</p><h2 id="h2b5382929c">remのルート指定いろいろ</h2><p>デフォルトでは <code>1rem = 16px</code>相当で、18pxにしようとすると <code>1.125rem</code> を指定することになり、そのままだと計算がめんどうなremですが、ルートの指定やSassで楽することができます<br>どっちでもいいですが、個人的にはSassが使える環境ならfunction作ります</p><h3 id="h089ff0cfb7">62.5%</h3><p>htmlに <code>font-size: 62.5%</code>を指定する方法。62.5%が10px相当になるため16pxは <code>1.6rem</code>になります。デフォルトより分かりやすい。<br>%で10px相当に指定してるのは、 <code>html {font-size: 10px}</code>とするとルートがpxなのでフォントサイズ設定が効かなくなるからです（当たり前ですが）</p><pre><code>html {
  font-size: 62.5%;
}

body {
  font-size: 1.6rem;
}

p {
  font-size: 2.4rem;
}</code></pre><h3 id="h0e903f440b">Sassのfunctionを使う</h3><p>Sassが使える環境ならfunctionを作っておくといいです。</p><pre><code>@function rem($value) {
    $remValue: ($value / 16) + rem; 
    @return $remValue;
}

p {
    font-size: rem(24);
}

/* 出力: 24px相当 */
p {
  font-size: 1.5rem;
}</code></pre><h2 id="hbac305d359">emの使い所</h2><p>使い回しするコンポーネントの中にある要素のフォントサイズはemで指定すると使いやすい場面があります。<br>一例ですが、例えばアイコン付きボタンのアイコン</p><pre><code>// html
&lt;button class="button"&gt;
	&lt;svg&gt;....&lt;/svg&gt;
	ボタン
&lt;/button&gt;

// css
// ボタンの基本スタイル
.button {
	font-size: 16px；
}

.button svg {
  font-size: 1em；
}

// 使い回す時
// html
&lt;button class="button secondary"&gt;
	&lt;svg&gt;....&lt;/svg&gt;
	ボタン
&lt;/button&gt;

// css
// こうするだけでsvgアイコンの方もフォントサイズが24pxに変わる
.button.secondary {
	font-size: 24px; 
}</code></pre><p>こんな感じでCSS設計するときに、Blockレベルはremやpx、Elementはemで書くという人もいます。<br>emを指定しておくと使い回す時に便利そうだなと思うときはemを使ってみましょう。<br></p><h2 id="ha5b2462570">有名サイトは何を使ってるか</h2><ul><li>px<ul><li>Apple（日本）</li><li>Airbnb</li><li>Amazon</li><li>Twitter</li></ul></li><li>rem<ul><li>Google（企業サイト）</li><li>Yahoo Japan</li></ul></li></ul><p><br></p>

フォントサイズの単位は何を使えばいいかについて

フォントサイズの単位について

<h2 id="h0669eefa7c">目次</h2><ul><li>種類</li><li>Sass<ul><li>SASS</li><li>SCSS</li><li>PostCSS</li><li>その他</li></ul></li><li>SassとPostCSSの組み合わせ</li><li>importルールの廃止とDart Sass</li></ul><p><br></p><h2 id="he665b3e0a1">種類</h2><h3 id="h6321f8cf3a">Sass</h3><p>Sassには記法が2つあります。いつも書いている「サス」というのは、後述のSCSSのことで、実はSASSが存在します。<br>SCSSの方が閉じかっこがあって分かりやすかったり、Sassが分からなくてもCSSで書くこともできるので、「サス」というと一般的にはSCSSの方を指すようになりました。<br></p><h4 id="ha6752d868e">SASS</h4><p>拡張子は <code>.sass</code><br>SASS記法で書くとこうなります</p><pre><code>div
    margin: 0 auto
    p
        padding: 20px
        span
            font-color: red;</code></pre><p><br></p><h4 id="hb704ab42a8">SCSS</h4><p>拡張子は <code>.scss</code><br>SCSS記法で書くとこうなります。</p><pre><code>div {
  margin: 0 auto;
  p {
    font-size: 1em;
  }
}</code></pre><p>Sassには簡単に書き方を試せるPlaygroundがあります。出力がよく分からんというときは、ここで試してみるといいです<br><a href="https://www.sassmeister.com/" target="_blank" rel="noopener noreferrer">https://www.sassmeister.com/</a><br></p><h3 id="h3426421af8">PostCSS</h3><p>一応プリプロセッサの一つとして挙げられますが、PostCSS自体はCSSを加工しやすいようにパースし、結果をCSSとして出力するだけです。<br><br>PostCSS用のプラグインを利用することで、SassのようなCSSのプリプロセッサとして使えます。<br><br>例えば、 <code>postcss-nested</code>というプラグインを使えば、ネスト（入れ子）で書けるようになります。<br><br>PostCSSのメリットとしては、自分で必要な機能だけを使った環境を作れることと、最新のCSSのpolyfillプラグイン（まだブラウザで対応されてないが、後に使えるようになる予定のCSS）を使えば、学習コストはCSSだけになります。<br><br>一方で環境構築のコストや管理の手間はかかります<br></p><h3 id="ha739b3b8f6">その他</h3><p>StylusやLessというのもあります。かなり前は聞きましたが、もう聞かなくなりました。<br>よっぽど物好きでない限りはSassでいいでしょう<br></p><h2 id="ha5cfe2ca50">SassとPostCSSの組み合わせ</h2><p>SassとPostCSSを組み合わせた環境はよく見られます。<br><br>Sassで生成されたCSSをさらにPostCSSで後処理をします。<br><br>例えば以下のようなことをします。</p><ul><li>autoprefixer: プレフィックスを自動でつけてくれる</li><li>css-mqpacker: 同じメディアクエリをまとめてくれる</li><li>cssnano: CSSの圧縮</li></ul><p><br><code>gulp-autoprefixer</code> というgulp用のプラグインもありますが、PostCSSとautopurefixerを使う理由は <code>gulp-autoprefixer</code>は結局PostCSSをautoprefixerを内包してるだけのgulp用ラッパープラグインだからです。なので、autoprefixerはバージョンアップしてるのに、 <code>gulp-autoprefixer</code>はまだ対応されてないということも起こりえます。<br></p><h2 id="h60799aef03">importルールの廃止とDart Sass</h2><p>Sassの <code>@import</code>ルールは廃止されることが予定されています。 <code>@import</code>は別のSassファイルを読み込んで変数を利用したり、一つにまとめることができます。<br><br>原文の予定では2022年の10月1日に廃止されます。<br><a href="https://sass-lang.com/blog/the-module-system-is-launched#future-plans" target="_blank" rel="noopener noreferrer">https://sass-lang.com/blog/the-module-system-is-launched#future-plans</a><br><code>@import</code>は <code>@use</code>や <code>@forward</code>といったルールに置き換わります。<br><br>このルールが実装されてるのがDart Sassです。Node Sassはもう開発が行われておらず非推奨になっています。<br>gulp-sassは現状はデフォルトではNode Sassですが、設定すればDart Sassが使えるので、今からDart Sassを使っておきましょう。<br><br><a href="https://www.npmjs.com/package/node-sass" target="_blank" rel="noopener noreferrer">https://www.npmjs.com/package/node-sass</a></p><blockquote>Warning: LibSass and Node Sass are deprecated. While they will continue to receive maintenance releases indefinitely, there are no plans to add additional features or compatibility with any new CSS or Sass features. Projects that still use it should move onto Dart Sass.</blockquote><p>Node SassはC++で開発されているLibSassをNode.jsで使えるようにしているラッパーライブラリです。<br>Dart SassはDartで開発されています。<br><br>さらに前にはRuby Sassがありましたが、2019年にサポート終了しています。</p>

SaaaやPostCSSなどCSSプリプロセッサについて

CSSプリプロセッサについて（SassやPostCSS）

<h2 id="h0669eefa7c">目次</h2><ol><li>Node.jsについて</li><li>npm / yarn について</li><li>タスクランナーについて（gulpなど）</li><li>モジュールバンドラーについて（webpackなど）</li><li>gulpとwebpackの併用って何してるの</li><li>もはやgulpいらない？</li><li>gulpがすでに導入されてるプロジェクトの始め方<ol><li>yarn したときや、yarn devした時によくあるエラー・解決法</li></ol></li></ol><h2 id="h7a76334207">1. Node.jsについて</h2><p>Node.jsはJavaScriptをサーバーサイド言語として使えるようにしたJavaScriptの実行環境の1つ。<br></p><h2 id="h9ce30e0f8d">2. npm / yarnについて</h2><h3 id="he138e13e3d">npm</h3><p>npmはNode.jsのパッケージ管理システム。Rubyにおけるgem、Pythonにおけるpipのようなもの。パッケージはライブラリやフレームワークのこと。Reactやwebpack、jQueryなどです。<br><br>もともとはNode.jsのためのパッケージ管理システムだったが、今ではフロントエンド用のパッケージの管理にも使われるようになっている。<br><br>Node.jsがあればnpmコマンドも使えるようになる<br></p><h3 id="h1b68635fcd">yarn</h3><p>Facebookが開発したnpmの改良版コマンドのようなもの。npmよりパッケージのインストールが高速だったり、yarn.lockファイルを作ってくれたりする（今ではnpmでも <code>npm ci</code>を使えばlockファイルは生成されるが、yarnはデフォルトで生成される）<br><br>yarnはnpmでインストールしましょう。<br></p><h4 id="hc2956e7ea8">yarn.lockファイルについて</h4><p>yarn.lockファイルはプロジェクトに依存してるパッケージの正確なバージョンを記録しています。<br><br>package.jsonを見ると様々なパッケージのバージョンが書かれていますが、特定のバージョンを指定してるのではなく、バージョンの範囲を指定しています。<br><br>そのためlockファイルがない状態で <code>yarn</code>や <code>npm i</code>をすると、その時期によってインストールされる細かいバージョンが違ってきて、動いてたはずなのに動かないということが起こります。<br><br>lockファイルでは正確なバージョンを記録することで、こういった問題を解決しています。<br><br>詳しくはこちらを参考に<br><a href="https://zenn.dev/luvmini511/articles/56bf98f0d398a5" target="_blank" rel="noopener noreferrer">https://zenn.dev/luvmini511/articles/56bf98f0d398a5</a><br><br>個人的にはyarn使ってます。</p><h3 id="hbfac673031"><br>タスクランナーについて（gulp, Grunt）</h3><p>タスクランナーとは開発を自動化するためのツール。2013年ごろからフロントエンド開発のトレンドになってるらしい（そのころはまだこの業界いなかった）<br><br>覚える必要ないですが昔はGruntというツールがあり、その後gulpがスタンダードになりました。<br><br>Gruntやgulpには専用のプラグインがあり、それらを使うことでScssをCSSへコンパイルしたり、画像の圧縮などをタスクとして登録し自動化することができます。<br></p><h3 id="h540ef54721">モジュールバンドラーについて（webpack, rollup.js, browserify）</h3><p>モジュールバンドラーはその名の通りモジュールをバンドル（束ねる）するツール。代表的なものはwebpackです。<br><br>CSSやJavaScript、画像などを一つのファイルにまとめてくれます。一つのファイルにすることでリクエストの回数を減らすことができます。<br><br>よくgulpと同列で挙げられることがありますが、厳密には違います。webpackもバンドラーとはいえgulpでやってることもできるのでタスクランナーの一つと思われがちです。<br><br>webpackがよく使われますが、たまにrollup.jsを使ってるのも見ます。rollup.jsの方がシンプルだったような。browserifyはほぼ聞かなくなりました。<br></p><h3 id="hc614023976">gulpとwebpackの併用</h3><p>ReactやVueなどでの開発環境はwebpackで作られますが（他もあるかもしれないけど聞いたことない）、web制作においてgulpとwebpackが併用されてることがよくあります。<br><br>あれは何をしてるかというと、webpackのバンドル機能やbabelでのJSの変換をgulpのタスクとして使ってます。<br><br>webpackを使うことで、htmlに以下のようにライブラリを追加する度に記述していたのを、JSでimportすることで一つにまとめてくれます。</p><pre><code>ライブラリ入れるたびに増えていく...😭
&lt;script src="./jquery.js"&gt;&lt;/script&gt;
&lt;script src="./xxxx.js"&gt;&lt;/script&gt;

JSでimportすることで、一つのファイルにスッキリ😊
&lt;script src="./bundle.js"&gt;&lt;/script&gt;</code></pre><h3 id="h5f0686bef7"><br>もはやgulpはいらない？</h3><p>gulpはgulpのプラグインを介して、node_mudulesにあるライブラリを実行してるに過ぎません。<br><br>例えば、gulpでsassを使う場合には <code>gulp-sass</code>というgulpのプラグインを使いますが、これは <code>sass</code>コマンドをgulpで実行するためのものです。<br><br>別にgulpがなくても <code>sass</code>コマンドを実行すればScssファイルのコンパイルはできます。<br><br>package.jsonにあるscriptsに、そういったコマンドやshell scriptを書いておけばnode_modulesに追加したライブラリをそのまま使うことができます。<br><br>ネットで見かける「gulpを使わずnpm scriptsで環境構築してみた」という記事はそういうことをしています。<br><br>npm scriptsのメリットの一つはGruntやgulpなどタスクランナーの変遷に左右されなくなります。ただしpackage.jsonの記述が増えたり、やっぱりgulpを使う恩恵はあるのでそんなに流行ってはないと思います。<br></p><h3 id="h7bf84d6b14">gulpがすでに導入されてるプロジェクトの始め方</h3><p>gulpで環境構築されたファイルを渡された時にどうすればいいか分からないと思うかもしれないですが、コマンドを数回打つだけです。</p><pre><code>// 1. まずpackage.jsonがあるファイルへ移動
cd hogehoge

// 2. パッケージ一式インストール
yarn

// 3. インストールが終わったら開発環境を立ち上げるコマンドを打つ
yarn dev</code></pre><p><br>3の開発環境を立ち上げるコマンドというのはpackage.jsonに書いてあります。<br><br>scriptsが登録されてるコマンドです。開発環境立ち上げであれば、だいたいdevかstartで登録されてることが多いです。<br>あるいはReadmeに書いてくれてます。もし開発環境を作ることがあれば、Readmeに書いておきましょう。</p><pre><code>{
  "name": "sample",
  "version": "1.0.0",
  "main": "index.js",
  "license": "MIT",
  "scripts": {
    "dev": "npx gulp dev",
    "prod": "npx gulp dev --env production",
    "build": "npx gulp build --env production"
  },
  "dependencies": {
    "gulp": "^4.0.2",
  }
}</code></pre><p><br></p><h4 id="h69b9464b4d">yarn したときや、yarn devした時によくあるエラー</h4><ul><li>使ってるライブラリが使ってるNode.jsのバージョンでは動かない<ul><li>→Node.jsのバージョンを変えましょう。エラーメッセージにどのバージョンなら動くか書いてます</li><li>もらった開発環境だとほとんどこのエラーな気がします</li></ul></li><li>ライブラリがインストールされてない<ul><li>たまにありますが、開発中に他の人が新しくパッケージを追加することもあります。それをGitでpullしてきたときに、自分の環境ではまだインストールしてないのでエラーになります。</li><li><code>yarn</code>しましょう</li></ul></li><li>依存パッケージによるエラー<ul><li>lockファイルを作りましょう</li></ul></li><li>（環境構築する時に）特定のライブラリがあるNode.jsのバージョンでは動かない<ul><li>一つ目と似てますが、そのライブラリのバージョンを動くバージョンまで下げましょう</li></ul></li><li>その他<ul><li>落ち着いてターミナルのエラーを見ましょう</li><li>エラーメッセージをコピぺでググれば、何かしら情報が落ちてます</li></ul></li></ul><p><br></p>

web開発では必須といっていい開発環境について

開発環境あれこれ（gulpやwebpackなど）

<h2 id="h0669eefa7c">目次</h2><ol><li>拡張子による違い<ol><li>png</li><li>jpg</li><li>gif</li><li>svg</li><li>webp</li></ol></li><li>画像圧縮の仕組み</li><li>Retina対応とは</li><li>HTMLでの画像の取り扱い</li><li>picture / srcset / sizes<ol><li>書き方いろいろ</li><li>画像は何パターン用意したらいいか / どの指定がベストか<strong>（結論見たい人はここ）</strong></li><li>有名技術ではどう指定されてる？</li><li>レイアウトシフト/ CLS</li><li>loading属性</li><li>decoding属性</li></ol></li></ol><h2 id="h171d47d3e8">1. 拡張子による違い</h2><h3 id="h421a5ab556">png</h3><ul><li>256色を扱うPNG8、1677万7216色を扱うPNG24、1677万7216色+256色を扱うPNG32がある（規格が3種類あるが、拡張子は全てpngなので、書き出す時以外は特に気にしなくていい）</li><li>透過可能</li><li>可逆圧縮の画像形式なので、低画質で保存しても元の画質に戻すことができる</li><li>jpgやgifに比べてファイルサイズが大きくなりがち</li><li>ロゴやアイコン、イラストなどで使われることが多い</li></ul><h3 id="h2729a771cf">jpeg（jpg）</h3><ul><li>1677万7216色を扱うことができ、色数が多い写真や、グラデーションがかかった画像に向いている</li><li>目に見えない差異をカットし、情報量を圧縮するため、大きい画像でも小さいファイルサイズにできる</li><li>写真に向いている一方で、文字やシャープなラインを含む画像はぼやけやすく、色数の少ないロゴやアイコンを保存すると他のファイル形式よりもファイルサイズが大きくなってしまうこともある</li><li>非可逆圧縮の画像形式となるため、低解像度で保存すると元の画質に戻すことはできない</li><li>高圧縮にすると画像がジャギジャギするので、圧縮率には注意</li><li>透過はできない</li></ul><h3 id="hcdff0437d7">gif</h3><ul><li>最大256色で表現されるので、ロゴやアイコンなど色数が少ない画像の保存に適している</li><li>色数が少ないためグラデーションがある場合、色の段差が発生する</li><li>透過できる</li><li>可逆圧縮の画像形式なので、低画質で保存しても元の画質に戻すことができる</li><li>アニメーション画像を作成できる</li><li>gifに変わる技術としてpngが開発されたため、制作の現場ではほとんど使われなくなっている</li></ul><h3 id="hf89e44b703">SVG</h3><ul><li>ベクター形式の画像。拡大しても滑らかな曲線が表現できる（jpgなどはビットマップ形式と呼ばれるいわば点画のようなもの。）</li><li>拡大縮小しても、容量が変わらないが、複雑なイラストはpngの方が軽くなる場合もあるので、見極めが必要</li><li>ロゴやアイコンなどシンプルなもので、サイト内の配置場所によって大きさが変わる場合などに便利</li><li>svgタグでマークアップすることで、CSSで色を変えることもできる</li><li>アニメーションの表現にも使える</li></ul><h3 id="hf34ebf4ada">webp</h3><ul><li>ウェッピーと読む</li><li>Googleが開発した画像形式でjpgやpngよりも2,3割ファイルサイズを小さくできると言われている</li><li>1677万7216色扱う</li><li>透過可能</li><li>アニメーションも可能</li><li>使えるブラウザが限られているため、表示できないブラウザに対してpngやjpgを表示する対応も必要 <a href="unsafe:%5B%3Chttps://caniuse.com/?search=webp%3E%5D(%3Chttps://caniuse.com/?search=webp%3E)">can i use</a></li><li>pictureタグを使うか、htaccessで非対応ブラウザの制御をする</li></ul><p><br></p><h2 id="h8ec980c37c">2. 画像圧縮の仕組み</h2><p>専門的な話になるので、ざっくりイメージだけまとめます<br>各拡張子ごとにいろいろ方法はあるそうですが、主な方法だけピックアップしました。<br></p><h3 id="h421a5ab556">png</h3><ul><li>フルカラー（1677万色）からインデックスカラー（256色）に変更する</li><li>イラストやロゴなど、色数が多すぎない場合にはインデックスカラーに減色しても見た目はほとんど変わらない</li></ul><h3 id="heec0203bf3">jpg</h3><ul><li>大きく影響がない部分を削ることで圧縮する</li><li>画像のビットマップの一つのマスを明るさ情報と色情報に変換し、高周波成分と低周波成分に分けて、高周波成分の情報を削るらしい（何言ってるかよく分からない）</li><li>おそらくですが、一つのマスに複数の情報があるのを、平均したり、多数派の情報に統一するようなことが行われてるんじゃないかと思ってます。</li></ul><h3 id="hcdff0437d7">gif</h3><p>pngと同様、減色で圧縮する。もともと色数が少ないので、そんなに圧縮されなさそう<br></p><h2 id="h0da75d9963">Retina対応とは</h2><p>Retinaディスプレイに対応することです。<br><br>Retinaディスプレイは従来の倍の解像度のディスプレイのため、画面上の物理的な大きさが300 × 200 pxの画像でも、実際は倍サイズの600 × 400 pxで表示されることになります。<br><br>デザイン上横幅300 × 200pxの画像だからといって、そのサイズのままコーディングしてしまうと、Retinaディスプレイでは画像が引き伸ばされて荒く見えてしまいます。そのため、倍サイズの画像を使います。<br><br>ただし、倍サイズというのはデバイスピクセル比が2なので倍サイズと言ってますが、デバイスピクセル比が3や4の端末も出てきてるそうで、そういった端末に対応する際には注意が必要です。<br><br>Retina対応のために必要以上のサイズの画像を指定すると、サイトが重くなるんじゃないかと懸念してしまいますよね。<br>そこで次に紹介する imgタグの <code>srcset</code> です<br></p><h2 id="h4c66c39a5f">HTMLでの画像の取り扱い</h2><ul><li>srcset / size属性</li><li>pictureタグ</li><li>レイアウトシフト</li><li>decoding="async"</li><li>loading="lazy"</li></ul><h3 id="h0f202e2ca7">srcset属性</h3><p>ブラウザのスクリーン要件（ウィンドウサイズ、デバイスピクセル比）に応じて、異なる画像を読み込むことができる。Retinaディスプレイの時はこのサイズの画像、そうじゃない時はこっちのサイズの画像と出し分けられます。<br>デバイスピクセル比の検証はChromeのデベロッパーツールで変更できます。<br>変更後にリロードが必要<br></p><h3 id="hcd552c3ee7">sizes属性</h3><p>画像をどのサイズで表示したいのかを指定する。srcset属性でw単位を使った時のみ記述する<br>ややこしいですが、横幅や高さを指定するものではないです。横幅や高さwidth, heightで指定します。下に例を書いてます。<br></p><h3 id="h7067acffa2">pictureタグ</h3><p>画像を振り分ける要素。条件にあった画像を表示することができる<br>アートディレクション（PCとSPで違う比率やデザインの画像を表示する）<br></p><h3 id="he1a58379aa">書き方いろいろ</h3><p>推奨の方法は</p><ol><li>サイズ変更のみの場合は <code>img</code> タグに <code>srcset</code> を使う</li><li>アートディレクションを入れる場合は <code>picture</code>要素を使う</li></ol><pre><code>// デバイスピクセル比によって画像を切り替える
// デバイスピクセル比が1の時は500.png、2の時（Retina）は1000.pngを表示する
// src属性はsrcsetが非対応のブラウザのために記述
&lt;img
    srcset="500.png 1x, 1000.png 2x"
    src="1000.png"
    alt="..."
/&gt;

// ビューポート（画面の横幅）と解像度によって画像を切り替える。単位はwを使う
// 以下の例だとデバイスピクセル比が1の場合、ビューポートが600pxだと800.jpが表示される
// デバイスピクセル比が2の場合、ビューポートが600pxだと1200.jpgが表示される
// またsizes属性で画像サイズを指定してます。800pxまでは100%、それ以降は1200pxで固定。
// つまり、1200.jpgに固定される。
&lt;img
    width="800"
    height="533"
    srcset="./images/1200.jpg 1200w, ./images/800.jpg 800w, ./images/400.jpg 400w"
    src="./images/800.jpg"
    sizes="(max-width: 800px) 100vw, 1200px"
    alt="..."
/&gt;

// SPとPCで画像を出し分ける（写真のトリミングが違う時や、バナーのデザインが違う時など）
// 上から順にマッチするかを判定し、マッチすればそれ以降は無視される
// 以下の例だと画面幅が450pxまではsp.png、700pxまではtb.png、それ以降はpc.pngが表示される
&lt;picture&gt;
  &lt;source media="(max-width: 450px)" srcset="img/sp.png" /&gt;
  &lt;source media="(max-width: 700px)" srcset="img/tb.png" /&gt;
  &lt;img width="1600" height="800" src="img/pc.png" alt="" /&gt;
&lt;/picture&gt;

// SPとPCで出し分けに対応した上で、デバイスピクセル比も対応する
&lt;picture&gt;
  &lt;source
    srcset="
      img/sp.jpg 1x,
      img/sp-2.jpg 2x"
    media="(max-width:450px)"&gt;
  &lt;img srcset="img/pc.jpg 1x, img/pc-2.jpg 2x" src="img/pc-2.jpg" alt=""&gt;
&lt;/picture&gt;

// webp対応
// webpに対応してればwebp、対応してないブラウザはxxx.jpg
&lt;picture&gt;
    &lt;source srcset="img/xxx.webp" type="image/webp" /&gt;
		&lt;img src="img/xxx.jpg" alt="" /&gt;
&lt;/picture&gt;</code></pre><h3 id="ha9bbe5012a">画像は何パターン用意したらいいか / どの指定がベストか</h3><p>デバイスの種類はかなり多く、全てに最適化するのは無理なので、そこまで神経質になる必要はない。<br><br>また、サイトによってはそもそも画像が少ない場合もあるので、そういうサイトで画像の最適化を頑張っても、大きな効果は得られません。対応パターンを増やせば増やすほど表示テストの手間も増えます。<br><br>案件ごとにサイトの特性や、要望、工数との兼ね合いでどこまで対応するか考えましょう。<br><br>必要であれば、アナリティクスでユーザー環境を調べたりして、どのサイズで対応するかを考えるのもあり。<br>Retina対応だけ考えたいなら以下の方法でいいんじゃないでしょうか。画像は2パターン。<br></p><pre><code>&lt;img
    srcset="500.png 1x, 1000.png 2x"
    src="1000.png"
    alt="..."
/&gt;</code></pre><h3 id="h72df4ec2e8"><br>ちなみに有名な技術ではどう指定されてる？</h3><pre><code>// WordPress
// メディアから投稿した画像は自動で数パターンのサイズで保存され、以下のように表示される
&lt;img
    loading="lazy"
    class="..."
    src=".../hoge.jpg"
    alt="..."
    width="1600" height="1000"
    srcset=".../xxx.jpg 1600w,
    .../xxx.jpg-300x200.jpg 300w,
    .../xxx.jpg-1024x682.jpg 1024w,
    .../xxx.jpg-768x512.jpg 768w,
    .../xxx.jpg-1536x1023.jpg 1536w"
    sizes="(max-width: 1600px) 100vw, 1600px"
&gt;

// Next.js
// next/imageを使うと、自動的に画像最適化を行ってくれる
&lt;img
	alt="..."
	src="xxx.jpg"
	decoding="async"
	style=""
	srcset="xxx.jpg 1x, xxx-2.jpg 2x"
&gt;</code></pre><h3 id="h0004d4afbb"><br>レイアウトシフト / CLS（Cumulative Layout Shift）</h3><p>レイアウトシフトは、サイトを開いた時に画像や動画が遅れて読み込まれ、レイアウトがずれる現象のこと<br>CLSはレイアウトシフトによるレイアウトのずれを定量化したもの。ページがどれぐらい安定しているかを表す。<br>画像だけでなく、webフォントや広告なども対策が必要<br></p><h4 id="h5cc9ebc1e8">レイアウトシフトが起こるとどうなるか</h4><ul><li>画像が遅れて表示したことで、読んでいた箇所を見失う</li><li>コンテンツがずれて、間違えてボタンを押してしまう</li></ul><p><br></p><h4 id="h5ca125aa6e">画像のレイアウトシフト対策方法</h4><p>imgタグにwidthとheightを設定する。CSSで <code>width: 100%; height: auto</code>など実際に表示したいサイズを設定する。CSSを指定することでimgタグのwidth/heightは上書きされる</p><pre><code>// 画像の実際の横と縦のサイズを指定する
&lt;img width="1000" height="500" src="img/xx.jpg" alt="" /&gt;

// 比率が重要なので、比率で指定してもOK
&lt;img width="2" height="1" src="img/xx.jpg" alt="" /&gt;</code></pre><p>ただし、上述の <code>picture</code>による画像の出し分けをする場合には注意が必要です。<br>縦横比が同じなら問題ないが、縦横比が異なる画像を出し分ける場合は、sourceにもwidth, heightを指定する</p><pre><code>&lt;div class="wrap"&gt;
	&lt;picture&gt;
    &lt;source media="(max-width: 450px)" srcset="img/sp.png" width="200" height="200" /&gt;
    &lt;source media="(max-width: 700px)" srcset="img/tb.png" width="1200" height="600" /&gt;
    &lt;img width="1600" height="800" src="img/pc.png" alt="" /&gt;
  &lt;/picture&gt;
&lt;/div&gt;</code></pre><h4 id="h79dac61fe9">レイアウトシフトの計測方法</h4><ul><li>Lighthouse</li><li>Chrome検証ツール</li></ul><p><br></p><h3 id="h7e25cef4d0">loading属性</h3><p>画像の読み込みを遅延するかどうかの属性<br>必要な画像から読み込みするので速度改善につながります<br>全てのimgに指定するのではなく、ファーストビュー以下の画像に指定するといい<br>safariは未対応<br>lazyを指定するとスクロールして画像に近づいた時に読み込みされます。画像が表示される領域に到達した時にはすでに表示されてるので目で確認はできませんが、chromeデベロッパーツールでNetworkタブに切り替えて、imgに絞ってみるとスクロールすると徐々に画像が読み込まれるのが分かります。</p><pre><code>// 遅延読み込みしない
&lt;img src="xxx.jpg" loading="eager" alt="" height="150" width="360"&gt;

// 遅延読み込みする
&lt;img src="xxx.jpg" loading="lazy" alt="" height="150" width="360"&gt;</code></pre><h3 id="h3548302656"><br>decoding属性</h3><p>loading属性はいつ読み込むかを指定するのに対して、decoding属性はいつデコードするかを指定する。デコードはデータから画像や映像を再生すること、要するに画像を描画することだと思います。<br>そのデコードを同期的にするか非同期的にするかを設定できます。</p><ul><li>同期処理：順番に処理をしていくこと。Aという処理をしている最中に、Bが開始するとAは中断される</li><li>非同期処理：平行して処理をすること。Aという処理をしてる最中に、Bが開始してもAはそのまま処理が続く</li></ul><p>autoもしくはsyncの場合、画像の描画が始まると他の処理が中断され、若干ページの表示速度に影響が出てくるかもしれません。<br>asyncにすることで、描画中も他の処理が平行して行われるため、表示速度改善が見込まれます。</p><pre><code>// 同期
&lt;img src="xxx.jpg" decoding="sync" alt="" height="150" width="360"&gt;

// 非同期
&lt;img src="xxx.jpg" decoding="async" alt="" height="150" width="360"&gt;

// 明示的に指定しない（デフォルト）
&lt;img src="xxx.jpg" decoding="auto" alt="" height="150" width="360"&gt;</code></pre><h3 id="hf374a8d5ec">loading / decording どう使うか</h3><ul><li>併用も可能（ただし、lazyによってデコードが遅れて、画像が表示されないということがあるらしいので注意が必要です）</li><li>ファーストビューには <code>decoding="async"</code>以降の画像はloading属性と併用というパターン</li><li>画像サイズが大きい場合lazyを指定すると表示が遅れる場合もあるらしいので、その場合は <code>loading="lazy"</code>は指定しない</li></ul><p><br></p><h2 id="h1afe451c43">さいごに</h2><p><br>imgタグだけ指定してればよかったですが、いろいろと指定方法が増えてたので改めて勉強になりました。</p>

フロントエンド・コーダーが知っておきたい画像の知識

<p>今までにWordPressでブログ作ったり、Hugoで作ったり、はてなやnoteで書いたりしてきましたが、Gatsby + microCMSで改めて始めようと思います。<br><br>更新頻度やアクセスは気にせず、技術のことについては自分用にまとめ記事、その他雑記で適当に書いていくつもりです。<br><br>はてなブログはまだ残してますが、Pro版の料金を払いたくなくなってきたので、そのうちやめようと思います。<br>いろいろ手を出してると、最終的には何かに一本化したくなります。<br><br>今後も技術の変遷はあると思いますが、今のところはGatsby + microCMSのJamstackなブログでやっていくのが運用的にも金銭的にもいいかなと思ってます。</p>

技術のことやその他いろいろ気になったことを書くブログを始めました。

Blog