WP最新テーマ アピールポイント スマホアプリ風カテゴリートップ・WebP・JSON-LD・4K-DPR-レスポンシブ

モバイル
ファースト

Webサイト、テンプレート、WordPressテーマなど、これらの歴史はデスクトップオンリーからスマートフォンにも対応程度、大画面・小画面切り替えがレスポンシブと勘違い

モバイルファーストの対象は、Googleのインデックスなのか、スマートフォンデバイスなのか、スマートフォンユーザーなのか

モバイルファーストのモダンWeb"あるべき姿"をWP最新テーマで実現

デスクトップ内
レスポンシブ

新テーマのデスクトップは、1カラム2カラム3カラム、またシェアボタンバー、サイドバーstickyなど 自由自在レイアウト

ユーザーのディスプレイやブラウザー横幅によって、コンテンツ箇所サイズが左右に伸縮するので、画像を含む横並びコンテンツなどはビジュアル崩れを起こさないように、TPOに応じたサイズ変更の最適化

デスクトップ インディでモダンWebはゆるがない

モバイルファーストのターゲット

Googleのインデックス

Googleのインデックスがターゲットなら、スマートフォン縦画面のHTMLソースが重要
小画面に合わせるために「display:none」を使ってしまわないように
HTMLソースには書き出さないことが肝要

スマートフォンデバイス

スマートフォンデバイスがターゲットなら、通信環境や機器スペックに配慮して、重く遅くならない工夫を
盲点として、DPR(Device Pixel Ratio:デバイスピクセル比)も重要
デスクトップ(DPR1)で横並び3カラムでスマートフォン(DPR3)縦画面で縦並び1カラムなら、読み込まれ表示される画像ファイルは、デスクトップでは幅600pxくらいで十分でも、スマートフォンでは1200pxくらいでないと画像がぼやける
4K・Retina・DPR:2-3対応のレスポンシブが要求される

PageSpeed Insightsの「適切なサイズの画像」で警告されるのは、画像のサイズでもKBの容量よりもPXの幅に注意、幅は大きすぎても小さすぎてもダメ出しされる

スマートフォンユーザー

スマートフォンユーザーがターゲットなら、デスクトップの画面を縮小するのではなく
Googleが目を光らせるリンク、モバイルでは「タップターゲット」のサイズや間隔に配慮
タップとは指で触れること、つまり指の大きさに合わせて大きく他との隙間も空けること

モバイルファーストの解釈 ~ 4K-DPR3-レスポンシブイメージ

モバイルファーストといえば、(A)のGoogleインデックスが語られることが多い
(B)のデバイスもスピード重視は力説されているが、DPRを踏まえたDPR:1デスクトップ1000pxよりDPR:3モバイル350pxのほうが大きい画像が表示されるべきことが語られることはほとんど無い

(C)についても、デスクトップのマウスクリックではなく指で触ることを忘れて、「タップ ターゲットのサイズが適切に設定されていません」と警告されているサイト・ページが非常に多い

WordPressでは、メディアを追加で投稿記事内に挿入される画像は、自動的に4Kレスポンシブとなって、(B)はそのままクリアできる
ただサムネイル(アイキャッチ)のあつかいでは、4K・Retina・DPR:2-3対応どころか、レスポンシブになるかならないかは「テーマ次第」

モバイルフレンドリー

おそろしいほどモバイルのマグナカルタを造りあげようとしているGoogle
モバイルフレンドリーのWebサイト・ページを高評価するよりも、モバイルフレンドリーでないページを低評価にするような「モバイル フレンドリー アップデート」

レガシーWeb vs モダンWeb

レガシーWebとは

レガシーWebの有様とは、デスクトップファーストで作成したWebサイトを、なんとかスマートフォンでレイアウトやデザインが崩れないように突貫工事でしのいでいるだけ

table、float、position(relative/absolute)による位置決めが特徴だろう
最大の弱点、難点、欠点は、レイアウト/デザインのためにmargin・padding・width・heightや、positionのtop・bottom・left・rightなどの数値を細かく設定していること

そのため、メディアクエリもブレイクポイントごとに数値設定を積み重ねしなければならず、スマートフォンの縦画面だけでも320から400以上と複数あって新機種も次々登場、そのたびに数値の書き直し/書き加えが必要になる

