ブラウザー・キャッシュの今
元々「静的なファイルは限界までキャッシュしろ！」というような金言はそれほど重要視していなかった。The changing role of the browser cacheという記事では、開きっぱなしにされるタブと継続的デプロイをキーワードに、ブラウザー・キャッシュの役割が変化していることを解説している。 ブラウザー・キャッシュが再訪問に対して威力を発揮するのに対し、開きっぱなしにされるタブでは再訪問されることはなく、継続的デプロイされるアプリケーションではその効果は限定的なものにしかなりえない、という意見だ。納得の出来る意見ではある。 僕が元々こういった長期間のキャッシュに疑問を持っていたのも少し似ている。特に継続的デプロイの元では限定的な効果になることは自明だと考えていた。またいわゆる普通のウェブページにおいては再訪問という行為そのものが随分前から死滅したとも考えている。具体的にはソー
Cache them if you can | High Performance Web Sites
March 22, 2012 10:41 pm | 24 Comments “The fastest HTTP request is the one not made.” I always smile when I hear a web performance speaker say this. I forget who said it first, but I’ve heard it numerous times at conferences and meetups over the past few years. It’s true! Caching is critical for making web pages faster. I’ve written extensively about caching: Call to improve browser caching (lack
Clearing Browser Data | High Performance Web Sites
September 10, 2012 7:50 pm | 13 Comments In Keys to a Fast Web App I listed caching as a big performance win. I’m going to focus on caching for the next few months. The first step is a study I launched a few days ago called the Clear Browser Experiment. Before trying to measure the frequency and benefits of caching, I wanted to start by gauging what happens when users clear their cache. In additio
Guy's Pod » Blog Archive » Mobile Browser Cache Sizes – Round 2
Note that the tested Android devices and OS versions were: Samsung Galaxy S (2.2), Google Nexus S (2.3), Motorola XOOM (3.0), Samsung Galaxy S 3 (4.0), Google Nexus 7 (4.1), Google Nexus S (4.1). As you can see, with the exception of Mobile Safari, cache sizes seem to have grown significantly over the last year. Now on to the details… Persistent vs Memory Cache In last year’s tests I attempted to
Mobile Browser Cache Limits: Android, iOS, and webOS
YUI Blog Development Mobile Browser Cache Limits: Android, iOS, and webOS Mobile Browser Cache Limits: Android, iOS, and webOS Update (July 12, 2010): While the results described in this article are accurate for HTML pages, new tests have revealed very different cache limits for CSS and JS resources. The updated results are described in Mobile Browser Cache Limits, Revisited. In early 2008, Wayne
ブラウザキャッシュによる HTTP 高速化チューニング
かれこれ一年ほど前に実施した実サービスでの apache のチューニングネタを思い出したように書いています。 以前いた部署では少ないサーバ台数で大量のリクエストを如何に処理しきるかってことに燃えていたので、静的コンテンツなどをブラウザに支障のない範囲で最大限にキャッシュさせ、サーバとネットワークの負荷を最小化させていました。 当時参考にした情報源は以下の３つでした。 どのようなレスポンスヘッダを返しておけばブラウザキャッシュを最大化できるかのテクニックがまとめられています。 ブラウザキャッシュとレスポンスヘッダ - murankの日記 Kazuho@Cybozu Labs: キャッシュの上手な使い方 [Studying HTTP] HTTP Status Code チューニングにおいて重要なのは自分自身での検証。というわけで自前で検証した結果と検証するために用意したプログラムを公開します。
Internet Explorer 9 において Webサーバーとの通信なしでキャッシュからコンテンツを表示する場合がある - Microsoft サポート
現象 Internet Explorer 9 で次の設定になっている場合、Web サーバーと通信せずキャッシュされたコンテンツを表示する場合があります。そのため、Web サーバーとの通信が必要な処理を行うことなくコンテンツが表示されることがあります。例えば、クライアント証明書を使った認証が必要なコンテンツ表示などがあります。 [インターネット一時ファイルと履歴の設定] で [自動的に確認する] が設定されている (既定値) 原因 本現象は Internet Explorer 9 の仕様です。 解決方法 この動作による Internet Explorer 9としての問題や影響はありませんが、以下のいずれかの方法で毎回 Web サーバーと通信してコンテンツを取得/表示させることができます。 Web サーバー側での対応 コンテンツのHTTP Header やMeta タグでCache-contr
Make IE cache the resources but always revalidate
The cache control header "no-cache, must-revalidate, private" allows browsers to cache the resource but forces a revalidate with conditional requests. This works as expected in FF, Safari, and Chrome. However, IE7+8 does not send a conditional request, that is, "If-Modified-Since" is missing in the request header and hence the server responds with HTTP/200 instead of HTTP/304. Here are the full se
IPA ISEC セキュア・プログラミング講座：Webアプリケーション編 第5章 暴露対策：プロキシキャッシュ対策
第5章 暴露対策 プロキシキャッシュ対策 プロキシキャッシュへのコンテンツ残留 ブラウザとWebサーバの間には、いくつかのキャッシュメカニズムが働いていることが多い。 プロキシサーバのキャッシュ──企業等LANを運用している多くの組織体ではLANからインターネットアクセスを行う際プロキシサーバを経由して行うことが多い キャッシュサーバ─インターネットプロバイダの中には、会員のWebアクセスを円滑にする目的でキャッシュサーバを運用しているところがある これらのキャッシュメカニズムは、ブラウザからのリクエストによって得られたコンテンツをキャッシュに保持しておき、同じURLのリクエストが生じたとき、本来のWebサーバにコンテンツを取りに行かず、キャッシュの内容をブラウザに渡すものである。 このようにキャッシュは、円滑なインターネットの利用に寄与してくれる。 しかし、コンテンツによっては、ただひと
クラウド時代はDNS Pinningが落とし穴になる | 水無月ばけらのえび日記
公開: 2011年9月3日19時50分頃 モバツイ (www.movatwi.jp)の作者えふしんさんと、Twitterでこんなやりとりをしました。 OperaってDNSのTTL考慮してない？！多くのブラウザは安全性のために短すぎるTTLを無視したりしますが (DNS Pinning)、それとはまた違う話でしょうか?AWSのElastic Load Balancingで、動的にロードバランサーのサーバが増えたり減ったりするようで、夜明けのOperaがよく全然違うサービスに繋がってしまうことがあるんですよね。少なくともクッキーは送っちゃってますよね...あー、なるほど。それはまずいですね。これは盲点でした……。 OperaやIEなどは、DNSのTTLが短く設定されていても無視してキャッシュし続ける事があります。これはDNSの負荷を減らすというだけはでなく、セキュリティ上の意味もあり、「DNS
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
The State of Browser Caching, Revisited
Two Important Differences between Firefox and IE Caching | HttpWatch BlogHttpWatch Blog
サービス終了のお知らせ
Vulnerability about IE, Firefox, Opera: bypassing DNS pinning | Vigilance.fr