ideaman's Notes

体感スピードの速い通販サイトを実現するにはどうすべきか、これまでの経験をもとに設計と実装のプラクティスを紹介する。

この記事は、新たに立ち上げるサイトや大幅なリニューアルを行うことを前提としている。既存サイトの手直しにはあまり実践的な内容ではないので、あらかじめ注意されたい。

また、最新の技術は全く紹介しない。最新情報をキャッチアップしたい方には不向きだろうが、本当に汎用的で実績のあるプラクティスだけを解説する。

Web 画像データを WebP や AVIF などの次世代画像フォーマットにすると、同じ画質でもそのデータ量を大幅に削減できる。AWS などの海外クラウドサービスではデータ送信料金を削減でき、ユーザーの通信負担も軽くなる。その効果は小さくない。

しかし、将来的には次世代画像フォーマットの全面移行もあるだろうが、従来フォーマット(JPEG・PNG・GIF)はその活躍期間が長すぎた。供給側のスキルやシステム仕様がすぐには追いつかないし、次世代画像フォーマット自体への信頼感の醸成(WebP や AVIF は本当に次の標準になるのか？)にもまだ当面の時間を要すると考える。

したがって当面の間は、元画像は従来フォーマット(JPEG・PNG・GIF)で供給しつつ、次世代フォーマットへの変換は配信目的に留まる体制が続くと踏んでいる。

この記事では次世代画像フォーマットの代表を仮に WebP とし、従来フォーマットの画像をどのタイミングで WebP に変換するのがよいか論じてみたい。

システムにおいて、キャッシュファイルやバックアップファイルはできるだけ長く保持しておきたいが、それによりストレージの空き容量が枯渇することは避けたい。

findコマンドを使い、例えば「1 週間以上古いファイルを削除する」といったスクリプトの例はよく目にする。しかし本質的な解決にはなっていない。1 週間でどのくらいストレージを消費するかは正確には予測できないからだ。

そこで以下の Go 言語製ツールを公開した。

• go-file-cleaner

このツールを使えば「10GB に収まるよう古いファイルから削除する」といった目標使用量に応じたクリーニングを実行できる。

AWS に代表される海外クラウドサービスの利用は、貿易という観点では輸入になる。国内における海外サービスの利用は増す一方であり、IT 分野においては輸入超過の赤字が体質化している。それが「デジタル赤字」の問題だ。

この デジタル赤字を縮小する意外な方法が Web 画像の軽量化だ。

• AWS のコストダウンに有効で、デジタル赤字を縮小できる。
• 処理を自動化しやすく、稼働し始めると運用の手間がかからない。
• 通信量が減るのでユーザーのモバイル通信コストも減り、表示も早くなる。

画像軽量化というと表示高速化のイメージが強いが、ネット回線が高速になった現在では期待するほどのインパクトはなくなった。

それよりはクラウドコストの面において確実な効果があり、事業者・ユーザー・国の貿易収支にメリットのある、まさに「三方よし」の打ち手になる。

次のグラフィックツールの拡張機能(プラグイン、アドオン、アプリなどの呼称)について軽く調査した。

• Figma
• Canva
• Photoshop

いずれも Web 技術(HTML・CSS・JavaScript)で作ることができる。HTML と CSS でユーザーインターフェースを整え、JavaScript でアプリケーションとの連携や独自の機能を実装する。

これはまさにブラウザの拡張機能と同じアプローチであり、多くのアプリケーションがそれに寄せてきている流れを感じる。

プラグイン開発と言うとハードルが高い印象があるが、今や Web のフロントエンド技術があれば簡単に挑戦できる時代になった。簡単なものであれば AI だけで実装できてしまうかもしれない。

個人的なメモも兼ねて、それぞれのグラフィックツールの拡張機能の作り方を紹介する。

Core Web Vitals をはじめとする多くサイトスピード指標は対数正規分布に基づくとされている。

その計算についてこれまでプロジェクトに応じて実装していたが、共通して利用できるユーティリティライブラリを公開した。

• web-vitals-distribution - npm

インストールや基本的な使い方は日本語の README を参照されたい。

• web-vitals-distribution/README.ja.md at main · ideamans/web-vitals-distribution

Core Web Vitals をはじめとするサイトスピード指標の多くは、対数正規分布 に基づくとされている。

実際に Google はその前提に基づき PageSpeed Insights のスコアを設計しており、弊社も「そのようなものだ」としてデータを扱っている。

しかし今一度、その前提を自分の目で確かめてみようと思った。

