静的サイトとCMSを併用すると起きる「共通パーツのズレ」｜二重管理をやめる方法

Webサイトの一部だけをCMSで運用していると、意外なところで問題が起きます。

その一つが、ヘッダーやフッターなどの共通パーツが複数箇所に存在してしまうことです。

自社サイトでも、静的HTMLで構築したページとDrupalで運用しているブログを同じドメイン内で併用しています。

ある日、ブログのフッターが崩れていることに気づきました。

調査してみると、単なるレイアウト崩れではありませんでした。

古いCSS、旧SNSのリンク、異なるボタン実装など、共通パーツを2箇所で管理していたことによる「ズレ」がいくつも見つかったのです。

この記事では、実際に自社サイトで起きた問題をもとに、なぜズレが起きたのか、そしてどう改善したのかを紹介します。

自社サイトで何が起きたのか

自社サイトでは、会社案内やサービス紹介などを静的HTMLで、ブログをDrupalで運用しています。

つまり、同じドメインの中に静的サイトとCMSが同居している構成です。

この構成自体は悪いものではありません。

それぞれの用途に合わせて仕組みを使い分けられるというメリットがあります。

ただし、共通パーツを両方に持たせる場合には注意が必要です。

今回、ブログのフッターが崩れていることをきっかけに調査したところ、次のような問題が見つかりました。

• 1か月以上前のCSSを読み込んでいた
• 同じ「トップへ戻る」ボタンを別々に実装していた
• 旧SNSアカウントへのリンクが残っていた
• コピーライトの表記が古いままだった
• フッターの構造にも違いがあった

一つひとつを見ると、小さな問題です。

しかし、すべての原因をたどっていくと、共通した問題が見えてきました。

同じものを2箇所で管理していたことです。

1か月以上古いCSSを配信していた

最初に見つかったのがCSSの問題でした。

ブログ側が読み込んでいたCSSのURLには、キャッシュバスターとして?v=から始まるバージョン指定を付けていました。

ところが、そのバージョンが1か月以上前のままになっていました。

本体サイト側では何度もCSSを更新しています。

そのたびにバージョンも更新していました。

一方、ブログ側の設定は手動で書き換える運用になっていました。

つまり、

1. 本体サイトのCSSを更新する
2. CSSのバージョンを変更する
3. ブログ側の設定も変更する

という作業が必要だったわけです。

そして、最後の作業が抜けていました。

その結果、ブログ側では古いCSSを読み込み続ける状態になっていました。

HTMLは新しくなっているのに、CSSだけが古い。

これではレイアウトが崩れても不思議ではありません。

同じ「トップへ戻る」ボタンが2つ存在していた

さらに調べると、ページ右下に表示している「トップへ戻る」ボタンも、静的サイト側とブログ側で別々に実装されていました。

見た目が違うだけなら、デザイン上の問題で済みます。

問題だったのは、ブログ側だけスムーズスクロールライブラリへの対応が抜けていたことです。

サイトではスクロール位置を独自に管理するライブラリを使用しています。

そのため、単純にブラウザ標準のスクロール処理を呼び出すだけでは、意図した動作にならない場合があります。

本体側では対応していたのに、ブログ側では別実装だったため、その対応が抜けていました。

同じ機能を2つ作ると、片方だけ改善され、もう片方が取り残される。

今回、それがそのまま起きていました。

SNSリンクやコピーライトも古いままだった

さらにフッターを確認すると、SNSアカウントのリンクにも違いがありました。

SNSアカウントを変更した際、静的サイト側は4箇所すべて新しいURLに変更していました。

ところが、ブログ側には2箇所ほど旧アカウントのURLが残っていました。

つまり、ブログの記事を訪れたユーザーが古いSNSアカウントへ移動してしまう状態です。

コピーライトの表記も同じでした。

会社の英語表記を統一したあとも、ブログのフッターだけ古い表記が残っていました。

これらも、原因は単純です。

同じ情報を2箇所で管理していたからです。

問題は「注意不足」ではなく「二重管理」だった

今回見つかった問題は、どれも「直し忘れ」と言うことができます。

しかし、

「次から気をつければいい」

で終わらせてしまうと、また同じことが起きます。

なぜなら、問題の本質は担当者の注意力ではなく、同じ情報を複数箇所で管理している構造にあるからです。
 

5-1. 静的サイト側では共通化できる

静的HTMLのサイトでは、SSI（Server Side Includes）などを利用して共通パーツを外部ファイル化できます。

たとえばフッターを1つのファイルとして管理し、各ページから読み込むようにすれば、フッターを変更するときも1箇所だけ修正すれば済みます。

管理する場所が1箇所なら、「片方を直し忘れる」という問題も起きません。
 

静的HTMLとCMSを組み合わせる構成については、WordPressのように更新できるのに公開サイトは静的HTML｜CMSと表示速度・セキュリティを両立する仕組みで詳しく書いています。
 

5-2. CMS側では別の仕組みで管理する

一方、DrupalのようなCMSでは、CMSのテンプレートやテーマの仕組みを使ってページを組み立てます。

今回の構成では、静的サイト側の共通パーツをそのままCMS側でも同じように管理することができず、結果として同じ内容を別々に持つことになっていました。

