Google社のSteve Soundersさんのブログ記事"Keys to a Fast Web App"を訳してみました。
速いウェブアプリの秘訣はAjaxアーキテクチャ、JavaScript、そしてキャッシングだと最近ツイートしました。この提示は自分の経験に基づいて、それぞれの寄与や節約の可能性に関する確固たるデータは持っていません。でもそれぞれについてコメントさせて下さい。
I recently tweeted that the keys to a faster web app are Ajax architecture, JavaScript, and caching. This statement is based on my experience – I don’t have hard data on the contribution each makes and the savings that could be had. But let me comment on each one.
Ajaxアーキテクチャ - ユーザーアクションすべてでページ再読み込みを伴うWeb 1.0は正しい選択ではありません。ユーザーの下からページを引っ張り出し(訳できてません…)、変更されていないリソースを再読み込みするのはもどかしいユーザー体験をもたらします。Web 2.0アプリを使って未変更のUIクロームを維持するとより円滑になり、Ajaxを使うことで軽量なデータAPIリクエストとクライアントサイドJavaScriptを使ってコンテンツの更新を実行でき、(正しく用いられた時には)滑らかで速いウェブアプリができます。
Ajax architecture – Web 1.0 with a page reload on every user action is not the right choice. Yanking the page out from under the user and reloading resources that haven’t changed produces a frustrating user experience. Maintaining a constant UI chrome with a Web 2.0 app is more seamless, and Ajax allows us to perform content updates via lightweight data API requests and clientside JavaScript resulting in a web app that is smooth and fast (when done correctly).
JavaScript - JavaScriptはウェブパフォーマンスというテントの長い支柱ですが、ほんの2,3年前はひどいものでした。覚えてますか?! スクリプトの読み込みはHTMLパーサとページの中の他のダウンロードすべてをブロックしていたものでした。スクリプトは1つずつダウンロードされました! 2009年にIE8がスクリプトの並列読み込みを初めてサポートしました。Firefox 3.5, Chrome 2, Safari 4がすぐに続き、もっと最近ではOpera 12が合流しました。(私見では、スクリプトの並列読み込みはウェブパフォーマンスの改善の中で単一では最も重要なものです。)スクリプト読み込みに加えて、JavaScriptエンジン自体のスピードが著しく速くなりました。だから私たちは2,3年前よりとても恵まれています。しかし、主なウェブサイト上で「急潜水」をしてみると、JavaScriptは依然、遅いページ、特に遅いレンダリングの最も頻度の高い原因となります。これはいくつかの要因によるものです。JavaScriptの負荷は200Kまで増えました。ブラウザは依然JavaScript回りでブロックするようです。例えば、いくつかのブラウザでは、後にインラインスクリプトが続くスタイルシートは次のダウンロードをブロックすることがあります。そして、一歩一歩の改良のための広いサポートがあるまで、多くのウェブページは、重いJavaScript負荷のダウンロード、パース、実行を待つ間、空白のままです。
JavaScript – JavaScript is a major long pole in the web performance tent, but just a few years ago it was even worse. Do you remember?! It used to be that loading a script blocked the HTML parser and all other downloads in the page. Scripts were downloaded one-at-a-time! In 2009 IE8 became the first browser to support parallel script loading. Firefox 3.5, Chrome 2, and Safari 4 soon followed, and more recently Opera 12 got on the bus. (Parallel script loading is the single, most important improvement to web performance IMO.) In addition to loading scripts, the speed of the JavaScript engines themselves has increased significantly. So we’re much better off than we were a few years ago. But when I do performance deep dives on major websites JavaScript is still the most frequent reason for slow pages, especially slow rendering. This is due to several factors. JavaScript payloads have increased to ~200K. Browsers still have blocking behavior around JavaScript, for example, a stylesheet followed by an inline script can block subsequent downloads in some browsers. And until we have wider support for progressive enhancement, many webpages are blank while waiting for a heavy JavaScript payload to be downloaded, parsed, and executed.
キャッシング - 初めてサイトを見るユーザーには、より良いキャッシングはウェブサイトを速くはしません。しかし、ウェブアプリの文脈では、より長いセッションに参加するユーザーや戻って来てそのウェブアプリを再利用しそうなユーザーについて考えます。デスクトップやネイティブアプリに匹敵するウェブアプリ体験を創造する航海では、キャッシングは必須の要素です。私はキャッシングでストレスを感じます。ウェブサイトのオーナーはそうすべきほどにはキャッシングを使いません。レスポンスの89%は一ヶ月未満のキャッシュが可能でそのうち38%は変更されませんが、レスポンスの58%にはキャッシングヘッダーがついていません。ブラウザのキャッシュは小さすぎるし、破棄アルゴリズムは改訂が必要です。非常にシンプルなAPIのlocalStorageがありますが、ブラウザのメーカはそれはパフォーマンス上悪いと警告します。アプリケーションキャッシュはより重い解ですが、それは使うのがしんどいです(Jake Archibaldの素晴らしいプレゼンテーションも参照して下さい。)
Caching – Better caching doesn’t make websites faster for first time users. But in the context of web apps we’re talking about users who are involved in a longer session and who are likely to come back to use this web app again. In the voyage to create web app experiences that rival those of desktop and native, caching is a key ingredient. Caching frustrates me. Website owners don’t use caching as much as they should. 58% of responses don’t have caching headers, and 89% are cacheable for less than a month even though 38% of those don’t change. Browser caches are too small and their purging algorithms need updating. We have localStorage with a super simple API, but browser makers warn that it’s bad for performance. Application cache is a heavier solution, but it’s hard to work with (see also the great presentation from Jake Archibald).
キャッシングのことばかり考えています。それは最も大きな、見逃された機会であり、だから私は次の2,3ヶ月キャッシングに集中するつもりです。キャッシングの分析は難しい。研究室ではキャッシュを埋めたりクリアしたりするテストをするのは難しい(そして時間がかかります)。操作や測定を簡単にするキャッシングのAPIはありません。
I’m obsessed with caching. It’s the biggest missed opportunity and so I’m going to spend the next few months focused on caching. Analyzing caching is difficult. In the lab it’s hard (and time consuming) to test filling and clearing the cache. There’s no caching API that makes it easy to manipulate and measure.
研究室でキャッシングをテストすることは有益ですが、実ユーザーのためにキャッシングがいかに機能するかをウェブ開発者やブラウザメーカが理解することがもっと重要です。Tenni Theuerと私がブラウザキャッシュの使用量を測定する先駆的な実験を行ってから5年が経ちます。あの研究はページビューの20%は空のキャッシュで実行され、もっと驚くべきことに日々のユーザーの40-60%には少なくとも1つ、空のキャッシュからのページビューがあることを示しました。私はこの実験をきっと再実験するでしょう。
Testing caching in the lab is informative, but it’s more important for web devs and browser makers to understand how caching works for real users. It’s been 5 years since Tenni Theurer and I ran the seminal experiment to measure browser cache usage. That study showed that 20% of page views were performed with an empty cache, but more surprisingly 40-60% of daily users had at least one empty cache page view. I’ll definitely re-run this experiment.
キャッシングへのフォーカスの一環でユーザーがキャッシュをクリアする時何が起こるかを測定するテストを開始しました。キャッシングに関するUIに関してブラウザがどう異なるのかは興味深いです。それらは直感的でもなく一貫性もありません。データ生成のご協力に感謝致します。どうか実験を実行してあなたの結果を投稿してください。実験は以下にあります:
I’ve started my caching focus by launching a test to measure what happens when users clear their cache. It’s interesting how browsers differ in their UIs for caching. They’re neither intuitive nor consistent. I would appreciate your help in generating data. Please run the experiment and contribute your results. You can find the experiment here:
Clear Browser Experiment
今週末に結果を報告します。では月曜日に。
I’ll write up the results this weekend. See you Monday.
