Scribble at 2025-08-21 17:23:58 Last modified: unmodified

やはり、今年になって Google Workspace で使っている Google Chat の表示が異様に遅くなっている。サイド・バーからスペースを選んでも、チャットの内容が表示されないことも多々あるし、表示されたとしても20秒くらいかかることがある。もちろんだが、自宅の NURO が遅いわけでもなければ、僕のマシンがチャットすら扱えないくらい遅いわけでもない。

想像できる理由の一つは、Google のサーバやネットワークというリソースを節約しているからであろう。節約すればするほど利益が出るからだ。しょせん、こういうことはどのていどまでエンド・ユーザが我慢するかという問題でしかなく、エンド・ユーザの利便性を最大化することが第一の目標であるネット・サービスなんて存在しない。あたりまえだが、アメリカの上場企業（いや上場していなくとも VC に援助してもらっていれば未公開でも）は株価つまりは利益が第一の目標である。

そしてもう一つの理由は、弊社も Google Chat を５年以上にわたって利用しているので、ローカルに溜め込んでいるデータが膨大になっている。そして、Google としてはローカルのデータを溜め込むことが優先の設計になっているだろう。なぜなら、チャットのデータを最新１ヶ月とかにして、そこから遡ったり、あるいは全期間にわたって検索するような処理が必要になったら、ネットワークや Google のサーバに負荷がかかるからだ。利用者の全てのデータをローカルにキャッシュすれば、Google 側のネットワークやサーバに負荷はかからないし、レスポンスも・・・それなりの範囲で早いとは言える。

だが、Ajax を始めとするフロント・エンドのパフォーマンスに依存するシステムの大半が、要するにエンド・ユーザのコンピュータの性能に依存しており、しかるにシステムのパフォーマンスについて責任転嫁するインチキであることは、"Ajax" だ "Comet"（知らない人に説明しておくと、これは "reverse Ajax" のことだ。ローカル・マシンから非同期で通信するシステムであり、たとえば Windows マシンに Adobe Creative Cloud をインストールすると、この仕組みを使う Node.js が問答無用でインストールされる）だというフレーズが登場した15年くらい前から、Shibuya.ja なんていう子供のお遊戯会など一笑に付しつつ、僕らのようなレベルで仕事をしていてウェブ・アプリケーションの動作原理にまで関心をもっていたエンジニアであれば、15年くらい前に誰もが指摘して懸念していたことだ。

ということで、５年以上も使ってきて、パフォーマンスの低下をユーザ側の責任にされるという便利な仕組みがあるのだから、アメリカの上場企業なんていう合法的なヤクザ者どもが利用しないはずもないわけである。