#Handsumとは何か？LQIPをさらに軽量にした超軽量プレースホルダー画像フォーマット #七12

7月 12, 2026

Handsum は、従来の LQIP（Low-Quality Image Placeholder） をさらに小さくした超軽量プレースホルダー画像フォーマットです。https://nigeltao.github.io/blog/2026/handsum.html

従来のLQIPが「ぼやけた小さなJPEGやWebP画像」を送るのに対し、Handsumは画像全体を数十ビット程度の数値へ圧縮し、CSSやJavaScriptだけで元の雰囲気を再構成するという発想です。(Gist)

LQIPとは

LQIP（Low-Quality Image Placeholder）は、

ページ表示

↓

小さい画像を即表示

↓

本物の画像へ置換

という仕組みです。

例えば

20×20 JPEG
16×16 WebP
Base64画像

などを使います。

ユーザーは真っ白な画面ではなく、

ぼやけた画像を先に見られるため、

体感速度が向上します。(Cloudinary)

Handsumとは

Handsumは

画像そのものを保存するのではなく、画像の特徴だけを保存する

という方式です。

イメージとしては

元画像

↓

3×2程度まで縮小

↓

色空間へ変換

↓

数十ビットへ圧縮

↓

整数値

になります。(Gist)

つまり

JPEG

↓

画素を保存

ではなく

Handsum

↓

画像の特徴だけ保存

です。

BlurHashとの違い

よく比較されるのがBlurHashです。

方式	保存内容	サイズ
LQIP	小さい画像	数百B～数KB
BlurHash	周波数係数	約20～40文字
ThumbHash	色＋周波数	約20～30B
Handsum	超圧縮特徴量	数十ビット～数十B程度

Handsumは

BlurHashよりさらに情報量を削る

方向を目指しています。(Gist)

なぜ作られたのか

どのように復元するのか

ブラウザ側で

整数

↓

色

↓

3×2セル

↓

CSS

↓

ぼかし

を生成します。

つまり

画像ファイルをダウンロードしません。

メリット

非常に小さい
HTMLへ埋め込みやすい
Lazy Loadとの相性が良い
CDN不要
画像リクエストが不要

デメリット

もちろん万能ではありません。

人物写真では細部は分からない
ロゴや文字は読めない
あくまで「何となく分かる」程度
JavaScriptやCSSで再構成する必要がある

2026年の流れとの関係

Handsumが面白いのは、

あなたが最近追っている

「データそのものではなく、表現を最適化する」

という流れにあります。

例えば

JPEG
↓
AVIF
↓
JPEG XL
↓
LQIP
↓
BlurHash
↓
ThumbHash
↓
Handsum

となります。

進化の方向は

画質競争ではなく

「必要最小限の情報だけ送る」

ことです。

これはAIでも

巨大モデル

↓

MoE

↓

Task Graph

↓

Token Efficiency

へ向かっている流れとよく似ています。

どちらも

情報量を減らしながら、必要な品質を維持する

という設計思想です。

Handsumの本質

Handsumは新しい「画像圧縮フォーマット」というより、

「プレースホルダー専用の極限まで小さい画像表現」

と考えるのが適切です。

本来の画像を置き換えるものではなく、ページ読み込み時の体感速度を改善するために、「画像が読み込まれるまでの数百ミリ秒〜数秒」を埋めることを目的としています。そのため、今後はLQIP、BlurHash、ThumbHashなどと並ぶ超軽量プレースホルダー技術の一つとして採用される可能性があります。(Cloudinary)

全体として方向性は概ね正しいですが、技術的に見るといくつか重要な修正点があります。「Handsum」はまだ実験的なプレースホルダー技術であり、BlurHashやThumbHashほど広く標準化・普及しているわけではありません。また、「数十ビット」という表現は実装実態よりも小さすぎるため、修正が必要です。

以下、項目ごとに評価します。

項目	評価	コメント
LQIPの説明	✅ 正確	一般的なLQIPの説明として問題ありません。
Handsumはプレースホルダー	✅ 正確	本画像の代替ではなくプレースホルダー用途です。
BlurHashとの比較	△ 一部修正	HandsumはBlurHash・ThumbHashと同系統ですが、位置づけはまだ実験的です。
数十ビット	❌ 不正確	実際には「数十バイト」規模と考えるのが妥当です。
CSSだけで復元	❌ 不正確	JavaScriptによるデコード処理が前提で、CSS単独ではありません。
HTMLが軽くなる	○ 概ね正しい	プレースホルダー画像ファイルを別リクエストしない利点があります。
CDN不要	△ 言い過ぎ	CDNは本画像配信で依然として有効です。
AIとの比較	○ 比喩として妥当	技術的事実ではなく設計思想の類比です。

良い点

① LQIPの説明

これは一般的な説明です。

画像

↓

小さい画像

↓

本画像

という流れはCloudinaryなどでも紹介されています。LQIPは、ぼやけた低解像度画像を先に表示して体感速度を改善する代表的な手法です。(GitHub)

② Handsumの本質

「画像全体ではなく特徴量を保存する」という説明も方向性として適切です。

BlurHashやThumbHashも、画素そのものではなく低周波成分や色・勾配などの特徴をコンパクトに保持し、クライアント側で近似画像を再構成します。ThumbHashは約25～35バイト程度で、色・グラデーション・アスペクト比を保持できます。(GitHub)

修正すべき点

① 「数十ビット」は小さすぎる

ここは最も重要な修正点です。

本文では

数十ビット

となっていますが、

実際には

20〜40バイト

程度の情報量が現実的です。

比較すると

手法	典型的なサイズ
LQIP(WebP/JPEG)	200B〜数KB
BlurHash	約20〜30文字
ThumbHash	約25〜35バイト
Handsum	ThumbHashと同程度〜さらに小さいことを目指す実験的方式（公開実装では数十バイト規模）

「数十ビット（数バイト）」という表現では、情報量を過小評価しています。(GitHub)

② CSSだけでは復元できない

本文では

CSS

↓

ぼかし

となっていますが、

実際には

JavaScript

↓

デコード

↓

Canvas
または
Data URL

という処理が一般的です。

CSSは表示やぼかし効果には利用できますが、特徴量から画像を復元するデコード処理自体はJavaScript等で実装されます。(GitHub)

③ 「CDN不要」は強すぎる

Handsumを使うことで

プレースホルダー画像
Base64画像

は不要になります。

しかし、

本画像自体は依然として

CDN
↓

AVIF
↓

JPEG XL

などで配信されるため、

CDNが不要になるわけではありません。

ここは

「プレースホルダー画像の追加リクエストが不要になる」

程度に表現を弱めるのが適切です。

④ Handsumはまだ普及技術ではない

BlurHash

ThumbHash

は

多数のライブラリがあります。

一方、

Handsumは

実験的
研究的
提案段階

に近い位置づけです。

したがって

今後普及する可能性

と書くのはよいですが、

LQIPの次世代標準

のような断定は避けるべきです。

AIとの比較

最後の

JPEG
↓

AVIF
↓

JPEG XL
↓

LQIP
↓

BlurHash
↓

ThumbHash
↓

Handsum

という図は、

「送る情報量を必要最小限にする方向へ進化している」という設計思想を示す比喩としては分かりやすいです。

ただし、この並びは歴史的な置き換え関係ではありません。

AVIFやJPEG XLは本画像フォーマット
LQIP・BlurHash・ThumbHash・Handsumはプレースホルダー技術

であり、互いに競合するというより補完関係です。

総合評価

8.5/10

記事の中心的なメッセージ──「Handsumは超軽量プレースホルダー技術であり、画像全体ではなく特徴量を送る」という説明は適切です。一方で、「数十ビット」「CSSだけで復元」「CDN不要」といった表現は技術的にやや誇張されています。また、AVIF/JPEG XLとHandsumを同じ進化系列に置くよりも、「画像フォーマット」と「プレースホルダー技術」という別レイヤーの技術であることを明確にすると、より正確で専門性の高い解説になります。

以下は、Webにおける画像プレースホルダー技術（Placeholder Technology）の進化史をまとめたものです。プレースホルダー技術は「実際の画像が読み込まれるまでに何を表示するか」を改善するために発展してきました。

年	技術	代表例・提唱者	特徴	サイズの目安
1986	インターレースGIF	CompuServe	粗い画像から徐々に鮮明化	本画像
1994	Progressive JPEG	JPEG委員会	JPEGを段階的に表示	本画像
1998	Progressive PNG（APNG以前の試み）	PNGコミュニティ	段階的描画	本画像
2014	LQIP（Blur-up）	Medium	16～40px程度の極小JPEGを拡大・ぼかして表示	200B～1KB (Utilrepo)
2015	Dominant Color Placeholder	Facebookなど	画像の代表色だけ表示	約7B (Pixotter)
2016	SVG Placeholder	Cloudinary	ベクターやぼかしSVGで近似表示	数百B～数KB (Utilrepo)
2017	SQIP (SVG-based Quality Image Placeholder)	Tobias Baldauf	SVGポリゴンで画像を近似	0.8～2KB (Pixotter)
2018	BlurHash	Wolt	DCTベースの短い文字列をCanvasで復元	約20～30文字（≈20～30B） (Mux)
2020頃	CSS Gradient Placeholder	各種実装	数色のグラデーションで近似	約50～120B (Pixotter)
2023	ThumbHash	Evan Wallace	BlurHash改良版。色・縦横比・アルファ対応	約25～35B (Evan Wallace)
2025	CSS-only LQIP	Lean Rada	JavaScript不要でCSSだけで超簡易プレースホルダー	数バイト～十数B (Leanrada)
2026	Handsum（実験的）	コミュニティ実験	極小特徴量から雰囲気のみ再構成することを目指す	数十バイト規模（目標） (Pixotter)