さらにビューポート幅・デバイス幅・ウインドウ幅のバリエーションが多いデスクトップ画面にいたっては、サイドバーなどはfloatなら数値決めが必須、さらにボディ幅・コンテナー幅・コンテンツ幅も、950とか1000とか数値を決めて、レイアウト/デザイン崩れを回避することになる

モダンWebとは

些細なポイントとしては%・vwなどをベースに横幅はリアルタイムのレスポンシブ、もちろんモバイル・スマートフォン縦画面できっちり/はっきり表示されていること

デスクトップの全画面表示(1920あたりでも)では、コンテンツ幅は数値決めされていても、ヘッダーやフッター、サイドバーなどが違和感なく表示されていること

デスクトップ インディは
デスクトップ インディペンデンス

デスクトップ インディ

スマートフォン・タブレット・デスクトップのレスポンシブは、CSSのメディアクエリで達成可能
WP最新テーマでは、ブレイクポイントは「600 960」
600以下はスマートフォン縦画面、601以上はスマートフォン横画面
かつ一応、タブレット縦画面を含むがブレイクポイントの960では、後述のように1024以下のデスクトップ ブレイクポイントが地雷になる可能性あり

ところで、デスクトップのデバイス・ディスプレイ・ブラウザーは、横幅がいろいろ、目安としては1080~1920までで、見るにたえうるレイアウト/デザインが望ましい

そこで、デスクトップ画面は、インディペンデンスつまり独立したものと捉えて、スマートフォン対応だけでなくデスクトップ ブラウザーの様々な横幅サイズにも対応する、これがデスクトップ インディのコンセプトであり、デスクトップ内レスポンシブがモダンWebの神髄とも言いたい

デスクトップ インディはタブレットも

じつは、スマートフォンとデスクトップの中間であるタブレットが泣き所となり、タブレット縦画面の1024が、はみ出しなど地雷になることも多い

タブレットは、デバイスとしてはモバイルに含まれるが、画面サイズとしてはデスクトップに近い
実機があればそれで表示確認、デベロッパーツールでiPad Pro(12.9-inch)の1024・DPR:2で表示確認して、レイアウト/デザインが崩れない、画像がぼやけず最適のサイズが表示されていることを確認するべきだろう

タブレット画面をターゲットにするものの、デスクトップのブレイクポイントで950や1000を設定していても、経験則として1024や1040でレイアウト/デザインが崩れることもあるので、これに対応するのもデスクトップ インディに含めたい
つまり、デスクトップのブレイクポイントが、たとえば960と設定している場合は、1024~1080などのレイアウト/デザイン崩れがないか、確認をおすすめする

 

HTML Living Standard
CSS3適応

ポリシーのあるsectionコーディングと、見出しタグ(h2以下)の使い方を提示して、コンテンツ作成のガイドラインを提示

clamp calc :not() :is() vw、[属性]やカスタムプロパティ、details/summaryを使い、CSS3ならではのデザインと省ソースでレスポンシブを実現

grid flexboxで縦並び/横並び自在
見出し/テキスト優先

gridやflexboxも2重3重の入れ子で、HTMLのSEO最善コーディングをベースに、横スクロール仕掛けなどでベターなUI/UXでビジュアルSEO!
ベーシックなコンテンツブロックは、複数のclass活用で瞬時にビジュアル変更

HTML Living Standard 適応

なぜHTML Living Standardをアピールするのか?

W3C策定のHTML5・HTML5.1・HTML5.2があって
これを廃棄して、WHATWGのHTML Living Standardが標準仕様になっている

経緯やら詳細やらはすっ飛ばして、今のブラウザー(モダン ブラウザー)が相手にしているのは、HTML5xではないということだけ覚えておきたい
モダン ブラウザーとは、最新版のGoogle Chrome、Mozilla Firefox、Apple Safari、Opera、そしてMicrosoftのEdge(ChromeのBlink採用)とほぼすべて

モダン ブラウザーで無難に表示されているならHTML Living Standard 適応

Web作成側が「HTML Living Standard 適応」と叫ばなくても、ブラウザーで無事表示されているなら無問題
そもそもHTML Living StandardはHTML5から劇的に変更されているわけでもない

Webの標準仕様では、廃止された要素・属性を使っている場合に注意

CSS3 適応

とにかく、clamp calc :not() :is() などは超便利
gridやflexboxも、floatやらpositionやら今までのレイアウト定番から解放されて呼吸が楽になる

body要素内のCSSは

