より小さなコンテンツスナップショットでローカライズを高速化

接続されたコンテンツグラフは非常に巨大になることがあります。1 つのランディングページがセクションを参照し、それらのセクションがアセットやエントリを参照し、さらにそれらのエントリがより多くの共有コンテンツを指します。

その深さはサイトをレンダリングする際には有用です。しかし、編集者がエントリを見つけたり翻訳ステータスを確認したりするだけの場合には、不要であることがよくあります。

データが多ければ常にコンテキストも増えるわけではない

ローカライズツールは、タイミングごとに異なる Contentful のビューを必要とします。

コンテンツインデックスには、エントリを識別し、検索し、フィルタリングするのに十分なデータが必要です。翻訳リクエストには、選択されたソースフィールドと保護された構造が必要です。プレビューでは、完全な参照グラフが必要になることがあります。

あらゆるビューに対して可能な限り最も深いペイロードを使うと、有用なコンテキストを追加しないままコストだけが発生します。

その結果、次のようなことにつながる可能性があります。

• コンテンツ一覧の表示が遅い
• 大きなキャッシュレコード
• メモリ使用量の増加
• 同じ参照の繰り返しハイドレーション
• 編集者が作業を開始できるまでの待ち時間の長期化

実際の翻訳モデルがまだ呼び出されていないにもかかわらず、インターフェースは遅く感じられます。

目的に応じてスナップショットを構築する

有用なコンテンツスナップショットは CMS のクローンではありません。特定のワークフローのために構築されたローカル表現です。

一覧表示や検索では、たとえば次のものが含まれます。

• エントリ ID とコンテンツタイプ
• 表示フィールドの値
• 設定済みの検索フィールド
• 利用可能なロケール
• ページパスの入力値
• 更新および公開のタイムスタンプ

システムは、ユーザーがエントリを開いたり翻訳リクエストを作成したりしたときに、より深いフィールドデータを取得できます。

この段階的なアプローチにより、重要な場面で詳細へのアクセスを維持しながら、日常的な処理を削減できます。

除外は構造的である必要がある

大規模なコンテンツモデルには、翻訳に無関係なフィールドが含まれていることがよくあります。アセット、技術的な参照、分析設定、内部関係は、再帰的に展開せずに表示されたままにしておく必要がある場合があります。

除外ルールは、シリアライズされたペイロードサイズに関する壊れやすい前提ではなく、フィールドの識別情報とコンテンツ構造に基づいて機能するべきです。深いハイドレーションから除外されたフィールドは、キャッシュ更新やクリーンアップジョブ全体で一貫して除外されたままであるべきです。

その予測可能性は、1 回のレスポンスから可能な限りすべてのバイトを絞り出すことよりも重要です。

キャッシュ制限を明示的に保つ

スナップショットも依然として大きくなる可能性があります。リッチテキスト、長い配列、広範な検索フィールドによって、異常に大きなエントリが作られることがあります。

アプリケーションは明確な境界を設定するべきです。

1. シリアライズされたスナップショットサイズを測定する
2. 重要でないキャッシュ済み詳細を省略または切り詰める
3. 安定した識別情報と検索メタデータを保持する
4. 必要に応じて完全なエントリを取得する
5. 黙って失敗するのではなく、本当の設定上の問題を明示する

キャッシュは高速化レイヤーです。作業を実行するために必要なデータの唯一のコピーになってはいけません。

パフォーマンスは編集フローを守る

編集者はレイテンシーを不確実性として体験します。反応が遅いフィルターは壊れているように見えます。深いハイドレーション後に形が変わる行は信頼できないように感じられます。不必要なコンテンツクロールを待つ一括アクションは、対象範囲を不明瞭にします。

より小さなスナップショットにより、プロダクトはユーザーの目の前の操作に応答できるようになります。詳細な CMS データは、ユーザーが詳細を求めた時点で取得できます。

要点

ローカライズシステムは、現在の判断に必要な量の Contentful データを読み込むべきです。

インデックス用スナップショットは小さく保ち、詳細なコンテンツは必要に応じて取得し、除外とキャッシュ制限を明示的にします。翻訳処理の高速化は、多くの場合、翻訳そのものの前段階、つまりコンテンツデータへのより規律あるアプローチから始まります。