Top Trends in Cybersecurity for 2024 | 
そのすべての利点にもかかわらず、Jamstackを大規模なカタログと頻繁な更新があるeコマースWebサイトに適用するには、多くの課題が伴います。 Salesforce Commerce Cloud、Magento、SAP-Hybrisなどのバックエンドプラットフォームでeコマースサイトを運営している場合は、すでにその一部に直面している可能性があります。
この記事では、大規模なeコマースJamstackサイトを構築する上での主な課題と、Layer(現Edgio)がこれらの問題にどのように取り組むのに役立つかについて説明します。
Jamstack Conference 2020でのLayer0 CTO Ishan Anandのプレゼンテーションのフルバージョンについては、公式のLayer0 YouTubeチャンネルをご覧ください。
Layer0（現在のEdgio）とは何ですか。
Layer0は、Jamstackの利点をeコマースにもたらし、サイトの速度を高速化し、開発ワークフローを簡素化します。 キャッシュされたデータをエッジからブラウザにストリーミングすることで、Edgioはウェブサイトの5を買い物客のタップ数よりも数秒早く維持することができます。 Sharper Image、Revolve、Shoe Carnivalは、Layer0 Jamstackプラットフォームを活用して開発者の生産性を高め、1秒未満のWebサイトを配信するサイトの例にすぎません。
Jamstackを大規模なeコマースに使用する際の課題は何ですか?
JamstackとHeadlessをeコマースに使用することは、特に大規模なカタログ、頻繁な更新、またはモノリシックなeコマースプラットフォーム上のサイトでは、通常、次の課題に対処することに関連しています。
- ビルド時間が長い
- 頻繁な更新
- サイトの移行が難しい
- 動的データ
- パーソナライゼーション
- A/Bテスト
- 不完全なAPI
- データパイプラインアーキテクチャ
- APIによって失われたカスタマイズ
- データベース接続の制限
- チームの能力
- CMSの統合
- CMSコンテンツに埋め込まれたスタイル
- BackOfficeワークフローの統合
時間摩擦やその他の課題を大規模に構築
Jamstackには、トラフィックの高いスケーラビリティが組み込まれています。 しかし、通常の静的レンダリングはビルド中に行われるため、ビルドステップでは新しいスケーリング次元が導入されます。 Webサイトを拡大したり、頻繁に変更を行ったりすると、Jamstackが高速で機敏なスイートスポットから抜け出します。 その結果、ビルド時の摩擦が生じます。 小さなサイトで作業している場合は、問題を一掃するのは簡単ですが、一般的なeコマースサイトではそうではありません。
覚えておくべきもう1つの重要なことは、サイトは開発者と同じくらい非開発者によって構築されているということです。 コンテンツ、マーケティング、マーチャンダイジングは常に変化するため、構築時間の摩擦はすぐに組織全体の問題になります。
これはすべて、「規模」はあなたが思っているよりも多く発生し、それはeコマースに限定されないことを意味します。 小売業者とニュースサイトの比較を見てみましょう。 eCommerceサイトの場合、SKUの数はページ数のプロキシになります。
多くの製品（SKU）を持つeコマースサイト、多くの記事を持つパブリッシャー
多くの記事を持つ出版社
Amazonのようなサイトだけが何百万ものSKUを扱っていると思うかもしれませんが、これは真実ではありません。 自動車部品のWebサイトはその好例です。年/モデル/メーカー/車両検索基準(YMMV)に基づいて、何百万もの製品をホストしています。 たとえば、TruPar.comは8M SKUでフォークリフト部品のみを販売しています。
ありがたいことに、いくつかの静的および動的レンダリング技術は、大規模なJamstackの問題に対処するのに役立ちます。
「静的」テクニック
- ビルド時間の最適化
- クライアント側レンダリング
- 増分静的（再）生成
「動的」テクニック
- サーバーレスサーバーサイドレンダリング+ CDN
- 並列静的レンダリング
「混合」レンダリング手法
- ページのクラスごとに最適なレンダリング手法を選択する
- 必要に応じてテクニックを混在させることができるフレームワークとプラットフォームを選択する
以下の段落では、これらのテクニックの意味について説明します。
静的テクニック
ビルド時間の最適化
動的なJavaScriptページのビルド時間を最適化する方法はいくつかあります。
インクリメンタルビルド
インクリメンタルビルドを使用すると、ビルドのアーティファクトを保存し、変更されたものだけを再生成できます。 1つのページだけが変更された場合は、その1つのページを再生成します。
並列ビルド
フレームワークは、ビルドを複数のプロセスまたはスレッドに分割します。 これは画像処理に役立ちます。
代替静的サイトジェネレータ
ネイティブパワーSSGは新しい方法であり、ビルド時間を改善することが判明しています。 例としてHugo (Go)やNift (C++)がある。 しかし、ネイティブに記述された静的サイトジェネレータの多くは、JavaScriptを多用するWebサイトではうまく動作しません。 比較的新しいトーストはそれに対処しようとしています。
ただし、フレームワークとクラウドプロバイダーによる並列ビルドと増分ビルドのサポートは異なることに注意してください。 すべてがサポートしているわけではなく、サポートが限られているだけです。
頻繁にアクセスしないページに余分なコストが発生する可能性がある
潜在的な過剰コストの問題もあります。 数万以上のSKUを持つ大規模なサイトがある場合、トラフィックのほとんどは配電に追従し、アクセスされることのないページの再構築に余分な計算時間を費やします。 サイトを更新するほど、コストが大きくなります。 これらのテクニックのいくつかについて考えるときは、そのことを念頭に置いてください。
willit.build (Gatsby Cloud上に構築されたサイトのビルド時間を提供するGatsbyのビルドベンチマークページ)によると、ContentfulとWordPressサイトのビルド時間は1ページあたり約200ミリ秒です。つまり、10kページのサイトでは、サイト全体のビルドに25分かかる可能性があります。 インクリメンタルビルドは、インクリメンタルビルドのパワーを示す数分に短縮できます。 このテクニックは、完全なビルドを行わない場合に役立ちます。
クライアント側レンダリング
アプリケーションシェルまたはSPAフォールバックモデルとも呼ばれ、クライアント側レンダリングはCDNルーティングです。 サイトが100万の製品をホストしている場合、これらはすべてこのCDNレイヤーによってindex.htmlにルーティングされ、アプリシェルを含む1つの静的ファイルになり、クライアント側でレンダリングされます。 ブラウザがそのページをロードすると、クライアントサイトルータはページコンテンツをブラウザにフェッチしてレンダリングします。
クライアントサイドレンダリングを使用すると、無限のページ数を効果的にホストできますが、いくつかの重要な考慮事項があります。
CSRはSEOに悪影響を及ぼす可能性がある
クライアントサイドレンダリングの注意点は、JavaScriptが読み込まれるまでページをレンダリングできないため、パフォーマンスが低下する可能性があることです。 2021年5月から、GoogleはCLS、LCP、FIDの3つのスピード指標に基づいてウェブサイトをランク付けします。これらをまとめてCore Web Vitalsと呼びます。 クライアントサイドレンダリングは、これらすべて、特に累積レイアウトシフトに悪影響を及ぼす可能性があります。 それは不可能ではなく、アプリシェルモデルで良いCLSを得るのは難しいだけです。 これを行うには、ページタイプごとにアプリシェルのカスタムバージョンを作成する必要があります。
クライアント側でレンダリングされたページは、（一部の）ボットでは読み取ることができません。
一部のボットは、クライアント側でレンダリングされたコンテンツを読み取ることができません。 Googleは、ボットがJavaScriptをレンダリングして解釈できると主張していますが、ほとんどのソーシャルプラットフォームを含め、他のほとんどのボットはできないことを知っています。これは多くのサイトにとって重要なトラフィックソースです。
CSRには、書き換えルールとリダイレクトルールのサポートが必要
CSRを実装する際の3つ目の注意点は、CDNプロバイダーが書き換えルールとリダイレクトルールをサポートしている必要があることです。また、他のプロバイダーよりも適切に対応している場合もあります。 たとえば、404ページのサポートを介してAWS CloudFrontでこれをシューホーンするか、Lambda@Edgeハンドラを使用する必要があります。
ありがたいことに、Jamstackの主要プラットフォームであるNetlify、Vercel、Layer0は、CSRを実現するためのかなり簡単な方法を提供します。
Netlifyには、redirectsファイルがあります。 200修飾子を使用すると、書き換えですが、ユーザーには表示されない非表示のリダイレクトです。
ネットリファイ
Vercelはvercel.jsonで書き換えをサポートしており、Next.jsとも緊密に統合されています。
ヴェルセル
Layer0のcdn-as-JavaScriptコマンドシェルはNext.jsの書き換えを提供し、他のフレームワークをサポートしています。
レイヤ0（Edgio）
増分静的生成
この技術はNext.jsによって開拓され、着信トラフィックに応答して新しい静的ページをオンデマンドで生成するというものであった。 ブラウザは、まだアクセスされていない新しいページを要求し、ページの内容に関係なく、CDNはプレースホルダーデータのみを含み、コンテンツを含まないユニバーサルフォールバックページをすばやく返します。
フォールバックページが表示されている間は、ページの静的ビルドプロセスがバックグラウンドで実行されます。 ビルドが完了すると、フォールバックページは静的JSONデータを読み込み、最終ページを表示します。 それ以降、将来の訪問では静的に構築されたHTMLが取得されます。
増分スタティック再生
増分静的生成のバージョンがあり、これは本質的に同じプロセスです。 それでも、トラフィックに応答して既存の静的ページを更新する必要があります。 そのため、基盤となるデータが変更された場合は、stale-while-revalidateにインスパイアされてビルドプロセスを再実行します。これは一般的ではありますが、広く評価されていないキャッシュプロトコルです。 これにより、ページの再構築中にフォールバックではなく古いバージョンのページが提供され、ビルドプロセスが終了したら新しいバージョンに置き換えられます。
増分スタティック再生：
- トラフィックに応じて既存の静的ページを更新します。
- フォールバックではなく、古いバージョンのページとして機能します。
増分スタティック再生は、SEOと互換性にわずかな影響を与えます。特に最初のページで顕著です。 フォールバックページは完全にCSRであり、データがないため、ボットがどのように対応するかは不明です。
ダイナミックテクニック
静的なテクニックに加えて、eコマースWebサイトは次のような動的なテクニックからも利益を得ることができます。
- サーバーレスサーバーサイドレンダリング+ CDN
- 並列静的レンダリング
サーバーレスサーバーサイドレンダリング+ CDN
SSRとCDNを併用すると、トラフィックに応じてオンデマンドでページを生成できるため、いくつかの利点があります。 この手法は、従来のeコマースプラットフォームの作成方法との互換性も高くなります。 多くのページをサポートし、必要に応じて動的に生成できます。また、レガシープラットフォームとの高い互換性を保証します。
しかし、この技術も少し物議を醸しています。 Jamstackコミュニティは、Jamstackとは何かについて非常に独断的である傾向があり、Jamstackには静的生成が必要であると主張します。
サーバーレスサーバーサイドレンダリングは、2の条件が満たされた場合に効果的にJamstackになります。
- 管理対象のDevOpsとサーバはゼロです。 サーバーレスなので、開発者はスケールウェイを管理する必要はありません。 これは、多くのJamstackプラットフォームがAPIを強化するために使用しているサーバーレスと同じであり、HTMLデータやSSRを介してそれを使用することができます。
- HTMLはCDNから提供されます。 これは重大な状態です。 最初のキャッシュミスの後、CDNで提供されるサイトは、静的に生成されたJamstackサイトと同じくらい高速になります。 これには適切なキャッシュ管理が必要であり、複数ページのサイトでは難しいことに注意してください。
並列静的レンダリング/SSRプリロード
Layer0では、展開時にエッジで事前レンダリングおよびキャッシュするURLのセットを指定して、ユーザーがサイトにアクセスするときに1秒未満のエクスペリエンスを得られるようにすることができます。
静的プリレンダリングには、アプリケーションコードにリクエストを送信し、サイトがデプロイされた直後に結果をキャッシュする必要があります。 このようにして、アプリケーションを構築してサーバーサイドレンダリングを実装するだけで、ページの一部またはすべてに対して静的サイトの速度の利点を得ることができます。 この機能は、ビルド時間が非常に長くなることなく、事前レンダリングするURLが多すぎる大規模で複雑なサイトに特に役立ちます。
SSRプリロードは、Layer0でページ速度を高速化するために使用される別の手法です。 通常のSSRパイプラインによく似ていますが、展開後のトラフィックログの分析に基づいています。 トラフィックの多いページは、デプロイと並行して事前にロードされます。 デプロイを瞬時かつ非同期に行い、トラフィックの多いページを構築します。 このようにして、ビルドからデプロイを分離します。 そのため、キャッシュヒットを最大化しながら即座にデプロイできます。
基本的に、トラフィックレベルの高いページのリクエストがある場合、キャッシュヒットが発生する可能性が高いです。 これは、この環境で可能な限り最高のキャッシュヒットを取得するための最良の方法です。
並列静的レンダリングでは、次のことが可能です。
- トラフィックの多いページのログを分析する
- 展開後にトラフィックの多いページのHTMLを非同期で取得して保存する
- キャッシュヒットを最大化しながら即座に導入
スタティック・プリレンダリング
混合レンダリング技術
静的レンダリングと動的レンダリングのどちらかを選択する必要はありません。 サイトのページのクラスごとに適切なものを選択できます。 「About Us」、「Return Policy」、またはブログの静的なページや、カート、製品、カテゴリなどのその他のページを動的として宣言することができます。 特に大規模にこれを行う場合は、必要に応じて柔軟にテクニックを混在させることができるプラットフォームプロバイダーを選択することをお勧めします。
ページのクラスごとに最適なレンダリング手法を選択してください。たとえば、一部のページ（ブログ、About Usなど）と、その他のページ（カート、製品、カテゴリなど）を静的に宣言するなどです。
必要に応じて柔軟にテクニックを混在させることができるフレームワークとプラットフォームプロバイダーを選択する
Layer0による大規模なJamstack
今日のCDNは画像、JavaScript、CSSをキャッシュしますが、JSONやHTMLファイルはキャッシュしません。これがページの読み込み時間を妨げています。 Layer0 CDN-as-JavaScriptを使用すると、動的なサーバーレスSSR環境でもエッジでデータをキャッシュできるようになります。
Jamstackはサーバーを方程式から外し、CDNがトラフィックを効果的に管理できるようにします。これは、トラフィックの変動に関係なく簡単に実行できます。 Layer0は同じですが、異なる方法で動作します。ビルド時にレンダリングするのではなく、リクエストに応じてレンダリングしますが、各ビルドをエッジでキャッシュするので、1ビルド後にビルドは不要になります。
小さなサイトではビルド時に各ページをレンダリングすることは問題ありませんが、サイズを大きくするとビルド時間がほとんど耐えられなくなります。 カスタマイズやパーソナライズ、またはこれらを提供するための回避策がないため、Jamstackは、eコマースやトラベルなどの大規模なデータベース駆動型Webサイトの構築に時間を割くことに重点を置いています。
CDN-as-JavaScript
Layer0 CDN-as-JavaScriptでは、キャッシュキー、ヘッダー、Cookieなどを強力にエッジ制御でき、コードでも動作します。 コードとフレームワークのルーティングを理解し、ローカルまたは本番前環境でエミュレートできます。
エッジルールは、従来のJamstackと同様にコードに組み込まれており、ライブログ、バージョニング、ワンクリックロールバックでエッジを完全に制御できます。
CDN-as-JavaScriptのルーティングパターンの詳細な例については、Layer0/Edgio Cookbookを参照してください。
パフォーマンスモニタ
キャッシュヒット率を最大化するには、そもそもこれらのレートが何であるかを知ることが重要ですが、この情報は通常、CDNのアクセスログの奥深くに埋もれています。
Layer0にはパフォーマンス監視機能が組み込まれているため、ページキャッシュのヒットやミスがいつ発生したかを簡単に理解でき、この情報を非常にわかりやすい方法で開発者に公開できます。 Layer0のパフォーマンスモニタでは、次の操作を実行できます。
- URLではなくルートに基づいてトラフィックを理解します。これは、開発者がアプリをどのように考えているかを示しているからです。 また、各デプロイを追跡するため、開発者はリグレッションを特定できます。
- スタックおよびロードシナリオ（API、SSR、Edgeなど）全体のパフォーマンスの問題を測定
Layer0は、レスポンスがオリジンのエッジから来ているかどうかを診断するツールであるDevToolsも作成しました。 DevToolsは、応答がオリジンの端から来ているかどうかを判断するのに役立ちます。 以下の例では、React Storefrontで構築されたアプリシェルの上でどのように動作するかを示し、リクエストがいつヒットしたかを示しています。 この例の応答は、Layer0（現在のEdgio）エッジネットワークを経由しています。
Layer0 DevToolsを使用すると、応答がエッジから送信されたかオリジンから送信されたかを診断できます。
応答がエッジから来ているかオリジンから来ているかを理解することは、スケールでプリフェッチするために重要です。これは、Layer0のもう1つの機能です。
大規模なプリフェッチ
プリフェッチは、瞬時のページ速度をアンロックするため、パフォーマンスにとって重要です。 Lighthouseでテストするような従来のページ速度テストは、顧客がクリックした後に何が起こるかに焦点を当てています。 しかし、顧客がタップする前に、レイテンシがゼロで、ほぼ無限の帯域幅を得ることができます。
Layer0 DevToolsを使用すると、応答がエッジから送信されたかオリジンから送信されたかを診断できます。
Layer0のWebサイトは、高度な予測プリフェッチとLayer0 CDN-as-JavaScriptを使用しているため、驚くほど高速です。これにより、買い物客のタップを数秒先に5を維持できます。 これは、キャッシュされた動的データをエッジからユーザーのブラウザーにストリーミングしてから、ユーザーが次にクリックすることを期待している内容に基づいて、何かをクリックする前にユーザーのブラウザーにストリーミングすることで行われます。 言い換えれば、ストアは、提供しているさまざまな製品、価格、情報のJSONデータをわずかな時間で提供できます。
差分移行
Layer0は反復的(段階的、プログレッシブ)移行を提供します。これにより、マーティン・ファウラーの絞殺パターンに従って、一度に1つのセクションを反復的に移行できます。 このようにして、特定の機能を段階的に「絞め」、新しいアプリケーションやサービスに置き換えます。 山の石を石で動かすようなものです。
増分移行では、CDNエッジまたはオリジンでのルーティング制御が必要です。 これは、cDN-as-JavaScriptを使用してレイヤ0でこれを行う方法の例です。
パーソナライゼーションとセグメンテーション
大規模なサイトでは、段階的で段階的な移行が重要です。 しかし、それはパーソナライゼーションに限定されません! また、言語、地理などもカバーしています。 大規模なサイトは通常、地理的にまたがって機能し、サイトにアクセスするユーザーに合わせてコンテンツをカスタマイズできる必要があるため、理にかなっています。
一般的なガイドラインは次のとおりです。このコンテンツが折り目の下にある場合は、遅延読み込みとクライアント側レンダリングをお勧めします。 カスタマイズされたコンテンツが上位にある場合は、サーバーレンダリング出力に含めることができます。
折りたたみの上にパーソナライズ=キャッシュキーにパーソナライズを追加
Layer0では、カスタムキャッシュキーを宣言し、通貨や動作に基づいてカスタマイズできます。 CDN-as-JavaScriptの数行で、カテゴリページのプロモーションと並べ替え順序をカスタマイズできます。
A/Bテストとレイヤ0
A/Bテストとパーソナライゼーションは、Jamstackサイトの構築に新たな複雑さをもたらします。 テストは、ROIを重視した意思決定を行う大規模なサイトや大規模な組織にとって非常に重要であり、コンバージョン率を向上させるために証明する必要があります。
ただし、従来のJamstackでは、ブラウザで実行されるクライアントサイドA/Bテストしか選択肢がありません。 問題は、これがパフォーマンスに影響を与え、2つの方法でテストを無効にする可能性があることです。 それはあなたのバリアントのパフォーマンスを傷つけ、あらゆる種類の改善を消去する可能性があります。 そして時々、A/Bテストは、目がテストされた要素を通過した後に有効になります。 ヘッダーにA/Bテストがあり、JavaScriptが実行されてその要素が変更された後、ユーザーはそのヘッダーを通過してすでにスキャンしている場合があります。
クライアント側A/Bテストの問題
- 通常、静的サイトの唯一のオプションは
- JavaScriptが実行されるまで実行されない
- テストが無効になる可能性のあるパフォーマンスの低下
Layer0 Edge Experimentsは、エッジでA/Bテストを有効にすることで、これらの問題を解決します。 XDNでは、新しいエクスペリエンスは常にネイティブでキャッシュされ、1秒未満です。 これは、A/Bテストを超えて、Webサイトの任意の亜種に拡張されます。
エッジ実験
Layer0には、強力なEdge Experimentsエンジンも組み込まれています。 このモジュールはCDN-as-JavaScriptの一部であり、すべてのバリアントを認識し、それぞれがエッジで個別にキャッシュされるようにします。 これにより、どの訪問者がどのバリエーションを表示するかを正確に制御できます。
エッジ実験を使用すると、次のことができます。
- ネットワークエッジに展開されているブランチにライブトラフィックをルーティングする
- A/Bテスト、カナリア展開、または機能フラグの実行
- 確率またはヘッダー値に基づいてルーティングルールを記述する
- IPアドレス
Edge Experimentsを使用すると、サイトのパフォーマンスに影響を与えることなく、テストを簡単に分割できます。 スプリットは、使いやすく強力なインターフェイスを介してエッジで実行されます。 Edge Experimentsは、A/Bおよび多変量テスト、カナリアデプロイ、青緑のテスト、レガシーWebサイトからの反復的な移行、パーソナライゼーションなどに使用できます。
お客様がLayer0からどのようにメリットを得ているか
Layer0は、JamstackとHeadlessへのスムーズな移行を提供し、大規模なカタログ、頻繁な更新、またはレガシーeコマースプラットフォームを実行しているサイトに大きな利点を提供します。 Shoe CarnivalとTurnkey Vacation Rentalsは、大規模サイトの開発者チームがLayer0のeコマースにJamstackとHeadlessを使用している例です。
ターンキー
ターンキーバケーションレンタルは、全国のトップ旅行先のプレミアムおよび高級レベルの賃貸住宅のためのフルサービスのバケーションレンタル不動産管理会社です。 Airbnbのようなサイトとは異なり、Turnkeyは事前に審査されたリストのみを提供しています。 また、標準化された一連の技術ツールを使用して、管理の詳細を一元的に処理します。
元の設定
Turnkeyは、AWS Elastic Beanstalk上でDocker内でアプリを実行しており、パフォーマンスに対するより優れた制御と洞察を提供するソリューションを探していました。
彼らはいくつかのJamstackソリューションを検討しましたが、Layer0のようなNext.jsをネイティブでサポートするプラットフォームを望んでいました。 決定要因の1つは、Layer0を使用すると、コードベースとデータパイプラインの動作をリファクタリングする必要がなくなることでした。
Layer0は、以下に示すいくつかの機能により、ターンキーによる俊敏性の向上に役立ちました。
環境
以前は、TurnkeyはJenkins内に構築されたカスタムパイプラインを使用しており、チームはトランクブランチからデプロイしていましたが、本番環境に移行する準備ができているものに完全な自信はありませんでした。
Layer0を使用すると、ブランチには個別の環境があり、ターンキーのチームは元の環境をセットアップできます。つまり、何かがQAに合格したことがわかるまで、ステージング環境にマージされません。 これにより、QAに伴う精神的な負担が軽減されます。
ログ
Beanstalkでサーバーログを調べることは悪夢になる可能性があります。探しているログ、どのサーバーにあるか、負荷分散されているかなどを正確に把握する必要があります。 Layer0を使用すると、ビルドから直接ログをライブストリームできます。これにより、トラブルシューティングしたいビルドを見つけ、再生を押して、ログを見ることができます。
差分移行
TurnkeyにはReact/Next.jsではなくページがあり、古いアーキテクチャで動作していた。 Layer0を使用すると、すでに移行したものをXDNに配置し、段階的に移行を続行できます。
Layer0は、パフォーマンスに集中するためのターンキーツールをチームに提供しました。
シューズカーニバル
シュー・カーニバル（Shoe Carnival Inc.）は、アメリカ合衆国の靴の小売業者である。 同社は現在、米国中西部、南部、南東部の地域で419実店舗と並行してオンラインストアを運営しています。
以下は、シューズカーニバルチームが特に便利だと感じたLayer0の機能の一部です。
柔軟性
Shoe CarnivalはSalesforce Commerce Cloudを使用しており、Shoe Carnivalのようなヘッドレスフロントエンドを実行することを意図していません。 フロントエンドにデータを実行するには、バックエンド側に多くのエンジニアリングと理解がありました。 これらの課題は、SalesforceとReactフロントエンドの間にあるLayer0バックエンドが提供する柔軟性によって解決できます。 Shoe Carnivalのチームは、Reactを使って自由に構築でき、Salesforceの制限を無視できました。
生産性の向上までの時間
シューズカーニバルの生産時間は劇的に増加しました。 チームはSalesforceの開発サイクルから分離して、展開に非常に迅速な変更を加えることができます。
サイト速度
生産までのスピードは大きな利点ですが、Shoe Carnivalが平均ページ読み込み時間5〜6秒からサブ秒になったため、サイトのパフォーマンスは一般的に無視するのが難しいです。 非常に詳細なレベルで物事をキャッシュし、顧客が探しているものが常に利用可能で最新であることを確認するためのツールを持っています。
段階的な導入
段階的な導入により、チームは完全なアプリケーションを構築して導入するよりもはるかに迅速に本番環境に導入できます。
Layer0への移行の影響については、Shoe CarnivalがCDNレベルで50対50のコンバージョンについて、オリジンサイトとヘッドレスサイトを比較テストしたところ、ヘッドレスサイトが常に勝ち、オリジンサイトを上回っており、スピードと可視性が向上しています。
概要
Layer0では、JamstackはWeb開発の未来だと考えています。 Layer0は基本的に、Jamstackのパフォーマンスとシンプルさのメリットを、従来の静的技術が適用されない大規模で動的なeコマースサイトのフロントエンド開発者チームにもたらします。 私たちはこれをダイナミックJamstackと呼びたいと思っています。 これにより、SPAのWebサイトが瞬時にロードされ、開発が容易になります。
Layer0には、アプリケーション対応のCDN-as-JavaScriptが付属しています。これにより、現在のCDNを拡張または置き換えることができ、必要なすべてのWebセキュリティ機能をエッジに提供できます。 Layer0には、開発に特化した多数のテクノロジーが搭載されており、開発、導入、プレビュー、実験、監視、 また、自動フルスタックプレビューURL、フロントエンド用のサーバーレスJavaScriptバックエンド、高度なキャッシュ監視など、ヘッドレスフロントエンドを簡単に実行できます。
Layer0はオールインワンの開発プラットフォームで、次のことが可能です。
- 事前レンダリングとジャストインタイムレンダリングの両方を使用して、eコマースにJamstackを活用
- 製品カタログAPIからデータをプリフェッチすることで、ゼロレイテンシネットワーキングを実現
- アプリケーションでEdgeをネイティブに構成する（cDN-as-JavaScript）
- エッジルールをローカルおよび本番前の環境で実行
- 新しいブランチとプッシュごとに、GitHub、GitLab、またはBitbucketからプレビューURLを作成します。
- パフォーマンスの高いA/Bテスト、カナリア展開、パーソナライゼーションのためにエッジでスプリットを実行
- AWS Lambdaよりもはるかに簡単で信頼性の高いサーバーレスJavaScript
