ウェブデザイナーをしているのに、自分のサイトだけがずっと後回しになっていました。クライアントのサイトは作るのに、自分のポートフォリオは「そのうち」のまま。
今回ようやく重い腰を上げて、ポートフォリオサイト（nigo-web.com）を立ち上げました。ポイントは3つです。
- 月額0円（すでに持っていた独自ドメインの更新料以外、かかっていません）
- スマホから更新できる（記事を書くのにPCを開かなくていい）
- 表示が速い（Lighthouseは全項目100点）
作りながらつまずいたところも含めて、全部書いておきます。同じように「自分のサイトを作りたいけど、続く気がしない」という人の参考になれば。ちなみに、この記事を書いている今も「明日も更新できるだろうか」とちょっと不安です。
なぜ作り直したのか
理由は2つありました。
ひとつは、転職やクラウドソーシングなどで「見せる場所」が必要だったこと。実績を聞かれたときに、URLを1つ渡せば良い状態にしておきたかった。
もうひとつが本題で、ポートフォリオサイトは「作って終わり」になりがちだということ。実績が増えたときに更新しようと思っても、結局そのまま放置してしまう。過去に作ったサイトが、まさにそうでした。
だから今回は、ブログを軸にしたポートフォリオにしました。毎日開いて更新する場所にしてしまえば、サイトが死なない。それに、実績一覧をきれいに並べるより、日々書いているものを読んでもらったほうが、自分がどういう人間かは伝わるんじゃないかと思ったんです。
「毎日スマホでSNSを開くみたいに、自分のサイトを開く」。それが今回の裏テーマでした。
WordPressではなくAstroを選んだ理由
最初はWordPressも普通に候補でした。情報は圧倒的に多いし、プラグインで何でもできる。
それでも今回 Astro を選んだのは、個人サイトとしての条件で考えたときに、こちらが有利だったからです。
1. 運用コストが0円
WordPressは基本的にレンタルサーバーが必要で、月500〜1,000円ほどかかります。Astroで作った静的サイトなら、Cloudflare Pagesの無料枠で公開できて0円。何年運用してもタダなのは、続ける前提のサイトでは大きい。
2. 表示が速い
Astroは基本的にJavaScriptを送らない設計で、コンテンツ主体のサイトだと素の状態でかなり速い。SEOを勉強したかったので、速度は最初から効かせておきたかった。
3. 保守がほぼいらない
WordPressは更新作業が定期的に発生するし、放置すると乗っ取りのリスクもあります。公開されるのが静的ファイルだけなら、そこを気にしなくていい。
意外と知られていない、ホスティングの落とし穴
無料の公開先といえばVercelも有名ですが、Vercelの無料プラン（Hobby）は広告掲載が規約で禁止されています。将来ちょっとでも収益化を考えるなら、ここは踏んではいけない地雷でした。
その点 Cloudflare Pagesは無料でも商用利用OK・帯域も無制限。「あわよくば収益化」の芽を残したかったので、最初からこちらを選びました。
念のため書いておくと、WordPressが悪いという話ではありません。案件の世界で需要が大きいことも知っています。今回は「個人が毎日更新する・0円・速い」という条件だったので、Astroが噛み合ったという話です。
サイトの構成
最終的にこうなりました。
- microCMS（記事の管理）… 無料プラン
- Astro（サイト生成）… 0円
- Cloudflare Pages（公開）… 無料・商用OK
- ドメイン… すでに持っていたものの更新料のみ
そして、この構成のいちばんの目的が更新フローです。
- スマホでmicroCMSの管理画面を開く（ホーム画面に追加してある）
- 記事を書いて「公開」を押す
- 数分後には本番サイトに反映されている
裏ではWebhookでCloudflareのビルドが走っているだけですが、体感としては「SNSに投稿する感覚」に近い。PCを開かなくていいというのが、続けるうえで想像以上に大きいです。
写真も同じで、GR IIIxで撮ったスナップをスマホから上げれば、そのままギャラリーに並びます。撮影日やF値・シャッタースピードは写真のExifから自動で読むようにしたので、入力する手間もありません。
こだわった細部
見た目の部分でも、いくつか手をかけています。
トーンの設計
好きな雰囲気のサイトを2つ選んで、フォント・字間・余白を実際の数値まで調べてから、自分のサイトのルールを決めました。「なんとなく似せる」ではなく、数値で分解すると再現性が出ます。
写真を主役にしたかったので、色は無彩色4つだけ。差し色は持たせていません。
写真を主役にする
トップのギャラリーは、写真が2列でゆっくり流れ続けるようにしました。撮った写真が増えるほど賑やかになるので、更新の動機にもなります。
速さ
Lighthouseはパフォーマンス・アクセシビリティ・ベストプラクティス・SEOの全4項目で100点。画像はビルド時にWebPへ変換して配信しているので、写真が多くても重くなりません。
思ったより、すんなりとはいかなかった
ここまで「こう作りました」という話ばかり書いてきましたが、実際は一直線ではありませんでした。むしろ、つまずいている時間のほうが長かったと思います。特に印象に残っている4つを書いておきます。
100点が、55点になった
表示速度をひととおり詰めて、Lighthouseで100点が出たときは素直にうれしかったです。
ただ、そのあと「日本語フォントも自分のサーバーから配信したほうが速いはず」と思って手を入れた瞬間、スコアが55点まで落ちました。表示されるまで17秒。何かの間違いだと思って測り直しましたが、何度やっても同じです。
原因は単純でした。日本語のフォントは、1書体で1MB近くある。英語フォントの感覚で太さ違いを3種類読み込んだら、3MB近くを最初に読ませることになっていたわけです。
結局、英字だけ自前で持って、日本語は外から非同期で読み込む形に落ち着きました。「自前で配信したほうが速い」という定石が、日本語では逆に働くことがある。これは覚えておこうと思います。
公開した記事の写真が、全部消えていた
最初の記事を公開して、スマホで自分のサイトを開いて、本文の写真が1枚も表示されていないのを見たときは血の気が引きました。
原因はセキュリティ設定でした。「このサイトが読み込んでいい外部サービス」をあらかじめ列挙しておく仕組み（Content-Security-Policy）があるのですが、そこに記事の画像を置いているCMSのドメインを書き忘れていたんです。画像そのものは正常に配信されていて、ブラウザ側が拒否していただけ、という状態でした。
厄介なのは、この設定はローカルでは効かないので、本番に上げるまで気づけないこと。しかも、機能を足すたびに壊れます。フォントで一度踏んで、画像でまた踏みました。
写真を差し替えたら、また点数が落ちた
仮画像を、実際にGRで撮った写真に差し替えたときのこと。見た目は完璧、動作も正常。それでも念のため測ってみたら、100点が64点になっていました。
調べると、6000ピクセルの元画像がそのまま配信されていました。リサイズの設定はしていたのに、1行だけ書き忘れていた項目があって、その場合は「元のサイズ」が使われる仕様だったんです。711KBの画像を、スマホに向かって送りつけていたことになります。
書き足したら65KBになりました。91%減です。見た目が同じだから気づけない、というのがいちばん怖いところでした。
iPhoneだけ、ガラスが曇る
キービジュアルの上に、すりガラスのような半透明のバーを置いています。Chromeで見ると狙いどおりの透明感が出るのに、iPhoneで見ると、ただの灰色の板でした。
最初に立てた仮説は、外れました。直したつもりで見てもらったら「まだ直ってない」。結局、比較用のページを作って自分のiPhoneで実際に見比べるという、いちばん原始的な方法で切り分けました。
犯人は、背景をぼかす指定そのものでした。iOSのSafariは、この指定を「ぼかし」ではなく「不透明なグレー」として描いてしまうことがあるらしい。ぼかしをやめて、色の重ね方だけで質感を作る方向に変えたら、ようやく両方で同じに見えるようになりました。
こうして並べてみると、4つのうち3つは「見た目は正常なのに壊れている」タイプでした。目で見て確認するだけでは足りなくて、数字で測るか、実機で確かめるかしないと気づけない。今回いちばん学んだのは、たぶんこれです。
これから
まだ中身はスカスカですが、ここから毎日書いていこうと思っています。Web制作とAIのこと、好きなApple製品のこと、GRで撮った写真、それとなんでもない日常のこと。
作って終わりにしないための仕組みは、ひととおり用意できました。あとは書くだけ、なんですが、それがいちばん難しいことも知っています。とりあえず明日、GRで撮った写真を1枚上げるところから始めます。
制作のご依頼やご相談も受け付けているので、お気軽にどうぞ。これまでの制作実績も頑張って更新していきます。
