基本的にweb関連の開発は、Chromeブラウザでしている、ユゲタです。
以前から作っていた、nodejsベースの自社用フレームワークですが、ようやくベータ版が出来上がったので、サーバーにアップして、とりあえず
GooglePageSpeedInsightsチェックしてみたら、エラーでチェックができんかった！
これは大変な事だと思ったが、何が悪いかよくわからん。
そして、いろいろなブラウザで見ていたら、macのsafariブラウザでなんかちゃんと表示されないことが分かった。
どうやらこの辺にヒントがありそうだと思って、今回はその調査を進めた話です。
原因のリクレポ対応
原因は、safariがset-fetch-destに対応していなかった事が原因でした。
え？set-fetch-destって何？って
「set-fetch-dest」は、リクエストヘッダに入っているどういうタイプのリクエスト情報なのかを表している値で、どういう値を返せば（レスポンス）いいか、判断できる便利な機能なんですね。
詳しくは下のURLを見てください。
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-Dest
これを利用して、拡張子が偽装されても、ちゃんとした値を返せると思っていたんですが、safariが非対応だったんですよ。
IEやモバイルOperaなんかはどーでもいいんですが、safariはヤバいですね。
GooglePageSpeedInsightsも、apple-webkitを使っているという事がなんとなくわかりました。（Chromeじゃないんかいというツッコミは置いときましょう）
仕方なく拡張子で対応
もう他に手段がないので、やはりファイル拡張子で判断して、アクセス種別を判断することにしました。
どおうせwebサーバーへの問い合わせって、htmlとjsとcssと、画像や動画や音声コンテンツぐらいだけだろうと安易に考えてもいいんですが、ここで一つ問題があって、
nodejsのwebサーバーということは、js拡張子でサーバー処理を行う必要があるという事なんですが、scriptタグのsrc呼び出しの.js拡張子と、URLでphpのようにアクセスしてきた.js拡張子をどのようjに区別すればいいのか・・・
こんな問題が勃発しました。
そもそも、これを回避するために、set-fetch-destを使っていたんですが、今となっては、そんな汎用性のない機能を使うわけにはいきません。
そこで判断したのは、contentTypeに、任意の値を持ったもの（Content-Type:application/apiなど）または、POSTリクエストを持っている.js拡張子のものは、サーバーサイドjs処理を行うように分岐することにしました。
この仕様でほぼ機能は要望を満たす事ができるようになったとさ・・・
仕様は重要
今回の修正で、無事に、GooglePageSpeedInsightで点数を出した結果、このブログサイトと同じ構成で、モバイル90点、PC99点を出す事ができました。
NextjsのSSRとSSGと似た様なサーバーサイドレンダリング機能を設けたお陰でしょう。
さらに、画像は全てwebpで対応するという、webサイトのお作法でツッコミできないぐらいの仕様にして、この点数が出せたわけですが、今後のホームページ制作では、このフレームワークで対応してあげることにしよう。
だって、webサイト構築は、htmlとjsとcssだけでできるから、超高速スピードでのシステム開発やホームページ開発ができるようになったんだから。
え？NextJS使えよって？webpackも便利に使えよって？そういう、バージョン依存になやまされるシステムって、運用コストが高くつくのよ。
基本をしっかりと押さえて、必要最低限の教育コストで、楽な運用ができて、手直しも楽な方が、手離れの良いシステムができるって事よ。
どこまでいっても、なまけ癖が抜けない、ユゲタでした。
エンジニアとは、怠けるために、しっかりとしたシステムを組み上げる人の事と考えた。