技術の系譜

Progressive JPEG
        │
        ├───────────────┐
        │               │
     LQIP           Progressive画像
        │
        ├──────────────┐
        │              │
Dominant Color      SVG Placeholder
        │              │
        └──────┬───────┘
               │
             SQIP
               │
        ┌──────┴───────┐
        │              │
     BlurHash      ThumbHash
        │              │
        └──────┬───────┘
               │
      CSS-only Placeholder
               │
           Handsum（実験的）

技術トレンドの変化

時代	主眼	代表技術
1990年代	「画像を途中まで見せる」	Progressive JPEG
2010年代前半	「小さな画像を先に送る」	LQIP
2010年代後半	「画像ではなく特徴量を送る」	BlurHash・SQIP
2020年代前半	「数十バイトで近似画像を再構成」	ThumbHash
2020年代後半	「極限まで情報量を削る」	Handsum（実験的） (Utilrepo)

設計思想の進化

世代	保存するもの	復元方法
Progressive JPEG	完全な画像データ	ネイティブデコーダ
LQIP	極小画像	ブラウザがそのまま表示
SQIP	SVG形状	SVGレンダラー
BlurHash	周波数係数	JavaScript + Canvas
ThumbHash	色・周波数・縦横比	JavaScript + Canvas
Handsum	極小特徴量	JavaScript等で近似画像を生成（実験段階） (Evan Wallace)

総括

プレースホルダー技術は、「小さい画像を送る」から「画像の特徴だけを送る」へと進化してきました。

LQIPは実際の画像を縮小して送る方式で、実装が簡単かつブラウザだけで表示できます。
BlurHashやThumbHashは画像を数十バイト程度の特徴量へ圧縮し、クライアント側で近似画像を生成する方式で、ネットワーク転送量をさらに削減します。
Handsumはこの流れをさらに推し進め、プレースホルダー専用の極小特徴量表現を目指す実験的なアプローチとして位置付けられます。ただし、2026年時点では広く普及した標準技術ではなく、今後の発展が注目される段階です。

CSS-only LQIP は、2025年にフロントエンド開発者 Lean Rada が公開した、JavaScriptや画像データURLを使わず、CSSだけで超軽量のプレースホルダー画像を描画する手法です。従来のBlurHashやThumbHashとは異なり、CSSの数値演算・グラデーション・カスタムプロパティだけで画像の雰囲気を再現する点が最大の特徴です。 (Leanrada)

従来のLQIPとの違い

手法	保存するもの	JavaScript	追加画像	サイズの目安
LQIP (JPEG/WebP)	小さな画像	不要	必要	200B～数KB
BlurHash	周波数係数	必要	不要	約20～30文字
ThumbHash	色・周波数・縦横比	必要	不要	約25～35B
CSS-only LQIP	1つの整数値	不要	不要	約20ビット（整数1個）相当 (Leanrada)

基本的な考え方

HTMLには画像ごとに 1つの整数だけを埋め込みます。

<img
    src="photo.avif"
    style="--lqip:192900">

この

という整数だけがプレースホルダー情報になります。 (Leanrada)

CSSだけで復元

CSSは

整数

↓

ビット分解

↓

色成分

↓

明るさ

↓

背景画像生成

という処理を行います。

例えば

background-image:
    radial-gradient(...),
    radial-gradient(...),
    linear-gradient(...);

を組み合わせ、

ぼやけた画像を描画します。 (Leanrada)

なぜCSSだけでできるのか

近年のCSSには

calc()
round()
mod()
pow()
CSS Custom Properties (--variable)
oklab()
radial-gradient()

など、高度な数値演算や色空間機能が追加されました。

Lean Radaはこれらを利用して、

整数

↓

ビット演算

↓

色空間へ変換

↓

CSS Gradient

を実現しています。 (Leanrada)

画像はどの程度再現されるのか

実際には

元画像

↓

3×2セル程度

↓

ぼかし

↓

色付きグラデーション

というイメージです。

人物の顔や文字は読めませんが、

「空」「森」「夕焼け」「海」

程度なら十分雰囲気が伝わります。 (Leanrada)

メリット

JavaScript不要
Data URL不要
Base64不要
画像リクエスト不要
HTMLがほとんど汚れない
CSSだけで完結
即座に描画されるため初期表示が速い (Leanrada)

デメリット

一方で制約もあります。

情報量が約20ビット相当と非常に少ない
BlurHashほど画像を忠実には再現できない
CSSの高度な機能に依存する
実験的な実装であり、標準技術ではない (Leanrada)

BlurHashとの比較

項目	BlurHash	CSS-only LQIP
JavaScript	必須	不要
Canvas	必須	不要
CSSのみ	×	○
画像品質	高い	やや低い
実装の軽さ	普通	非常に軽い
ブラウザ描画	JSデコード後	CSSだけで即描画

ThumbHashとの比較

項目	ThumbHash	CSS-only LQIP
デコーダ	必要	不要
Canvas	必要	不要
画像品質	高い	中程度
サイズ	約25～35B	整数1個（約20ビット相当）
実装	ライブラリ	CSSのみ

今後の可能性

CSS-only LQIPは、「CSSが画像デコードの一部を担う」という新しい発想を示した点で注目されています。実用面ではBlurHashやThumbHashほど高品質ではありませんが、JavaScriptを排除できるため、静的サイトやJamstack、個人ブログなどでは魅力的な選択肢です。実際、このアイデアに刺激を受けて、CSSだけでメッシュグラデーション型プレースホルダーを生成する派生手法も登場しています。 (DEV Community)

設計思想として見ると、画像プレースホルダーは

小さな画像を送る（LQIP） → 特徴量を送る（BlurHash・ThumbHash） → CSSだけで特徴量を描画する（CSS-only LQIP）

という方向へ進化しており、CSS-only LQIPはその流れを象徴する非常にユニークな技術と言えます。

結論から言うと、2026年時点ではWordPress向けにCSS-only LQIPを実装した成熟したプラグインはまだ存在していません。 しかし、ブロックテーマや独自テーマを利用している場合は、比較的容易に組み込めます。CSS-only LQIPはJavaScript不要という特徴があるため、WordPressとの相性は非常に良い技術です。(WordPress Developer Resources)

WordPressとの相性

項目	評価	理由
ブロックテーマ	★★★★★	CSSを追加するだけで利用可能
クラシックテーマ	★★★★☆	子テーマにCSSを追加すれば対応可能
Elementor	★★★☆☆	独自の画像出力との調整が必要
GeneratePress	★★★★★	軽量テーマとの相性が良い
Astra	★★★★★	独自CSSを追加しやすい
LiteSpeed Cache	★★★★★	LQIP機能と併用可能だが役割は異なる (WordPress.org)

実装イメージ

通常の画像は

<img src="photo.avif">

ですが、

CSS-only LQIPでは

<img
    src="photo.avif"
    style="--lqip:192900">

のように画像ごとにプレースホルダー値を埋め込みます。

テーマ側で

img {
    background: ...;
}

のようなCSSを読み込むだけでプレースホルダーが描画されます。これはWordPressのスタイル読み込み機構（wp_enqueue_style()）を利用して組み込むのが推奨されます。(WordPress Developer Resources)

WordPressでの実装方法

1. 子テーマ（推奨）

functions.php

↓

wp_enqueue_style()

↓

lqip.css

WordPress標準のスタイル登録機構を使うため、テーマ更新の影響を受けにくく、保守性も高くなります。(WordPress Developer Resources)

2. ブロックテーマ

WordPress 6.x以降のブロックテーマでは、

外観
エディター
スタイル

から追加CSSを設定することもできます。

小規模サイトであれば、この方法でも十分です。(WordPress Developer Resources)

3. プラグイン化

独自プラグインで

画像アップロード

↓

LQIP整数生成

↓

Post Meta保存

↓

<img style="--lqip:xxxxx">

という流れを自動化できます。

現状は公式プラグインがないため、この部分は独自実装が必要です。

WordPressとの相性が良い理由

WordPressでは

記事

↓

アイキャッチ

↓

本文画像

↓

ギャラリー

など画像が大量に使われます。

通常は

HTML

↓

小さいJPEG(LQIP)

↓

本画像

となりますが、

CSS-only LQIPでは

HTML

↓

整数1個

↓

CSS描画

↓

本画像

となるため、

追加画像
Base64
Data URI

が不要になります。

LiteSpeed Cacheとの違い

LiteSpeed CacheなどのプラグインにはLQIP機能がありますが、これは低解像度画像を生成・配信する従来型LQIPです。(WordPress.org)