この記事では、サイトスピードに特化した無料のアクセス解析ツールである Speed is Money で計測したサイトスピード指標が本当に対数正規分布に基づくのか、いくつかの視点から確認をしてみた。

弊社が提供するアクセスランキング機能運用サービス Rankelt4 に、AIレビュー機能 を追加した。

CDTV(カウントダウンTV)のようなランキング形式の音楽番組をイメージしてほしい。先週のトップ10を振り返り、今週のトップ10を楽しみながらMCがコメントする。

AIレビュー機能はいわばそのようなレポート機能だ。Ranklet4に設定いただいたアクセスランキングを活用し、生成AIで上位記事とその推移に関するレビューを自動作成する。

レビューは毎週または毎月、メールで自動配信もできる。メディアやブログ運用のアシスタントとしてぜひ活用いただきたい。

Core Web Vitalsが検索順位に影響すると言われて数年が経った。SEOに関わらず、サイトスピードに関心のあるサイトは少なくないだろう。

そこで日本の主要なECサイト100サイトについて、Core Web Vitalsが改善の方向に向かっているのか調査してみた。

やはり感覚のとおり、CLSは多くのサイトで改善済みだがLCPはほとんど改善が進んでいない実態が見えた。

このブログでは最近、Core Web VitalsやPageSpeed Insightsに関する記事を続けて書いた。

きっかけは2024年11月23日のMTDDC Meetup TOKYO 2024にて登壇させていただくことになり、これまでの集大成を語りたく「これで完璧！超実践的Core Web Vitalsの健全化手法」と仰々しいテーマにしたのだが、プレゼンテーションの構成を検討するうち、話したいことが多すぎてまったく完璧ではなくなってしまった。

• 宮永 邦彦 氏｜MTDDC Meetup Tokyo 2024【11/23（土）開催】

そこで講演では話しきれない内容を補完するために、テーマについて詳細な記事を書き始めた。

• PageSpeed Insightsの正しい読み方・活かし方 | ideaman's Notes
• pagespeed-quest/README.ja.md at main · ideamans/pagespeed-quest
• Core Web Vitalsの実践的な改善術 - CLS編 | ideaman's Notes
• Core Web Vitalsの実践的な改善術 - LCP編 | ideaman's Notes
• Core Web Vitalsの実践的な改善術 - INP編 | ideaman's Notes
• INPの収集および改善提案サービスを開始 | ideaman's Notes
• Core Web Vitalsの改善術 - サードパーティタグ編 | ideaman's Notes

本記事はその講演のまとめと、これまで書いた記事の総集編をお届けする。

INP(Interaction to Next Paint)は、2023年4月にFID(First Input Delay)と置き換わる形でCore Web Vitalsに昇格した指標だ。

• Interaction to Next Paint（INP）  |  Articles  |  web.dev

この指標はページの読み込みに関する指標ではなく、ユーザーの操作に対する応答の速さを示す値である。

性能の低いPCを使っていると、画面上のメニューやボタンなどをクリックしてもすぐに反応せずイライラすることがあるだろう。同じ事象はWebページでも起こりうる。それがINPと捉えて間違いない。

本記事では、このINPの改善術について解説する。

Core Web Vitals改善術の一環としてサードパーティタグの扱いについて解説する。

サードパーティタグがCore Web Vitalsに影響するというのは奇異に聞こえるかもしれないが、実は大いに関係がある。

サードパーティタグはGoogle Tag ManagerやGoogle Analyticsに代表される、外部の企業から提供されるHTMLタグであり、そのほとんどはJavaScriptを実行する。JavaScriptの動作は本来とても重いものだ。

多くの企業がサードパーティタグのメリットだけに注目し、負荷については空気のようなものと思い込んでいるが、筆者の経験上、Core Web Vitals改善の鍵はこのサードパーティタグの扱いにあると言っても過言ではない。

いわゆるWeb技術によるスピード改善と、サードパーティタグについて改善は、アプローチも責任者も違う異質な業務となる。そのためひとつの独立した記事として論じたい。

Core Web Vitalsのひとつ、LCP(Largest Contentful Paint)の改善手法について解説する。

同じCore Web VitalsのCLS(Cumulative Layout Shift)は丁寧にコーディングを行えば改善できるが、それに比べてLCPの改善は難しい。

実際にSEOの文脈でCore Web Vitalsが話題になった2021年〜2022年ごろ、CLSの改善は多くのサイトで見られたが、LCPまで改善できたサイトは少ない。