とはいうものの、新テーマでは一部でCSS(<style>)をbody要素内に書きだしていて、よろしくない…
なぜなら、W3CのHTML5.2ではbody内<style>は許容されたものの、HTML Living Standardでは配置できないと

ところでHTML Living StandardのDOCTYPE宣言は「<!DOCTYPE html>」で、W3CのHTML5#も同じ「<!DOCTYPE html>
ブラウザーはHTML Living StandardとHTML5#とが混在しても両方通用するというかもしれない

ともあれ、PageSpeed Insights数値向上策として、「重要な JavaScript や CSS はインラインで配信し、それ以外の JavaScript やスタイルはすべて遅らせること」を検討した結果の所業で様子見中

「使用していない CSS の削減」「CSS の最小化」などは、squarechange_historyからcircleに改善しているので、結果オーライか…

 

スマートフォンアプリ
ビジュアル再現

gridやflexboxのレイアウトで、スマートフォンアプリのような、人気サイトのようなアーカイブトップの表示を再現

スマホアプリ模倣のスタイルは、アーカイブトップと連動して関連ページでも

linkアーカイブトップは人気スマホアプリのビジュアル仕様で6タイプ

ビジュアル スタイルは6種類

ZOZOTOWN型スタイル、メルカリ型スタイル、Instagram型スタイル、およびYahooニュース/不動産紹介スタイル

スタンダード(標準型)スタイルは「ブログスタイル」、さらに「theブログ レガシースタイル」もあり

 

画像が縦横にびっしり並ぶInstagram型
画像がびっしりに短メッセージ上乗せのメルカリ型
画像と下にメッセージのZOZOTOWN型
画像と右にメッセージのYahooニュース型(不動産紹介型)

 

スマホアプリのスタイル/レイアウト/デザイン

すぐ上の画像4つ並んでいるのカテゴリートップのビジュアルスタイルは、左上から

Instagram型スタイル

gridレイアウトで画像が横3列、縦は何行でも
Instagram型スタイルといっても用途は画像SNSではなく、下記メルカリ型のメッセージ無し版、サムネイルの訴求力があれば画像リンクのナビゲーションに

メルカリ型スタイル

gridレイアウトで横3列、2列4列も設定次第
デスクトップファーストのヤフオクサイトを凌駕するモバイルファーストのメルカリサイト
画像と短テキストメッセージで魅力をアピール
小画面のスマートフォンに特化した今風のスマホアプリのスタイルを再現

ZOZOTOWN型スタイル

本家ZOZOTOWNはスマートフォンでは横3列、テーマではgridレイアウトで横2・3・4列に
これも今どきの商品多数のECサイトまたスマホアプリ画面
画像と下の短テキストメッセージで商品ページへお誘い

Yahooニュース型スタイル

画像左でテキスト右、個別ページへ誘導
一目瞭然のサムネイルと魅力のタイトルテキストで紹介パターン採用

ユーザーが馴染んでいるスマホ画面のスタイル/レイアウト/デザイン

上記4スタイルのアーカイブトップは、モバイルファースト、モバイルオンリーのユーザーが見慣れたスマホアプリ画面やUI/UXを再現して、単なるレスポンシブのWebスマホ画面から脱皮しよう!

 

画像左にメッセージ右のスタンダード型
タイトル上 画像左と抜粋やページ情報右のレガシーtheブログ型

スタンダート型スタイル / レガシーtheブログ型スタイル

スタンダード型は画像左メッセージが右、moreボタン付き

レガシーtheブログ型は、タイトルが上、その下に画像が左でテキスト系が右、抜粋・日付・カテゴリー・タグ、カスタムフィールドの短テキスト、およびmoreボタンと、お馴染みのtheブログスタイル

インフィードのAdSense

6スタイルそれぞれにフィットするAdSenseのインフィード広告が表示されて、アフィリエイトサイトにも最適

 

WebP採用

WebPはプラグインのヘルプ

所定のサイズのJPGやPNGをアップロードして、EWWW Image OptimizerがWebP変換、かつ4Kレスポンシブに
もちろんプラグイン無しならWebP無し、それでも4Kレスポンシブは外さない

画質維持と画像サイズダウン

WebP採用は、Google主導の画像サイズダウンが目的
ただしJPGは画質劣化のリスクあり、PNGもサイズアップのケースあり
Googleはじめ他情報を鵜呑みにしないで、自分で検証が大事

WebP変換かつサムネイルのレスポンシブイメージ対応

