Bloggerでのデータファイル置場に関する検証と考察

Googleのブログサービス、BloggerではJavaScript、スタイルシート等の静的ファイルをサーバにアップロードする機能が無い。
つまり、これらのファイルは別のサーバにホスティングする必要がある。
ホスティングするサーバに関して検証を行い考えてみた。
あくまで個人的な考えです。

発端

私は今までGoogle App Engineにファイルをホスティングしていたのだが、先日(といっても結構前)、Google App Engineで数時間に及ぶ接続障害が発生し、私のブログが閲覧できない状態になってしまった。
これは、head内でGoogle App Engineのファイルを参照していたため。

ホスティングサービス

Google Site

無料で利用でき、かつGoogleが提供しているサービスとして、Google Siteがある。
Google Siteでは、ファイルアップロード機能も用意されているため、Google Siteにアップロードし、そのファイルをBloggerにて参照するという方法。
アップロードもGUIが用意されているため比較的簡単にできる。
また、ファイルの世代管理も可能。

Google App Engine

こちらも無料で利用できるGoogleのサービス。
少々知識は必要だが、自由度も高く、アプリケーションも開発できる。
ファイルのアップロードは、コマンドラインやEclipseなどによるデプロイという方式をとるため、手間がかかる。
また、ときどき障害が発生し、ファイルが参照できなくなる。
ファイルが参照できないと、最悪の場合、Bloggerの閲覧が不可能になる。(head内でGoogle App Engineのファイルを参照している場合など)

オンラインストレージ

Dropboxや、SugarSyncなどにファイルをアップし、パブリックリンク機能を利用する方法。
ファイル管理は楽にできる。
また、ファイルの世代管理も可能。
但し、レスポンスが悪い時もある。

検証

Google Site、Google App Engine、Dropbox、SugarSyncにファイルを置いて、レスポンス時間を計測。
head内でGoogle App Engineのファイルを参照するのは懲りたのだが、改めてどの程度の応答か確認してみる。
置くファイルは、100KB(102,400Byte)のJavaScriptファイル。
計測する環境は、以下

• Windows 7 64bit
• Google Chrome 23

計測は、Google Chromeのデベロッパーツール(Ctrl+Shift+I)のNetworkにて行う。
また、デベロッパーツールにて、ブラウザのキャッシュを無効化(Disable cache)した。
計測後、HARファイルとしてエクスポートし、集計しました。

単位はミリ秒です。

	Google Site (リダイレクト)	Google Site (ファイル取得)	Google Site (リダイレクト+ファイル取得)	Google App Engine	SugarSync	Dropbox
1回目	312	277	589	549	613	1295
2回目	342	269	611	512	595	1273
3回目	260	263	523	720	589	2043
4回目	271	439	710	559	565	1220
5回目	281	267	548	816	948	1463
6回目	324	240	564	669	757	1700
7回目	256	275	531	655	822	1596
8回目	294	572	866	562	1011	1336
9回目	295	315	610	561	804	1541
10回目	324	458	782	748	527	1323
平均値	296	338	633	635	723	1479
中央値	295	276	600	609	685	1400
最小値	256	240	523	512	527	1220
最大値	342	572	866	816	1011	2043

検証で分かったこと

Google Site

Google のサービス内(Blogger、Google App Engine等)からであれば、ファイルを読み込むことが可能。
ただし、直接読み込めるわけではなく、リクエスト»Auth keyの発行»リダイレクト»ファイル読込 となるため、2回目のリクエストでようやくファイルを読み込むことができる。
Google App Engineと比較すると、稼働率は高いと思う。
レスポンスで返されるファイルは、Content-Encoding:gzipとなっており、ファイルが圧縮されているため、通信量の節約が行われているので、レスポンスも早い。
Last-Modified,Etag,Cache-Control(max-age=1, must-revalidate)ヘッダによってキャッシュ制御が行われている点も良い。

Google App Engine

ファイルを直接読み込むことが可能。
Google Siteと同じようにContent-Encoding:gzipによってファイルを圧縮して返してくれる。
しかし、Google Siteより稼働率は低いと思う。
ファイルに付与するヘッダや、キャッシュの有効期限を任意に設定できるという点で、自由度は高い。

