HTML5フレームワークにおける表示オブジェクトのパフォーマンス検証※検証結果は次のブログ記事にまとめていますので、まずはこちらを参考ください。 http://ics-web.jp/lab/archives/201 HTML5のフレームワークでどれが最もパフォーマンスがいいのか、移動・回転・拡縮・透明度・親子構造を扱う条件のベンチマークテストで試してみた。 続きを読む
描画とかGPUアクセラレーションの怪 (モバイル編)
何かと不透明なあたり 気がつけば一ヶ月ほどブログを更新していませんでした。リハビリ記事です。 今回は、GPUを効かせる == それに関連するプロパティ（ただしOSやバージョンによって何がトリガかは厳密に異なる）を適用したら挙動が改善した、というようなノリの体験TIPSをゆるくまとめました。 このあたりの振る舞いについては、描画パフォーマンスの問題として、それなりに明らかになってきているように思います。WebKitのレンダリングプロセスにはじまり、GPU命令のサポートが受けられるのはどんな操作だとか、GPUへ処理が預けられるレイヤーの生成がどーとか、最近よく見聞きします。 自分が業務で扱っているスマートフォン向けのWebサービスでは、このような描画パフォーマンスの問題は、スクロールパフォーマンスと合わせて非常にクリティカルです。この辺りについてのロジカルなまとめは、某氏が近日中にまとめるらし
Webアプリケーションを高速化する50のトリック
MicrosoftのInternet Explorer PMであるJatinder Mann氏は、BUILD 2012でHTML5アプリとサイトを高速化する50のパフォーマンストリックというセッションで、Webアプリケーションを高速化する多くのチップスを提供した。 Mann氏が提供したアドバイスは、以下の6つの原則を中心に構成されていた。 1. ネットワークリクエストに迅速に応答する リダイレクトを避ける。上位1,000のWebサイトのうち63%は、リダイレクトを使用している。これらはリダイレクトをやめることによって10%のパフォーマンスを改善することができる。 メタリフレッシュを避ける。世界のURLのうち14%は、メタリフレッシュを使っている。 可能な限りユーザーの近くにあるCDNを使用してサーバーの応答時間を最小化する。 異なるドメインからのリソースをダウンロードすることによって、同時
WebWorkerでXMLHttpRequest - Qiita
XMLHttpRequestをWebWorkerで実行する Senchaが公開したHTML5のFacebookクライアント、Fastbookの高速化手法として、 XMLHttpRequestをWebWorkerで実行するのがあるそうです。 ということで、実際にやってみました。 WebWorkerの呼び出し jQueryを用いた環境で使いやすいように、jQueryの$.ajaxインターフェイスに似せています。 ただし、XMLHttpRequestをWebWorkerからは取得できないので、全く一緒ではありません。 ExecutorServiceの実装 WebWorkerを大量に作成すると負荷がかかるので、 少し手間ですが、同時実行数を制限し、リクエストをキューイングする ExecutorServiceを実装します。 var ExecutorServece = (function() { Ex
旧・Macの手書き説明書 - FC2 BLOG パスワード認証
ブログ パスワード認証 閲覧するには管理人が設定した パスワードの入力が必要です。 管理人からのメッセージ https://mac-tegaki.comへ移転中 閲覧パスワード Copyright © since 1999 FC2 inc. All Rights Reserved.
GmailがハマったSPDYの落とし穴 - ぼちぼち日記
1. SPDYブーム到来 おかげさまで、ここ数日 SPDY が私の周りで非常にブームになってきています。 前回案内したSPDY＆WS勉強会は既に200名以上の申し込みがあり、今ではSPDYネタでブログを書くと非常に注目されるうれしい状況です。時代はまさに、 SPDYはハイプサイクルを順調に駆け上がっている 状況だと思います。 図１：2012年のハイプサイクル： 図はガートナー社のプレスリリース http://www.gartner.co.jp/press/html/pr20120906-01.html から引用 SPDYが、まだ黎明期に入ったばかりなのか、それとも既にピーク期に入ったのか、それは歴史が証明してくれるでしょう。 ということで勉強会までSPDY熱が冷めないよう、私もいろんなSPDYネタを出していきたいと思います。 2. GmailがハマったSPDYの落とし穴とは 先日、 Goo
CoffeeScript's for vs. Underscore _.each vs. jQuery $.each · jsPerf
CoffeeScript's for vs. Underscore _.each vs. jQuery $.each JavaScript performance comparison Revision 3 of this test case created by Onigoetz on 2012-4-10 Preparation code <script src="https://raw.github.com/documentcloud/underscore/ba3e31b53ef5752b40cfb2d71f594536fefbe916/underscore-min.js"> </script> <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js"> </script> <scrip
0-9, Android, iOSでのjQuery, jquip, zepto, jQ.Mobi, riddle初期化時間比較
Android, iOSでのjQuery, jquip, zepto, jQ.Mobi, riddle初期化時間比較 PCではなくAndroid, iOSのみの時間なので注意 http://jsrun.it/kyo_ago/1Akw 何も読み込まない状態 5~10ms http://jsrun.it/kyo_ago/pggf jQueryを読み込んた初期化時間 300ms~500ms http://jsrun.it/kyo_ago/jGTs jquip.events.css.ajaxを読み込んだ初期化時間 80ms~150ms http://jsrun.it/kyo_ago/e3B0 zepto load timeを読み込んだ初期化時間 80ms~150ms http://jsrun.it/kyo_ago/XzUy jQ.Mobi load timeを読み込んだ初期化時間 30ms~50m
ネイティブよりも速いと評判のfastbookの裏側を調べてみる - webとかmacとかやってみようか R
本記事は、Sencha Advent Calendar 2012 の23日目の記事です。1日遅れでごめんなさい！あ、今日であってた(;´▽｀A 当初完走は無理なんじゃないかと思ってたけど、みんなのがんばりで完走目前！おめでとうございます！ Sencha Touchで作ったネイティブよりも速いfacebookアプリ「fastbook」が話題になっていますね。 原文: The Making of Fastbook: An HTML5 Love Story 和訳: HTML5へのラブストーリー: メイキングオブFastbook ネイティブを凌ぐすごいパフォーマンスに驚きますよね！これらは実際にはどんなコンポーネントを使って作られているのかすごく気になります。そこで、ちょっと調べてみたいと思いました。 ネイティブアプリ向けパッケージが、https://github.com/extjs/fastbo
モバイルブラウザのキャッシュとデータストレージについて
表題の件について情報を漁った 現時点で裏取り検証をまったくしていないので、議論対象の参考程度でお願いします。 これから実際に手元のプロダクトで検証していく予定ですが、誤読や内容などの疑わしきはTwitterとかでマサカリ投げてください。 ここでは海外のイカしたgeekらが調べてくれた、貴重な情報を信じて話を進めて参ります。素直が一番って、ばーちゃんが言ってました。 Browser Cache キャッシュと言っても無限の領域ではなく、むしろ現実的に出回っているモバイルデバイスのリソースは、ごくごく有限です。その上でブラウザの振る舞いを理解できていないことを反省して、ちょっと調べてみた次第。 まずはブラウザキャッシュに依存したストラテジを支える、キャッシュコントロール + ユーザー操作に関するブラウザの基本的な振る舞いについて。 Early findings: Mobile browser c
なぜあなたがウェブサイトをHTTPS化するとサイトが遅くなってユーザーが逃げていくのか - 射撃しつつ前転 改
完全に釣りタイトルですけど中身は真面目に書くよ。 近年、ウェブサイトのHTTPS化が流行のようになっている。私の知る限り、Googleの各種サービスやTwitter、Facebookなどが完全にHTTPSで通信を行うようになっている。HTTPS、つまりSSLによる通信の暗号化によって、ユーザにこれまでよりも安全なウェブサイトを提供できる。 しかし、あなたが作っているサイトをふと思いつきでHTTPS化してしまうと、たぶん、これまでよりもサイトが遅くなる。ここでは、HTTPSで通信する場合の問題を解説する。 なぜ遅くなるのか HTTPで通信する場合、クライアントがサーバへと接続するためにはTCP/IPの3ウェイハンドシェイクという手順が必要になる。めんどくさいのでここでは詳しくは説明しないが、要するにクライアントがリクエストを投げる前にパケットを１往復させないといけないのである。パケットの往復
CSSファイルをJSから非同期読込する方法
CSSファイルをクライアントサイドだけで動的なURLつけて非同期読み込みしたい場合、単純に以下のようなコードを書くと同期読み込みになって読み込み完了まで他のファイルの読み込みがブロックされる。 (function () { var href = 'style sheet url'; var link = document.createElement('link'); link.rel = 'stylesheet'; link.href = href; var head = document.getElementsByTagName('head')[0]; head.appendChild(link); })(); これに関しては以下のように別のiframeを作成して読みこめば非同期で読み込めるので、他のファイルの読み込みをブロックしない。 （iOS, Androidで動作を確認） (fun
指定した画像のロードが全て終わった後のタイミングで任意のスクリプトを実行するJavaScript - Web系がおもしろい。
今会社にお金になるような仕事がなくて、ちょっと社長がピリピリしてて精神的にちょっと疲れるなぁ…といった毎日が続いてて、休日もあんまりJS書く状態にありつけませんでした。。なかなか。 そしてブログ書き込もうとしたらログアウトされてた関係で内容消えて書き直しになるし、踏んだり蹴ったり…うおー… とりあえずソース 今のところIEでは実行できません。 Safari, Opera, Chrome, Firefoxで実行できます。 IEも対応しました。IE用にExplorerCanvasを用意してくださいませ。 HTML <!DOCTYPE html> <head> <title>preload</title> <meta charset="UTF-8"> <!--[if IE]><script type="text/javascript" src="excanvas.compiled.js"></s
JavaScriptで画像ファイルをプリロード
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
『AndroidのWebViewのスクロールが遅い問題』
アプリ内のWebViewのスクロールが端末ブラウザよりもはるかに重い。 もうアプリとしてリリースできないレベルくらい重い。 特にある4.0端末が死ぬほど重い。ブラウザならサクサクなのに。。。 ということで、調査。 色々調べて、 ここに書いてある、 android:hardwareAccelerated="true" をmanifestに指定すると驚くほどに改善！ブラウザと大差ないすばらしいレベル！！ 3.0以上のみしか使えないけど、取り急ぎ4系はサポートできるので良しとしたが、、、 こんな問題があるとのこと。。。 当面タブレットはサポートの視野に入れてないので、一旦見なかったことに。 余裕ができたら良い方法調べよう。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
creatorish.com
404 Not Found
設計から実装まで、今すぐ始める高速化
GitHub's CSS Performance
Speaker Deck | Easily Share Your Presentations Online