WordPressならEWWW Image Optimizerなどのプラグイン導入で、WebPは対応可能

WordPressのサムネイルはモダンレスポンシブにはならない

ただしコンテンツ箇所での「メディアを追加」で画像はレスポンシブイメージのWebP変換が達成できるものの、サムネイルは<?php the_post_thumbnail(); ?>のコードでは、同一画像ファイルが読み込まれるだけでCSSで同一画像ファイルを伸縮させるプリミティブのレスポンシブWebデザイン(レガシーレスポンシブ)となるだけで、後述の4K・Retina・DPR 2・DPR 3対応のレスポンシブイメージにはならない

WPサムネイルの4K(Retina)・DPR 2・3対応のレスポンシブイメージを実現

画像重視、サムネイル活用のWordPressテーマとしては、そのままでは扱いづらいサムネイルを、特別なコーディングで「4K(Retina)・DPR 2・3対応のレスポンシブイメージ対応のレスポンシブイメージ(モダンレスポンシブ)」を実現している

JSON-LD
導入
自動/手動で
書き出し

構造化データの組み込み、JSON-LDをhead(場合によってはbody最下部)に、自動や手動で書き出し

JSON-LD
ファイル
テンプレート
用意

breadcrumb、article、website、organization、local-business、faq、および event、product などの自動生成またはユーザー記入用テンプレートを用意

JSON-LDは無いより有ったほうがいい !?

JSON-LDはコーディングが面倒臭い、かつSEOとして必須でも有利でもない

自動もしくはほぼ自動

そこで、個別投稿は自動でパンくずリスト(breadcrumb)、出力チェックだけのほぼ自動で記事(article)を出力
このページのソースをご覧いただきたい

管理画面と個別投稿または固定ページの編集画面で入力のJSON-LD

組織情報(organization)、店舗情報(local-business)、商品情報(product)は、管理画面および個別投稿または固定ページの編集画面で入力して出力

個別投稿または固定ページの編集画面ですべて入力のJSON-LD

FAQ(faq)、イベント(event)は、個別投稿または固定ページの編集画面で随時入力して出力

 

マテリアル デザイン
マテリアル アイコン
マテリアル カラー

スマホアプリでGoogleが推奨/主導するマテリアルデザインを推進

GoogleアイコンのMaterial Symbols and Icons をセルフホストとして組み込み
マテリアル カラーを含む30のカラーセットでハイセンスの着せ替えも

マテリアル デザインは
各種シャドウと
最適タップ ターゲット

マテリアル立体感を演出する box-shadow・text-shadow・filterなどをTPOに応じて効果的に使用
外側の影で浮き上がり、内側の影で盛り上がり

リンクやボタンなどは「タップ ターゲット」、GoogleのPageSpeed Insights SEOでチェックして適切なサイズとスペースで

マテリアル デザイン(Material Design)

モバイルファーストのWebページの望ましいビジュアルとして

マテリアル アイコン

スマートフォン画面で分かりやすいシンボルを

linkGoogle Material Icons Googleアイコン(GMI) セルフホスト(self-host)

linkGoogle Material Symbols Googleアイコン(GMS) セルフホスト(self-host)

Material Symbols and IconsやAwesomeなどのWebアイコンはフォント、さらにSVGはベクター形式、4K・Retina・DPR 2・DPR 3などの高解像度ディスプレイでもぼやけない、モダンレスポンシブ対応なのでクール

マテリアル カラー

スマートフォン画面で分かりやすい色づかい

linkカラーセット マテリアルカラー16+1 レジェンドカラー14 着せ替え

上記を参考に、下記のパレットを利用

 

4K DPR 3
レスポンシブ
イメージ対策

4K(Apple製品はRetina)にデフォルトで対応
2Kは普通サイズ、4Kは普通サイズ縦横2倍の画像、さらにレスポンシブにするという特殊なコーディングを発明(笑)

サムネイルは1280px
コンテンツは3840px

コンテンツの画像は、最低3840pxでWordPressが自動的に4Kレスポンシブに
サムネイルは最低1280pxでやはり自動的に4Kレスポンシブになるコーディングを開発

画像の2とおりのレスポンシブ

レスポンシブWebデザイン(レガシーレスポンシブ)

同一サイズの同一画像ファイルをCSSで伸縮させるのが、レスポンシブWebデザイン(レガシーレスポンシブ)
画像はCSSwidth:100% height:auto、ボックスのwidthで伸縮させる

