ますます多くのウェブサイト運営者が Google Fontsをローカルに統合訪問者の個人データをよりよく保護するために。動的に統合されたフォントは、明示的な同意なしにGDPRに違反し、警告のリスクが高まります。
中心点
- データ保護ダイナミックGoogleフォントは、GoogleサーバーにIPアドレスを送信します。
- 法的確実性地域統合は警告や罰金のリスクを減らす。
- ウェブサイトのパフォーマンス自社サーバーは、多くの場合、外部ソースよりも速くフォントを配信します。
- プラグインOMGFのようなツールは、ローカル統合をかなり単純化する。
- テーマのカスタマイズフォントはCSSで明確に置き換えられ、外部リンクはすべて削除されなければならない。
なぜ動的統合が問題なのか
多くのテーマやプラグインは、デフォルトでGoogle API経由でGoogle Fontsを使用しています。これは、ページにアクセスするたびに、訪問者のIPアドレスが米国のサーバーに送信されることを意味します。ミュンヘン地方裁判所の判決によると、これは同意のないデータ保護違反にあたる。さらに、ユーザーがこの送信に特に異議を唱える方法はない。このため、多額の罰金や高額な警告を受けるリスクが大幅に高まる。
個人データが同意なしにEU域外のサーバーに送信されると、すぐにGDPRに違反します。グーグルがフォントは個人データを収集しないと主張しても、IPアドレスだけでもデータ保護に影響を与えることは明らかです。
Google Fontsのローカル統合の仕組み
ローカル統合とは、ご自身のサーバーにフォントを保存することです。これにより、ウェブブラウザがGoogleにサーバーリクエストをする手間が省け、あなたのドメインから直接ファイルを取得することができます。これが、ステップ・バイ・ステップの仕組みです:
- オープン fonts.google.com をクリックし、必要なフォントとバリアントを選択します。
- フォントをダウンロードし、.woff2ウェブ・フォーマットに変換します。 グーグルウェブフォントヘルパー.
- .woff2ファイルをFTPまたはバックエンドから/wp-content/fonts/のようなサブフォルダにアップロードします。
- を完了する。
フォント・フェイス-コマンドをあなたのウェブサイトのCSSに入力し、フォントのパスを入力してください。
CSSコードの例:
フォントフェイス
font-family: 'OpenSans';
src: url('/wp-content/fonts/OpenSans-Regular.woff2') format('woff2');
font-weight: 400;
font-weight: 400; font-style: normal;
}
そして、それをウェブサイトのスタイルシートで使用する: font-family: 'OpenSans', Arial, sans-serif;
WordPressでGoogle Fontsをローカルに統合する
WordPressは特に、テーマやプラグインを介した不要なGoogle Fonts統合の影響を受けやすい。見落とされがちな原因は、Elementor、Divi、WPBakeryなどのプリインストールされたウィジェットやビルダーです。そのため、"Google Fonts Checker "のようなツールで徹底的にチェックする価値がある。以下のような目に見える接続 fonts.googleapis.com 或いは fonts.gstatic.com を完全に取り除かなければならない。
フォントを変更する前に子テーマを作成するのがベストです。そうすることで、テーマのアップデート後も変更が保持されます。子テーマのフォルダにフォントをロードし、CSSに保存場所をリンクします。また、プラグインを使用することもできます。
ローカル統合に役立つプラグイン
プラグインは、特に技術力の低いユーザーにとって、物事をより簡単にします。いくつかのツールは、自動的に外部フォントをローカルバージョンに置き換えます:
- OMGFこのプラグインは自動的に使用されているGoogleフォントを認識し、ローカルに保存し、外部からの呼び出しを置き換えます。有料のProバージョンは、拡張キャッシュとカスタムフォントのサポートを提供しています。
- 自動最適化キャッシュ機能に加え、Autoptimiseはフォントの埋め込みもコントロールできます。特にElementorやDiviを設置する場合に実用的です。
- フォント・プラグイン・プロほとんどの一般的なページビルダーと互換性があります。WordPressメニューによる直感的な操作。
Google Fontsをページビルダーにローカルに統合する
Diviユーザー テーマの設定で外部フォントの読み込みを無効にすることができます。ローカルフォントは、Divi Customiserを使用するか、子テーマに追加して統合します。
エレメンタ には、カスタムフォントエリアに独自のフォントをアップロードして使用するオプションがあります。自動リロードは、コードスニペットを使用して無効にする必要があります:
add_filter( 'elementor/frontend/print_google_fonts', '__return_false' );
時点では WPベーカリー ローカル統合は、CSSを直接カスタマイズすることで手動でのみ機能しました。フォントはテーマまたは子テーマに配置し、明示的に参照する必要があります。
複数フォントの管理
多くのプロジェクトでは、単一のフォントだけでなく、複数のフォントスタイル、あるいは異なるフォントファミリーが使用されます。そのため、フォントの管理が混乱することがあります。正しく動作させるためには、まず、どのフォントがどの場所で使われているかをメモするか、スタイルシートをチェックする必要があります。
特にElementorやDiviのようなページビルダーを使用している場合、モジュールごとに異なるフォントを読み込むことができる。例えば、見出しは "Open Sans"、本文は "Roboto "で作成できます。また、太字や斜体のフォントスタイルもある。フォントとそのバリエーションを体系的に記したリストを作成するのがベストです。これにより、必要なフォントの一部だけをローカルに統合することを防ぐことができます。フォントスタイルが欠落していると、表示エラーが発生したり、個々のスタイルがGoogleサーバーから取得され続けたりすることがよくあります。
でダウンロードする場合 グーグルウェブフォントヘルパー を使えば、通常、必要なフォントスタイルや言語サポートをすぐに選択できます。これにより、ファイルサイズを最小限に抑えるだけでなく、外部サーバーへの不要なリクエストを避けることができます。
典型的な過ちとそれを避ける方法
アップデート後、テーマは外部フォントを再び有効にすることができます。そのため、DevToolsを使って、Googleからフォントが許可なく読み込まれていないか定期的にチェックしてください。マルチサイトの場合は、各ページを個別にチェックする必要があります。プラグインは、テーマがすでにカスタマイズされている場合でも、フォントを再統合することができます。
また、クローラーツールキットやブラウザの拡張機能を使用して確認してください。一部のフォントスタイル(斜体、太字)が欠落している場合、視覚的な違いが生じることがあります。ダウンロードの際には、使用されているすべてのフォントバリエーションを選択するようにしてください。もう一つの間違いは、フォントのプリロードを忘れることです。ローカルに大きなフォントファイルを提供する場合、ヘッダーコードでプリロードすることで、レンダリング時間を最小限に抑えることができます。
本番稼動前の重要事項
プロジェクトを本番稼動させたり、既存のページの最終的な変更を有効にしたりする前に、ステージング環境や開発環境でのテストフェーズをお勧めします。そこで以下をチェックできます:
- スムーズなレンダリングすべてのフォントが機能し、テキストブロックが正しく表示されていますか?
- フォントスタイルの欠落太字、斜体、その他の変形をフロントエンドで明示的にテスト。
- 削除されたCSSコンポーネントテーマ内に古いコードが残っていることがあります。fonts.googleapis.comに古い@import命令がないことを確認してください。
- キャッシュとCDNCDNを使用している場合、または積極的なキャッシュを有効にしている場合は、フォントの変更も配信されるようにする必要があります。必要であれば、古いバージョンを避けるためにキャッシュをクリアしてください。
- 切り替え前のバックアップフォントを置き換える前にウェブサイトとデータベースの完全なバックアップを作成し、必要に応じてすぐに以前の状態に戻せるようにしてください。
このような徹底的なチェックにより、不具合を減らし、エラーのない、データ保護に準拠したサイトを訪問者に提供することができます。透明性を確保することは、複数人でウェブサイトを作成する場合に特に重要です。 フォント・フェイス-ルールまたは使用するプラグイン。
地域統合によるパフォーマンスの向上
ローカルフォントはデータ保護リスクを軽減するだけでなく、ウェブサイトの読み込み時間を改善することもよくあります。外部サーバーへのリクエストがないため、フォントコンテンツはホスティングサーバーから直接配信されます。webhoster.deのような高速なホスティングサーバーでは、このことが明らかなメリットをもたらします。また、フォントのアクセスとバージョンはあなた自身のコントロール下にあるため、キャッシュをより効率的に制御することができます。
単純に比較すれば、ダイナミック・インテグレーションとローカル・インテグレーションの違いがわかる:
| 特徴 | グーグルフォント(ダイナミック) | ローカル・グーグルフォント |
|---|---|---|
| データ保護 | クリティカル(IP伝送) | GDPR対応 |
| ローディング時間 | 外部からの要求により遅くなる | 良いホスティングでより速く |
| セキュリティ更新 | グーグルによる自動化 | 手動メンテナンスが必要 |
| 警告リスク | 高い | 非常に低い |
よくある質問ローカルのGoogle Fonts統合に関するよくある質問
1. .woff2をサポートしていないブラウザは?
ほとんどのモダンブラウザは、.woff2ウェブフォントフォーマットに対応しています。 このフォーマットを読めない非常に古いブラウザの場合は、次のようにすることもできます。 .woff またはその他の亜種である。しかし、最新のブラウザの市場カバー率が高いため、現在のターゲットグループにはもはや必要ない場合が多い。
2. フォントがローカルに埋め込まれた場合、ユーザーは文句を言うことができますか?
むしろそうではない。ローカル統合は、データ保護の観点から特に望ましく、通常は訪問者に気づかれることはない。実際、サイトの読み込みが速くなり、ユーザーデータの取り扱いがより透明化されれば、好意的なフィードバックが得られることもある。
3. パフォーマンスの向上は果たしてどれほどのものなのか?
これはホスティングとページ全体のサイズに依存します。多くのフォントバリアントや複数のフォントがあるページでは、外部リクエストの節約は明らかに顕著です。ローカルフォントは、インターネットアクセスが遅い訪問者や、ネットワーク接続が安定していない地域の訪問者に特にプラスの効果をもたらします。
4. 1年後にフォントを更新する必要がありますか?
グーグルフォント自体は、時折、新しいフォントスタイルを含むように最適化または拡張されます。原則として、既存のバージョンは機能的に維持されるため、強制的なアップデートは必要ありません。しかし、常に最新の状態に保ちたい場合(新しいグリフが追加された場合など)、時々ファイルをダウンロードして置き換えることができます。
5 テーマメーカーが外部フォントを要求する場合は?
これについては、テーマプロバイダーのサポートチームに尋ねてみる価値がある。多くの場合、標準フォントをオフにしたり、ローカルに統合された独自のファイルで置き換えたりすることが可能です。一部のプレミアム・テーマでは、このためのオプションがすでに設定に用意されています。
プライバシー・ポリシーには何が含まれるのか?
また、プライバシー・ポリシーの中に、地域統合のための注意書きを入れるべきです。例えば、短い段落で十分なことが多い:
「ウェブサイトのデザインにはローカルフォントを使用しています。外部サーバーへのデータ転送はありません。"
こうすることで、GDPRに準拠した使用であることを明確にし、サイト上の技術的プロセスについて訪問者に透明性を与えることができます。同様のルールは、Adobe Fontsのような外部で使用されるフォントサービスにも適用されます。
上級ユーザーのためのベストプラクティス
すでにGoogle Fontsのローカル統合に対応している場合は、さらに最適化を行うことができます。font-faceによる単純な統合に加え、フォントのスライシングやサブセット戦略を用いてフォントをさらに効率化することができます。これらのテクニックは、特定の文字セットのみ(例えば、特殊文字を含まないラテン文字のみ)を埋め込むことで、ソースファイルのサイズを縮小します。
国際的なターゲット・グループをお持ちの場合は、個々のユーザーごとに読み込み時間を最適化するために、ウェブサイトを複数のフォント・ファイルに分割する価値があるかもしれません。また フォント表示: をCSSに追加して、読み込み時のフォントの表示方法を定義します(例 スワップ 或いは フォールバック)を使用することで、ユーザーが最終的なフォント表示まで長く待つ必要がなくなります。
サーバー設定に対する戦略的アプローチも重要である。例えば、正しいキャッシュヘッダを設定する(例えば キャッシュ・コントロール そして 期限切れ)を使用することで、ブラウザが長期的にファイルをキャッシュし、ページが呼び出されるたびに再読み込みする必要がなくなります。これは、同じドメインで複数回フォントを使用する場合に特に便利です:
ExpiresActive On
ExpiresByType font/woff2 "アクセスプラス 1 年"
ExpiresByType font/woff "アクセスプラス 1 年"
</IfModule
これらの設定により、サイトのパフォーマンスはさらに向上し、フォントはGDPRに準拠します。
追加のセキュリティ:ロギングとコントロール
フォントがどのように統合されているかを詳細に文書化している事業者もある。例えば、社内のデータ保護コンセプトでは、どのフォントが使用され、サーバーのどこに配置され、いつダウンロードされたかを記録することができる。これは、顧客や当局にデータ保護対策を説明しなければならない大企業や代理店にとって特に重要です。
また、「Google Fonts Checker」やDevToolsのようなツールを定期的に、例えば四半期に一度、自分のプロジェクトで実行することもできます。これにより、新しくインストールされたプラグインやスクリプトがGoogleへの外部接続を確立していないことを確認できます。これは、特に多くの参加者がいる大規模なウェブサイトでは推奨されるプラクティスです。
結論:Googleフォントを安全に使う
誰が Google Fontsをローカルに統合は、訪問者のデータを保護し、読み込み速度を最適化し、法的影響を防ぎます。OMGFのようなツールを使うか、CSSをカスタマイズすることで、切り替えは比較的簡単です。プラグインの使用と手動での微調整の組み合わせをお勧めします。定期的にチェックし、アップデートを確実に行い、適切なホスティングサポートを利用すれば、データ保護の面でも安全です。


