--- title: "爆速な技術ブログを作るために意識していること" description: "Astroで静的な技術ブログを作るときに意識した、HTML、JavaScript、CSS、画像、フォント、依存関係、Lighthouse計測の見方をまとめる。" lang: ja url: "https://engineer-blog.tomoki-ttttt.workers.dev/articles/tech-blog-performance-notes/" publishedAt: "2026-05-16T15:00:00.000Z" tags: ["Astro", "Web Performance", "Lighthouse", "技術ブログ"] projectIds: ["tech-blog"] --- ## はじめに このブログでは、できるだけ軽く、速く、読みやすい技術ブログを目指している。 この記事では、爆速な技術ブログを作るために、実装面で意識していることをまとめる。 具体的には、次のような内容を扱う。 - 記事本文を静的HTMLとして出すこと - JavaScriptを初回表示に関与させすぎないこと - CSSをクリティカルパスとして見ること - 画像、アイコン、OGPを軽く扱うこと - 日本語Webフォントを安易に読み込まないこと - 依存関係を増やしすぎないこと - Lighthouseの実測値をどう見るか - デスクトップとモバイルを分けて確認すること - 爆速ブログを保つためのチェックリスト この記事は、フレームワーク選定の話というより、実際に技術ブログを軽く保つための実装メモに近い。 Astroで静的に出力しているブログを前提にしているが、Next.jsやViteなど、他の構成でブログやドキュメントサイトを作るときにも応用できる内容だと思う。 ## 記事本文を静的HTMLとして出す 技術ブログで一番大事なのは、本文がすぐ読めることだ。 そのため、このブログでは記事本文をクライアント側で組み立てるのではなく、ビルド時に静的なHTMLとして生成する方針にしている。 Markdownで書いた記事を、ビルド時にHTMLへ変換しておく。 ブラウザは受け取ったHTMLをそのまま解釈できる。 JavaScriptの実行を待たなくても、本文を表示できる。 この形にしておくと、初回表示がかなり素直になる。 特に避けたいのは、記事本文の表示にJavaScriptを絡めすぎることだ。 たとえば、次のような構成にすると、ブログとしては必要以上に複雑になりやすい。 - 記事データをクライアント側でfetchする - JavaScriptでMarkdownをパースする - Reactなどで記事本文全体を描画する - 初回表示時に状態管理やルーティング処理が必要になる Webアプリならそれが必要な場面もある。 でも、技術ブログの記事ページは基本的に「読む」ためのページだ。 であれば、最初からHTMLとして置いておくのが一番速く、壊れにくいと思っている。 ## HTMLを膨らませすぎない 静的HTMLにすればそれだけで完璧、というわけではない。 HTML自体が大きくなりすぎると、それはそれで初回表示に影響する。 技術ブログでは、記事本文、コードブロック、OGPメタ、構造化データ、多言語用のalternateリンクなど、意外とHTMLが膨らみやすい。 なので、HTMLでは次のような点を意識している。 - 不要なラッパー要素を増やさない - 全ページ共通のコンポーネントを重くしない - head内のメタタグを必要十分にする - OGPやSEO用の情報を過剰に入れない - 記事本文のHTMLサイズが不自然に大きくなっていないか確認する 特に、共通レイアウトは注意が必要だ。 ヘッダー、フッター、SEOコンポーネント、テーマ初期化、ナビゲーションなどは全ページに乗る。 ここが重くなると、すべての記事ページが重くなる。 ページ単体の実装だけでなく、共通レイアウトに何を入れているかを見るのが大事だ。 ## JavaScriptを初回表示に関与させない パフォーマンスを考えるうえで、JavaScriptはかなり慎重に扱っている。 JavaScriptはファイルサイズだけでなく、パース、コンパイル、実行、メインスレッドの占有まで含めてコストになる。 技術ブログでは、見た目上は小さな機能でも、積み重なるとかなり効いてくる。 たとえば、次のような機能だ。 - テーマ切り替え - コードブロックのコピーボタン - 目次の追従 - サイト内検索 - コメント欄 - アニメーション - アクセス解析 - 外部ウィジェット - シンタックスハイライト これらは便利だが、全部を常設すると、記事を読むだけのページとしては重くなりがちだ。 なので、JavaScriptを入れるときは次のように考えている。 - そのJavaScriptは初回表示に本当に必要か - HTMLとCSSだけで実現できないか - 全ページで読み込む必要があるか - その機能がなくても記事本文は読めるか - メインスレッドをブロックしていないか - 後から消しやすい実装になっているか 特に Astro の場合、必要なところだけクライアント側で動かすことができる。 ただし、アイランドアーキテクチャが便利だからといって、記事ページにどんどんインタラクティブなコンポーネントを足すと、結局普通の重いフロントエンドに近づいてしまう。 このブログでは、記事本文の表示にはJavaScriptを関与させないことを基本にしている。 テーマ初期化のように必要な処理はあるが、それもできるだけ小さく、早く終わるようにする。 ## CSSをクリティカルパスとして見る CSSは見た目を整えるだけのものではなく、初回描画に直接関わる。 CSSはレンダリングをブロックすることがある。 つまり、CSSが大きかったり、読み込みが遅かったりすると、HTMLが届いていても画面に描画されるまで待たされることがある。 このブログでは、CSSについて次のような点を意識している。 - 共通CSSを肥大化させない - 記事ページに不要なトップページ用CSSを持ち込まない - 複雑なレイアウトを避ける - 重い装飾を多用しない - アニメーションやtransitionを雑に全体適用しない - モバイルでスクロールが重くならないようにする 特に注意したいのは、見た目のための重いCSSだ。 たとえば、次のようなものは使いすぎると負荷になりやすい。 - `box-shadow` - `filter` - `backdrop-filter` - `blur` - 大きなグラデーション - 複雑なsticky要素 - 大量のtransition - スクロール連動アニメーション もちろん、これらを一切使わないという話ではない。 ただ、技術ブログでは本文を読むことが中心なので、装飾のためにスクロールや描画を重くするのは避けたい。 また、Astro側ではCSSの出力方法も見ている。 小さなCSSであればインライン化した方がリクエストを減らせることがあるが、CSSが大きくなると逆効果になる場合もある。 なので、CSSは「ファイルサイズ」だけでなく、レンダリングの邪魔をしていないかという視点で見ている。 ## 画像・アイコン・OGPを軽くする 技術ブログでは、画像を使いすぎないことも重要だ。 旅行ブログやメディアサイトなら画像が主役になることもあるが、技術ブログの主役は基本的に本文だ。 画像が必要な場面はある。 スクリーンショットがあった方が分かりやすい記事もある。 OGP画像やアイコンも必要だ。 ただ、画像は簡単にページを重くする。 意識しているのは次のようなことだ。 - 不要なアイキャッチ画像を入れない - 記事と関係ない装飾画像を増やさない - スクリーンショットは必要な範囲だけ切り抜く - WebPやAVIFなど軽い形式を検討する - 画像のwidth / heightを指定してCLSを防ぐ - preloadする画像を増やしすぎない - OGP画像を過剰に巨大化させない 特に `preload` は便利だが、使いすぎると逆に他の重要なリソースを邪魔する可能性がある。 「早く読ませたいもの」を優先するための指定なので、何でも先読みすれば良いわけではない。 技術ブログの場合、最優先は本文だ。 画像を速く見せることより、本文が早く読めることを優先したい。 ## フォントはシステムフォントを基本にする 日本語サイトでWebフォントを使うと、見た目は整いやすくなる。 ただし、日本語フォントはファイルサイズが大きくなりやすく、読み込みコストも無視できない。 技術ブログでは、ブランド表現よりも本文の読みやすさと表示速度を優先したい。 そのため、このブログでは基本的にシステムフォントを使う方針にしている。 システムフォントを使うメリットはシンプルだ。 - 追加のフォントリクエストが不要 - 表示が速い - OSに馴染んだ見た目になる - フォント読み込みによるちらつきが少ない - レイアウト変化を抑えやすい もちろん、Webフォントが悪いわけではない。 ブランドサイトやポートフォリオでは、フォントの印象が重要になることもある。 ただ、個人の技術ブログでは、まず読めること、速いこと、長く運用しやすいことを優先している。 ## 依存関係を増やさない 高速化でかなり効くのが、依存関係を増やさないことだ。 ライブラリを1つ追加すると、それ自体のサイズだけでなく、関連する依存、ビルド設定、更新対応、セキュリティ対応も増える。 特にクライアント側に入るライブラリは慎重に見ている。 たとえば、次のようなものは便利だが、導入前に本当に必要か考える。 - 日付整形ライブラリ - アニメーションライブラリ - UIコンポーネントライブラリ - 検索ライブラリ - シンタックスハイライト - Markdown拡張 - 画像ギャラリー - コメントシステム 技術ブログでは、簡単な日付表示やタグ表示くらいなら自前で十分なことも多い。 検索機能やシンタックスハイライトも、記事数が少ない段階では必須とは限らない。 入れるとしても、全ページの初回表示に影響しない形にしたい。 依存関係を増やさないことは、速度だけでなく保守性にも効く。 軽いサイトを作るというより、重くなる入口を減らす感覚に近い。 ## 静的アセットとして配信する このブログでは、ビルドした静的ファイルを配信する構成にしている。 静的配信の良いところは、リクエスト時にアプリケーションサーバーでHTMLを生成しなくていいことだ。 DBアクセスも不要。 API呼び出しも不要。 ユーザーごとの動的生成も不要。 ビルド済みのHTML、CSS、JavaScript、画像をそのまま返せばいい。 この構成は、個人技術ブログとかなり相性が良い。 - 構成が単純 - 壊れにくい - キャッシュしやすい - 運用コストが低い - セキュリティリスクを小さくしやすい - サーバー側の処理時間に左右されにくい Webアプリなら動的な仕組みが必要だ。 でも、記事を読むためのブログであれば、できるだけ静的に寄せた方が速く、運用も楽になる。 ## Lighthouseの実測値を見る 高速化を考えるとき、Lighthouseはかなり便利だ。 ただし、Lighthouseの点数だけを見るのではなく、それぞれの指標を分けて見るようにしている。 このブログで測ったときの例は、だいたい次のような感じだった。 | 環境 | FCP | LCP | TBT | CLS | Speed Index | |---|---:|---:|---:|---:|---:| | Mobile 例1 | 0.8s | 0.9s | 0ms | 0 | 0.8s | | Desktop 例1 | 0.4s | 0.4s | 0ms | 0 | 0.5s | | Mobile 例2 | 0.9s | 0.9s | 0ms | 0.001 | 2.2s | | Desktop 例2 | 0.3s | 0.3s | 10ms | 0.001 | 0.3s | FCP、LCP、TBT、CLSはかなり良い値が出ている。 一方で、MobileのSpeed Indexだけが大きくブレることがあった。 ここが面白いところで、LCPが速いからといって、必ずしも画面全体の見え方が常に同じように速いとは限らない。 Lighthouseは一つの計測結果なので、実行するたびに多少ブレる。 ネットワーク状態、CPU、レンダリングタイミング、画像、CSS、外部要因などによって変わる。 なので、一回の結果だけで判断するのではなく、複数回測って傾向を見るようにしている。 ## 静的な技術ブログで狙いたい目標ライン これはあくまで個人的な目安だが、静的な技術ブログなら、かなり攻めた数値を狙えると思っている。 ChatGPTと相談しながら、静的な技術ブログ向けの理論値・目標値・許容ラインを整理すると、だいたい次のようになる。 | 指標 | 理論値 | 現実的な目標 | 許容ライン | |---|---:|---:|---:| | FCP | 0.2〜0.5s | 0.5〜1.0s | 1.5s未満 | | LCP | 0.3〜0.8s | 0.8〜1.5s | 2.0s未満 | | TBT | 0ms | 0〜50ms | 100ms未満 | | CLS | 0 | 0〜0.01 | 0.05未満 | | Speed Index | 0.3〜0.8s | 0.8〜1.5s | 2.5s未満 | ただし、これはかなり軽いサイト前提だ。 たとえば、次のようなサイトではこの目標は厳しすぎると思う。 - 広告が多いメディアサイト - 画像が主役の旅行ブログ - ECサイト - ダッシュボード - ログイン後のWebアプリ - 外部スクリプトが多いサイト - 大量のWebフォントを使うサイト このブログのように、Astroで静的HTMLを生成し、画像やJavaScriptをかなり抑えた技術ブログだからこそ、このくらいの数値を目指せるという感覚だ。 ## デスクトップとモバイルは別物として見る デスクトップで速いからといって、モバイルでも速いとは限らない。 これは実際に測っていてかなり感じた。 デスクトップではFCPやLCPが0.3〜0.4秒台で出ることがある。 一方で、モバイルでは同じページでもSpeed Indexが2秒台になることがあった。 理由はいろいろ考えられる。 - CPU性能が違う - ネットワーク条件が違う - 画面サイズが違う - CSSの適用タイミングが違う - フォント描画の影響が違う - 画像の扱いが違う - モバイルのLighthouse条件が厳しい 特に個人開発では、開発中の確認をPCで済ませがちだ。 でも、実際に読む人はスマホで見ているかもしれない。 だから、デスクトップだけ見て「爆速」と判断しないようにしている。 最低でも、LighthouseのMobileとDesktopは両方見る。 できれば、実機やDevToolsのPerformanceも見る。 このくらいは習慣にしておきたい。 ## 数字だけに最適化しない Lighthouseは便利だが、Lighthouseの数字だけに最適化しすぎるのは少し危険だと思っている。 最初は、FCP、LCP、TBT、CLS、Speed Indexの数値をかなり重視していた。 もちろん、これらは初回表示の状態を把握するうえで重要だ。 特に、静的な技術ブログでは悪い数値が出たときに原因を追いやすいので、Lighthouseはかなり役に立つ。 ただ、サイトの体験は一つのスコアだけでは判断できない。 たとえば、LCPが良くても、スクロールが重いことはある。 TBTが低くても、モバイルでの表示が安定しないことはある。 Desktopではきれいな数値が出ていても、MobileではSpeed Indexが大きくブレることもある。 だから、Lighthouseを見るときは合計スコアだけでなく、次のような観点も合わせて確認するようにしている。 - FCP、LCP、TBT、CLS、Speed Indexを個別に見る - MobileとDesktopを分けて見る - 一回の計測結果だけで判断しない - Networkでリクエスト数と転送サイズを見る - Coverageで未使用のCSSやJavaScriptを見る - Performanceでメインスレッドの詰まりを見る - 実際にスクロールして重くないか確認する Lighthouseは、問題を見つけるための道具としてはとても優秀だ。 ただ、最終的な目的はスコアを上げることではなく、読者がストレスなく記事を読める状態にすることだ。 数字は見る。 でも、数字だけで判断しない。 このバランスを忘れないようにしたい。 ## 爆速技術ブログのためのチェックリスト 最後に、技術ブログを軽く保つためのチェックリストをまとめる。 ### HTML - [ ] 記事本文はビルド時にHTML化している - [ ] 記事本文をクライアント側JavaScriptで生成していない - [ ] 不要なラッパー要素を増やしていない - [ ] 共通レイアウトが重くなっていない - [ ] head内のメタタグが過剰になっていない - [ ] OGP、canonical、hreflangなどは必要十分にしている - [ ] HTMLサイズが不自然に大きくなっていない ### JavaScript - [ ] 初回表示に不要なJavaScriptを読み込んでいない - [ ] 記事ページにReactなどのハイドレーションを安易に入れていない - [ ] 記事本文の表示にJavaScriptが必須になっていない - [ ] テーマ初期化など必要な処理は小さく保っている - [ ] 外部スクリプトを増やしていない - [ ] コピー機能、検索、目次追従などを入れる前にコストを考えている - [ ] DevToolsでメインスレッドを長時間ブロックしていないか確認している ### CSS - [ ] 共通CSSが肥大化していない - [ ] 記事ページに不要なトップページ用CSSを持ち込んでいない - [ ] CSSがレンダリングをブロックすることを意識している - [ ] `box-shadow`、`filter`、`backdrop-filter`、`blur` を多用していない - [ ] アニメーションやtransitionを全要素に雑に適用していない - [ ] sticky要素や重い装飾でスクロールが重くなっていない - [ ] モバイルでスクロールが重くなっていない ### 画像・アイコン - [ ] 不要なアイキャッチ画像を入れていない - [ ] 画像はWebPやAVIFなど軽い形式を検討している - [ ] 画像のwidth / heightを指定している - [ ] スクリーンショットは必要な範囲だけにしている - [ ] preloadする画像を増やしすぎていない - [ ] favicon、アイコン、OGP画像を過剰に増やしていない - [ ] 画像が本文表示より優先されすぎていない ### フォント - [ ] 日本語Webフォントを安易に読み込んでいない - [ ] システムフォントで十分か検討している - [ ] フォント読み込みによる表示遅延を確認している - [ ] フォント差し替えによるレイアウト変化を確認している ### 依存関係 - [ ] 便利ライブラリを追加する前に本当に必要か考えている - [ ] クライアント側bundleに入る依存を特に慎重に見ている - [ ] 日付整形やタグ表示など、軽い処理をライブラリに頼りすぎていない - [ ] 検索機能を入れる場合、indexサイズやJSサイズを確認している - [ ] シンタックスハイライトを入れる場合、全ページに余計な負荷をかけていない - [ ] 使っていない依存関係を残していない ### 配信・ビルド - [ ] 静的ファイルとして配信できる構成になっている - [ ] DBやAPIを初回表示に絡めていない - [ ] ビルド済みのHTML/CSS/JS/画像をそのまま配信している - [ ] キャッシュしやすいファイル構成になっている - [ ] デプロイ後の成果物サイズを確認している - [ ] CIでbuild、lint、typecheckを確認している ### 計測 - [ ] LighthouseのMobileとDesktopを両方見る - [ ] FCP、LCP、TBT、CLS、Speed Indexを個別に見る - [ ] 一回の計測結果だけで判断していない - [ ] Networkでリクエスト数とサイズを見る - [ ] Coverageで未使用CSS/JSを見る - [ ] Performanceでメインスレッドの詰まりを見る - [ ] 実機またはモバイル相当環境でスクロールの重さを見る - [ ] デスクトップだけ速くなって満足していない - [ ] Lighthouseの数字だけで体験を判断していない ## おわりに 爆速な技術ブログを作るために必要なのは、魔法の設定を一つ入れることではなく、小さな負荷を増やさないことの積み重ねだと思っている。 静的HTMLとして本文を出す。 JavaScriptを初回表示に関与させすぎない。 CSSをクリティカルパスとして見る。 画像やフォントを慎重に扱う。 依存関係を増やしすぎない。 デスクトップとモバイルを分けて計測する。 こうした地味な判断の積み重ねが、結果として速く、軽く、長く運用しやすいブログにつながる。 ただし、Lighthouseの数字だけを追えばいいわけではない。 初回表示が速くても、ページ遷移が遅く感じることはある。 デスクトップで速くても、モバイルで遅くなることもある。 一つのスコアだけでは、サイト全体の体験は判断できない。 だからこそ、数字は見つつも、最後は実際の体感も確認する。 このバランスを忘れずに、今後もこのブログを軽く保っていきたい。 --- **追記（2026-05-21）：** その後、このブログに Shiki を使ってシンタックスハイライトを導入した。「軽さを崩さない形で入れること」を判断基準にした経緯については、[爆速技術ブログに Shiki でシンタックスハイライトを入れた理由](/articles/add-shiki-syntax-highlight/)にまとめている。