加えて、ネットの記事にはLCPの改善について誤解が多い。よく見られるのが画像の軽量化であるが、画像データがLCP悪化の主な要因であるケースなどほとんどない。

この記事ではLCP改善の実践的な手法を紹介したい。

Core Web Vitalsの中で INP(Interaction to Next Paint) は、実際のユーザーがWebページを操作して初めて計測される指標だ。

そのため指標が悪い原因を正確に特定するのが難しい。

そこでユーザー環境で生じたINPを計測、BigQueryに収集し、調査に活かす仕組みを構築した。

そのデータを用い、理論に頼るだけではない実践的なINPの改善提案サービスを開始する。

Core Web Vitalsのひとつ、CLS(Cumulative Layout Shift)の改善方法について解説する。

• Cumulative Layout Shift（CLS）  |  Articles  |  web.dev

CLSの改善は他の指標に比べて難しくはない。丁寧にコーディングを行うことでほぼ解決できる。それゆえ改善済みのサイトも多い。

しかしJavaScriptによるコンポーネントのレイアウトを制御できていないWebページはまだ散見される。

この記事ではJavaScriptによるコンテンツの挿入が行われるページや、カルーセルスライダーを用いたページについて実践的なアドバイスを記した。

PageSpeed InsightsはWebページのスピードを評価する際に便利なツールではあるが、非常にミスリードを起こしやすい。

目立つのはパフォーマンススコアと指摘事項の数々だが、弊社がフロントエンドのスピード改善を提案する上でそれらを見ることはほとんどない。

厳しい言い方をするとスコアはまやかしで、指摘事項は時代遅れである。加えてスコアと指摘事項に因果関係もない。

断っておくがツールを非難したいのではない。スコアと指摘事項に振り回されては、サイトを高速化したいという本来の目的は一向に果たせないことをお伝えしたい。

アクセスランキングはWebサイトの人気機能のひとつであるが、弊社ではGA4を活用したアクセスランキング表示のWebサービス Ranklet4 を提供している。

• Ranklet4 [無料] GA4から人気ページランキングをかんたん表示

「どのサイトでもGoogle Analyticsでアクセス解析をしているのだから、そのデータを活用してアクセスランキングを簡単に表示できるようにしよう」というアイデアから始めた無料サービスだ。

Google Analytics(以下GA4)のデータを使うのは、単に「せっかくデータを取っているから」といった受け身な理由に限らない。アクセスランキングを自前で実現するのはなかなか大変なのだ。

そんなアクセスランキング実現のつらみと、GA4を活用することの意義について話をしたい。

サイトスピードが遅いとサイトの収益性が悪化し、逆に早ければ儲かる。それはよく知られている。しかし なぜそうなるのか説明 するには、少し高い解像度で理解していないと難しい。

サイトスピードが早くなると収益が上がると言うが、その財源は一体どこにあるのか？ 誰がどう払ってくれるものなのか。

単純化すると、サイトスピードは機会損失率と成約率のトレードオフを調整するレバー のようなものだ。

実はWebサイトは、サイトスピードに起因する機会損失を常に抱えている。サイトスピードが早くなれば機会損失率が減って成約率が増える。遅くなればその逆に作用する。

機会損失という見えないものを見るにはデータが要る。通販サイトの実例を交えて詳しく見てみよう。

Difyには外部サービスと連携するツール機能があり、カスタムツールとして自前のAPIを連携対象に追加できる。

この記事では 「ふたつの数字の掛け算を行うという非常にシンプルな独自API」 を例にして、Difyにおけるカスタムツールの利用手順や、注意点を紹介する。

ChatGPT with canvasをご存知だろうか。AIとともに、ソースコードや文章を編集できる機能だ。

GitHub CoPilotもそうだと言えるし、これまでも近いことはできた。しかし**「共通の作業対象」**がインターフェースや出力として明確になった点が新しい。

このような共同作業を、Difyのチャットでも実現する方法を解説したい。

アイデアマンズ株式会社のロゴマークはプログラムで自動生成している。

この度、ロゴマークの生成プログラムを刷新し、alogorithm2としてリリースした。

DifyのソースコードにはDocker Composeプロジェクトが同梱されている。

それを利用すると自分専用のDify環境をサクッとセルフホストできるのだが、それを本番運用に利用するのは心許ない。

ではAWS上で、ガチ目のDifyスタックを展開するとしたらどうするか考えてみた。

Difyでナレッジを取り込むと、その内容はベクトルデータベースに格納される。