SugarSync

ファイルを直接読み込むことが可能。
レスポンスは若干遅め。
Google Siteと同じようにContent-Encoding:gzipによってファイルを圧縮して返してくれる。
Last-Modified,Etag,Vary(Accept-Encoding)ヘッダによってキャッシュ制御も行われる。
障害は少ない。

Dropbox

ファイルを直接読み込むことが可能。
レスポンスはかなり遅い。
なぜなら、Google Site、Google App Engine、SugarSyncと異なり、gzip圧縮してくれないため、通信量が多くなる。
他と比べて、倍の時間がかかっている。
Cache-Control:max-age=0となっているため、ファイルは常にサーバから取得される。
レスポンスが遅いうえに毎回問い合わせとなるため、最悪。
障害は少ないがオススメしない。

総評

今回の検証ではGoogle Siteが一番良さげ。
早速head内で読み込んでいるファイルをGoogle App EngineからGoogle Siteに変更しました。
Dropboxは意外に残念な結果でした。

他に検証してほしいホスティングサービスがあれば、コメントにて教えてください。
ただし、パブリックリンクが取得できるホスティングサービスに限ります。
Google Drive、SkyDrive、Boxは現時点でパブリックリンクに対応していません。

IE8ではIE7互換モード、IE9は標準でレンダリングさせる方法

私は Internet Explorer が嫌いだ。
IE9になっても、まともにサポートされないHTML5。
という事で、このサイトはIEでの動作確認をあまり行っていない。
また、これまで、以下のMETAタグをヘッダに挿入し、強制的にIE7互換モードでレンダリングするようにしてきた。

<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7"/>

これが無いと、IE8でまともに表示されない。
IE9まではこれで良かった。
IE9になり、CSSのサポートがマシになってきたので、IE8はIE7互換モード、IE9は標準でレンダリングさせたいと思い、調べていると以下のブログを見つけた。
Bloggerのカスタマイズでお馴染み、クリボウさんのブログ。

Internet Explorer でレイアウトが崩れる Blogger テンプレートは、IE 7 互換モードのタグを削除してみるといいかも | クリボウの Blogger Tips

http://www.kuribo.info/2012/07/blogger-ie7-compatibility-tag.html

IE9のブラウザーモードとドキュメントモード - hachy.net

http://www.hachy.net/2010/08/ie9.html 複数指定できるなんて知らなかった。
という事で、METAタグを以下のように書き換えてみた。

<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7; IE=EmulateIE9"/>

これで、IE8はIE7互換モード、IE9は標準でレンダリングされるハズ。

[GAE/J] Bloggerで@font-faceによるWeb Fontを利用する方法

Bloggerに@font-faceによるWeb Fontを利用しようと思ったのだが、思いのほか手間取ったのでメモ。
サーバ上にファイル置いたり、リクエストヘッダ弄ったりするのは分からない/めんどいという方は以下の方法をお試しあれ。
@font-faceによるWeb Fontの実装方法 (サーバへのフォント配置不要) - ログろいど

発端

Web Symbols typefaceという素晴らしいWeb Fontを見つけたので、ぜひBlogger上で利用したいと思った。
これがきっかけ。

Bloggerの制限と、@font-faceの制限

手間取るきっかけとなったBloggerと@font-faceの制限を以下にまとめる。

Bloggerの制限

Bloggerでは以下のような制限がある。

• 画像ファイル以外のファイルをホスティングする事が出来ない

これは前から把握していた。
そこで、Blogger上からファイル置場として利用できる環境を探った。(Googleが提供しているサービスのみ)
以下がBloggerで利用できるファイルホスティングサービス。

• Google Site
• Google App Engine (GAE)

前々からGAEをファイル置場として利用しているので、今回もGAEをセレクトした。
早速試してみる。
ん・・・フォントがダウンロードされていない。
レスポンスヘッダを見ると、Content-Length 0となっている。
どういう事だろう・・・。

@font-faceの制限

@font-face側の制限かと思い、@font-faceについて調べた。
すると、@font-faceには以下の制限があることが判明。

4.8.1 Default same-origin restriction