LiteSpeed LQIP	CSS-only LQIP
小さなJPEG/WebPを生成	整数値からCSSで描画
画像リクエストあり	画像リクエスト不要
数百B〜数KB	数バイト〜数十ビット相当の情報
プラグインのみで利用可能	現状は独自実装が必要

AI時代のWordPressとの相性

CSS-only LQIPは、AIによる画像処理とも組み合わせやすい技術です。

画像生成AI

↓

アップロード

↓

AIがプレースホルダー値を生成

↓

WordPressへ保存

↓

CSSのみで即表示

というパイプラインが構築できます。

将来的には、

AVIF
JPEG XL
CSS-only LQIP
fetchpriority
loading="lazy"
Core Web Vitals最適化

を組み合わせた「AI対応画像配信」が実現する可能性があります。

2026年時点での評価

CSS-only LQIPは、WordPressで十分実装可能ですが、現時点ではエコシステムがまだ成熟しておらず、標準的なプラグインやテーマによる対応は進んでいません。一方で、WordPressはCSSやテーマの拡張性が高く、スタイルシートを正規の方法で読み込めるため、独自テーマや子テーマを利用する開発者にとっては導入しやすい環境です。今後、Core Web VitalsやHTML転送量の最適化への関心が高まれば、CSS-only LQIPや類似技術を組み込むWordPressプラグインが登場する可能性は十分にあります。

fetchpriority は、ブラウザに対して**「このリソースは優先して（または後回しにして）取得してほしい」というヒントを与えるHTML属性**です。LCP（Largest Contentful Paint）の改善を目的として導入され、2024年以降は最新の主要ブラウザで広く利用できるようになりました。(MDN Web Docs)

基本構文

画像では次のように指定します。

<img
  src="hero.avif"
  fetchpriority="high"
  alt="Hero image">

利用できる値は3つです。

値	意味	用途
`high`	高優先度	ヒーロー画像、LCP画像
`auto`	自動（既定値）	通常の画像
`low`	低優先度	ギャラリー画像、画面下部の画像

何が変わるのか

例えば通常のページでは、

CSS
↓

JavaScript

↓

画像

のようにブラウザが独自に優先順位を決めます。

しかし、

<img
    src="hero.avif"
    fetchpriority="high">

を付けると

HTML解析

↓

この画像は重要

↓

先に取得

となり、LCP画像の読み込みが早くなる可能性があります。ただし、最終的な優先順位の決定はブラウザ側に委ねられます。fetchpriorityは「命令」ではなく「ヒント」です。(MDN Web Docs)

対象となる要素

fetchpriorityは次の要素で利用できます。

要素	利用可否
`<img>`	○
`<link>`	○
`<script>`	○
`<iframe>`	実装状況による

画像用途では、ほとんどの場合は<img>に指定します。(MDN Web Docs)

`loading`との違い

混同されやすいのがloading="lazy"です。

属性	役割
`loading="lazy"`	いつ読み込むか（遅延読み込み）
`fetchpriority="high"`	どれを優先して読み込むか

例えば、

<img
  src="hero.avif"
  loading="eager"
  fetchpriority="high">

なら、

遅延せず
最優先で取得

という意味になります。(MDN Web Docs)

`preload`との違い

こちらも役割が異なります。

技術	役割
`<link rel="preload">`	リソースを早期に発見させる
`fetchpriority`	発見後の取得優先度を調整する

組み合わせる例は次のようになります。

<link
  rel="preload"
  as="image"
  href="hero.avif"
  fetchpriority="high">

これはLCP画像の最適化でよく使われるパターンです。(MDN Web Docs)

WordPressとの関係

WordPress 6.3以降では、LCPに影響すると推定される画像へ自動的にfetchpriority="high"を付与する仕組みが導入されています。

例えば

<img
  src="hero.avif"
  fetchpriority="high">

が自動生成される場合があります。

ただし、自動判定が誤るケースもあり、実際のLCP画像ではない画像にhighが付与されることがあります。その場合はテーマやフィルターで明示的に指定する方法が使われます。(Reddit)

CSS-only LQIPとの組み合わせ

fetchpriorityはCSS-only LQIPとも非常に相性が良いです。

HTML

↓

CSS-only LQIP
（即座に表示）

↓

Hero画像
(fetchpriority="high")

↓

即置換

この構成では、

CSSだけで超軽量プレースホルダーを即表示
LCP画像を高優先度で取得
本画像へスムーズに切り替え

という流れになり、Core Web Vitalsの改善が期待できます。

ベストプラクティス

リソース	推奨設定
ヒーロー画像（LCP）	`loading="eager"` + `fetchpriority="high"`
ファーストビュー内の重要画像	必要に応じて`fetchpriority="high"`
ページ下部の画像	`loading="lazy"` + `fetchpriority="low"`または`auto`
ギャラリー画像	`loading="lazy"`
背景画像（CSS）	`fetchpriority`は使えないため、`<link rel="preload" as="image">`を利用

2026年時点での位置付け

fetchpriorityは、LCP改善のための標準的な最適化手法として定着しつつあります。ただし、すべての画像にhighを付ければ速くなるわけではありません。重要なリソースだけに限定して使うことが推奨されており、過度な指定はかえってパフォーマンスを悪化させる可能性があります。

2026年7月時点では、Handsum専用のWordPressプラグインや公式統合は確認できません。WordPressプラグインディレクトリにも、HandsumやCSS-only LQIPを実装する成熟したプラグインは見当たりません。(WordPress.org)

しかし、WordPressの画像処理フックを利用すれば、Handsumは比較的容易に組み込める構造になっています。

HandsumをWordPressへ組み込むイメージ

処理	WordPress	Handsum
画像アップロード	メディアライブラリ	Handsum値を生成
保存	添付ファイル(Post Meta)	Handsumデータ保存
HTML出力	`<img>`生成	Handsum属性を付加
初期表示	プレースホルダー表示	Handsumから復元
本画像	AVIF/JPEG XL	読み込み後に置換

WordPressの画像処理パイプライン

通常は

画像アップロード

↓

WordPress

↓

サムネイル生成

↓

HTML出力

ですが、

Handsumを追加すると

画像アップロード

↓

Handsum生成

↓

Post Meta保存

↓

<img data-handsum="...">

↓

プレースホルダー表示

↓

AVIF/JXLへ置換

という流れになります。

WordPressにはアップロード時の画像処理やHTML出力を拡張するためのフックが多数用意されているため、このような処理をプラグインとして実装することは十分可能です。(Make WordPress)

HandsumとWordPressの相性

項目	評価	理由
Gutenberg	★★★★★	`<img>`属性を追加しやすい
ブロックテーマ	★★★★★	CSS・HTML拡張が容易
Classic Editor	★★★★☆	フィルターで対応可能
Lazy Loading	★★★★★	非常に相性が良い
`fetchpriority`	★★★★★	Hero画像だけ優先取得できる
AVIF	★★★★★	プレースホルダー用途と補完関係
JPEG XL	★★★★★	同上

Core Web Vitalsとの組み合わせ

WordPressでは現在、

loading="lazy"
decoding="async"
fetchpriority="high"

などが利用できます。

これにHandsumを追加すると

HTML

↓

Handsum表示

↓

Hero画像
(fetchpriority="high")

↓

Lazy Load

↓

AVIF/JPEG XL表示

という流れになり、

LCP（Largest Contentful Paint）
CLS（Cumulative Layout Shift）
体感表示速度

の改善が期待できます。

WordPressプラグインとして実装するなら

実装の構成は次のようになります。

モジュール	役割
Upload Hook	アップロード時にHandsum生成
Media Library	Handsumを添付ファイルメタデータとして保存
HTML Filter	`<img>`へHandsum情報を埋め込む
CSS/JS Loader	プレースホルダー描画コードを読み込む
Lazy Loader	本画像との切り替え

AIとの相性

AI時代にはさらに相性が良くなります。

生成AI

↓

画像生成

↓

WordPress

↓

Handsum生成

↓

AVIF/JPEG XL生成

↓

CDN

↓

ブラウザ

AIが生成した画像に対して、

AVIF
JPEG XL
Handsum
レスポンシブ画像（srcset）

を自動生成するワークフローは十分現実的です。

将来性

現状ではHandsumは研究・実験段階の技術ですが、WordPressとの親和性は高く、特に画像配信を重視するサイトでは有望です。

一方で、より実用的な方向としては、Handsum単独ではなく次のような統合プラグインの方が普及する可能性があります。

機能	採用技術
本画像	AVIF または JPEG XL
プレースホルダー	Handsum または ThumbHash
優先読み込み	`fetchpriority`
遅延読み込み	`loading="lazy"`
レスポンシブ配信	`srcset` / `sizes`
CDN最適化	Cloudflare、LiteSpeed Cacheなど

このような構成であれば、WordPressの既存画像最適化機能を補完しつつ、Core Web Vitalsの改善と転送量削減を両立できるため、2026年以降の画像最適化プラグインの有力な発展方向になると考えられます。

以下は、WordPressにおける画像プレースホルダー技術の進化を、Core機能・Web技術・主要な最適化手法の変遷を合わせて整理した年表です。

