したいのですが、エラーの量もそこまで多くなくて困らないので放置しています。スタックトレースに表示されません。err)を送信することで一時しのぎしています。これは以下の表示されます。したやり方があると思うので直したいところです。利用しているので、ドキュメントに沿って導入してみたが動きませんでした。終了してしまうことが原因みたいだったようです。Issueもありました。https://github.com/bugsnag/bugsnag-js/issues/495エラーを送信する処理(bugsnagClient.notify)を自分で実行して、その終了を待てばよさそうなのですが、必要な情報を自分で詰めないといけないのでややめんどうでした。使えばこのあたりでやってくれます。https://github.com/bugsnag/bugsnag-js/blob/96238c360d1f021af9d006fead5d10f827cf0079/packages/plugin-express/src/express.js#L64-L76とりあえず最低限の情報だけ詰めて対応しました。アップロードする必要があります。がんばればできそうですが、今回はめんどうなので諦めました。いつかやるかもしれません。導入するのにはまったことなどを書きました。おかげでいくつかのエラーを特定して潰すことができました。いくつか中途半端になっているところがあるので今後改善していきたいと思います。スマホ対応について書きます。キャッシュする戦略について書きます。概要については以下にも概要を書いたので一読しておくとよりわかりやすいと思います。キャッシュすることで、パフォーマンスとコストを最適化することができます。そのあたりの理由も含めて書いていきます。キャッシュのパージキャッシュはやれば速くなるのは確実ですが、コンテンツが更新されたタイミングで適切にパージしないと、新しいコンテンツがユーザーに届きません。パージの戦略は提供するコンテンツやキャッシュする範囲によっても様々です。ブログサービスのようなサイトでページキャッシュするケースを考えてみます。単純に考えると、ブログ記事が更新されたときに対象のブログページだけパージすればよさそうですが、キャッシュする範囲によってはその限りではありません。更新されたタイミングでも必要かもしれません。トップページや最新記事一覧ページのようなところに記事のコンテンツが表示されていて、それらのページもキャッシュしているなら、すべての記事作成、更新でそれらのページのパージが必要です。はてなブログのようなログイン機能があったらどうでしょう。ログインしている状態でキャッシュをつくると最初にキャッシュしたときにログインしているユーザー情報が全員に表示されてひどいことになります。そんなことないだろ、と思うかもしれませんが気をつけていてもミスによってそういった状態になってしまう例をいくつも見てきました。最近ではメルカリのニュースが記憶に新しいです。キャッシュは狭い範囲で必要最小限に留めるべきです。Like、ユーザー情報の表示はクライアント側(JS)でレンダリングする、キャッシュするのは記事ページのみに留める、などです。扱わず、クライアント側で認証情報を付け足す、という設計にしました。認証については以下に書きました。これで、キャッシュする範囲は最低限ですが、それでもパージするタイミングは少なくありません。カレンダーのタイトル、概要の更新エントリの登録・編集・削除ユーザー情報(名前、アイコン)の変更デプロイなどです。このような操作が行われたときに、どうやってパージするかを見ていきましょう。以内にキャッシュをパージしてくれます。https://www.fastly.com/products/web-and-mobile-performance/caching-and-purgingパージの速さはユーザー体験につながるので、ぜひこれを使いたいところです。具体的にどのようにパージするかを説明します。カレンダーのタイトル、概要の更新エントリの登録・編集・削除これらは単純で、該当カレンダーページのキャッシュだけをパージすればいいだけです。メソッドでリクエストするだけです。https://adventar.org/calendars/1だけで済みます。特別なクライアントもいらず、非常に簡単です。ユーザー情報(名前、アイコン)の変更はもう少し複雑で、そのユーザーが登録しているカレンダーページをすべてパージする必要があります。