ともきちのエンジニア成長記 — Works | ともきちのエンジニア成長記

主なハイライト

Next.jsからAstroへの移行による静的・軽量な構成
Lighthouse CIとJSバジェットによる継続的な品質監視
技術判断や改善プロセスが継続的に残る統合プラットフォーム

概要

「ともきちのエンジニア成長記」は、学習内容、開発メモ、技術選定、個人開発の過程を記録するための技術ブログ兼ポートフォリオサイトです。記事を読む体験を最優先にし、初回表示に不要なJavaScriptをできるだけ減らし、記事本文を静的HTMLとして配信する構成にしています。

背景・経緯

もともとはNext.jsで運用していましたが、記事を読むだけのページに対してWebアプリ的な機能は過剰だと感じ、静的生成を中心にした軽量な構成へ移行しました。また、AIで簡単にサイトが作れる時代だからこそ、単なる成果物ではなく、自分の技術判断や改善の過程が継続的に残る場所としてポートフォリオと統合しました。

解決した課題

ユーザーの課題

自分の技術的な成長過程を知りたい採用担当者や、個人開発プロジェクトの設計意図を知りたいエンジニアに向け、学習・実装・改善のプロセスを一つの場所に集約すること。

技術的な課題

記事本文を読むためのページにおいて、ブラウザがJavaScriptの実行を待たなくても本文を読める静的なHTML構成を実現すること。

運用・その他の課題

記事や機能が増えてもパフォーマンスや保守性を保てるように、ビルド、lint、Lighthouse CI、JavaScriptバジェットを組み合わせた継続的な品質確認の仕組みを作ること。

主な機能

技術記事の投稿 : Markdownによる記事管理
多言語対応 : 日本語・英語のコンテンツ提供
作品一覧 / 詳細 : 開発プロジェクトの詳細な背景や技術選定を掲載
View Transitions : シームレスで自然なページ遷移

担当・役割

Next.jsからAstro構成への移行判断
サイトコンセプト・情報設計
UI/UX設計・スタイリング (Tailwind CSS v4)
Astroによるフロントエンド実装
Cloudflare Workersへのデプロイ構成
Lighthouse CI / JSバジェットの導入と運用

技術スタック

Frontend

Astro v6
Tailwind CSS v4
TypeScript

Infrastructure / Hosting

Cloudflare Workers Static Assets
GitHub Actions

Tooling

Biome
Lighthouse CI
pnpm

システム構成

Astroで静的HTMLを生成し、Cloudflare Workers Static Assetsで配信する構成。CIでビルド・型チェック・lint・Lighthouse CI・JSバジェットを実行し品質を担保しています。

Code / Content
 ↓
lint / format / typecheck
 ↓
build (Astro Build -> Static HTML / CSS / JS)
 ↓
JavaScript Budget Check
 ↓
Lighthouse CI
 ↓
Deploy (Cloudflare Workers Static Assets)

Next.jsからAstroへ移行した判断

記事ページの主な目的は文章を読むことであり、クライアント側JSや複雑な状態管理を必要としない静的構成の方がブログに合っていると判断しました。

静的HTMLとして本文を届ける設計

クライアント側でfetchやパースを行わず、ビルド時にHTML化することで、JSのダウンロード・実行を待たずに本文を表示できるようにしました。

JavaScriptを初回表示に関与させすぎない設計

テーマ切り替えなどの機能を追加する際も、「HTMLとCSSだけで実現できないか」「後から削除しやすいか」を慎重に評価しています。

Cloudflare Workers Static Assetsへのデプロイ

動的なサーバー処理やDBアクセスを廃止し、静的アセットとして配信することで、速度・安定性・保守性のバランスを取りました。

Lighthouse CIとJavaScriptバジェットによる継続計測

機能追加による肥大化を防ぐため、JS gzip合計50KBのバジェットを設定し、Lighthouse CIで複数ページを継続監視しています。

技術ブログとポートフォリオの統合

単発の作品紹介ではなく、記事や改善ログを同じ場所に蓄積し、継続的な開発の過程として自分のスキルを見せられる構成にしました。

UI/UX・デザインの工夫

装飾を増やしすぎず、本文の読みやすさとスクロールの軽さを優先した1カラム設計
View Transitionsによる、静的サイトでありながら気持ちよく移動できる遷移体感
コードブロック、見出し、関連記事への迷いのない導線設計

FCP 0.5〜1.0s、TBT 0〜50msなどの厳格なパフォーマンス目標の設定
実行環境ブレを考慮した、理想値とは別の現実的なCIしきい値の設定
適切なメタデータ（canonical, hreflang等）の整備とセマンティックHTMLの徹底

セキュリティ・プライバシー

サーバー側の動的処理やDBアクセスを持たない静的配信による攻撃面の最小化
依存関係（ライブラリ）を増やしすぎず、更新対応やセキュリティリスクを抑える運用方針

苦労した点・改善した点

課題

Next.jsからAstroへの移行判断

解決策

ブログに本当に必要な機能を整理し、不要な機能を削ぎ落とす決断をした

結果

サイト構成がシンプルになり、記事本文を素早く届けることに集中できた

課題

速さと体験のバランス

解決策

「初回表示に本当に必要か」を基準に、検索やアニメーションなどの導入を慎重に判断

結果

JSの肥大化を防ぎつつ、必要なインタラクティブ性を維持

課題

Lighthouseの数字だけに最適化してしまうリスク

解決策

スコアだけでなく、実際の表示、スクロール、遷移体感も合わせて確認

結果

数値上の速さだけでなく、実際の読書体験も優れたサイトを実現

学び

技術選定は「流行っているか」ではなく「用途に合っているか」で考えることが重要
パフォーマンス改善は一度で終わるものではなく、JSバジェットなどの継続的な監視の仕組みが不可欠

今後の展望

記事一覧ページの表示・遷移体感の改善
Worksページの情報量と見せ方の改善
多言語記事の拡充とShikiによるコード表示体験の改善

リンク

サイト: https://engineer-blog.tomoki-ttttt.workers.dev
記事: /articles/about-this-blog/
関連ページ: 爆速な技術ブログを作るために意識していること
関連ページ: About