あの日の午後、私は席でサボっていたら、突然グループチャットが騒がしくなった——GitHubが開けない。最初は会社のネットワークの問題かと思ったが、Twitterを見ると世界中の開発者が悲鳴を上げていた。誰かが冗談で「人類史上、生産性が最も急落した日かもしれない」と言っていた。私も最初は笑っていたが、自分のプロジェクトがちょうどその日にリリース予定だったことに気づくまでは。
事の次第はこうだ。手元に小さなプロジェクトがあり、フロントエンドのリソースをビルドすると約3MBのJSコードになる。普段のデプロイはCIを通しているが、GitHubが落ちたためCIが動かず、ローカルでビルドしたファイルを手動でサーバーにアップロードするしかなかった。アップロード中、なぜ今回こんなに遅いのか不思議に思った。プログレスバーがカタツムリのように遅い。10分近く待ってようやくアップロードが完了したが、ページを開くと真っ白だった。
サーバーの問題かと思い、ログを半日調べた結果、ファイル転送中に何か問題が起き、コードに奇妙な文字が混入していた。その時は呆然とした。リリースまであと30分、再ビルドは間に合わない、ロールバック用のバックアップもない。その瞬間、普段からコードを圧縮する習慣があれば、ファイルは半分になり、転送エラーの確率もずっと低くなり、もしかしたら間に合ったかもしれないと本当に実感した。
その後どう解決したか？以前適当に保存しておいたオンラインツール「JSフォーマット圧縮」を引っ張り出した。普段は全く使わない。コードが動けばいい、圧縮なんてどうでもいいと思っていた。しかしあの日は藁にもすがる思いで、ローカルの3MBのソースを放り込み、圧縮をクリックすると、数秒後に1.2MBのファイルが出てきた。急いでアップロードし、壊れたファイルを置き換え、ページを更新すると、直った。
その瞬間、画面を見つめながら、心中複雑だった。コード圧縮なんて、普段は地味で、むしろ余計に思える——今はネット速度も速く、帯域も安い、誰がそんな容量を気にする？しかし、GitHubが落ちたり、CIが止まったり、ネットワークが不安定になったりすると、小さな容量こそが正義だと気づく。流量を節約するだけでなく、転送時間を短縮し、エラーの確率を下げ、いざという時にあなたを救う。
しかも正直、コード圧縮の利点はこれだけではない。圧縮したコードは、他人がロジックを覗こうとしても手間がかかる。暗号化とは言えないが、少なくとも右クリックでソースを表示するような人たちをある程度防げる。また、圧縮後のファイルは読み込みが速く、ユーザー体験も良い。特にモバイルでは、数百KB減るだけで白画面が1秒減るかもしれない。以前は些細なことだと思っていたが、あの経験以来、完全に考えを改めた。
今の私の習慣は、ビルド後に必ずJSフォーマット圧縮を通してからデプロイすることだ。手間はかからないが、安心できる。明日と意外のどちらが先に来るかはわからない。GitHubは落ちる、CIは止まる、ネットワークは不安定になる。しかし、圧縮された小さなファイルは、常に最も安定したバックアップ手段だ。
だから、事が起きてから後悔しないように。普段から圧縮しておけば、いざという時に命を救える。これは高度な技術ではなく、簡単な習慣に過ぎない。しかし、往々にしてそうした小さな習慣が、あなたが慌てふためくか、冷静に対処できるかを決めるのだ。