手抜きです
これ http://emija.hatenablog.com/entry/2014/03/11/231940 の話です。 Web のパフォーマンスは我々の共通の懸案ですから、真面目に考えていきましょう。 当該 URL で調査 広告オン時 Adblock した時 いずれもキャッシュ無効です。 結論 広告ベタベタ増やしてる + WiMAX のルーター置いてる場所がなんかダメなのが悪いんじゃないの？ 参考資料 読み込みに使ってるページはこれ http://blog.livedoor.jp/dqnplus/archives/1790719.html 痛いニュース広告オン 痛いニュース Adblock なんとなくブログ界隈全体が表示遅いんじゃないかという気がしますね。 ちなみに以下はうちのサイト さらにいろいろ調べた結果 ブログだいたい Adblock して 4 秒ぐらいで表示されてしてないと 8
Chromeの動作が圧倒的に速いように感じている。Chromeがリリースされた当初、それがなぜなのかよく分からなかった。グーグルだけにできて、ほかのWebブラウザ開発者にできないことなどあるように思えないが、それにしてはあまりに速いように感じたからだ。 その疑問のほとんどは、Chromeのオープンソースプロジェクト版「Chromium」の公式ブログの解説で氷解した。ブログを読んで分かったのはグーグルのエンジニアたちが信じられないほどのスピード狂であることと、そのスピードへのこだわりには2種類の“スピード”があることだ。 1つは処理速度、もう1つは応答速度だ。特に後者、ユーザーをできるだけ待たせない、イラつかせないということに対する徹底したこだわりは、すさまじい。その背後には「スピードとは、つまりお金だ」という洞察があるようだ。 0.5秒の遅延でユーザー離れ グーグル創業約1年後の1999年
矢口裕也です。 Advent Calendar 10日目はiOSのUITableViewの話をします。 ぼやき iOSアプリを開発していると70%くらいの時間はUITableViewに費やしている気がしてきます。 UITableViewは非常にめんどうなものですが、パフォーマンスがシビアでかつユーザーの快適さに直結するものなので大いに手間をかける価値があります。 この記事ではガクガク処理落ちするUITableViewを例として改善していきながら快適なUITableViewのつくりかたを解説します。 目的 以下のケーススタディでは次の目的でコードを改善していきます なめらかに動くようにする ここでのポイントは実際速くなくてもユーザが快適に感じればOKである、ということです。処理速度が高速である必要はありません。 戦略 UITableViewでのパフォーマンス問題は次の2点であることが多いです
iOS 7 の UI が分かりにくいワケ
［iOS の UIPicker を比較する］ 新しい iOS 7 の UI が識別しにくいと思っていたら、Sean Woodhouse がデベロッパの立場から同じことを指摘している。 iOS 6 と iOS 7 の UIPicker の違いを比較したものだ。 Itty Bitty Labs: “Lifting the lid on the iOS 7 UIPicker” by Sean Woodhouse: 30 September 2013 ＊ ＊ ＊ やっと iOS 7 ピッカーがよくなった？ iOS 7 の見かけが大きく変わった原因のひとつは UIPicker（およびその関連で UIDatePicker も）がフラットになったことだ。新しいピッカーは表面上はよりクリーンになったように見える。自分は iOS 6 のピッカーのビジュアル偏重と疑似３次元回転効果が好きではな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
