t_wの輪郭

2022年8月21日

複数回発行されているSQLクエリを1回にまとめることで高速化を図った。
結果としてはDOMContentLoadedが600ms程度から550ms程度になり、僅かに高速化された。

リンク先のコンテンツ量が乏しいリンクと前景を無効化する処理を、アクセスされた時ではなく事前に処理するようにした。
DOMContentLoadedが550msから130msに高速化された。満足のいく結果になった。

2022年8月10日

若干サイトがもたつく気がする。度重なる機能追加で重たくなった可能性がある。実行速度の測定をしてみる。
開発環境でhtmlが渡されるまでを測定してみたところ、以下の結果となった。
開発環境：162, 145, 156, 153, 150 [ms]→平均153.2 [ms]

サーバー側のプログラムを触ってみたがそれほど高速化できなかった

Amazon Mobile Popoverの読み込み待ちで描画が遅れている。削除した。

そろそろCDNが使いたくなってきた。ただ、CDNを使うとサーバーまでアクセスが届かないので

• アクセス解析ができない
• 記事が一定数閲覧されたらTwitter APIで自動的にTwitterへ投稿ができない

一旦の対応としてGoogle AnalyticsをCookie無しでも動くようにした。

2022年5月4日

ローカルで動かしているときは問題ないのに、サーバで動かすとリソース（特にfavicon.svg）の取得に謎の待機時間が生じていた。600msとかの待機時間が発生していた。

nginxの設定でlimit_req_zoneが
limit_req_zone $binary_remote_addr zone=limit_req_by_ip:10m rate=1r/s;
にしてしまっていたのを、
limit_req_zone $binary_remote_addr zone=limit_req_by_ip:10m rate=10r/s;
に変更した。

秒間1アクセスまでに律速されていたのが、秒間10アクセスまで許容するようにした。
良く調べずに使うからこうなる。

調べてる途中でDBが遅いのかもしれないと思い、CREATE INDEXした。効果はなかった。

変な小細工をして手間をかけるよりも、CDNを噛ませる方が楽に早くできるので好み
サーバ側の負荷も下げられる
ただ、デライトのような動的なコンテンツを扱う場合は工夫が必要になりそう
お金もかかる

ビルド時にウェブサイトのHTMLファイルを生成する方式。またはそれを行うソフトウェア・フレームワークのこと。

If a page uses Static Generation, the page HTML is generated at build time

利点

• サーバーの負荷が小さい
• CDNの恩恵を受けることが容易なため、レスポンスを早くしやすい

Statically generated pages can be cached by CDN with no extra configuration to boost performance