Google Chrome、Linux下での速度問題のまとめと回避方法

(2016年2月22日更新)この問題を修正する変更が開発者により行われ、すでにソースコードに取り込まれています。この変更が実際のリリースに適応されるのにはしばらく時間がかかりますが、近いうちに修正が入るものと思われます。

最近のGoogle Chromeに、すでに何件か報告されている問題で最近原因が解明されたものがあり、その問題と取り敢えずの対処法に関してまとめます。

どういう問題なのか

Google Chromeのアドレスバー(Omnibox)の入力レスポンスがものすごく遅くなります。スペックにもよりますが、具体的には一文字入れるとそれが出てくるまでに数秒を要する、といった具合です。極端な場合には多大な遅延のせいで、入力される文字の順番が入れ替わってしまう場合もあります。(例えば、google.comと入力したつもりがgogole.cmoとなるなど)

また、インターフェース自体の再描画も全体的にもっさりとするため、メニューを開くのに遅延が出るなどの問題が発生し、全体的にGoogle Chromeメインプロセスが消費するCPUが高くなる傾向にあります。

原因は?

バグが報告されていたものの最近までその原因は特定はされていませんでした。1月6日にChromiumプロジェクトのKochi氏がこの問題がフォントのキャッシュがフォントのフォントファミリー名による参照によりキャッシュされていないとみなされ、再キャッシュプロセスが発生してしまうのが原因で発生しているということが報告されました。

つまり、まとめると以下のようになります。(Kochi氏が指摘する源ノ角ゴシック JPを使用した場合)

  • Google Chromeが源ノ角ゴシック JPを使用してフォントをレンダリングしようとする
  • Google Chromeが源ノ角ゴシック JPを使用しようと、そのフォントファミリー名のSource Han Sans JPで参照しようとするが、キャッシュされていないと見做し、キャッシュ動作(非常に重い)が発生する

というようなプロセスが発生し、これが一文字入力されるごとに発生していた、という問題のようです。

尚、上記に併せ、同氏によりコードの修正レビューが提出されていますが、すでにこの修正を含む、書き換え自体が予定されていることもあるようで、パッチとしての適応はされないようです。そのため、根本的な解決にはしばらく時間を要すると予想されます。

回避策

根本的な解決はコードに対処が入るまで行わられないものの、取り敢えず回避することは可能です。基本的にフォントのファミリー名が問題にならないフォントを使用すればいいわけです。尚、こちらで実験したところ、IPAフォントとその亜種ではこの問題が発生してしまうようです。(日本語環境ではこれらが指定されていることも多いでしょうから、この問題にあたってしまう人も多いかもしれません。)

回避方法

前述のように、この問題の影響の受けないフォントに置きかえてやるのが回避する方法になります。Gnomeを使用している場合、gnome-tweak-toolを使用し、UIが使用するフォントを問題のないものに置きかえる必要があります。gnome-tweak-toolは標準ではインストールされていないので別途インストールが必要です。

KDEの場合kde-config-gtk-styleをインストールした上で、外観設定の中のGTK設定のフォントを変えることで対応できます。

KDE GTK Config

フォント設定を例えば、Noto Sans CJK JPなどに置き換えることで対応可能です。

フォント設定

この変更を行い、右下の適応ボタンを押すことで変更が保存されます。尚、Google Chromeに対し、この変更を有効にするためには変更した後に、Google Chromeを再起動する必要があります。

Rhodanthe CA設置について

ホスティング会社が最近SNIながらもSSL/TLSに対応しました。ということで、管理中のサイト群も暗号化に対応するのですが、一つ問題としては証明書の管理が非常に大変なことでした。現状、HidekiSaitoCom PKI情報にも記載しているようにいくつかのサイトにおいてはStartSSLより無料で入手した証明書を使用しています。しかしながら、StartSSLは証明書の発行に制限がついており、また、破棄証明の作成に費用がかかるシステムになっています。そのため、全てのサイトに対してこの証明書を入手するのは破棄が必要になった場合の費用及び、破棄を行わない限り、代わりの証明書を得ることができないという関係上、何らかの不都合が生じた場合、非常に問題が発生する可能性があります。かと言って、ほぼ収益が0のサイトで証明書の費用を捻出するのは大変です。将来的にはLet’s Encryptプロジェクトが解決しうる問題であるかも知れませんが、一般公開が始まった後でもホスティング側での対応も必要であり、使用できるまでにそれなりの時間がかかるものと思われます。

そこで、現状の打開策としては自己証明書(いわゆるオレオレ証明書)を使用する方法もあるのですが、ここはGnuPGをプロモートしている者として、外部的にも検証が可能である方法を考えたすえ、実験的にRhodanthe CAを設置しました。(要はオレオレ証明書ならぬ、オレオレ認証局とOpenPGPの合わせ技です。ちなみに高木氏の区分でいくと第二種オレオレ証明書+ぐらいのものになるかも知れません。)

Rhodanthe CAの構成図
Rhodanthe CAの構成図

通常の認証局と違い、ルート証明書の別途導入が必要であるなど、サイトの正当性を保証する性質のものではありませんが、オポチュニスティックな暗号化を使用できるように今回、この設定を行いました。機能としてはルート認証及び中間認証、及び証明書破棄リスト(CRL)の利用ができるようになっています。尚、Let’s Encryptにおいてもフリーで自動的に証明書が得られる形になるようですから、サイトの認証などはほぼないものの、恐らく正当な(素の状態で警告が出ない)証明書を使用するシステムとなるかと思いますが、正当性証明に関してはドメイン名以上のものは行われないと思われますので、その正当性の信頼性は恐らくRhodanthe CAよりも少し良いぐらいになるかと思われます。ともあれ、恐らく、今後はネット上の暗号化された通信の割合を増やす、ということが主な課題になってくることから、これまで通常の証明書が担ってきた、サイトの正当性の証明はExtended Validation証明書が主流になってくると思われます。

ちなみにGoogleなど、大手の会社は自社で認証局を持っています。この場合は、正当なルート認証局より認証局自体を認証してもらう(つまり、ルート認証局の下に属する中間認証局になる)方式になっています。これはもちろん非常に高価であり、またこのような形で、正式な認証局として設置するには証明局運用規定を設置するなど、個人じゃ到底無理なレベルですので素直に諦めました。(確か、州によっては免許も必要だったと思います。ワシントン州は必要みたい。)