2014/8/30に開催された「HTML5とか勉強会 in IWATE 2014」のセッション資料です。

2014/8/30に開催された「HTML5とか勉強会 in IWATE 2014」のセッション資料です。
最近、こういう事例が増えてます ネイティブゲームアプリもグリグリアニメーションする昨今 🐤俺らもブラウザゲームの限界を目指そうぜ! 🐤盛るぜー盛るぜーー超盛るぜーー 数ヶ月後… 🐤来月リリースだけどカクカクします助けてーー 🐲きさまら何度やったらわかるんだ…そこに正座しろ…(ゴゴゴゴゴ) #こうですか?— コラーゲンたっぷりさん (@uupaa) 2014, 8月 19 🐲なぜ作ってる途中で実機で動作確認をしなかったんですか? 🐤え、あの、CreateJS なら大丈夫かとおもって… 確認してませんでした 🐲(イラッイラッ #こうですか— コラーゲンたっぷりさん (@uupaa) 2014, 8月 19 🐲(はぁ…)とりあえず実機動作とコードを見たいので開発サーバ名やログインする為の情報ください …2日後… 🐤…これで💦 🐲…動かない…あとminify解除してない状態な
昨日,ページャNightという勉強会で,はてなブログのJSの見どころを紹介するLTをした.(昨日の日記). 資料公開しようかと思ったのだけど,発表資料そのまま公開しても意味不明なので,エントリに書き直すことにした. たとえば,このLGTM画像は発表資料の1枚目で,もし発表資料をそのまま公開したら,こういう謎の画像を解説もないまま見ることになっていたはず. JSのページャいっぱいある はてなブログの編集画面には編集サイドバーというのがあって,写真とかAmazon検索とかTwitterとかinstagramとかあれこれ貼れるようになってる. Amazon検索しても画面遷移するわけじゃなくて,ウェブ2.0という感じで,XHRでJSONを取ってきて,HTMLを組み立てて表示,クリックすると選択,貼り付けを押すとエディタに挿入される,という仕組み. 編集サイドバーから貼れるサービスは10種類くらいあ
無限スクロールまたはauto pagingと呼ばれるUIには、読み終えたコンテンツがどんどん画面の上のほうに溜まっていってメモリーを食い潰すという問題がある。 なかでもTumblrは画像などのコンテンツが多いため、ダッシュボードダイバーたちは無限Tumblrユーザースクリプトなどのユーザースクリプトをインストールして、読み終えたコンテンツを定期的にページ上から自動削除するといった対策を講じていた。 ところが最近のTumblrのダッシュボードでは、ポストが画面外に出るとその中の要素が一時的にページから削除され、画面内に表示されると要素が再度復元されるようになっている。どうやらこれによって無限スクロールによるメモリーの圧迫が抑えられているらしい。 関連するコードはhttps://secure.assets.tumblr.com/assets/scripts/dashboard.jsの/*! s
OK OK, I couldn't resist that title but it probably goes a bit far. Let me try for a little more nuance: PyPy.js: Now faster than CPython, on a single carefully-tuned benchmark, after JIT warmup. It has been the better part of a year since I first started hacking on PyPy.js, an experiment in bringing a fast and compliant python interpreter to the web. I've been pretty quiet during that time but ha
さて、超チューニング祭が終わったので、感想を書こうと思う。すでに、参加者の中で、感想を書いている人もいる。 レポート - 超チューニング祭で努力賞(最速賞)をとるためにやったこと - Qiita ニコ動 超チューニング祭で最優秀賞もらいました 超チューニング祭に参加した - masarakki's blog JavaScript - 超チューニング祭に参加&表彰した - Qiita kmizu/slide_cho_tuning また、いつの間に行ったのか、優勝者に取材したところもあるらしい。 『ニコ超3』の超チューニング祭で、“創世神”戀塚昭彦氏を上回ったカップルが見せたバランス感覚 - エンジニアtype さて、筆者の視点からみた超チューニング祭はどうだったか。 そもそも、私がスタッフとして配置されるブースは、超時空ニコニコ研究所であるはずだった。しかし、超会議にさかのぼること三週間前、
Webフロントエンド・パフォーマンス 思考整理系。 Webフロントエンドにおける3要素として、過去のセッションでは下記の3つを中心に紹介していました。 通信コスト - Networking 描画コスト - Rendering 計算コスト - Computing これらの問題は複雑に絡み合い、時として相反する関係をとります。例えば、通信コストを減らすために、視覚表現を画像からCSS3に置き換えたら、描画コストが高くなってしまいスクロールが重くなった、なんてケースは頻繁にあるでしょう。 理解の問題 この3つのコストは確かにパフォーマンスに影響を与える要因であります。しかし、その要因がWebフロントエンドのページライフサイクルにおいて、どこで影響を与えているかは表してくれません。 要因がどのような影響を及ぼしうるかという基礎的な理解と、パフォーマンスの問題に取り組むための切り口としての理解は、そ
来る2014年4月26日(土)・27日(日)に、「ニコニコ超会議3」が開催され、その中で「超チューニング祭 ~ニコニコを超快適にしてみた~」が開催されるそうです。 これは、現行のスマートフォンサイトのTopページのソースファイルを競技者がチューニングして、速度やデザイン・UIの改善をして、速度と使い勝手を競うのだそうです。 「これは面白そうだ! 会場は家から近いし!」と思って参加するつもりでいましたが、事前調査で計測してみた結果、フロントエンドのチューニングでは速くならないことがわかったので、その内容について説明します。 (主催者の方にも、フロントエンドのチューニングでは速くならないという情報は伝えてあります。) まずは、計測データ まずは実際のトップページ(http://sp.nicovideo.jp)の計測データを見てみましょう。 計測は、NTT DoCoMoとSoftBankの3G回
こんにちは、id:hakobe932です。はてなブログではユーザ体験の改善のために、ページ表示速度を向上させるための様々な取り組みを行っています。このエントリーでは、はてなブログで行っている、ブラウザキャッシュの活用、JavaScriptのページ最下部での読み込み、JavaScriptの圧縮、という3つの取り組みについて解説します。 ブラウザキャッシュの活用 同じ内容のJavaScriptやCSSを、ページを表示するたびにダウンロードすると、余分なHTTPリクエストが発生しますし、読み込み時間がかかります。 ブラウザのキャッシュを利用できれば、余分なリクエストを減らすことができます。はてなブログでは、なるべく長い間ブラウザにキャッシュを保存するために、JavaScriptなどの一部の種類のファイルのレスポンスに、以下のようなヘッダを指定しています。 $ curl -I http://hat
これ 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
WebSocketが一番速いアプリケーションサーバはどれだ?:Tomcat、Jetty、Socket.IO/Node.js性能比較(1/3 ページ) はじめに 2012年の10月にWindows 8が発売され、そこに搭載されたInternet Explorer(以下、IE) 10ではHTML5の機能が利用できるようになりました。また、2013年の2月にWindows 7版のIE 10もリリースされ多くのユーザーがHTML5の恩恵を受けられるようになりました。 HTML5の機能の多くは、Webブラウザ側で実装されれば、HTMLやCSSを適切に記述することで利用が可能です。しかし、今回取り上げるWebSocketはサーバ側でも機能の実装が必要です。このため、WebSocketを利用する場合はWebブラウザだけではなくサーバを選ぶ必要があります。 WebSocketそのものの技術的な解説は、以下
「HTML5 Advent Calendar 2013」の24日目の記事です。 Webアプリのパフォーマンス改善と言えば、JavaScriptやDOMアクセスなど、既存の技術ベースな改善手法を想像する方も多いでしょう。最近では、こうした改善のあり方を、別の視点からもう少し広げようというアイデアが存在感を持ち始めています。それは「Web標準」です。 そこで今回、Web標準側でできるWebアプリのパフォーマンス改善について、掻い摘んで紹介します。全てを説明となるとキリがないので、キーワードを中心とさせて頂きます。最近になって、結構実用化が進んできているので、悩んだ時には試してみる価値はあるでしょう。 1. リソースを先に読み込む linkタグにてURLなどを指定することで、これから先に読み込ませる可能性が高いWebページのリソースを予め読み込むWeb標準があります。ニュースサイトでは次のページ
Gruntのtaskの実行にかかる時間を劇的に短縮する方法 最近ではGrunt無しでのフロントエンド開発は考えられなくなってきた気がしますが、大抵taskを実行した際に結構時間がかかってしまいます。 Gruntの実行にかかる時間を減らすにはどうすれば良いのか調べてみたら、loadTasks as they are needed to speed up Grunt load time · Issue #975 · gruntjs/gruntのissueに方法がありました。 何に時間がかかっているか taskを走らせた際、何で時間がかかっているのかをtime-gruntで確認してみると、実行しているtask自体ではなくnpmタスク(適切な表現かは分かりませんがGruntプラグインの事です。)の読み込みの方に時間がかかっている事が分かります。 loadNpmTasks()で2秒はかかっている状態
Introduction While JavaScript employs garbage collection for automatic memory management, it is not a substitute for effective memory management in applications. JavaScript applications suffer from the same memory related problems that native applications do, such as memory leaks and bloat, yet they must also deal with garbage collection pauses. Large-scale applications like Gmail encounter the sa
(追記: 2018年10月)何年か経ってから見ても内容大丈夫そうでした。 この記事はFrontrend Advent Calendar 2013の6日目の記事です。昨日は谷さんでWeb Components/Polymerを軽く触ってみるでした。(これ今後数年で大流行りしそうに思うので、未読なら是非!) さて、最近はHTML5だCSS 3だFlashやめてJS制御でアニメーションだーってんで盛り上がってるわけですが(周回遅れ)、いざアニメーションを実装してみても、なかなかスムーズに動いてくれなかったりしますね。 どうやったらスムーズに動くかってのを解説したいと思います。 なおこの辺りの情報は、概ね斎藤さんを中心としたFrontrend絡みの方々に教えて頂きました。感謝感謝。 先に結論 概念的なの GPU合成レイヤーを適切に使うと早い いわゆるハードウェアアクセラレーション 何がCPUで、何
普段気をつけてるよリスト "モバイルで、WebViewとブラウザのコンパチで、特にセオリー化されていないデザインモジュールのなか、装飾画像もふんだんに使うぞ系サービス開発" の文脈における、パフォーマンス確保のため気をつけてるよリスト。 よく、パフォーマンス「向上」とか「確保」とか申しますが、メンテナンスコストなどと天秤にかけて、「必要十分」のラインを狙うのが重要だと思う次第。 画像リソース 画像リソースを揃えるときのセオリ。圧縮率とか最適化とか細かいチューニングはあれど、大雑把に下記を守る。そしてImage Optim(or 相当の処理)。 JPEGはプログレッシブで画質60くらい(オレ目安) PNGは差し支えない範囲で色数をきちんと削る 50px未満のサムネイルは@2.0xなリソースにしない 案外、Androidあわせの@1.5xや@1.0xでも大丈夫なことすらある GIFアニメを入れ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く