フリーランスエンジニアのサイト運営｜Lighthouse Performance 81→99 に改善した話

フリーランスエンジニアとして自分のサイトを運営していると、避けて通れないのがサイトのパフォーマンスです。

「個人サイトなんだから表示速度は気にしなくていい」と思うかもしれません。でも、実はフリーランスにとってサイトのパフォーマンスはビジネスに直結します。

この記事では、このサイト（Startup School）のLighthouseスコアをPerformance 81→99に改善した話を、フリーランスのビジネス視点で紹介します。

なぜフリーランスにとってサイト表示速度が重要なのか

Google検索順位への影響

Googleは2021年からCore Web Vitalsをランキング要因に組み込んでいます。特に重要なのがLCP（Largest Contentful Paint）で、「ページのメインコンテンツが表示されるまでの時間」を測る指標です。

2.5秒以下: Good（検索順位にプラス）
2.5〜4.0秒: Needs Improvement
4.0秒以上: Poor（検索順位にマイナス）

このサイトはLCP 3.8秒でNeeds Improvement。検索順位で不利になっている可能性がありました。

コンバージョン率への影響

Googleの調査によると、ページの読み込みが1秒から3秒に遅くなると、直帰率が32%増加します。5秒になると90%増加。

フリーランスのサイトで言えば、「エージェントに登録してみよう」と思ってクリックしたのに、ページが表示されるまでに3秒以上かかったら、その人は離脱します。せっかくの見込み客を表示速度で失っていることになります。

技術力の証明

これはフリーランスならではの話ですが、自分のサイトが遅いエンジニアに仕事を頼みたいでしょうか？

クライアントがエンジニアを探すとき、その人のサイトやポートフォリオを見ることがあります。そのサイトが遅かったら「この人、パフォーマンスのこと考えられないのかな」と思われます。逆に、サイトが速ければ「ちゃんとしてるな」という信頼感に繋がります。

改善前のスコア

Lighthouseでモバイルを計測した結果がこちらです。

指標	スコア
Performance	81
Accessibility	96
Best Practices	100
SEO	100

SEOは満点なのに、Performanceだけが足を引っ張っていました。

Core Web Vitalsの詳細:

指標	値	評価
FCP	3.1秒	Poor
LCP	3.8秒	Needs Improvement
TBT	40ms	Good
CLS	0	Good
SI	4.5秒	Poor

ボトルネックはどこにあったか

LCPの内訳を分析すると、**Render Delay（レンダリング遅延）が2.7秒で全体の72%**を占めていました。

ブラウザはHTMLを受け取っているのに、画面にテキストが表示されるまで2.7秒もかかっている状態です。

原因を調べたら2つ見つかりました。

原因1: Google Analytics 4のスクリプトが表示をブロックしていた

GA4のスクリプト（155KiB）を「ページ表示前に読み込む」設定にしていました。つまり、GA4のダウンロードと実行が終わるまで、ページが表示されない状態になっていたのです。

GA4はページの見た目には一切関係ありません。ユーザーが見るコンテンツには不要なスクリプトなのに、それがページ表示を止めていました。

原因2: 使っていないフォントを読み込んでいた

Webフォントを2つ（Geist Sans + Geist Mono）読み込んでいましたが、Monoフォント（28KiB）を使っている箇所を検索したらサイト全体で3箇所しかありませんでした。しかもタイムラインの年代ラベル（2012~ NOW）だけです。

28KiBのフォントファイルを3箇所のためだけにダウンロードさせていました。

何をやったか

GA4の読み込み方法を変更

Next.jsの公式推奨ライブラリに移行しました。これを使うと、GA4スクリプトはページの表示が完了した後に読み込まれます。

ユーザーがCTAボタンをクリックする頃にはGA4は読み込み済みなので、計測に影響はありません。むしろ、以前の設定ではGA4の初期化タイミングが不安定で、リアルタイムレポートがうまく動かないことがありました。移行後は正確に動くようになり、パフォーマンスと計測精度の両方が改善しました。

使っていないフォントを削除

Geist Monoフォントを完全に削除しました。3箇所の年代ラベルはシステムフォントで表示するようにしましたが、見た目はほぼ変わりません。

フォントリクエストが2つから1つに減り、ダウンロード量が59KiBから31KiBに47%削減できました。

フォントの表示設定を最適化

残したフォント（Geist Sans）の表示設定を変更し、フォントのダウンロード中でもフォールバックフォントでテキストが表示されるようにしました。LCP要素がテキスト（<h1>）だったので、この設定だけでもLCPが改善します。

改善結果

指標	改善前	改善後	変化
Performance	81	99	+18
FCP	3.1秒	1.3秒	-58%
LCP	3.8秒	2.3秒	-39%
TBT	40ms	20ms	-50%
SI	4.5秒	2.3秒	-49%

LCPは3.8秒→2.3秒に改善し、Googleの「Good」基準（2.5秒以下）をクリアしました。

作業時間は合計20分程度です。大がかりなリファクタリングは一切していません。

やらなくてよかったこと

Lighthouseは「未使用JavaScript 27KiB」も指摘していました。中身を調べたら、Next.jsのフレームワーク内部コード（ルーティングやハイドレーション処理）でした。ページ遷移には必要なコードで、削減しようがありません。

Lighthouseの指摘を全て潰す必要はありません。 中身を確認して、自分で対処できるものとフレームワーク由来のものを切り分けることが大事です。

フリーランスエンジニアへの示唆

今回の改善で感じたことをまとめます。

自分のサイトは最高の技術デモ

フリーランスエンジニアにとって、自分のサイトはポートフォリオでありデモサイトでもあります。Lighthouseで90点台後半を出せていれば、クライアントからの信頼にも繋がります。

「動いているから大丈夫」は危険

GA4を「ページ表示前に読み込む」設定にしていたのは、以前にGA4の計測がうまく動かなかった時の対処療法でした。「動いているからいい」と放置していましたが、実はパフォーマンスを大幅に劣化させていたのです。

フリーランスとして複数のプロジェクトを経験していると、「まず動くものを作る → 後で最適化する」が身についています。でも「後で」を忘れがちです。定期的にLighthouseを回して、パフォーマンスの劣化に気づく仕組みが必要です。

使っていないものを消すだけで速くなる

28KiBのフォントを消しただけでスコアが上がりました。コードを書くのではなく、不要なものを見つけて消すだけでパフォーマンスは改善します。

使用箇所を検索して3箇所しかないと分かった瞬間、「これだ」と思いました。こういう地味な調査が一番効きます。

まとめ

フリーランスのサイト表示速度は、検索順位・コンバージョン率・技術力の証明に影響します
今回はGA4の読み込み方法変更と不要フォントの削除だけで Performance 81→99 に改善しました
作業時間は約20分。大がかりな改修は不要です
Lighthouseの指摘は全て潰す必要はありません。中身を見て判断しましょう
フリーランスエンジニアなら、自分のサイトのパフォーマンスにはこだわるべきです

エージェントの比較や案件の探し方については、エージェント3社比較やフリーランスの始め方で詳しく解説しています。