前回のエントリーで、Dartの次は、TypeScriptを検証する。と書いたけど、なぜか自分のPCでは、VisualStudio for WebにTypeScriptのプラグインがインストールできなかったので、TypeScriptを使うことを諦めました。コマンドラインでコンパイルはできたけど、それでは型付け言語のメリットであるIDEによる補完や参照検索やリネームリファクタリングが効かないので。ちなみにプログラマのPCではあっさりインストールできたとのこと。がっくり。 というわけで、Dartを実戦投入することを決定してDartで開発をしています。 フロントエンド高速化のExpiresヘッダ さて、今日の本題。Webシステムのフロントエンド高速化のお話です。Webシステムの速度の大きなボトルネックとしてDB負荷がありますが、ブラウザ側のレンダリングを高速化する話としてフロントエンド高速化があり
Webパフォーマンス ベストプラクティス Last updated: 02 October 2012 翻訳：@t32k WebページをPage Speedで調べるとルールに準拠していないものが提示される。このルールというのは、一般的にあなたが開発段階において取り入れるべきフロントエンドのベストプラクティスだ。あなたがPage Speedを使用しようとしまいと、私たちはこの各ルールについてのドキュメントを提供する（たぶんちょうど新しいサイトを開発中でテストする準備が整ってないだろう）。もちろん、これらのページはいつでも参照することができる。私たちはあなたの開発プロセスに取り入れてもらうために、このベストプラクティスを実装するための明確なティップスと提案を提供する。 パフォーマンス ベストプラクティスについて Page Speedはクライアント側からの観点でパフォーマンスを評価し、一般的にペー
ウェブサイト高速化勉強会 : ATND 2012/09/29 ウェブサイト高速化勉強会 #tnmk0929 - Togetter さくらのVPSにてサーバ＆ドメイン取得を行った流れもあり、個人用鯖にも何らかのWebコンテンツを配備・公開して行く事になるだろう(てかそういう風にして行きたい)と言うのもあり、ちょうど目にしたこちらの勉強会に目が留まり、参加して来ました。 なので現状のWebサイトを高速化させるために、ってのではなくて今後のために、という意味合いが強いですね。 会場は横浜タネマキ。最近は個人的にはYokohama.groovy等で2週間に一遍は使ってる感じですね。 タネマキ 【コワーキング ＆ シェアオフィススペース】 開始間際、ディスプレイ接続で調整が上手く行かず10分程押した後スタート。 Web Site Optimization for Beginners こもり まさあき
最近のHTML5の盛り上がりには勢いがありますが、実際の所HTML5はどうなのか気になったので描画パフォーマンスを測定してみました。上記のグラフが結果ですが、HTML5で一番よい実装よりもFlashのほうが3倍弱高速という結果がでました。ブラウザによってはFlashのほうがHTML5より18倍も高速という結果もでています。 さらに言えば、HTML5の描画パフォーマンスが最も良かったのはSafariですが、ブラウザによってはそれの15%ぐらいのパフォーマンスしかでないブラウザもあり処理速度にばらつきが大きいのが特徴でした。ですが、Flashはどのブラウザでもスコアの振れ幅が小さくブラウザ間の処理速度は安定しているように思います(プラグインなので当然といえば当然の結果ですが)。 検証デモ HTML5やFlashと言っても様々な実装方法があるので、よく使われる方法を幾つか用意して検証しています。
最近Androidとの抗争が激化しているago（@kyo_ago）です。 jQueryはCSSセレクタを多用する特徴がありますが、jQuery内では実行ブラウザやCSSセレクタの記述によって呼び出されるブラウザAPIが変わり、それによって実行速度にも影響が出ます。 この記事では「セレクタAPIとはなにか」、「CSSセレクタの記述によって呼び出されるセレクタAPIの種類」、「高速なセレクタAPIを使用するための方法」、「高速なセレクタAPIが使われるかどうか確認する方法」などを紹介したいと思います。 （※この記事はJavaScript Advent Calendar 2011 (フレームワークコース) : ATNDの1日目の記事です） セレクタAPIとはなにか セレクタAPIとは「#hoge .huga」のようなCSSセレクタから、DOM上に存在する要素を取得するためのAPIです。 jQue
Posted at 2010/10/22 01:59, Modified at 2010/10/22 03:42 Facebook のフロントエンドは結構かわったことをやっていて、例えば、ログイン後の http://www.facebook.com/home.php には <div id="pagelet_home_stream"></div> みたいな空の HTML があり、その後に <script>big_pipe.onPageletArrive({ … });</script> <script>big_pipe.onPageletArrive({ … });</script> ... と script 要素が何個もならんでいる。 BigPipe: Pipelining web pages for high performance この仕組みは (変数名のとおり) BigPipe と呼
このウェブサイトは販売用です！ t32k.com は、あなたがお探しの情報の全ての最新かつ最適なソースです。一般トピックからここから検索できる内容は、t32k.comが全てとなります。あなたがお探しの内容が見つかることを願っています！
続・ハイパフォーマンスWebサイトを読んでCSSセレクタの高速化の話しが面白かった（というか全然知らなくてちょっとびびった）ので紹介します。 セレクタは右から左に解釈される これは正直知らなくて、結構衝撃でした。 #foo .bar {} これはなんとなく#fooを探して、その中の.barを探している気がしてたんですけど、実は.barを探して、その親要素に#fooがあるかを探すそうです。なので特に#fooが必要なければ .bar {} と書いたほうが高速だということ。 また、以下の様に要素名で指定すると、その要素を全て探します。 #foo a {} これは一度a要素を全て探すので、できればaにclassをふって #foo .anchor {} とするほうが高速のようです。（#fooをとるとより高速） 特にユニバーサルセレクタなどは、 #foo * {} とすると、全ての要素の親要素に対して
CSSを小分けにして@importで読み込んで管理している方も多いかと思いますが、これではHTTPリクエストがファイルの数だけ発生して、パフォーマンス的に良くありません。 Googleがページの表示速度を検索結果に反映するとか言い出したりもしているので、これはもうリクエスト数を減らすしか無いですね！ でも手動でファイルを一つ一つ連結するのはとても面倒です！と言うわけで、そんな面倒な作業を自動でやってくれるPHPのクラスを書いてみました。 ライブラリについて @importで複数のファイルを読み込んでいるCSSを、動的に解析し、連結・圧縮を行います。また、表示する際にLast-ModifiedやExpiresなどのHTTPヘッダーを送出したり、gzip圧縮を行うなど、リクエストを出来るだけ軽減できるようにしています。 ダウンロード CSS_DynamicCompressor ライセンス MI
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