理由としては、SSIはWebサーバーが静的ファイルを配信するときに処理する仕組みで、CMSが動的に生成したHTMLには効かなかったからです。

ここから、

「本体を更新したら、ブログ側も更新する」

という人間の記憶に依存した運用が始まります。
 

5-3. 更新回数が増えるほどズレやすくなる

1回や2回なら、両方を更新することを覚えていられます。

しかし、更新が10回、20回と重なってくると、どこかで抜けます。

特に、今回のキャッシュバスターのように更新するたびに値が変わるものは、人間が手作業で管理するのに向いていません。

実際、今回見つかった取り残しは次の5つでした。

• SNSアカウントのURL
• コピーライトの表記
• フッターの構造
• CSSのバージョン
• トップへ戻るボタンの実装

すべて別々の問題に見えますが、根本には同じ原因があります。

「同じものを2箇所に持っていた」ことです。

どう解決したか

「今後は気をつける」ではなく、できるだけズレにくい構造へ変更することにしました。
 

6-1. CSSのバージョンを自動生成する

まず、キャッシュバスターを手動で変更する方式をやめました。

本体ファイルの最終更新時刻を利用して、バージョンを自動生成する方式に変更しました。

Drupalの場合、テーマ側のライブラリ定義などを調整することで、このような仕組みを実装できます。

ただし、CMS側にもキャッシュがあるため、設定やファイルを変更した場合はキャッシュのクリアが必要になることがあります。
 

6-2. 重複していた機能を1箇所に寄せる

「トップへ戻る」ボタンについては、ブログ側の独自実装を削除しました。

静的サイト側で使用しているJavaScriptをブログ側でも利用していたため、ブログ側には必要なHTMLだけを配置する構成に変更しました。

これによって、

• 見た目を統一できる
• 本体側のスクロール処理を利用できる
• 今後の修正箇所を減らせる

というメリットが得られました。

同じ機能を2つ持つ必要がないのであれば、1つにまとめる。

これが一番シンプルな対策です。
 

6-3. すべてを一度に統合しない

一方、フッターについては、今回は完全な共通化までは行わず、まず内容を揃えるところまでにしました。

本体側の共通パーツには、HTMLだけでなくJavaScriptなどの読み込みも含まれています。

これをそのままCMS側へ持ってくると、同じライブラリを二重に読み込んでしまう可能性があります。

そのため、完全に共通化するには、HTML部分とスクリプト部分を分離するなど、もう一段階構成を整理する必要があります。

ここで重要なのは、すべてを一度に直そうとしないことです。

変更範囲が大きくなるほど、別の問題を引き起こす可能性も高くなります。

まず影響範囲の小さい部分から改善する。

これもWebサイトの保守では重要な考え方です。

手作業と自動化はどう使い分けるか

ここまで読むと、

「全部自動化すればいいのでは？」

と思うかもしれません。

しかし、すべてを自動化する必要はありません。

自動化にも、開発や保守のコストがかかります。

判断のポイントは、その情報がどのくらいの頻度で変わるかです。

毎回変わるものを人間の記憶だけで管理するのは、ミスが起きやすい設計です。

一方で、年に1回しか変わらない情報のために複雑な仕組みを作る必要もありません。

自動化するべきものと、手動で管理してよいものを分ける。

これが現実的な運用です。

2箇所管理になっているサイトはどう確認するか

すでに静的サイトとCMSを併用している場合は、まず共通部分に違いがないか確認してみてください。

今回は、実際に公開されているページのHTMLを取得して比較しました。

ブラウザで見た目を比べるだけではなく、

• 読み込んでいるCSS
• 読み込んでいるJavaScript
• CSSやJavaScriptのバージョン
• 共通パーツのHTML
• SNSなど外部リンク

といった情報を比較すると、違いを見つけやすくなります。

特に、片方のサイトを更新したときは、もう片方にも影響がないか確認する習慣を作るとよいでしょう。

ただし、これも最終的には人間による確認です。

長期的には、「確認する」のではなく「ズレにくい構造にする」ことが重要です。

まとめ

静的サイトとCMSを併用する構成は、それぞれのメリットを活かせる便利な方法です。

ただし、共通パーツや機能をそれぞれに実装すると、徐々に違いが生まれていきます。

• 同じ情報を2箇所で管理すると、更新漏れが起きやすい
• 更新頻度の高い値は自動化した方がよい
• 同じ機能を複数実装するより、1箇所に寄せた方が保守しやすい
• すべてを一度に統合せず、影響範囲を考えて段階的に改善する

今回見つかった5つの問題は、どれも単体では大きな不具合ではありませんでした。

しかし、1か月以上古いCSSを配信していたことには、フッターが崩れるまで気づきませんでした。

「気づけなかったこと」そのものが、今回一番の問題だったと思います。

Webサイトの保守では、担当者が頑張ってミスを防ぐよりも、そもそもミスが起きにくい構造にしておく方が重要です。

静的サイトとCMSを併用している方は、一度、両方のページで共通パーツや読み込んでいるCSS・JavaScriptに違いがないか確認してみることをおすすめします。