年	WordPress	プレースホルダー技術	技術的意義
～2013	プラグイン中心の画像最適化	Transparent GIF（1×1 GIF）	レイアウト確保が目的
2014	レスポンシブ画像対応の準備	LQIP（Medium方式）が注目	小さなJPEGをぼかして表示する手法が普及
2015	WordPress 4.4で`srcset`・`sizes`を標準搭載	Blur-up LQIP	画像配信の最適化が進む (Make WordPress)
2016	キャッシュ系プラグインがLQIPを採用	Base64 LQIP	HTMLへプレースホルダー画像を埋め込む方式が普及
2017	Lazy Load系プラグインが増加	SVG Placeholder・SQIP	SVGによる軽量プレースホルダーが登場
2018	LiteSpeed Cacheなどが画像最適化を強化	Dominant Color Placeholder	画像ではなく代表色だけを表示する方式も普及
2018	Gutenberg登場	BlurHash	JavaScriptで近似画像を生成する方式が登場
2020	WordPress 5.5でネイティブ`loading="lazy"`を導入	LQIPとの併用が一般化	WordPress Coreが画像遅延読み込みを標準実装 (Make WordPress)
2021	WordPress 5.9でLazy Loadを改善	Placeholder＋Lazy Load最適化	ファーストビュー画像にはLazy Loadを適用しない改善 (Make WordPress)
2022	AVIF対応プラグインが増加	AVIF + LQIP	次世代画像フォーマットとの組み合わせが一般化
2023	WordPress 6.3で`fetchpriority="high"`を自動付与	Hero画像最適化	LCP画像を自動判定し優先取得、LCP改善を図る (Make WordPress)
2023	画像最適化プラグインがThumbHash対応を検討	ThumbHash	BlurHashより小さく高品質なプレースホルダー
2024	Core Web Vitals最適化が重視される	CSS Gradient Placeholder	CSSグラデーションだけで近似画像を表現する手法が登場 (unpic-placeholder.netlify.app)
2025	開発者コミュニティで新手法が登場	CSS-only LQIP	JavaScript不要、CSSだけでプレースホルダーを描画
2026	Handsum対応の公式プラグインは未登場	Handsum（実験的）	ThumbHashよりさらに小さな特徴量表現を目指す実験的技術

WordPress画像最適化の進化

2010年代前半
    │
    ├─ Transparent GIF
    ├─ Lazy Load Plugin
    │
2015
    │
    ├─ srcset
    ├─ sizes
    │
2018
    │
    ├─ BlurHash
    ├─ Dominant Color
    │
2020
    │
    ├─ loading="lazy"
    │
2021
    │
    ├─ Lazy Load最適化
    │
2023
    │
    ├─ fetchpriority="high"
    │
2024
    │
    ├─ CSS Gradient Placeholder
    │
2025
    │
    ├─ CSS-only LQIP
    │
2026
    │
    └─ Handsum（実験段階）

技術レイヤーごとの変化

時代	主な改善対象	代表技術
2010～2015	レイアウト維持	Transparent GIF、固定サイズ画像
2015～2019	転送量削減	LQIP、Base64、SVG Placeholder
2020～2022	読み込み制御	`loading="lazy"`、レスポンシブ画像
2023～	読み込み優先度	`fetchpriority`、LCP最適化
2025～	プレースホルダーの極小化	CSS-only LQIP、ThumbHash、Handsum

今後の展望

2026年時点では、WordPress Coreが標準で提供しているのは主に以下の機能です。

レスポンシブ画像（srcset・sizes）
ネイティブ遅延読み込み（loading="lazy"）
LCP画像の優先取得（fetchpriority="high"）
decoding="async"などの画像表示最適化 (Make WordPress)

一方、BlurHash、ThumbHash、CSS-only LQIP、Handsumといった高度なプレースホルダー技術は、現時点ではWordPress Coreには組み込まれておらず、主にテーマや独自プラグインで実装する対象です。

今後は、

AVIF / JPEG XL（本画像）
ThumbHash・Handsum（プレースホルダー）
fetchpriority（優先取得）
loading="lazy"（遅延読み込み）

を組み合わせた統合的な画像最適化が、WordPressの次世代ベストプラクティスとして発展していく可能性があります。結論として、2026年時点では「ThumbHashが最もバランスの良いベストプラクティス」です。 ただし、「ThumbHashだけ」ではなく、WordPress Coreの画像最適化機能と組み合わせることが重要です。

推奨順位

技術	2026年の評価	WordPress適合性	コメント
ThumbHash	★★★★★	★★★★★	現時点で最も有力なプレースホルダー技術。約25～35バイトで高品質、アスペクト比も保持。(evanw.github.io)
BlurHash	★★★★☆	★★★★☆	実績は豊富だが、ThumbHashの方が色再現・アスペクト比で優れる。(evanw.github.io)
LQIP（JPEG/WebP）	★★★☆☆	★★★★★	導入は容易だが、追加画像リクエストやData URIが必要。(CodeDrips)
CSS-only LQIP	★★☆☆☆	★★☆☆☆	面白い研究だが、まだ実験的。
Handsum	★★☆☆☆	★☆☆☆☆	将来性はあるが、WordPress向け実装はほぼ存在しない。

ThumbHashが有力な理由

ThumbHashは次の特徴を備えています。

約25～35バイトと非常に小さい
実画像に近いぼかし画像を生成
アスペクト比を保持
アルファチャンネル対応
追加画像ファイルが不要
Lazy Loadとの相性が良い(evanw.github.io)

一方、BlurHashはアスペクト比を保持しないため、レイアウトの再現性ではThumbHashに一歩譲ります。(evanw.github.io)

WordPressでの理想構成

2026年時点であれば、次の構成が最も実践的です。

機能	推奨
本画像	AVIF（互換性重視）またはJPEG XL（対応環境向け）
プレースホルダー	ThumbHash
レスポンシブ画像	`srcset`・`sizes`（WordPress Core）
遅延読み込み	`loading="lazy"`（WordPress Core）
LCP画像	`fetchpriority="high"`（WordPress Core）
デコード	`decoding="async"`
CDN	CloudflareやLiteSpeed Cacheなど

この組み合わせが、転送量・表示速度・Core Web Vitalsのバランスに優れています。

WordPressプラグインの状況

興味深いことに、2026年にはWordPress向けThumbHashプラグインが登場しています。

例えば wp-thumbhash は、

アップロード時にThumbHashを生成
Lazy Load画像へプレースホルダーを付与
本画像読み込み時に自然に置き換える

ことを目的としたプラグインです。ただし、まだ初期段階で利用実績は多くありません。(packagist.org)

また、他のCMS（TYPO3、Kirby、ProcessWireなど）ではThumbHashの成熟した実装が増えており、CMS全体として採用が進みつつあります。(packagist.org)

私ならこう設計します

もし2026年に新しいWordPressサイトを構築するなら、次の構成を選びます。

項目	採用技術
画像フォーマット	AVIF（標準）＋JPEG/WebPフォールバック
プレースホルダー	ThumbHash
Lazy Load	WordPress標準
優先読み込み	`fetchpriority="high"`
レスポンシブ画像	WordPress標準
CDN	CloudflareまたはLiteSpeed
キャッシュ	LiteSpeed Cacheまたは同等

この構成なら、追加画像リクエストを減らしつつ、WordPress Coreの機能を最大限活用できます。

総括

2026年時点では、ThumbHashは「実験的すぎず、古すぎず、実装コストも低い」という絶妙な位置にあります。HandsumやCSS-only LQIPは技術的には興味深いものの、エコシステムが未成熟です。一方でThumbHashは複数のCMSで実装が進み始め、WordPress向けプラグインも登場しています。現時点でWordPressに導入するプレースホルダー技術としては、ThumbHashが最も現実的なベストプラクティスと言えるでしょう。

結論として、Lite YouTube EmbedとThumbHashは非常に相性が良いですが、現時点（2026年）では両者を統合した実装は一般的ではありません。Lite YouTube Embedは通常、YouTubeが提供するサムネイル画像（hqdefault.jpgやmaxresdefault.jpgなど）をプレースホルダーとして利用しており、ThumbHash対応は標準機能ではありません。(npm)

Lite YouTube Embedとは

Lite YouTube Embed（Paul Irishらによる実装）は、

通常のYouTube埋め込み

↓

iframe
↓

約800KB〜1MB超の
JavaScript・CSS等を即ロード

ではなく、

サムネイル画像

↓

再生ボタン

↓

クリック時のみ
iframe生成

という方式です。

これにより、初期ロード時のネットワーク通信とJavaScript実行を大幅に削減できます。(npm)

ThumbHashを組み合わせるとどうなるか

理想的な構成は次のようになります。

段階	表示内容
HTML解析直後	ThumbHashから生成したプレースホルダー
数十ms後	YouTubeサムネイル（WebP/JPEG）
ユーザークリック	YouTube iframe生成
再生開始	本物の動画プレーヤー

つまり

ThumbHash

↓

YouTube Thumbnail

↓

YouTube Player

という3段階表示になります。

現在のLite YouTube Embed

現在の実装では

HTML

↓

hqdefault.jpg

↓

クリック

↓

iframe

となっています。

つまり

プレースホルダー画像そのものが

