クライアント側とサーバー側のレンダリング:すべてが白黒ではない理由

時代の幕開け以来、HTMLを画面に表示する従来の方法は、サーバー側のレンダリングを使用することでした。それが唯一の方法でした。サーバーに.htmlページをロードすると、サーバーが移動して、ユーザーのブラウザーでそれらを有用なドキュメントに変換しました。

ほとんどのWebページはほとんどが静止画像とテキストを表示するためのものであり、対話性の妨げになることはほとんどなかったため、サーバー側のレンダリングも当時はうまく機能していました。

今日に早送りすると、もはやそうではありません。最近のWebサイトは、Webサイトを装ったアプリケーションのようなものだと言えます。それらを使用して、メッセージの送信、オンライン情報の更新、買い物などを行うことができます。Webは、以前よりもはるかに高度です。

したがって、サーバー側のレンダリングが、クライアント側でWebページをレンダリングする成長し続ける方法にゆっくりと後れを取っていることは理にかなっています。

では、どちらの方法がより良いオプションですか?開発中のほとんどのものと同様に、それはあなたがあなたのウェブサイトで何をしようとしているのかによります。長所と短所を理解してから、自分に最適なルートを自分で決める必要があります。

サーバー側のレンダリングのしくみ

サーバー側のレンダリングは、情報を画面に表示するための最も一般的な方法です。これは、サーバー内のHTMLファイルをブラウザーで使用可能な情報に変換することによって機能します。

Webサイトにアクセスするたびに、ブラウザはWebサイトのコンテンツを含むサーバーにリクエストを送信します。リクエストは通常​​数ミリ秒しかかかりませんが、それは最終的には多くの要因に依存します。

  • あなたのインターネット速度
  • サーバーの場所
  • サイトにアクセスしようとしているユーザーの数
  • いくつか例を挙げると、ウェブサイトがどれほど最適化されているか

リクエストの処理が完了すると、ブラウザは完全にレンダリングされたHTMLを取得し、画面に表示します。その後、Webサイトの別のページにアクセスすることにした場合、ブラウザはもう一度新しい情報を要求します。これは、ブラウザにキャッシュされたバージョンがないページにアクセスするたびに発生します。

新しいページに現在のページとは異なる項目がいくつかあるかどうかは関係ありません。ブラウザは新しいページ全体を要求し、すべてをゼロから再レンダリングします。

たとえば、HTTPアドレスがexample.testsite.com。の架空のサーバーに配置されたこのHTMLドキュメントを取り上げます。

    Example Website   

My Website

This is an example of my new website

Link

サンプルWebサイトのアドレスを架空のブラウザーのURLに入力すると、架空のブラウザーはそのURLで使用されているサーバーに要求を行い、何らかのテキストの応答がブラウザーに表示されることを期待します。この場合、視覚的に表示されるのは、タイトル、段落の内容、およびリンクです。

ここで、次のコードを含むレンダリングされたページからのリンクをクリックしたいとします。

    Example Website   

My Website

This is an example of my new website

This is some more content from the other.html

前のページとこのページの唯一の違いは、このページにはリンクがなく、代わりに別の段落があることです。ロジックでは、新しいコンテンツのみをレンダリングし、残りはそのままにしておく必要があります。残念ながら、それはサーバー側のレンダリングが機能する方法ではありません。実際に起こることは、新しいコンテンツだけでなく、新しいページ全体がレンダリングされることです。

これらの2つの例では大したことではないように思われるかもしれませんが、ほとんどのWebサイトはそれほど単純ではありません。最新のWebサイトには数百行のコードがあり、はるかに複雑です。ここで、Webページを閲覧し、サイトをナビゲートするときにすべてのページがレンダリングされるのを待たなければならないことを想像してみてください。あなたがWordPressサイトにアクセスしたことがあるなら、あなたはそれらがどれほど遅くなるかを見てきました。これが理由の1つです。

