- 投稿日：2021-11-29T23:16:23+09:00
Sassでの記述方法
Sassとは Sassとは、「Syntactically（文法的に） Awesome（イケてる・すごい） StyleSheet（スタイルシート）」の略で、CSSのメタ語です。（プリプロセッサと言われます） ※メタ語とはある言語についてなんらかの記述をするための言語で、特定のルールを加えて具体的な応用を可能にするものです。 要は「CSSを拡張して、文字通りイケてる書き方ができるようにしたもの」ということになります。 規模の大きいサイトを作成していくと、コードが複雑になり、スタイルの管理も難しくなるので、それを管理しやすくするためにSassが作られました。また、作業効率もあがると思います。 SassにはSASS記法とSCSS記法の２種類ありますが、主流はscssなのでこちらで説明していきます。 記述方法 今回使用するindex.html <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8" /> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> <meta http-equiv="X-UA-Compatible" content="ie=edge" /> <title>Document</title> <link rel="stylesheet" href="style.css" /> </head> <body> <!-- 変数 --> <h1>あいうえお</h1> <h2>かきくけこ</h2> <h3>さしすせそ</h3> <!-- ネスティング --> <div id="nest"> <p id="nestp1">たちつてと</p> <p id="nestp2">なにぬねの</p> <p id="nestp3">はひふへほ</p> <div> <!-- ミックスイン --> <div class="mixins1">まみむめも</div> <div class="mixins2">やゆよ</div> <!-- 継承 --> <p class="inheritance1">らりるれろ</p> <p class="inheritance2">わをん</p> </body> </html> ファイルについて CSSの場合ファイル名の拡張子は.cssでしたが、scssの場合、.scssとなります。 前回作成した、style.cssの拡張子を変更し、style.scssとします。 文法 基本的にcssと書き方は同じで、機能（文法）が追加されたと考えて良いです。 よく使う以下４つの文法を説明します。 ①変数 変数とは、プログラミング言語における「値を入れておく箱」のこと https://wa3.i-3-i.info/word1603.html 繰り返し使うような値を変数に格納しておけば、メンテナンス時に変更したい箇所が出て来た時に、少ない作業量で済みます。 $main-color: red; h1 { color: $main-color; } h2 { color: $main-color; } h3 { color: $main-color; } ②ネスティング（nesting） ネスティング（nesting）とは、入れ子にすること https://wa3.i-3-i.info/word1284.html #nest { #nestp1 { color: blue; } #nestp2 { color: green; } #nestp3 { color: orange; } } ③ミックスイン（mixins） 少し難易度高いですが、知っておくと便利です。 @mixinでコードの塊を作成し、別の場所でそれを呼び出すことができます。 以下は「hoge」という「mixin」を作成し、それを「.mixins1」、「.mixins2」で呼び出しています。 @mixin hoge($color: black, $fSize: 10px) { color: $color; font-size: $fSize; } .mixins1 { @include hoge(red, 20px); } .mixins2 { @include hoge(); } ④継承（inheritance） 継承とは、元ネタから要素を受け継いで、元ネタの特徴を備えた新しいのを作ること https://wa3.i-3-i.info/word1202.html こちらも難易度高めですが、知っておくと便利です。 %test-sharedでスタイルを指定し、「.inheritance1」や「.inheritance2」の@extend %test-shared;のコードにて%test-sharedで指定したスタイルを継承しています。 %test-shared { border: 1px solid #ccc; padding: 10px; color: black; } .inheritance1 { @extend %test-shared; } .inheritance2 { @extend %test-shared; border-color: red; } 使用方法 scssファイルはそのままでは使用できず、cssファイルに戻す（コンパイルする）必要があります。 それを自動で実施してくれるツールがあるので紹介します。 Live Sass Compiler https://marketplace.visualstudio.com/items?itemName=ritwickdey.live-sass 上記をVSCodeでインストールした後、画面下部にWatch Sassと表示されるのでそれをクリック。 すると自動で、scssファイルをコンパイルしてcssファイルに変換してくれます。 scssファイルを編集しても、保存すると同時にcssファイルも自動で反映してくれるので便利です。 参考 https://digitalidentity.co.jp/blog/creative/css-sass.html https://www.fenet.jp/dotnet/column/tool/5245/#SCSSとは何か https://wa3.i-3-i.info
- 投稿日：2021-11-29T15:42:37+09:00
食べログ スマートフォンページのCSSを最適化してLCP改善にトライ！
この記事は食べログアドベントカレンダー2021の2日目の記事です 12/2(木) 担当、食べログWEBデザイナーの @mamiyan です。 食べログに入社してあっという間に4年目になり、頑張って先輩らしく振る舞っています...！ この記事では、今年の6月頃に取り組んだ、食べログのスマートフォンサイト（以下、SPと略します）のうち、店舗詳細TOPページのCSSファイル最適化についてLCPに触れながらまとめていきます。 ▼食べログの店舗詳細TOPページ（例：プレミアムプラン） 1.なぜCSSファイルを最適化する必要があったのか CSSファイルの肥大化 一部のCSSファイルの二重読み込み問題 PageSpeed Insightsでパフォーマンスの悪さが目立っていた 長期運用されている大規模サービスならではの悩みかもしれませんが、多くの方が同一ファイルを修正しているので、一定ルールのもと適切にメンテナンスを行っていても歴史とともに肥大化していきます。 肥大化したCSSはブラウザのレンダリングパフォーマンスに悪影響を与えます。またコアウェブバイタル（Core Web Vitals）がGoogle検索のランキング要因に組み込まれると囁かれたタイミングで見過ごせませんでした。 さらにはGoogleのパフォーマンス計測サイトであるPageSpeed Insightsでパフォーマンスが悪目立ちしていたので、重い腰を上げて取り組みました。 なお、コアウェブバイタルやLCPについての詳しい説明は以下の引用にて省略とさせてください。 コアウェブバイタルとは？ Core Web Vitals は、Web 上で実際にユーザーが体験するユーザー エクスペリエンスに関する重要な観点の測定を目的とした一連のフィールド指標です。Core Web Vitals には指標と各指標のターゲットとなるしきい値が含まれており、これらを参考にすることで、運営するサイトでのユーザー体験が "良い"、"改善が必要"、"悪い" のいずれの状態にあるかを開発者が定性的に理解できるようになります。 引用：web.dev 2020 年時点で Core Web Vitals は、Largest Contentful Paint (最大視覚コンテンツの表示時間、LCP)、First Input Delay (初回入力までの遅延時間、FID)、Cumulative Layout Shift (累積レイアウト シフト数、CLS) という 3 つの指標により構成されています。それぞれの指標は、ユーザー エクスペリエンスに関する様々な観点を測定します。 引用：web.dev LCPとは Largest Contentful Paint (LCP) 指標は、ビューポート内に表示される最も大きい画像またはテキスト ブロックのレンダリング時間を、ページの初期読み込み開始タイミングと比較してレポートします。 引用：web.dev 2. 効果は？ 取り組み内容を紹介する前に、効果について触れておきます。 CSSやdocumentのファイルサイズを537KBと大幅に削減しました！ ここまで大きなダイエットが見込めると思っていなかったので嬉しかったです。 対象ページ：https://s.tabelog.com/tokyo/A1303/A130301/13238724/ Type ファイル名 Before After CSS application_inline.css 13.1KB 0 CSS rstdtl_common.css 27.2KB 0 CSS rstdtl_top.css 19.3KB 0 CSS rstdtl_async.css 50.5KB 0 CSS rstdtl_common_async.css 52.5KB 0 CSS rstdtl_top_async.css 0 56KB document 13238724/ (rstdtl_top_inline.css含む) 519KB 88.3KB 合計 681.6KB 144.3KB 2-1. Lighthouseで効果を確認する ChromeのデベロッパーツールにあるLighthouseではLCPが0.6s改善されているように見えます。 ただ計測タイミング（時間帯？）によって大きくぶれる傾向があるのでなんとも言えません。 2-2. PageSpeed Insights で効果を確認する リリースして3週間後にPageSpeed Insightsで比較しましたが、LCPの数値に改善は見られませんでした。 Origin Summaryは28日間の収集期間なので1週間弱足りていないのですが、残りの数日でも変化は見られませんでした。 あまり効果はなかった、、、？ Before（2021/6/30 11時ごろ） After（2021/7/19 16時ごろ） 2-2-1. 「使用していないCSSの削減」項目に効果あり とはいえ、PageSpeed Insightsの「改善できる項目」で指摘内容に変化が見られました。 以下、LCPの変化をご覧ください。 LCPの変化 狙い通り、CSSの最適化を行ったので 使用していないCSSの削減 という指摘項目で0.6sほど改善できました。 2-2-2. 「レンダリングを妨げるリソースの除外」項目に効果あり ちなみに、レンダリングを妨げるリソースの除外では3つのCSSファイルが指摘されていました（下記画像の青の下線3つ）。 この対処方法として、「インラインCSS」と「遅延読み込みCSS」に区分けしてレンダリングのブロッキングを回避する手法を取りました。狙い通り、指摘項目からCSSファイルがなくなっていることを確認できました。 ※指摘されていたCSSファイルがない 紛らわしいのですが、application_inline.cssはインラインという名前がついていますが実際にはインライン読み込みされておりませんでした。そのためレンダリングの妨げとなっていたようです。 3.やったこと 上記の2で対応についても軽く触れていますが、まとめると以下です。 使用していないルールセットの削除 重複しているルールセットの削除 ファーストビューで使用しているルールセットの抽出 ファーストビューのCSSはインライン読み込み ファーストビュー以外のCSSは非同期読み込み（遅延） 店舗詳細TOPに関しては分岐条件が多くデザイナーだけで全容を把握するのは困難だった為、エンジニアさんとフロントエンドエンジニアさんに協力を仰ぎ汎用モジュールの使用可否を調査しました。 リストアップした汎用モジュールを三者で睨めっこして、1.5hほどチャットツールで通話しながら調査しました。 最終的には、呼び出していた5つのCSSファイルを2つに集約。 ファーストビューで使用するCSSは rstdtl_top_inlineにまとめ、それ以外を rstdtl_top_asyncと区分けしました。 この対応により、レンダリングのブロッキング回避に貢献しています。 4.PageSpeed Insightsを見れば、コアウェブバイタルの各種数値を改善できる項目が分かる 短縮できるおおよその時間がご丁寧にもPageSpeed Insightsで "改善ポイント"と "短縮できる推定時間" のセットで提示してくれています。なので、LCPの数値が遅い！何をやればいいんだ？となったとき、真っ先にここを見れば疑問が解決できます。 例：SP店舗詳細トップのURLでチェックした改善ポイント このうちデザイナーができるCSS周りの対処方法は青の下線の2つです レンダリングを妨げるリソースの除外 詳細：ページの First Paint をリソースがブロックしています。重要な JavaScript や CSS はインラインで配信し、それ以外の JavaScript やスタイルはすべて遅らせることをご検討ください。 使用していないCSSの削減 詳細：スタイルシートから使用していないルールを削除して、スクロールせずに見える範囲のコンテンツで使用されていない CSS の読み込みを遅らせると、ネットワークの通信量を減らすことができます。 要約すると、「不要なCSSを削除して、ファーストビューのCSSはインラインで配信してください」と解釈できます。 この改善ポイントですが、実はFCPも同じような提案がされています。 つまり、この2つの改善ポイントの対策を行ったらLCPとFCPの両方を改善できるということになります。 これらのCSSの対策を行うとLCP/FCPの両方の対策ができるので、一石二鳥ですね。 5. まとめ 指摘されていたCSSの改善ポイントに対して、概ね解消できることはやり切りました。 しかし目に見えるほどの大きなリターンが得られるわけでもありませんでした。 労力に見合わない作業であっても、結果的にユーザビリティに寄与できるのであれば、積極的に取り入れていきたいと思っています。 そのほかLCPの指摘項目に目をやると使用していないJavascriptの削減が目立っており、短縮できる推定時間は4.92sとなっております。 一番効果の見込めそうなところから着手するのがセオリーですが、フロントエンドエンジニアさんに伺ったところcommon.jsに関してはリプレイスのタイミングで対処予定とのことでした。 ※新しい実装方法は Atomic Design+styled-componentsを採用 あとは広告のJSも積み重なって影響しているのでそちらも監視しておくと良さそうです。 以上、「食べログ スマートフォンページのCSSを最適化してLCP改善にトライ！」でした 明日はエンジニア @sudomeg さんの「作る人にも使う人にも嬉しいMVPをやってみた 〜実用最小限の見つけ方〜」です。お楽しみに！
- 投稿日：2021-11-29T13:36:10+09:00
flexboxについての何か
CSSのFlexboxを適用すると思うような表示が出来ず表示が崩れる事が多々あると思います。 そんな時は「display:flex」直下の子要素として＜div＞や＜span＞等で囲うと高確率で直ったりしますので一度お試しあれ。
- 投稿日：2021-11-29T11:32:02+09:00
期間限定でCSSを切り替える ~社内で大不評の【誰得？】シリーズ~
パーソンリンク アドベントカレンダー16日目です！? 内容 <link id="StyleSheetFilePath" rel="stylesheet" href="base.css" /> <script> window.onload = function() { var nowDate = new Date(); var startDate = new Date('2021/12/24 0:00:00'); var endDate = new Date('2021/12/25 23:59:59'); if ( startDate < nowDate && nowDate < endDate ) { var styleSheetFilePathElement = document.getElementById("StyleSheetFilePath"); styleSheetFilePathElement.href = "xmas.css"; } } </script> クリスマス限定でCSSを切り替えたいのであればこれでいけるはず。 （試してないので多分としか言いようがないけど。。。） JavaScriptで日付とかは持たない方がいいけどね。PCの時間変えられたら意味ないので。。。 なにこのシリーズ 社内で不評なたまに呟く「誰の得になるの！？」シリーズです。 さようならー