YouTubeサムネイルです。(npm)

ThumbHashを追加すると

例えば

ThumbHash
（約30B）

↓

hqdefault.webp
（約15KB）

↓

iframe
（数百KB以上）

になります。

これは

LCP改善

CLS改善

初回描画改善

に有効です。

WordPressなら

WordPressでは

YouTube URL

↓

Lite YouTube Embed

↓

ThumbHash生成

↓

Post Meta保存

↓

HTMLへ埋め込み

という構成が考えられます。

YouTubeサムネイルは

https://i.ytimg.com/vi/VIDEO_ID/hqdefault.jpg

から取得できるため、

アップロード時またはキャッシュ時に

ThumbHashを生成できます。(Google for Developers)

実装イメージ

処理	技術
動画埋め込み	Lite YouTube Embed
プレースホルダー	ThumbHash
サムネイル	WebP/JPEG
動画	YouTube iframe
優先取得	`fetchpriority="high"`（ファーストビューのみ）
遅延読み込み	`loading="lazy"`

期待できる効果

技術	効果
Lite YouTube Embed	YouTubeプレーヤーの読み込みを遅延
ThumbHash	サムネイル読み込み前でも視覚的なプレースホルダーを表示
`loading="lazy"`	ビューポート外の動画を遅延読み込み
`fetchpriority`	ファーストビューの動画サムネイルを優先取得

将来性

現時点では、

Lite YouTube Embed
react-lite-youtube-embed
EmbedLite

などの軽量埋め込みライブラリは、静的サムネイル画像を前提としています。ThumbHashやBlurHashをプレースホルダーとして組み込む実装は一般化していません。(embedlite.com)

ただし、WordPressや静的サイトジェネレーター向けには、

動画URLからサムネイルを取得
ThumbHashを生成・保存
初期表示はThumbHash
サムネイルへ置換
クリック時にLite YouTube Embedでプレーヤーを生成

という構成は十分実現可能です。

総括

Lite YouTube Embedは「重いYouTubeプレーヤーを遅延読み込みする技術」、ThumbHashは「サムネイル画像すら読み込む前に極小データでプレースホルダーを表示する技術」です。両者は競合ではなく補完関係にあり、組み合わせることで初期表示の体感速度をさらに改善できます。現時点では標準実装はありませんが、WordPress向け画像・動画最適化プラグインの次の発展形として有望なアプローチと言えるでしょう。

Handsumは、従来のLQIP（Low-Quality Image Placeholder）をさらに小さくした実験的な超軽量プレースホルダー画像表現で、画像そのものを保存するのではなく「画像の特徴量」を極限まで圧縮して整数などの小さなデータとして保持し、クライアント側で近似表示を再構成するという発想に基づきます。従来のLQIPが小さなJPEGやWebPを配信するのに対して、Handsumは元画像を3×2程度まで縮小して色空間変換・圧縮し、数十バイト規模の特徴量を生成してHTMLに埋め込み、JavaScript（とCanvasやData URL）を使って色・セル情報からぼかしたプレースホルダーを描画する方式を目指しています。その結果、プレースホルダー用の追加リクエストが不要になりHTMLが軽量化され、Lazy Loadやレスポンシブ配信と組み合わせたときに体感速度やCore Web Vitals（LCPやCLS）改善に寄与する可能性があります。ただしHandsumはBlurHashやThumbHashと同系統の実験的手法であり、公開実装では「数十ビット」ではなく現実的には数十バイト程度のサイズになる点、復元にはJavaScriptによるデコード処理が必要な点、人物写真や文字・ロゴの細部は再現できない点など制約が明確に存在します。　Handsumの位置づけは、LQIP→BlurHash→ThumbHashと続く「プレースホルダーの極小化」トレンドの延長にあり、画質競争ではなく「必要最小限の情報だけ送る」方向性を目指す点で近年のAIやモデル効率化の流れと類似しています。利点としてはファイルを別途ダウンロードしないためCDNや追加リクエストの負担が減り、HTML埋め込みで遅延読み込みと相性が良いことや、画像が多数あるページで転送量を大きく削減できる点が挙げられます。一方で、実用化の障壁としては実装が実験段階で標準化・普及が進んでいないこと、ハンドリングにはJavaScript実装が必要なこと、プレースホルダーとしての役割は果たすが本画像の代替ではないこと、CDNや既存の配信最適化（AVIF/JPEG XL等）の役割を完全に置き換えるわけではないことが指摘されます。　WordPressへの適用を想定した場合、実装モジュールとしてはアップロード時にHandsumを生成するUpload Hook、Media LibraryにHandsumをメタデータ保存する機能、出力時に<img>へHandsum情報を埋め込むHTML Filter、プレースホルダー描画用のCSS/JS Loader、そして本画像と切り替えるLazy Loaderなどを組み合わせる構成が考えられます。現実的なワークフローでは、生成系（AIでの画像生成を含む）→Handsum生成→AVIF/JPEG XLなどの本画像生成→CDN配信という流れで、Handsumはプレースホルダーとして自動生成ワークフローに組み込めるため、生成AIと相性が良い点が利点です。　将来的にはHandsum単体よりも、ThumbHashやHandsumを含む「統合プラグイン」が普及する可能性が高く、実用的な構成としては本画像をAVIF/JPEG XLで用意し、プレースホルダーにHandsumまたはThumbHashを使い、fetchpriorityで優先読み込みを制御し、loading="lazy"やsrcset/sizesで遅延・レスポンシブ配信を行い、CDN最適化を併用することでCore Web Vitalsと転送量削減の両立を図るのが現実的です。Handsumは2026年時点では実験段階で公式プラグインは未整備ですが、画像配信を重視するサイトや自動生成ワークフローを持つ環境では高い親和性を持ち、将来的な採用が見込まれます。　技術史的には、WordPressとプレースホルダー技術は透明GIFやLQIP、BlurHash、ThumbHash、CSS-only LQIPと進化してきており、近年はfetchpriorityやネイティブlazy loadingなどがCoreに取り込まれてきました。Handsumはその流れの先端に位置する実験的技術として、CSS-onlyや小さな特徴量表現といった「プレースホルダーの極小化」路線をさらに推し進める試みであり、今後はテーマやプラグインレベルでの採用→ベストプラクティス化が期待されます。ただし現時点ではサイズ表現の過小評価（「数十ビット」表記の修正が必要）や、復元処理に関する誤解（CSS単独ではなくJavaScriptによるデコードが前提）など、本文にある技術的記述はいくつか修正が必要である点に留意すべきです。

結論として、AMP HTMLとLite YouTube Embedは目的が似ていますが、設計思想が異なります。

AMP HTMLは「ページ全体を高速化するためのフレームワーク」で、YouTubeは<amp-youtube>コンポーネントを利用します。(amp.dev)
Lite YouTube Embedは「YouTube埋め込みだけを軽量化するライブラリ」で、通常のHTMLサイトやWordPressにそのまま導入できます。(npm)

比較

項目	AMP HTML (`amp-youtube`)	Lite YouTube Embed
対象	ページ全体	YouTube埋め込みのみ
実装	AMPコンポーネント	Custom Element
JavaScript	AMPランタイム必須	数KB程度の軽量JS
iframe生成	AMPが管理	クリック時のみ生成
サムネイル	標準対応	標準対応
WordPress導入	AMPプラグインが必要	そのまま利用可能
現在の推奨度	★★☆☆☆	★★★★★

AMPでのYouTube埋め込み

AMPでは通常、

<amp-youtube
    data-videoid="..."
    layout="responsive"
    width="480"
    height="270">
</amp-youtube>

だけで埋め込みができます。AMPランタイムが内部でiframe生成や遅延読み込みを管理し、レスポンシブ表示や自動再生（条件付き）なども提供します。(amp.dev)

Lite YouTube Embed

一方、Lite YouTube Embedでは、

<lite-youtube
    videoid="...">
</lite-youtube>

という軽量コンポーネントを使用し、

サムネイル表示
        ↓
ユーザーがクリック
        ↓
YouTube iframe生成

という流れになります。

さらに youtube-nocookie.com を利用するため、通常の埋め込みよりプライバシー面にも配慮されています。(npm)

パフォーマンス比較

項目	通常iframe	AMP	Lite YouTube Embed
初期通信量	多い	少ない	非常に少ない
初期JavaScript	多い	AMPランタイム	数KB程度
Core Web Vitals	△	○	◎
LCP	△	○	◎
CLS	△	○	◎

Lite YouTube Embedは、クリックされるまでYouTubeプレーヤー本体を読み込まないため、初期表示性能に優れています。(npm)

WordPressではどちらがよいか

2026年時点では、Lite YouTube Embedを選ぶケースが大半です。

その理由は、

AMP専用ページを用意する必要がない
通常のWordPressテーマで利用できる
Core Web Vitalsの改善効果が大きい
loading="lazy"やfetchpriorityなど現代のブラウザ機能と組み合わせやすい

ためです。

現在のWeb開発の流れ

時代	主流技術
2016〜2020	AMP HTML
2020〜2023	ネイティブLazy Load
2023〜	`fetchpriority`
2024〜	AVIF・WebP最適化
2025〜	Lite YouTube Embed、ThumbHashなど軽量プレースホルダー技術