明るい面では、サーバー側のレンダリングはSEOに最適です。あなたのコンテンツはあなたがそれを得る前に存在しているので、検索エンジンはそれを索引付けしてうまくクロールすることができます。クライアント側のレンダリングではそうではない何か。少なくとも単純ではありません。

クライアント側のレンダリングのしくみ

開発者がクライアント側のレンダリングについて話すとき、彼らはJavaScriptを使用してブラウザーでコンテンツをレンダリングすることについて話します。したがって、HTMLドキュメント自体からすべてのコンテンツを取得する代わりに、ブラウザを使用してサイトの残りの部分をレンダリングするJavaScriptファイルを含む必要最低限​​のHTMLドキュメントを取得します。

これはWebサイトをレンダリングするための比較的新しいアプローチであり、JavaScriptライブラリが開発スタイルに組み込み始めるまで実際には普及しませんでした。いくつかの注目すべき例は、Vue.jsとReact.jsです。これらについては、ここで詳しく説明しました。

前のWebサイトに戻って、example.testsite.com次のコード行を含むindex.htmlファイルがあるとします。

    Example Website 

クライアントを使用してレンダリングするときのindex.hmtlの動作方法にいくつかの大きな変更があることがすぐにわかります。

For starters, instead of having the content inside the HTML file, you have a container div with an id of root. You also have two script elements right above the closing body tag. One that will load the Vue.js JavaScript library and one that will load a file called app.js.

This is radically different than using server-side rendering because the server is now only responsible for loading the bare minus of the website. The main boilerplate. Everything else is handled by a client-side JavaScript library, in this case, Vue.js, and custom JavaScript code.

If you were to make a request to the URL with only the code above, you would get a blank screen. There is nothing to load since the actual content needs to be rendered using JavaScript.

To fix that, you would place the following lines of code into the app.js file.

var data = { title:"My Website", message:"This is an example of my new website" } Vue.component('app', { template: ` 

{{title}}

{{message}}

Link `, data: function() { return data; }, methods:{ newContent: function(){ var node = document.createElement('p'); var textNode = document.createTextNode('This is some more content from the other.html'); node.appendChild(textNode); document.getElementById('moreContent').appendChild(node); } } }) new Vue({ el: '#root', });

Now if you visit the URL, you would see the same content as you did the server-side example. The key difference is that if you were to click on the link the page to load more content, the browser will not make another request to the server. You are rendering items with the browser, so it will instead use JavaScript to load the new content and Vue.js will make sure that only the new content is rendered. Everything else will be left alone.

This is much faster since you are only loading a very small section of the page to fetch the new content, instead of loading the entire page.

There are some trade offs with using client-side rendering, though. Since the content is not rendered until the page is loaded on the browser, SEO for the website will take a hit. There are ways to get around this, but it’s not as easy as it is with server-side rendering.

Another thing to keep in mind is that your website/application won’t be able to load until ALL of the JavaScript is downloaded to the browser. Which makes sense, since it contains all the content that will be needed. If your users are using slow internet connection, it could make their initial loading time a bit long.

The pros and cons of each approach

So there you have it. Those are the main differences between server-side and client-side rendering. Only you the developer can decide which option is best for your website or application.

Below is a quick breakdown of the pros and cons for each approach:

Server-side pros:

  1. Search engines can crawl the site for better SEO.
  2. The initial page load is faster.
  3. Great for static sites.

Server-side cons:

  1. Frequent server requests.
  2. An overall slow page rendering.
  3. Full page reloads.
  4. Non-rich site interactions.

Client-side pros:

  1. Rich site interactions
  2. Fast website rendering after the initial load.
  3. Great for web applications.
  4. Robust selection of JavaScript libraries.

Client-side cons:

  1. Low SEO if not implemented correctly.
  2. Initial load might require more time.
  3. In most cases, requires an external library.

If you want to learn more about Vue.js, check out my website at juanmvega.com for videos and articles!