User agents must implement a same-origin restriction when loading fonts via the @font-face mechanism. This restriction limits the loading of fonts for a given document to fonts loaded from the same origin. Fonts can only be loaded via the same host, port, and method combination as the containing document, using the origin matching algorithm described in the [HTML5] specification. The origin of the stylesheet containing @font-face rules is not used when deciding whether a font is same origin or not, only the origin of the containing document is used. The restriction applies to all font types.

Some implementers would prefer to define a new mechanism (tentatively named From-Origin) to control access to all resource types, in preference to the origin matching algorithm referred to here. As such, this subsection should be considered at risk for alteration if such an alternative mechanism is defined.

Given a document located at http://example.com/page.html, fonts defined with ‘src’ definitions considered cross origin must not be loaded:

/* same origin (i.e. domain, protocol, port match document) */
src: url(fonts/simple.ttf);                     
src: url(//fonts/simple.ttf);                     

/* cross origin, different protocol */
src: url(https://example.com/fonts/simple.ttf);              

/* cross origin, different domain */
src: url(http://another.example.com/fonts/simple.ttf); 

4.8.2 Allowing cross-origin font loading

User agents must also implement the ability to relax this restriction using cross-site origin controls [CORS]. Sites can explicitly allow cross-site downloading of font data using the Access-Control-Allow-Origin HTTP header.

If an alternative mechanism to control resource loading (such as the suggested From-Origin HTTP header) is specified, the appropriate mechanism to relax the default same-origin restriction for @font-face may also change. As such, this subsection should be considered at risk for alteration if such an alternative mechanism is defined.

CSS Fonts Module Level 3

http://www.w3.org/TR/css3-fonts/

お～。
クロスドメインの制約に引っかかっていたのか。
Access-Control-Allow-Originをレスポンスヘッダに付与して回避しろと。
なるほど。

GAEでのCORS実装

レスポンスヘッダに Access-Control-Allow-Origin を付けろと言われても、GAEの static file のレスポンスにヘッダを追加するなんて機能はGAEで実装されていない。
となると、Java等で、レスポンスヘッダに Access-Control-Allow-Origin を付与するプログラムを書くしかない。
ということで、GAE/Jでレスポンスヘッダに Access-Control-Allow-Origin を付けるプログラムを書いた。
Blogger上で試してみると・・・OK。Web Fontが表示されている。

Web Symbolsのサンプル

%&'()*+,-./01234567:;<>?@ABCDFHIJKLMNOPQRSTUVWXZ[\]_`abcdefghijklmnopqrstuvwxyz{}~²³¹×

GAE以外での回避方法

Google Siteにファイルを置いても、Google SiteはBloggerのドメイン外なので、クロスドメイン通信となる。
また、Google Site側では、レスポンスヘッダに Access-Control-Allow-Origin を付けてくれたりという親切なことはしてくれない。
よって、プログラムを自分で書く以外に方法はないと思います。

プログラミングが苦手という方は、以下の方法で、Base64エンコードした内容をソース中に埋め込むか、Access-Control-Allow-Origin をヘッダに付与して返してくれるようなサービスを利用することになります。
@font-faceによるWeb Fontの実装方法 (サーバへのフォント配置不要) - ログろいど

参考までに

利用して良いかは不明ですが、Web Symbols typeface にホストされているフォントファイルは、Access-Control-Allow-Origin を付けてくれるので、Blogger上で利用可能です。
サイト内に利用可等明示されていないので、作者に確認が必要かと思いますが。
許可を得たうえで使用する場合は以下のような感じ。

@font-face {
    font-family: 'WebSymbolsRegular';
    src: url('http://www.justbenicestudio.com/fonts/websymbols-regular-webfont.eot');
    src: url('http://www.justbenicestudio.com/fonts/websymbols-regular-webfont.eot?#iefix') format('embedded-opentype'),
         url('http://www.justbenicestudio.com/fonts/websymbols-regular-webfont.woff') format('woff'),
         url('http://www.justbenicestudio.com/fonts/websymbols-regular-webfont.ttf') format('truetype'),
         url('http://www.justbenicestudio.com/fonts/websymbols-regular-webfont.svg#WebSymbolsRegular') format('svg');
    font-weight: normal;
    font-style: normal;
}