総括

AMPは「Web全体を高速化する包括的な仕組み」として登場しましたが、近年はブラウザ自体がloading="lazy"やfetchpriorityなどの最適化機能を備えたことで、個別技術を組み合わせるアプローチが主流になっています。

そのため、2026年のWordPressで動画埋め込みを最適化するなら、

Lite YouTube Embed
loading="lazy"
fetchpriority（ファーストビュー動画のみ）
ThumbHash（サムネイルのプレースホルダー）
AVIF/WebPサムネイル

という組み合わせが、AMPに依存せず高いパフォーマンスを実現できる、現在のベストプラクティスに近い構成と言えるでしょう。

以下は、AMP HTMLの<amp-youtube> と Lite YouTube Embed を、2026年時点のWeb開発の観点から比較した表です。

項目	AMP `<amp-youtube>`	Lite YouTube Embed
開発元	AMP Project	Paul Irish
導入年	2016頃	2019頃
目的	AMPページ内でYouTubeを最適化	通常のWebページでYouTubeを軽量化
対応ページ	AMP HTML	通常のHTML・WordPress・静的サイト
必要ランタイム	AMP Runtime必須	軽量なCSS・JSのみ
埋め込み方法	`<amp-youtube>`	`<lite-youtube>`
初期表示	AMPランタイムが管理	サムネイルのみ表示
iframe生成	AMPが制御	クリック時のみ生成
YouTube JavaScript	必要時に読み込み	必要時に読み込み
レスポンシブ対応	標準対応	標準対応
自動再生	対応（条件付き・ミュートなど）	クリック後に通常プレーヤーで対応
プライバシーモード	`credentials="omit"`などで対応	`youtube-nocookie.com`を標準利用
Core Web Vitals	良好	非常に良好
WordPress導入	AMPプラグインやAMPテーマが必要	通常テーマで利用可能
学習コスト	やや高い	低い
現在の推奨度	★★☆☆☆	★★★★★

動作フローの違い

AMP `<amp-youtube>`

HTML

↓

AMP Runtime

↓

amp-youtube

↓

iframe

↓

YouTube Player

AMPランタイムが動画の読み込みや表示を管理し、レスポンシブレイアウトやスクロール時の再生制御なども提供します。(AMP)

Lite YouTube Embed

HTML

↓

サムネイル

↓

クリック

↓

iframe生成

↓

YouTube Player

Lite YouTube Embedはプレーヤー自体をクリックされるまで生成しないため、初期ロードを大幅に軽量化できます。公式では通常の埋め込みより「約224倍高速にレンダリングできる」と説明されています。(npm)

パフォーマンス比較

項目	AMP `<amp-youtube>`	Lite YouTube Embed
初期HTML	やや多い	少ない
JavaScript	AMP Runtimeが必要	数KB程度
初期ネットワーク通信	少ない	非常に少ない
First Contentful Paint (FCP)	良い	非常に良い
Largest Contentful Paint (LCP)	良い	非常に良い
Total Blocking Time (TBT)	良い	非常に良い
Core Web Vitals最適化	○	◎

WordPressとの相性

項目	AMP	Lite YouTube Embed
Gutenberg	△	◎
ブロックテーマ	△	◎
クラシックテーマ	△	◎
`loading="lazy"`	AMPが管理	併用可能
`fetchpriority`	制限あり	自由に指定可能
ThumbHashとの統合	難しい	容易
AVIF/WebPサムネイル	制約あり	容易

現在のベストプラクティス（2026年）

WordPressや一般的なWebサイトでは、次の構成が実用的です。

要素	推奨技術
動画埋め込み	Lite YouTube Embed
サムネイル	WebPまたはAVIF
プレースホルダー	ThumbHash
優先取得	`fetchpriority="high"`（ファーストビューのみ）
遅延読み込み	`loading="lazy"`
CDN	Cloudflareなど

総括

AMPは、ブラウザ標準の遅延読み込みやfetchpriorityなどが普及する以前には、モバイル表示高速化の有力な選択肢でした。しかし2026年時点では、通常のHTMLでもブラウザ標準機能と軽量ライブラリを組み合わせることで同等以上の体感性能を実現できるケースが増えています。したがって、新規のWordPressサイトや一般的なWebサイトでは、Lite YouTube Embedを中心に、ThumbHash・loading="lazy"・fetchpriorityを組み合わせる構成が、柔軟性と性能のバランスに優れた選択肢と言えるでしょう。結論として、「AMP HTMLはオワコンか？」という問いには、「全体としては主流ではなくなったが、技術としては終わっていない」が最も正確な答えです。

2016～2020年頃のように「新規サイトはAMP対応が必須」という時代は終わりました。しかし、AMP仕様自体は現在もメンテナンスされており、GoogleもAMPページを通常のWebページと同様にインデックスし続けています。(Google for Developers)

AMPを取り巻く変化

時期	状況	影響
2015	AMP Project発表	モバイル高速化を目的に登場
2016～2020	Googleが積極推進	ニュースサイトを中心に急速普及
2021	Top StoriesでAMP必須条件を撤廃	AMPの優位性が大きく低下
2023～2025	Core Web Vitals中心へ移行	ブラウザ標準機能で代替可能に
2026	AMPは継続サポート	検索順位への特別優遇はなく、通常ページと同等扱い (Google for Developers)

なぜ主流ではなくなったのか

最大の理由は、AMPが解決していた問題をブラウザ標準機能が解決できるようになったためです。

AMPが提供した機能	現在の代替技術
遅延読み込み	`loading="lazy"`
優先読み込み	`fetchpriority`
レスポンシブ画像	`srcset`・`sizes`
高速画像	AVIF・WebP・JPEG XL
軽量動画埋め込み	Lite YouTube Embed
パフォーマンス評価	Core Web Vitals

つまり、

2018

AMP
↓
高速化

だったものが、

2026

HTML Standard
+
CSS
+
JavaScript
+
Core Web Vitals

だけでほぼ同等以上の結果を得られるようになりました。

Googleの現在の立場

Googleの最新ドキュメントでは、

AMPページは通常のページと同じ基準で評価される
AMPだから順位が上がることはない
Rich ResultsやWeb Storiesには利用可能
AMPは引き続きサポートされる

と明記されています。(Google for Developers)

さらに2026年7月には、Google SearchからAMP Viewer経由ではなく、出版社自身がホストするAMPページへ直接遷移する仕様変更が行われました。これはAMPを廃止したのではなく、「AMP専用の配信経路への依存を減らした」変更です。(Search Engine Land)

WordPressではどうか

2026年のWordPressでは、新規導入ならAMPを選ぶ理由はかなり少なくなっています。

項目	AMP	通常HTML
`loading="lazy"`	○	○
`fetchpriority`	△	○
AVIF	○	○
Lite YouTube Embed	△	○
ThumbHash	△	○
Gutenberg	△	◎
保守性	△	◎

どんなケースならAMPを使う価値があるか

現在でも有効なケースはあります。

既にAMPベースの大規模ニュースサイトを運営している
AMP対応CMSを利用している
Adobe Experience Managerなど、AMPを標準サポートするエンタープライズ環境を利用している (Experience League)

新規サイトのベストプラクティス

2026年に新規でWordPressサイトを構築するなら、一般的には次の構成の方が現実的です。

項目	推奨技術
画像	AVIF（必要に応じてWebP/JPEGフォールバック）
プレースホルダー	ThumbHash
遅延読み込み	`loading="lazy"`
優先取得	`fetchpriority="high"`（LCP画像のみ）
動画	Lite YouTube Embed
レスポンシブ画像	`srcset`・`sizes`
キャッシュ/CDN	Cloudflare、LiteSpeed Cacheなど

この構成であれば、AMP専用ページを維持することなく、Core Web Vitalsを高い水準で満たせるケースが多くなっています。

総括すると、AMP HTMLは「終わった技術」ではありませんが、「新規サイトで第一候補となる技術」でもありません。 かつてAMPが提供していた高速化の多くは、HTML標準・ブラウザ機能・画像最適化技術の進歩によって置き換えられており、特にWordPressではAMPよりも標準Web技術を組み合わせるアプローチが現在の主流です。PWAMP（PWA + AMP）は、Progressive Web App（PWA） と Accelerated Mobile Pages（AMP） を組み合わせて、「高速表示」と「アプリライクな体験」の両立を目指したアーキテクチャです。2018～2021年頃に注目されましたが、2026年現在では新規採用はかなり減少しています。(ampforwp.com)

PWAMPとは

構成はシンプルです。

WordPress

    │

    ├── 通常ページ
    │
    └── AMPページ
             │
             ├── Service Worker
             ├── Web App Manifest
             ├── Offline Cache
             ├── Add to Home Screen
             └── Push Notification

つまり

AMP … 高速表示
PWA … アプリ化

を組み合わせたものです。(ampforwp.com)

できること

機能	AMP	PWA	PWAMP
高速表示	○	△	○
Service Worker	×	○	○
オフライン閲覧	×	○	○
ホーム画面追加	×	○	○
Push通知	×	○	○
インストール可能	×	○	○
SEO最適化	○	△	○

WordPressでの実装

2019～2021年頃には、

