研究によると、Web サイトの読み込み時間が 1 秒増えるごとに、10% のユーザーが失われることがわかっています。ページの開封率を数秒で向上させるために、あらゆる分野の人々が常に最適化戦略を模索していますが、ブラウザ領域での最適化だけでは究極の要件を満たすことはできなくなり、誰もがサーバーの方向で模索を続け始めました。 Once let [サーバーサイドレンダリング] この古代の概念は普及しており、非常に人気があります。
サーバーサイドレンダリングはSSRと略され、正式名称はServer Side Renderingと呼ばれ、その名のとおりサーバー側でレンダリング作業を行います。この方法は、ファースト スクリーンのレンダリングに有益であり、SPA アプリケーションのファースト スクリーンの応答速度が向上するだけでなく、検索エンジンのクローリングも容易になり、SEO の最適化にも役立ちます。しかし、2023 年までに SSR は予想ほど人気がなくなりました。
SSR を使用する理由のほとんどは SEO に役立つと信じている評論家もいますが、検索エンジンが開発のペースに追いつき、フレームワークで書かれた SPA を十分にサポートしている現在、SSR はそれほど必要ではありません。SSR は誤った要件であると考える人もいますが、ビジネス ロジックとコントローラーは分離され、できるだけ早くロードされます。
しかし、ネットワーク環境や端末の状況によってWebページへのアクセス体験が満足に得られないユーザーが依然として多数存在するという意見もあり、こうしたユーザーのエクスペリエンスを向上させるためにはSSRが不可欠な手段となります。 。
この点に関して実際の状況はどうなっているのでしょうか？実際のアプリケーションにおいて、SSR が Web の主流の開発モデルになることを妨げている理由は何ですか? このアプローチは今日の環境では時代遅れなのでしょうか? SSRにはどのようなビジネスシナリオが適しているのでしょうか？この点に関して、オープン ソース チャイナは 2 人のフロントエンドの大物を招待して意見を聞きました。
-
Liu Kui、コミュニティではクイトと呼ばれています。Alipay エクスペリエンス テクノロジー部門のフロントエンド エンジニア、オープンソースのマイクロ フロントエンド ソリューションの著者、qiankun 氏。現在、Ant で Web インフラストラクチャの研究開発関連業務を担当しています。
-
Liu Yong は、コミュニティでは Tianzhu という愛称で呼ばれており、大企業の Node.jsインフラ部門の責任者であり、EggJS / CNPM のコア開発者です。
1. SSRは疑似要件ではありません
Q1: あなたの経験では、 SSRにはどのようなタイプのプロジェクトやシナリオがよく使用されますか? いくつか例を挙げていただけますか？
Liu Kui: 以下のような、最初の画面のパフォーマンスに非常に敏感な Web サイトや SEO への要求が強い Web サイトでは、SSR がより頻繁に使用されます。
-
E コマース プラットフォーム: 最初の画面のレンダリングが高速化されたことで、ユーザーは製品情報をより速く確認できるようになり、購入コンバージョン率が向上します。
-
マーケティング活動ページ: 数秒で開くことで、マーケティング活動のビジネス効果を効果的に向上させることができます
-
ポータル Web サイト: コンテンツベースの Web サイトには通常、SEO に対する強い要求があります。
Q2: 実際の経験に基づいて、CSR (クライアントサイド レンダリング) モードと比較したSSRの利点は何だと思いますか?
Liu Kui:私の個人的な経験から言えば、最大の利点はファースト スクリーン エクスペリエンスです。ユーザーは SSR モードでの HTML 読み込みプロセス中に有効なページ コンテンツを確認できます。これは基本的に CSR では実現が困難です。
Q3:検索エンジンはすでにレンダリングをサポートしていますが、 SEO上の理由からSSRを使用する必要があると思いますか?
Liu Kui:よく知られた理由により、国内の検索エンジンは SPA タイプのアプリケーションを十分にサポートしていません。Web サイトのクローラーによるインデックスを強化したい場合は、基本的には SSR (または SSR の亜種) ソリューションを使用する必要があります。 。
Q4: SSR は誤った要件であると考えている人がいますが、ファースト スクリーンのレンダリング パフォーマンスを向上させるには、バックエンド サービスのビジネス ロジックをコントローラーから分離する必要があります。コントローラーはビュー コントローラーとインターフェイス コントローラーに分かれており、同じビジネス ロジックを呼び出します。ページが初めて開かれるとき、フロントエンドJavaScript はページによってレンダリングされたデータをロードし、ユーザーが操作するときにインターフェイスにデータを取得するように要求します。この解決策は、パフォーマンスに不安がある SSR よりもはるかに優れています。どう思いますか？
Liu Kui:このソリューションの本質は依然として CSR であり、CSR ソリューションの本来の問題は解決できません。つまり、ユーザーは JS のダウンロードが完了するまで待たなければなりません -> インターフェース要求を開始します -> JS がデータを取得し、有効なコンテンツが表示される前にページがレンダリングされます。ネットワーク環境やユーザー機器の条件がより厳しくなると、この問題はより顕著になります。
Liu Yong:チームのインフラストラクチャの成熟度とビジネス シナリオに基づいてテクノロジを選択します。これら 2 つのソリューションの間に絶対的な利点や欠点はなく、完全に分離されているわけでもありません。これらはフロントエンド エンジニアリングを通じて 1 つのソリューションに組み合わせることができます。
2. SSR、有名になるのはちょっと大変です。
Q5: 現状から見ると、SSR はWeb の開発モデルの主流になっていませんが、何が障害になっていると思いますか?
Liu Kui:主に以下の理由があると思います。
-
技術的な複雑さ: SSR はサーバー側でレンダリングされ、フロントエンド フレームワークと統合される必要があるため、開発者にはより多くの技術的知識が必要です。
-
SSRによってもたらされる追加の開発および保守コスト: CSR と比較して、SSR ソリューションでは、フロントエンドがサーバー関連の開発および運用および保守にさらに注意を払う必要があります。たとえば、より高性能なサーバー側レンダリング ロジックの作成方法やその方法などです。潜在的なメモリ リークへの対処、変数汚染やその他の分離の問題、SSR ディザスタ リカバリの実装方法 (SSR に障害が発生した場合の CSR へのフォールバック) など、これらはすべてチームに追加のリソースと時間の投資を必要とします。
-
シナリオマッチング：国内のサービスは小規模なプログラムやAPPなどキャリアを通じて配信されているものが多く、純粋なWeb技術スタック製品が比較的少ない点が海外のシナリオとは大きく異なります。
Liu Yong:まず、SSR にはサーバー リソースのコストがかかりますが、コスト削減と効率向上の観点から、サーバーレスやエッジ コンピューティングなどのインフラストラクチャと組み合わせてバランス ポイントを見つける必要があります。一方で、サーバーである以上、運用保守能力やフロントエンドチームの技術蓄積にも一定の要件があります。
第 2 に、フレームワークのカプセル化とメンテナンスが適切に行われていない場合、SSR を作成するビジネス学生はメモリ リークを簡単に引き起こす可能性があり、これは非常に一般的です。さらに、現在のフロントエンド フレームワークは SSR シナリオ用に最適化されていないため、最初の画面表示は速いものの、非常に大きなバンドル ファイルをダウンロードする必要があるため、ユーザーの操作時間が遅すぎる場合、利益が損失を上回ります。 。
最後に、進化の道筋については、たとえば、Ant はオフライン パッケージの上流と下流のインフラストラクチャをすでに完成させており、APP 側とネットワーク側の兄弟チームが連携して磨き上げています。このモデルには、オフラインパッケージが多すぎるとビジネス競争の問題などのいくつかの欠点がありますが、最初の画面のパフォーマンスの点で、SSRが必ずしもSSRより優れているわけではなく、現時点ではかなりの抵抗があるでしょう。 SSRに切り替えます。
Q6: SSR の開発費や維持費が高すぎるという意見があり、 CSRに目を向けたという意見もあります。CSRでもSSRと同じ効果が得られるのでしょうか？具体的な行動計画はありますか？
Liu Yong:ファースト スクリーンのパフォーマンスの重要な点から言えば、CSR が特定の最適化 (少なくとも 3 つのシリアル HTTP リクエスト) を行わない場合、ファースト スクリーンの時間は間違いなく SSR ほど良くありません (相互運用性の時間は必ずしもそうではありません)。
ただし、ServiceWorker、オフライン パッケージなど、対応するソリューションが多数あります。
Liu Kui:最初の画面のレンダリング速度だけの観点から、CSR が SSR と同様の効果を達成したい場合は、次の最適化ソリューションを採用できます。
-
最初の画面ページの静的リソースの最適化:コードカットと遅延読み込みなどにより、最初の画面に必要な JS/CSS が最小化バージョンであることを確認し、インライン化などにより HTML に直接取り込んでネットワークを削減します。 ; 最初の画面のレンダリングにはリクエストが必要です。
-
キャッシュとプリロード:クライアントのキャッシュおよびプリロード メカニズムを使用して、二次アクセスの速度を向上させます。
-
軽量のフレームワークを使用する:最初の画面の JS サイズを削減し、読み込み速度を向上させるには、軽量のフロントエンド フレームワークを選択します。
-
主要なインターフェイスの応答速度を最適化する:最初の画面に必要な主要なコンテンツのインターフェイスの応答速度を最適化し、フロントエンドがページをより速くレンダリングできるようにします。
しかし、追加の SEO 要求がある場合、純粋な CSR だけで同じ効果を達成するのは難しいかもしれません。
Q7: オリジナルアプリからSSR統合アプリに直接切り替える場合、費用はいくらかかりますか？それは開発チームにどのような課題をもたらすでしょうか?
Liu Kui:コストと課題は次のとおりです。
-
アプリケーション変更のコスト:ほとんどのアプリケーションはサーバー環境で直接実行できず、基本的にある程度の変更が必要です。たとえば、ファースト スクリーン レンダリング コードのウィンドウや位置などのブラウザ固有の API への依存を排除したり、JS を構築したりするなどです。サーバー上で実行されているなど。
-
SSR機能の開発と運用保守の課題:フロントエンドおよびサーバーサイドの開発経験が豊富なチームは、ほとんどの企業では非常にまれです。前述したように、SSR はサーバーサイドの開発と運用保守のさらなる課題をもたらします。これもまた必要です。フロントエンドチームによって検討されます。
3. 今後はSSR+CSRが新たな方向性になるかも？
Q8: 現在、一部の Web サイトではファースト スクリーンのサーバー側レンダリングが使用されています。つまり、ユーザーが最初に開くページではサーバー側レンダリングが使用され、これによりレンダリング速度が確保されますが、他のページではクライアント側レンダリングが使用されます。背面が完成し分離終了です。これは両方の利点を組み合わせた、より完璧なソリューションだと思いますか?
Liu Kui:はい、これはコミュニティにおける現在のベスト プラクティスでもあり、SSR および SPA アプリケーションの利点を十分に維持できます。
Liu Yong:これは実際には何年も前から行われていました。たとえば、カリフォルニア大学の Yunlong の Scrat Pagelet でも同様のことが行われていました。当時でも、後続のページは部分的にサーバー経由でレンダリングされ、フロントエンド ページはオンデマンドで更新されていました。
この方法は、業界のさらなる実践でも見られています。開発者は分離の有無を気にすることなく自然にロジックを記述し、フロントエンド エンジニアリング層、SSG + SSR + CSR で自動的に分割されます。静的にビルドできるコンポーネントはビルド フェーズで直接処理され、サーバー側でレンダリングできるコンポーネントと、残りの不要なコンポーネントはフロントエンドで直接レンダリングされます。フロントエンド エンジニアリング インフラストラクチャが十分に完成し、研究開発モデルが十分に統合されていれば、これらはすべて実行できます。
最後に念を押しておきますが、私が知っている SSR プラクティスのほとんどは、通常、短期的な CDN を前面にブロックしてから、CSR を使用して変更とその後のビジネス ロジックを数千人に対して実行します。
Q9: SSRの今後の展開はどのように考えていますか？ハードウェアのアップグレードによって段階的に廃止されるのでしょうか、それともテクノロジーのアップデートによってさらに普及するのでしょうか?
Liu Yong:最適化のアイデアは決して時代遅れになることはありません。おそらくいつか、私たちが慣れ親しんでいる SSR プログラミング インターフェイスが変わるでしょう。たとえば、SSR は nunjucks や ejs などのテンプレートを使用していましたが、現在は React と Vue を使用しています。今後も新しい技術が出てくるでしょうが、SSRの実践モデルとなるでしょう。
Liu Kui:私の経験によると、多くの場合、新しい技術ソリューションは、より良いインタラクティブ エクスペリエンスを得るために、より多くのハードウェア パフォーマンスを絞り出そうとします。そのため、いつでも比較的「ローエンド」のデバイスが存在することになります。解決しました（笑）
私の考えでは、SSR の主な導入コストは研究開発とサーバーの運用保守であり、これは多くの企業のフロントエンドチームにとって大きな負担であり、ROI が低いため SSR の導入は困難です。しかし、サーバーレスの発展に伴い、フロントエンド チームの運用保守コストを大幅に削減できる、ほぼ「運用保守ゼロ」のサーバーレス ソリューションが数多く登場しました。同時に、コミュニティの傾向から判断すると、Next.js、remix-run、Qwik、Astro、Fresh など、近年人気のあるさまざまなフロントエンド フレームワークが Edge と SSR を採用しています。同時に、React などのライブラリでは、パフォーマンスが向上したストリーミング SSR 機能も導入されました。これらのフレームワーク テクノロジーの統合と反復により、SSR アプリケーションを開発するフロントエンド エンジニアの研究開発コストを大幅に削減できるだけでなく、従来の SSR のパフォーマンス効果をさらに向上させることもできます。
現在の傾向からすると、研究開発費や運用保守コストが下がってくるので、SSRはますます普及していくのではないかと思います。
Q10: プロジェクトの経験に基づいて、 SSRモデルをどのように評価しますか?
Liu Yong:フロントエンドの歴史的な進化から判断すると、SSR→CSR→SSRと、一見すると歴史が逆転しているように見えますが、実はそうではありません。
たとえば、当時のフロントエンドの HTML + CSS + JS は、オールインワンの単一ファイル メソッドでした。当時のフロントエンドにはコンパイル機能がなく、一緒に記述することしかできなかったためです。フロントエンドエンジニアリングの進化により、開発期間が複数に分割されたファイル構成、構築時の自動処理が主流となり、さらにVue SFCのような単一ファイル方式が登場しましたが、これは逆行しているのでしょうか？実際にはそうではありませんが、インフラストラクチャが改善されると、ユーザー プログラミング インターフェイスがより直観的になり、パフォーマンスや展開などをツールに任せることができます。
したがって、SSR モードには実際のシナリオがあると思いますが、現段階では、より適切に実装するために解決する必要のある実用的なパフォーマンスの問題やエンジニアリングの問題がまだたくさんあると思います。
Liu Kui: CSR も優れたファースト スクリーン エクスペリエンスを実現できますが、ユーザーのデバイスの機能によって制限され、パフォーマンスの上限が明らかです。SSR は、エッジ コンピューティング (ESR) やストリーミング レンダリングなどのサーバー側の機能をより適切に活用して、パフォーマンスの上限を効果的に引き上げることができ、ほとんどの場合、Web アプリケーションのファースト スクリーンのパフォーマンスを向上させる効果的な武器となります。
もちろん、プロジェクトやチームごとに特性や目標は異なり、開発モデルを選択する際にはさまざまな要素を総合的に考慮する必要があります。
どう思いますか？あなたのプロジェクトではSSRまたはCSRが採用されましたか? コメント欄にあなたの経験を教えてください~