リニューアルでやったこと

WordPressからEleventyへ

WordPressをやめて静的サイトジェネレーターにしようという計画はかなり前から持っていて、2015年9月の近況報告あたりでは完全にそのつもりでいた記憶があります。

WordPress自体には好意も敵意も持っていませんが、ウェブ制作業界に入ってから現在の会社に入る前まで、かなりの時間をWordPressを使ったウェブサイトの制作に使っていた気がします。
WordPressはウェブサイトを作る上では、ほぼなんでもできる（できてしまう）ので、様々な案件をこなしたと思います。WordPressを主戦場にしている方々からすれば新兵もいいところでしょうが。

それはともかく、WordPressはアップデート時の各種バックアップやら、管理画面へ辿り着こうとするbotのアクセスやら、とにかく面倒で、ほとんど字ばかりの自分のサイトでこんな面倒なことを続けていくのは耐えがたく、早く静的サイトジェネレーターに移りたいという思いでした。

そもそもWordPressでブログを作ったのは、右も左もわからないような頃に「流行っているから」という理由で選びました。それからしばらくはWordPressをいじるのは楽しかったです。仕事にも役立ったので嫌いにはなりませんでした。

WordPressデータのエクスポート

これまでの作り直しの挫折にはデータの移行が面倒くさいという問題がありました。記事のスラッグ、パーマリンク、ISO 8601形式の日付、記事内容、それらすべてを手動でコピーし、HTMLファイルに貼り付けるという不毛な作業をしては挫折していたのです。

同じ轍を踏まないように、今回はWordPressのREST APIを利用しました。いま思えばSQLで処理したほうが楽だったのかもしれませんが、なるべく普段使っているものでさくっと済ませたかったのです。
APIから取得したデータをNode.jsで処理して、1記事1ファイルに書き出して移行が終了しました。

サーバーへのデプロイと、ブランチ別プレビュー

当初の予定としては、GitHubのmasterブランチにpushされたら、CIでビルドして、ビルドされたファイルをサーバーに置いてあるリポジトリにpush --forceして公開、という流れを予定していました。

サーバーにSSHでログインしてGitをインストールし、Oracleに買収される前のwerckerで実際にデプロイするところまで進んでいましたが、月日が流れてwerckerのアカウントが完全にわからなくなってしまいました。

リニューアル後のデプロイ方法を替える予定はなかったため、CircleCIあたりでやろうかと思っていましたが、昨年GitHub Actionsが使えるようになったことを思い出し、「これはCIサービスを使わないでもいけるのではないか」と考え直しました。

最終的にはAEnterprise/rsync-deployを使い、SSHとrsyncでデプロイできました。

また、masterブランチ以外をNetlifyでビルド、ホスティングし、変更や記事追加時のプレビューとしています。

リニューアルの目標としていたもの

リニューアル前まではよくある2カラムのブログでいろいろな飾りがついたデザインをしていましたが、作り直しにあたって、メインのコンテンツに集中できて、すぐ読めるように速いサイトを目指していました。

ナビゲーションがページの一番下にあるのは、記事を見に来てロゴの次に目に入るのがナビゲーションというのは目標から外れるのではないか、という考えからです。はじめは一番上のロゴも外そうかと考えていましたが、左上にロゴがあるという共通認識を崩すのは逆にわかりづらいのではないかという疑問があります。結局、ページの先頭のロゴがあるのとないのでは、どちらがより集中できてわかりやすいのか判断できなかったため、既存のまま残すことにしました。

読みやすさは文字の大きさと行間（line-heightではない）を意識して作っています。
以前から、海外製のバーティカル・リズムを実現するCSSライブラリなどを見ていると、見出しの行間が文字サイズによってスカスカすぎたり詰まりすぎているのではないか（1行なら問題ない）という印象を受け、それならば本文も見出しも行間が同じサイズになるようにすればよいのではないかと考えていました。
ちょうどよい機会だったので、今回はそれを採用しています。

文字サイズのリズムについては「文字サイズの比率と調和」を参考にしています。
上下に広がる空白については、基本となる文字サイズが取る1行の高さを基準に、N倍整数倍したものを使っています。

また、今回はボーダーの数をとにかく減らしたいという気持ちがあったのですが、どうやっても読みづらくなってしまう場面があったので、そういった部分にはじゃまにならない程度にボーダーを使っています。

色に関しては、背景色floralwhiteを必ず使いたい、という点からスタートし、その色を基準にColorHexaで色を選んで調整しました。

結果として読みやすいかどうかは、作った自分では判断が難しいところですが、読みやすくなっていたとしたら幸いです。

速度面については、Lighthouseによる計測では、パフォーマンスの項目がGoogleアナリティクスの読み込みで減点されている以外はかなりよい点数が出ています。
自分の体感としても問題ないのではと思います。

HTMLについて

section要素が存在しなかった時代の記事には<div class="section">などといったものが存在していたため、その手の古いものはすべて書き直しました。

記事以外に関しては、なるべくシンプルに、WAI-ARIAも可能な限り使わない、そういったマークアップを心がけていますが、まだまだ未熟でよくわからない、という感想を得ました。

HTMLを圧縮していることについて、「なぜHTMLを圧縮しているのか、それより他にやることがあるだろう」という意見はよくわかりますが、HTMLを自分の好みに整形するツールがないので、それならば圧縮してしまったほうがいっそ清々するという気持ちでやっています。

リニューアルお知らせ記事の公開後、数名にclass属性値について言われましたが、HTMLについているクラス名はposthtmlのプラグイン「posthtml-minify-classnames」で自動生成しているものです。
公開用のファイルにはsourcemapもないので、クラス名を変えてしまっても問題ないし、面白そうだからやってみようと思って採用しました。GitHubに置いてあるソースを見ればわかりますが、もともとは普通のクラス名です。
このプラグインの面白いところは、スタイル指定がないクラス名をHTMLから除いてくれるところです。CSSをstyleタグ内にまとめ、Purgecssで使っていないスタイルを削除し、posthtml-minify-classnamesでクラス名を短くしつつ、使っていないclass属性値を削除し、html-minifierで圧縮、という流れです。

CSS周り

そこそこ新しめの機能を使っていますが、基本的にはInternet Explorer 11でも特に問題なく閲覧できます。色の指定にCustom Propertiesを使っているので、IE 11ではすべての色がブラウザーで設定されているとおりになります。

旧Microsoft Edge（EdgeHTML版）とIE 11では、ページ最初にあるロゴのマウスオーバーによるアニメーションがない以外は問題ありません。
あのロゴのアニメーションにはclip-pathを使っているのですが、それが使えない環境では普通のロゴが表示されるようにSVGを作成しています。
ページを構成する要素で一番CSSの指定が多いのがロゴの部分です。

アーカイブのページで地味にSubgridを導入していますが、使えなくても大丈夫なレイアウトなので、使ってみたかっただけ感が出ています。

フォントの指定はsans-serifとmonospaceの指定のみです。お好きなフォントでご覧ください。
本音を言うと「速度を考えるとウェブフォントは使いたくないが、デバイス・フォントの指定はもう自分のサイトではやりたくない」と思ったからです。気が向いたら何か指定するかもしれませんが、いまのところ満足しています。

他にも細々したことをしていますが、それは別の記事で紹介します。

JavaScriptは使わない

JavaScriptはこのサイトには使う必要ないだろうと判断した結果、Googleアナリティクスの外部ファイル以外は存在しません。

もしかすると404ページで使うかもしれないな、という程度です。