レスポンシブイメージ(モダンレスポンシブ)

これに対して複数サイズの複数画像ファイルをビューポート(もしくはボックスサイズ)のDPRに合わせて最適な画像ファイルを、ブラウザーが選択表示するのがレスポンシブイメージ(モダンレスポンシブ)
HTMLpicture / srcset 記述子(w)で最適画像ファイルを選択する仕組み

表示スピードを追求するなら

Webページの表示スピード、PageSpeed Insightsの3悪は、CSS・JavaScript・画像
画像はサイズ(容量)が少ないほど、横縦の幅が小さいほど、軽く速く表示される

画質を追求するなら

小画面のスマートフォンのデビューで、レガシーWebはデスクトップ大・タブレット中・スマホ小の画像表示に取り組む

ところがAppleのiPhoneがRetina、DPR 2やDPR 3のディスプレイがサプライズされてDPR 2なら横縦2倍、DPR 3なら横縦3倍の画像でくっきり・はっきり表示されることになる
DPRが大きくなるほど、高解像度になるほど、画質のためには大きい画像が要求され、そのままでは重く遅くなるはめに…

スピードと画質の両立ならレスポンシブイメージ(モダンレスポンシブ)がベストの選択

デスクトップは高スペックなので、じつは画像表示はレガシーでもモダンでも問題なし
高画質で大容量の画像を、できるだけ軽く速く表示させる可能性があるのがレスポンシブイメージ
つまり、レスポンシブイメージこそ、モバイルファーストのWebサイトの証明でもある

モダンもレガシーもレスポンシブなしも有りか !?

なお、画像や画質にこだわりがないが無ければ、ビジュアル貧者のサイトなら、レスポンシブイメージは無用だろう
逆に、ビジュアル富者であれば、同じようにどんな場面でも高画質で大容量の画像だけを置けばいいかもしれない

つまり、スマートフォンユーザーを無視、モバイルファーストの否定であれば、レガシーでもモダンでもレスポンシブは不要
無視・否定ではなく、突き詰めず深刻視せずにユーザーやデバイスをスルーするのであれば、レガシーのレスポンシブWebデザインでOKでしょ

 

gridレイアウト

gridレイアウトで、HTMLがより(SEO的に)理想的なブロック順のコーディングを実現
ソースはどこにあっても表示は上に下に右に左に、重要コードは必ず上に
デスクトップならサイドバー配置で12パターンのレイアウト

linkgridレイアウト カラム数・サイドバー位置 12パターン

flexboxコンテンツ デザイン

flexbox(grid)で、縦並び/横並び/スクロール
メディアクエリも、省コードで複雑なソースなし
スマートフォン・タブレット・デスクトップでカラム数が変わり幅が変わる
CSSテンプレートで思い通りに

このサイトはgridとflexboxでできている

HTMLソースの順番を入れ替え表示するgridやflexbox

このサイトは、gridレイアウトとflexboxデザインを知らなければ、できあがらなかっただろう

デスクトップのサイドバーを含む、ヘッダー箇所やフッター箇所、もろもろ、WordPress最新テーマ装備のgridレイアウトで実現
しかもclassの追加/書き換えで瞬時にレイアウトを変更できる

サイト全体、カテゴリーごと、タグごと、カテゴリー個別、タグ個別、そして固定ページ・個別投稿の一括と個別、レイアウト変更が簡単にできる

gridは大レイアウトも小レイアウトも

gridアイテムの横並び、折り返し、横スクロールなど、レイアウトは自由自在
また個別のアイテムも、上部は横いっぱい、その他下に中部左と中部右を横並び、また下部左・下部中・下部右を横並びと、行と列のレイアウトも自由自在

gridはCSS製なので、メディアクエリとも相性がいいので、デスクトップ・タブレット・スマホで、行と列の入れ替えなど好き勝手なレイアウトが可能

flexboxはアイテムのデザイン

flexboxは、gridと同じようにflexアイテムの行と列のレイアウトも可能
どちらかというと、アイテムのHTMLコーディングで上中下の入れ替えや並び順の変更、左右配置と逆配置など個々のコンテンツのデザインが得意

gridとflexboxが連携・合体すると最強のWebサイトに仕上がったりする

レガシーWeb

レガシーWebの代表は、floatやpositionの relative / absolute など

