サーバーサイドレンダリングって何？と思った人が読むブログ記事

最近SEOに毒され気味の、ユゲタです。 webサイトやwebサービスを公開していると、どうしても気になってしまうのが、Google検索のSEOですよね。 これを気にしない会社は逆にヤバい気もしますが、 Googleに嫌われたら、もはやこの世の中では商売ができないのではないか（少なくてもweb業界で・・・）と思ってしまいます。 そんな、SEO対応を必須とした企業のweb開発者の苦悩を少しだけ共有してあげたいという思いも込めて、今回ブログを書いてみました。

フロントエンドの現状

会社で新しいwebサービスを作ろうとすると、ちょっとでも軽いwebサイトを作りたいと思って、vanilla化(*1)しようとしますが、 ちょっとやそっとの知識レベルでは、サイト構築をするのはエベレストに１人で登るようなモノです。 そして多くのエンジニアが、フロントエンドとバックエンドを切り分けて、ブラウザ表示に関することは、フロントエンドに作業を押し付けてしまいます。 押し付けられたフロントエンド担当者は、まずググって、「node.js」をすっ飛ばして、「React」にたどり着きます。 そして、そこから大手企業が作った ・Angular.js ・vue.js ・Backbone.js などに手を伸ばし、 TypeScriptやら、Next.jsなどに到達して、ここで、エベレストの頂きを制覇した感覚に陥ります。 そして、恐ろしく大量のブラックボックスになり得る、module群をdockerと込みで構成して、開発環境を作りますが、 これが構築に時間がかかるかかる・・・ 何か少しのトラブルがあると膨大な時間をかけて、原因究明とリファレンスやらドキュメントやらスタックオーバーフローをネットサーフする事になります。 ２，３年後にそのシステムを運用し続けてみると、やっていた作業は、 ・フレームワークに組み込まれたライブラリや訳のわからんモジュールのバージョン管理 ・それぞれのバージョンアップなどに伴うシステムの適合改修作業 ・カスタマイズ要望が来た時にルールを無視した特注システムの整合性合わせ こんな感じで、実は、プログラミングというよりは、ケツ拭き作業をずっとやってきたことに気がつくでしょう。 同じ２，３年の開発作業をやっていた友達が、おもしろいライブラリ開発やOSS活動をしているのを横目に見てしまうことになるのは目に見えています。

サーバーサイドレンダリングを理解する

話が大幅に脱線しましたが、そもそもこうしたフレームワークに手を出さざるを得なくなるのは、サーバーサイドレンダリングを自分で構築できないからではないかと考えられます。 CGIによって、HTMLタグを出力すればいい時代であれば、PHPやRubyなどで、データベースから読み取ったとおりにタグを吐き出せばいいのですが、 今やJavascriptで、ユーザーデバイス状況を見ながら最適化されたHTMLタグを出力しなければいけません。 でも、通常のJavascriptは、HTMLが読み込まれてから、ブラウザ側で、いろいろな情報を読み解いて、それからDOM等に変更指示を与えていく作業になるので、 Googleなどのクローラーが読み取りに来た際に、最初に出力されたHTMLタグのみしか読み取ってくれないことになります。 ここで、SEOに弱くなるとして、ファーストLOAD直後のHTML構成自体を、Javascriptバリの精度で出力することを、サーバーサイドレンダリングという風に言っているようです。 でも、これって、Reactなどのフレームワークを使わなくても、NodeJsを使って、自分で柔軟に書くこともできるし、 やろうと思えば、PHPだけでも、かなりのことができるでしょう。 簡易にフレームワークを導入すると、地獄が待っているし、その後面白くも何とも無いよ、という事を伝えたかったのですが、 特に、フレームワークの仕様を悪く言っているつもりではなく、先を見据えた環境構築をしてもらいたいと切に願っているだけの話でした。 面白い開発とは、自分に何かしらのリターンが得られるものでなければいけないと思うんだけどな〜。

注釈

*1 : vanilla化

世の中で一番軽くて早くて軽量で柔軟度が高いと言われる世界最強Javascriptフレームワーク vanilla js