Difyは多種多様なベクトルデータベースに対応しているようで、環境設定ファイルを眺めているだけでも興味深い。

Difyが対応していると思われるベクトルデータベースを調べてみた。

セルフホストしたDifyからNotionに接続するには少し工夫が必要だった。

Difyのセルフホスティングについては、手順をまとめた記事を参照のこと。

その内容に沿って接続の手順を解説する。

この記事はVPSでお安く自分専用のDifyを持つ方法の続きだ。

Difyは、WebクローラーであるJina ReaderまたはFirecrawlと連携することで簡単にRAGを実現できる。

Firecrawlもオープンソースでセルフホストできる。そこでDifyをインストールしたVPSにFirecrawlもインストールし、こちらもお安く実現してみた。

その手順を紹介する。

LLMアプリ開発が楽しいDifyだが、無料だとできることが限られ、有料プランは個人にはちと高い。3アカウントも手に余る。

• Dify AI · Plans and Pricing

そこでオープンソース版をVPSにセルフホストしてみた。これなら月額1500円程度から、自分だけのDifyを持つことができる。

その手順を紹介したい。

LLMアプリの開発プラットフォームDifyを使い始めた。もう楽しすぎる。

• Dify.AI · 先進的なAIアプリケーションのためのイノベーションエンジン

「便利そうだけど、APIを使ってプログラミングした方が柔軟じゃないか？」とすぐに飛びつかなかったかつての自分に、「Difyはいいぞ！」と諭すつもりで、どんなことができて、どんなメリットがあるか紹介したい。

まだ触りたてなので間違っているところもあるかもしれない。間違いは容赦いただきたい。

以前こちらの記事「サイトスピードと幸福の心理学」の要約をXに載せた。サイトスピードに関する心理学的エピソード集で大変面白かった。

• SpeedCurve | The psychology of site speed and human happiness

「サイトの速度と人間の幸福の心理学」

The psychology of site speed and human happinesshttps://t.co/UfaSTXQIOg

この記事のトピックをまとめてみました。

1.
当たり前だが人間は待ち時間が嫌い。待たされるくらいなら歩かされた方がまし、というくらい。…

— アイデアマンズ@フロントエンドWeb高速化 (@ideamans) February 1, 2024

このブログでも、はてなブログやQiitaのようにタイトルなどからOGP画像(SNSシェア用のアイキャッチ画像)を自動生成するようにした。

そのためのバナー生成システムを独自に開発し、オープンソースとして公開した。

• banner-generator

既視感のあるテーマだが、自分でも作ってみたいと以前から考えていた。その紹介をしたい。

VPSなどの素のサーバでWebアプリを公開するとき、SSLをどうするかという問題がある。

弊社では、Amazon Route 53でDNS運用、lego (Go言語製のLet's Encryptクライアント)で取得した証明書を用い、nginxのDockerコンテナを使った汎用的なSSLゲートウェイを立てている。

そのノウハウを共有したい。一度慣れておくとWebアプリの公開が気楽になる。

いろいろなサイトのフロントエンドを観察していて面白いことに気づいた。

Appleの公式サイトではいわゆるサードパーティタグが使われていないのだ。

広告の計測系はもちろん、Google Analyticsのようなアクセス解析すらない。

まるで古の個人サイトのような作りに驚いた。

そろそろWeb画像はWebPのみの配信でよいのではないか？

このテーマについて賛成論と反対論をしてみたい。

弊社ではクライアントとのソースコード共有や、Wikiによるドキュメントの共有のためにGitLabをセルフホスティングしている。

GitHubがあるのにセルフホスティングするのは時代に逆行していると思われるが、動機やメリットもある。

そしてこのGitLabセルフホスティングは、いろいろ工夫をしながら実質的に月額500円程度のコストで実現している。

その辺の話をとりとめもなくしてみようと思う。GitLabの自社運用を検討している方の参考になれば嬉しい。

弊社ではクライアントとのソースコードやWikiによるドキュメント共有に、自前のGitLabを使うことがある。

よくある操作を毎回GUIから行うのが手間なので、Go言語によるCLIツールを作り、せっかくなのでオープンソースにした。

Webページの読み込み過程を動画化し、比較できるツールをオープンソースで公開した。

この記事では、サイトスピードに関する指標のうち、どの指標が売上に最も影響するか？ という疑問に対する事例とアクセス解析の過程を解説する。

サイトスピードを改善したいがどの指標にフォーカスして良いか迷っている方や、サイトスピード改善の費用対効果に不安のある方にぜひお読みいただきたい。