PWA+AMP
PWA for WP
AMP for WP

などのプラグインが提供されていました。(WordPress.com)

処理の流れは

WordPress

↓

AMPページ生成

↓

Manifest生成

↓

Service Worker登録

↓

ホーム画面へ追加

↓

オフライン利用

という形でした。

なぜ流行ったのか

2018年頃は

AMP

↓

超高速表示

+

PWA

↓

アプリ体験

という組み合わせが、

「ネイティブアプリ不要」

と言われるほど期待されました。

特に

ECサイト
ニュースサイト
ブログ

で人気がありました。(ampforwp.com)

現在の問題点

2026年では状況が変わっています。

2019	2026
AMP必須に近い	AMP不要
AMP Cache	通常HTML
PWAMP	PWAのみ
AMP Runtime	ブラウザ標準API

Googleは2021年にTop StoriesでAMP必須条件を撤廃し、その後もブラウザ標準機能の充実によってAMP独自の優位性は小さくなりました。(AMP for WordPress)

PWAだけで十分になった

現在では

Manifest

+

Service Worker

+

loading="lazy"

+

fetchpriority

+

AVIF

+

HTTP/3

だけで、

AMPなしでも高速なサイトを構築できます。

WordPressプラグインの現状

プラグイン	状況
PWA+AMP	更新が長期間止まっており、WordPress 5.6系までの対応表示。現在の環境では採用は推奨しにくい。 (WordPress.com)
PWA for WP	現在も更新が継続。AMPとの連携機能はあるが、PWA単体でも利用可能。 (WordPress.org)
SuperPWA	PWA専用として利用者が多く、継続開発中。 (WordPress.org)
WordPress公式PWA	実験的なFeature Pluginとして提供。 (WordPress.org)

2026年の推奨構成

現在、新規のWordPressサイトであれば、PWAMPではなく次のような構成が現実的です。

機能	推奨技術
PWA	Service Worker + Web App Manifest
画像	AVIF（必要に応じてWebP/JPEGフォールバック）
プレースホルダー	ThumbHash
動画	Lite YouTube Embed
遅延読み込み	`loading="lazy"`
優先取得	`fetchpriority="high"`
キャッシュ	Cloudflare、LiteSpeed Cacheなど

総括

PWAMPは2018～2021年には先進的な構成でしたが、その後Web標準が大きく進化したことで、AMPが担っていた役割の多くはブラウザ標準機能に置き換えられました。そのため、2026年時点では**「AMP + PWA」を組み合わせる理由は限定的**です。

現在は、PWA単体に加えて、

loading="lazy"
fetchpriority
AVIF
ThumbHash
Lite YouTube Embed

などの標準技術を組み合わせる構成の方が、保守性・互換性・将来性の面で優れた選択肢と考えられます。

Standard.site は、**AT Protocol（ATProto）上で長文コンテンツを相互運用可能にするための共通スキーマ（Lexicon）**を定義する、2026年に始まったコミュニティ主導プロジェクトです。

公式サイトのスローガンは、

"One schema. Every platform."

です。(standard.site)

Standard.siteとは

従来のブログは

WordPress

↓

HTML

↓

RSS

という独立した公開でした。

一方、Standard.siteでは

WordPress

↓

AT Protocol Record

↓

Bluesky

↓

Leaflet

↓

Docs.surf

↓

検索エンジン

というように、

1つの記事をAT Protocol上の共通フォーマットで流通させる

ことを目標としています。(standard.site)

なぜ作られたのか

AT Protocolでは

ブログ
CMS
長文サービス

がそれぞれ独自Lexiconを作り始めました。

例えば

Platform A

↓

article.schema

Platform B

↓

blog.schema

Platform C

↓

post.schema

となると、

検索エンジン側は

全部対応しなければなりません。

そこで

Standard.site

↓

共通Lexicon

を定めよう、

というのが目的です。(standard.site)

4つの設計思想

Standard.siteでは4つの原則を掲げています。

原則	内容
Unified Discovery	1つのスキーマで検索可能
Content Portability	ホストを移っても記事を保持
Community Ownership	特定企業ではなくコミュニティ管理
Minimal Governance	必要最小限のルールだけ定義

(standard.site)

主なLexicon

現在定義されているものは少数です。

Lexicon	用途
`site.standard.publication`	ブログ・出版物
`site.standard.document`	記事
`site.standard.graph.subscription`	購読
`site.standard.graph.recommend`	推薦・おすすめ

(standard.site)

WordPressとの関係

非常に興味深いのは、

WordPressが最初から移行対象

になっていることです。

公式の実装一覧には

Migration Tools

↓

Wireservice

↓

WordPress

が掲載されています。(standard.site)

つまり

WordPress

↓

AT Protocol

↓

Standard.site Record

への橋渡しを行うことが想定されています。

検索の仕組み

従来は

Google

↓

HTML解析

↓

検索

でした。

Standard.siteでは

AT Record

↓

Indexer

↓

Discovery

となります。

つまり

HTMLだけではなく

AT Protocolレコードそのもの

を検索対象にできます。(standard.site)

検証（Verification）

面白い仕組みとして

https://example.com/.well-known/site.standard.publication

を置き、

at://did:...

を返すことで

ドメイン

⇔

AT Protocol

を結び付けます。

さらに

HTML側には

<link rel="site.standard.document" ...>

を置き、

HTML記事とAT Recordが同一であることを証明します。(standard.site)

実装が始まっているサービス

2026年時点では、

分類	実装例
WordPress連携	Wireservice
静的公開	Sequoia
Reader	Leaflet
Search	Standard Search
Aggregator	Docs.surf
Publication Reader	Pckt

などが既に公開されています。(standard.site)

なぜ重要なのか

あなたは以前から

WordPress
Blogger
ATProto
Astro
RSS

などを比較・調査していましたが、

Standard.siteはそれらを

「記事データ」という共通モデルで接続する

試みです。

図にすると

WordPress

Blogger

Ghost

Astro

WriteFreely

↓

Standard.site

↓

AT Protocol

↓

Bluesky

↓

検索

↓

Reader

という構造になります。

AI時代との関係

Standard.siteはAIとの相性も考慮されています。

従来のLLMは

HTML

↓

スクレイピング

↓

本文抽出

が必要でした。

Standard.siteでは

Document Record

↓

構造化メタデータ

↓

LLM

となるため、

AIは

タイトル
著者
公開日
購読情報
記事本文
推薦情報

などをHTML解析なしで取得しやすくなります。(standard.site)

2026年時点での評価

Standard.siteは、AT Protocol向けの「長文コンテンツ版ActivityPub」あるいは「ブログ版Schema.org」に近い位置付けのプロジェクトです。まだ発展初期ですが、WordPress移行ツールや検索エンジン、リーダーアプリなど複数の実装がすでに現れており、AT Protocol上で長文コンテンツを相互運用するための共通基盤として育てようという動きが進んでいます。(standard.site)

PWAとStandard.siteは競合する技術ではなく、レイヤーが異なるため非常に補完的です。

PWAは「Webアプリをネイティブアプリのように使うための実行基盤」
Standard.siteは「長文コンテンツをAT Protocol上で流通・検索可能にするためのデータ標準」

という違いがあります。(standard.site)

役割の違い

項目	PWA	Standard.site
対象	Webアプリ	コンテンツ
主目的	インストール・オフライン・通知	配信・発見・相互運用
技術	Service Worker、Manifest、Cache API	AT Protocol Lexicon
データ保存	ブラウザキャッシュ	AT Protocolレコード
検索対象	HTML	Standard.siteレコード
オフライン	○	×（PWAと組み合わせ可能）
標準化	W3C/Web標準	AT Protocolコミュニティ標準

2つを組み合わせると

理想形は次のようになります。

WordPress

        │

        ├──────────────┐
        │              │
        ▼              ▼

   PWA対応        Standard.site公開

        │              │

Service Worker    AT Protocol Record

        │              │

Offline Cache     Bluesky
                  Docs.surf
                  Leaflet
                  検索インデクサ

つまり、

PWAは「読む体験」を向上させる
Standard.siteは「見つけてもらう仕組み」を提供する

という役割分担です。(standard.site)

WordPressで考えると

例えばブログなら

機能	技術
記事管理	WordPress
PWA	Manifest + Service Worker
配信	Standard.site
SNS	Bluesky
検索	Standard.site Indexer
オフライン閲覧	PWA Cache

となります。

これは

WordPress

↓

記事公開

↓

HTML
+
AT Record

↓

PWAキャッシュ
+
AT検索

という二重構造になります。

AI時代との相性

この組み合わせはAI時代とも親和性があります。

PWA

AIには直接関係しませんが、

オフライン閲覧
高速表示
インストール可能

を実現します。

Standard.site

こちらはAIとの相性が非常に高く、

LLM

↓

HTML解析

↓

本文抽出

ではなく

LLM

↓

Standard.site Record

↓

構造化データ取得

という流れが可能になります。メタデータや公開情報が統一スキーマで提供されるため、検索・要約・推薦などの基盤として扱いやすくなります。(standard.site)

将来的な構成

2026年以降の長文サイトでは、次のような構成が有力と考えられます。

