画像やリンクが無効になっている可能性もあるのでご了承下さい。
はじめに
Web サイトのパフォーマンスを計測して数値化する代表的なものに Google の PageSpeed Insights (以下 PSI) がある。
Google 検索結果に対する影響度合いとしては少ない部分だけど、快適である方が閲覧しやすいのは当然なので、問題があれば改善したい。
発生していた問題
ただ、今回はちょーっとばかり頭抱え、解決までに時間を要した問題があった。
それは時折正常に計測が出来ずにエラーが出ていたこと。
当サイトでの計測結果からレンダリングされたページのインデックスページに表示されるハズの画像が表示されていたりされていなかったりと歯抜け状態になっていて net::ERR_TIMED_OUT だとかエラーが記録されていた。
GTmetrix という他の計測サイトでは問題無く全てのレンダリングが行われていることから PSI 固有という物でもないが、発生する頻度も少なめ。でも影響は大きそうな問題だと思った。
原因を探る
PSI はダメで GTmetrix が大丈夫なら何かが異なるはず。
アクセスログを確認したところ、直ぐに大きな違いが見つかった。
正常にアクセスしてくる GTmetrix は HTTP/2.0。問題が起きている PSI は HTTP/1.1 を喋っていた。
では「何故こうなるのか」と次なる課題が生まれた。
解決まで
接続関連だからサーバーサイドの設定から確認していった。
Firewall の設定、fail2ban に何か変なのが引っかかっていないか、等々と試行錯誤。
そして Web サーバーとして動作させている nginx は OpenSSL を組み込んでいたので、これを BoringSSL に切り替えたビルドをして見ようと。これが解決の糸口だった。
OpenSSL を使用していたときにはなんら問題無く nginx -t をして設定に問題はなかったのだが、BoringSSL に切り替えると ssl_ecdh_curve に記述していた設定にエラーがあると出た。
該当した設定値は secp521r1 であり、これは Google Chrome でのサポートがなくなった方式だったようだ。
そこで ssl_ecdh_curve auto; と設定して上げることで PSI からのアクセスに HTTP/2.0 が使用されるようになり、インデックスページの画像も正常に全て読み込まれるようになった。
恐らく鍵交換に問題があって HTTP/1.1 にフォールバックされていたんだろうと
その後の追加検証により、OpenSSL を組み込んでいるときも ssl_ecdh_curve は auto のままにしておけば問題はないと分かった。secp384r1 とか指定してもエラーが出たので。
おわりに
PSI でのスコア改善を狙って弄っていたところで今回の問題に気付いたが、そもそもの ssl_ecdh_curve に関する設定を行ったのは 4 年位前だったと記憶しているので長い間こんな状態だったのかと、やっちまった気分になっていた。
PSI での計測に不明なエラーとか、レンダリングされたページの中で画像が歯抜けだったりした場合は、サーバー側の設定を見直してみるといいだろう。
コメント