レスポンシブにすると、モバイル一括で設定できず、たとえばpositionはスマートフォンの画面幅、320・375・430など一定ではないので、left:30pxなどと設定すると痛い目にあう
floatもどこかのブレイクポイントで解除したり、floatサイドバーはコンテンツ箇所の横に回り込むが、画面幅に合わせることも難儀する

ただし、レガシーにはレガシーのよさもあり、枯れているというか安定した実績があるというか、とくに緻密な位置決めは position relative / absolute は重宝している

 

PageSpeed Insights数値向上策

PageSpeed Insightsの数値を低下させる、重く遅くする三悪は、CSS・JavaScript・画像
その三悪対策としては、削除、削減、圧縮、キャッシュ

CSS・JavaScriptの圧縮は、改行やコメントを削除して1行にする、複数のCSS・JavaScriptを1つにまとめること
さらにサーバーサイドでのgzip・brotliなどでの圧縮

画像の圧縮は、容量や大きさなどのサイズダウン、jpg・pngなどをWebPに変換

Googleサービスのほとんどが
PageSpeed Insights
数値低下の原因

reCAPTCHAは、CSS・JavaScriptに加えてGoogleフォントまで、かなりのスピード低下のリスクとなる
セキュリティ対策としては益少なく害多いので、他の軽く速いツールや方法を選択するべき

AdSenseは、JavaScriptでできている !?、コードも膨大なので、スピード低下がはなはだしい
せっかくPageSpeed Insightsを持っているのだから、AdSenseも軽く速くするブラッシュアップを期待したい




PageSpeed Insights数値向上策は
CSS/JavaScript/画像の三悪対策

CSSとJavaScriptをインライン化

HTML(DOM)のレンダリング中に、CSSやJavaScriptを読み込むとレンダリングがストップする
とくにファーストビューのところは、CSSは分離してクリティカルCSSとして処理
JavaScriptは、ほとんどをPHPの中に格納してインラインで読み込み
functions.phpやプラグインなどの設定で、CSSやJavaScriptの遅延読み込みも

CSSはデバイス別に分離

とくにモバイルファーストとして、デスクトップ用のCSSは分離してスマートフォンでは読み込まないようにしている

HTMLソースもデバイス別に分離

CSSのdisplay:noneは絶対のタブー、PHPの上流でデバイス別にHTMLソースを振り分け/読み込みを設定
サイドバーなどもスマートフォン・タブレット・デスクトップで別々のソースを読み込んでいる

画像のレスポンシブイメージと遅延読み込み

WebP変換を含め、遅延読み込みなどは、EWWW Image Optimizerプラグインのヘルプによるもの
レガシーの画像のレスポンシブWebデザインでは、同一画像ファイルを伸び縮みさせているだけで、重く遅くなる原因となりかねない
モダンのレスポンシブイメージでは、picture srcset 記述子(w)によって、モダンブラウザーはTPOに応じた画像ファイルを選択して他の画像ファイルは無視する
つまりHTMLソースの画像コードは膨大でも、ブラウザーが取捨選択するので、軽く速くなるはず
WebP変換に遅延読み込み、さらにはwidth / heightがない画像ソースに付け足してくれるので、モダンブラウザーのレスポンシブ表示に大きく貢献してくれる

PageSpeed Insightsのバグ !?

PageSpeed Insightsは「Moto G4 画面は360 x 640 px 画質/デバイスピクセル比は DPR 3」をベースにしているらしいが、これをChromeやFirefoxのデベロッパーツールで端末設定して確認しても、それとPageSpeed Insightsが「適切なサイズの画像」の警告で示す画像サイズが違っていることが多い
さらには、Moto G4の縦画面の横幅は「360px」で「DPR:3」なので、全画面表示画像の横幅は「360 x 3 = 1080」、これで1040の画像が表示されていても、もっと小さいものを、とクレームが…
苦心惨憺のレスポンシブイメージ コーディングも、否定されて腹が立つ!

Moto G4 360 DPR:3 1040px画像がダメ出し

PageSpeed Insightsの数値向上策も、とことん付き合うと、Webサイトが貧相になり、そもそもピントが狂っている警告もあるので、ほどほどにしておきたい

ただし、PageSpeed Insightsには、速度の「パフォーマンス」だけでなく、「ユーザー補助」「おすすめの方法」「SEO」があって、こちらはなるほどと思う指摘も多く、Webサイト作成の重要な指針ともなるので、ほとんど「100」になるようにはしている