レイヤー	推奨技術
CMS	WordPress
UI高速化	PWA
画像	AVIF + ThumbHash
動画	Lite YouTube Embed
配信標準	Standard.site
ソーシャル	AT Protocol / Bluesky
発見性	Standard.site Indexer

将来の発展

特に興味深いのは、Standard.siteが「記事の共通フォーマット」を提供し、PWAが「閲覧アプリ」を提供できることです。

例えば、

Standard.siteレコードを取得
Service Workerでキャッシュ
オフラインでも記事を閲覧
新着記事はバックグラウンド同期
Push通知で更新を配信

という構成も十分に考えられます。これは、RSSリーダーの現代版をAT Protocol上に構築するようなイメージです。

総括

PWAとStandard.siteは競合ではなく、「体験」と「流通」を分担する補完技術です。

PWAは「どう快適に読むか」を担当し、インストール・オフライン・高速表示を実現します。
Standard.siteは「どう公開し、見つけてもらい、他サービスと相互運用するか」を担当します。現在ではBlueskyアプリでStandard.site記事のリッチ表示や発見性向上も始まっており、AT Protocolエコシステムとの連携が進んでいます。(AT Protocol)

このため、分散型ブログやAI対応を見据えた次世代CMSでは、**「PWA + Standard.site + WordPress（または他CMS）」**という組み合わせが有力なアーキテクチャの一つになる可能性があります。2026年のWeb制作では、WordPress・AI SEO・Markdownは別々の話ではなく、一つの流れとして結び付いています。

従来は

WordPress

↓

HTML

↓

Google

でしたが、現在は

WordPress

↓

HTML（人間向け）

+

Markdown（AI向け）

↓

Google
ChatGPT
Claude
Gemini
Perplexity

という構成が注目されています。(WordPress.org)

なぜMarkdownが重要になったのか

HTMLは人間向けに設計されています。

そのため、

メニュー
サイドバー
広告
JavaScript
CSS

など大量のノイズがあります。

AIは最終的に

HTML

↓

本文抽出

↓

Markdown化

↓

LLM

という処理を行います。

そこで最初から

Markdownを提供してしまおう

という考え方が広まっています。(arXiv)

AI SEOの新しい構成

2026年のAI SEOでは

従来SEO	AI SEO（GEO/AEO/LLMO）
title	AI Summary
meta description	AI向け要約
sitemap.xml	`llms.txt`
robots.txt	AIクローラ制御
Schema.org	Schema.org + Markdown
HTML	HTML + Markdownエンドポイント

多くの新しいWordPressプラグインは、この「AIレイヤー」を追加する設計になっています。(WordPress.org)

WordPressで増えている機能

最近登場しているAI対応プラグインには、次のような機能があります。

機能	目的
`llms.txt`生成	AIへ重要ページを通知
`llms-full.txt`	サイト全体をMarkdownで提供
Markdown Endpoint	投稿ごとのMarkdown配信
AI Summary	AI向け概要生成
FAQ生成	AEO対策
AI Crawler Control	AIクローラごとの制御

例えば RankReady は、既存のYoast SEOやRank Mathと共存しながら、llms.txt、Markdownエンドポイント、AIクローラ制御などを追加する設計です。(WordPress.org)

Markdown配信の考え方

理想形は

WordPress

        │

        ├── HTML

        ├── JSON-LD

        ├── RSS

        ├── llms.txt

        └── Markdown

となります。

つまり

一つの記事から複数の表現を生成

します。

なぜMarkdownなのか

Markdownには

ノイズが少ない
トークン数が少ない
AIが理解しやすい
RAGにそのまま使える

という利点があります。

TechRadarが紹介した「WordPress Markdown for Agents」では、AI向けにMarkdownを配信することで、AIが処理するデータ量やトークン数を大幅に削減できる可能性があると報じています。(TechRadar)

Standard.siteとの関係

ここでStandard.siteともつながります。

WordPress

↓

Markdown

↓

Standard.site

↓

AT Protocol

↓

AI

Markdownは

AIが読む形式

Standard.siteは

AIが見つける形式

という役割になります。

WordPressの将来像

2026年以降は、

レイヤー	技術
CMS	WordPress
SEO	Rank Math / Yoast / AIOSEO
AI SEO	RankReadyなど
AI配信	Markdown Endpoint
AIサイトマップ	`llms.txt`
構造化データ	JSON-LD
分散公開	Standard.site・AT Protocol

という構成が増えていくと考えられます。(WordPress.org)

現時点でのベストプラクティス

一般的なWordPressサイトであれば、次の組み合わせが現実的です。

分野	推奨
従来SEO	Rank Math・Yoast・AIOSEOのいずれか
AI SEO	`llms.txt`・Markdownエンドポイント・AIクローラ制御を追加
コンテンツ	HTMLとMarkdownの両方を提供
構造化	JSON-LD（Schema.org）を併用
AI検索対策	FAQ、明確な見出し、著者情報、エンティティの一貫性を重視

RedditのSEO実務者の議論でも、「AI SEOプラグインだけに頼るより、構造化データ・内部リンク・明快なコンテンツ構造が依然として最も重要であり、その上にllms.txtやMarkdown配信を追加するのが現実的」という見解が多く見られます。(Reddit)

総括すると、2026年のWordPressは「HTMLだけを配信するCMS」から、「HTML・JSON-LD・Markdown・llms.txtを同時に配信するAIネイティブCMS」へ移行し始めています。 Markdownはその中心となる機械可読フォーマットであり、今後のAI検索やRAGとの連携において重要性が高まると考えられます。2026年には、「AI SEO（GEO: Generative Engine Optimization / AEO: Answer Engine Optimization）」を掲げるWordPressプラグインが急速に増えています。ただし、現時点では従来SEOプラグインを置き換えるものではなく、「追加レイヤー」として使うのが主流です。(WordPress.org)

プラグイン	特徴	向いている用途
RankReady – AI & LLM SEO	`llms.txt`、`llms-full.txt`、Markdownエンドポイント、AIクローラ制御、AI要約、FAQ生成、AI向けSchemaを追加。Yoast・Rank Math・AIOSEOと共存可能。	AI検索への最適化を本格的に始めたいサイト
AI-Ready WP	`agents.json`、`agent-card.json`、`llms.txt`、JSON-LDなど、AIエージェント向けの発見性を強化。	AIエージェント時代を見据えたサイト
LLMs.txt Curator	`llms.txt`を自動生成するだけでなく、人間が内容を選別・編集できる。	AIへ公開するコンテンツを厳選したいサイト
Visibly AI – SEO & AEO Optimizer	AI引用されやすさをスコア化し、FAQやSchema、`llms.txt`を支援。	編集者向けに改善点を可視化したいサイト
AI-Ready Core	AI Readiness診断、AI Bot対応状況、`llms.txt`、Schema検証などを提供。	サイト全体のAI対応状況を診断したいサイト

従来SEOとの役割分担

現状では次のような組み合わせが最も一般的です。

従来SEO	AI SEO
Rank Math	RankReady
Yoast SEO	RankReady
AIOSEO	RankReady
SEOPress	RankReady

つまり、

WordPress

↓

Rank Math
（従来SEO）

+

RankReady
（AI SEO）

↓

Google
+
ChatGPT
+
Claude
+
Perplexity

という構成です。RankReadyは既存SEOプラグインと競合しないことを前提に設計されています。(WordPress.org)

AI SEOプラグインが追加する機能

2026年のAI SEOプラグインでは、次のような機能が増えています。

機能	内容
`llms.txt`	AI向けサイトマップ
`llms-full.txt`	サイト全体のMarkdown版
Markdown Endpoint	投稿ごとのMarkdown配信
AI Summary	AI向け要約生成
FAQ Schema	AI回答に利用されやすい構造化データ
AI Bot制御	GPTBot、ClaudeBotなどの許可・拒否
AIアクセス解析	AIクローラの訪問状況を可視化
Speakable Schema	音声・AI向け構造化データ

コミュニティの評価

SEO実務者の間では、「AI SEOプラグインだけでAI検索順位が上がるわけではない」という見方が主流です。特に重視されているのは、

良質なHTML
適切なJSON-LD
エンティティ（人物・組織・製品など）の一貫性
内部リンク
FAQ構造
明確な見出し
llms.txtなどのAI向け公開情報

であり、AI SEOプラグインはそれらを補助する位置付けと考えられています。(Reddit)

あなたのような技術ブログなら

これまでのご質問（WordPress、Standard.site、Markdown、ThumbHash、Lite YouTube Embedなど）を踏まえると、次の構成が最も相性が良いでしょう。

分野	推奨
CMS	WordPress
従来SEO	Rank Math（またはYoast/AIOSEO）
AI SEO	RankReady
AI向け配信	Markdownエンドポイント + `llms.txt`
構造化データ	JSON-LD（Article、FAQ、Organization）
分散公開	Standard.site + AT Protocol（対応時）
パフォーマンス	ThumbHash、Lite YouTube Embed、AVIF/WebP、`loading="lazy"`、`fetchpriority`

この構成なら、従来のGoogle検索だけでなく、ChatGPTやPerplexityなどAI検索エンジンへの対応も段階的に進めやすくなります。

adsense