【Coding Toolkit】小さなツール26種を「作りながら」学んだこと

ナビの「Coding Toolkit」、実は自作なんですねー

そうなんです。今回は最適化の話をお休みして、あれを作ったときの話を書きます。

何を作ったか

Coding Toolkit は、フロントエンドの作業でよく使う小さなツールを集めたサイトです。

サイズ（clamp生成／px⇄rem変換／余白スケール）
カラー（表記変換／コントラスト比チェック）
CSSジェネレーター（影・グラデーション・角丸・三角形・アニメーションなど11種）
変換・エンコード（Base64・URL・HTMLエンティティ・画像→data URI）
テキスト（整形・正規表現・文字数カウント・ダミー文・差分・日付計算）

ここに用語集37語を加えて、合計33ページです。ぜんぶブラウザの中だけで動きます。サーバーに何かを送ることも、外部のAPIを呼ぶこともしていません。入力した内容が自分のブラウザの外に出ないので、ちょっとした個人情報が混ざったテキストの整形にも気にせず使えます。

1ツール＝1URLにした理由

最初は「サイズのツールまとめページ」のように、カテゴリごとに1ページへ全部詰め込む作りでした。使う分には十分なんですが、作り直すときに気になったのが検索のされ方です。

「CSS box-shadow ジェネレーター」で検索した人に、box-shadow専用のページを見せたい。まとめページの真ん中にあるツールの1つ、では届きにくいんです。そこで26個のツールに26個のURLを割り、カテゴリ一覧・トップと合わせて全33ページの構成に組み直しました。

ページ数は増えますが、1ページの役割が「この計算のことだけ」に絞られるので、canonicalやOGタグ、サイトマップも機械的に整理できます。ページを分けたことで逆にシンプルになった部分です。

作りながら踏んだ落とし穴

ビルドの仕組みはシンプルで、共通パーツ（CSS・JS）と各ページのHTML断片を、スクリプトで1つずつのページに合成しています。作業自体は単純なんですが、環境がらみで2回ほど痛い目にあいました。

1つ目は、コメント1行でファイルが全部0バイトになった話。ビルドスクリプトに日本語のコメントを書いたら、出力されるHTMLが軒並み空っぽになりました。エラーは出ません。原因は文字コードでした。UTF-8で保存したはずのスクリプトを、実行環境が別のエンコーディングとして読み込んでしまい、日本語の直後で構文の解釈が崩れていたんです。文字列の中の日本語ではなく、コメントの日本語だけでも起きるのがやっかいなところでした。

対策は「スクリプト本体はASCIIだけで書き、日本語が必要な文言は外部のテキストファイルに追い出す」でした。タイトルや説明文をスクリプトの中に直接書かず、別ファイルから読み込む形にしたら、以後は再発していません。

2つ目は、コピーコマンドのオプション1つで「何もコピーされない」事件。ファイルを丸ごとコピーする処理で、日本語パス対策として使っていた厳密一致のオプションを、ワイルドカード（*）指定と一緒に使ってしまいました。厳密一致のオプションは文字どおり厳密で、*を「その文字そのもの」として扱うため、該当するファイルが存在せず、静かに何もコピーされずに終わっていました。

幸い、直す前にバックアップを取る手順にしていたので、実害はありませんでした。「日本語パスに強いオプション」と「ワイルドカードが効くオプション」は、両立しない場面がある、というのがここでの教訓です。

「難読化」をやめた話

作業の途中まで、配布用のJS・CSSに簡単な「難読化」（コメントと空行を削る処理）を入れていました。見た目にはそれっぽく縮んだんですが、あるとき効果を測ってみたら4.4%、わずか2.2KB程度しか小さくなっていませんでした。

そして、消していたコメントの中身をよく見たら「/* box-shadow */」のような、セクションの見出しになっているだけの、読む人を助けるコメントでした。秘密の計算式が入っているわけでもないツールで、読みやすさを削って得たものが2.2KBだけ。これは割に合わないと判断して、難読化そのものをやめました。

ファイルサイズを本当に削りたいなら、サーバー側のgzip圧縮の方がずっと効きます。何かを消して読みにくくする前に、「それ、本当に効果ありますか」を一度測ってみるのが大事だと学びました。