Update (2016-02-22): Developers have implemented changes to address this issue. While you won’t see the benefit of these changes immediately, it is certainly “coming soon” at this point.
I have been experiencing excessive lag on Google Chrome on Linux for a while, and I have been searching for solutions. The issue itself, has been reported in different incarnation of bug reports, including issue #424082 on Chromium bug reporting system.
Recently, it was tracked by one of the Chromium developers that some font configuration is causing an unnecessary call to fontconfig, giving it bit of a performance penalty.
Perhaps this problem wouldn’t have affected so much about western fonts, because of relatively less load involved in the system to parse western font sets (though I’d think increased CPU load would have been observed, albeit in shorter duration.)
If you are affected by this issue, you’d seen a significant lag in UI interaction, including input to the Omnibox, as well as other actions such as menus.
Unfortunately, a good number of Japanese users may have been encountering this issue, as very common fonts (at least on Linux) such as IPA fonts would have been one of fontsets that can cause this issue.
To work around, in case of KDE, you will have to install kde-config-gtk-style and change GTK styling to use fonts other than ones affected by this issue. (On Gnome, it would be gnome-tweak-tool.)
Note that you will have to restart Chrome everytime you change this setting.
Recently, the hosting company I use made it compatible to use Server Name Indication to support SSL/TLS. This has made it possible for me to encrypt many of sites under HidekiSaitoCom domain. Currently, as written in HidekiSaitoCom PKI Information some of my sites utilize certificates issued by StartSSL. The problem of StartSSL is that its limitation calls for a fee for each revocations issued, and this is mandatory for generating a replacement certificate; the problem that can be very critical for low budget sites such as mine. Certificate costs are not negligible for websites with virtually no income. These problems are perhaps one’s aimed to be fixed by Let’s encrypt project, but its implementation is still far, and considering server side implementation seems to be necessary with their model, it is still unknown when this would be available to me.
One way to solve this problem is to use Self-signed Certificate which basically a certificate that attests itself, however, as a promoter of GnuPG I thought of handling this slightly better. Meet Rhodanthe CA.
The goal of Rhodanthe CA is not to authenticate the site, however, it is mainly used to offer opportunistic encryption scheme, using root certificate that can be externally verified using an OpenPGP key. Feature for the CA includes root certificate, intermediate certificates, and also offers Certification Revocation List. Considering the upcoming Let’s Encrypt feature seems to aim to provide a light-weight basic level of domain matching authentication, other than seeing scary warning when accessed without importing the root certificate, it should offer just as good security. Perhaps, in the future, actual authentication is more bound to Extended Validation Certificates; it’s very important that we provide functional encryption to the site.
As a side story, major corporation such as Google owns its own Certificate Authority. They have this functionality by having root certificate authority to sign their CA key, which effectively makes Google’s CA Intermediate Certificate Authority to the root CA (in their case GeoTrust) in order to issue certificates for Google’s services. The problem of this is the cost and burden such as Certificate Practices Statement; what is beyond for individuals like myself to apply for.