HTML5 Conference 11/25

HTML5 Conference 11/25
JavaScriptである区間にかかった時間を計測する時に、次のようなコードを書いたことがあると思います。 const start = performance.now(); // 処理 // 色々な処理がすべて終わった doSome(() => { console.log(performance.now() - start); }) Performance Timelineのperformance.markとperformance.measureなどを使うと、ある区間の処理時間をもっと簡単に取ることができます。 APIについて詳しくは以下の記事を見るといいと思います。 User Timing API: あなたの Web アプリをもっと理解するために - HTML5 Rocks Performance.mark() - Web API インターフェイス | MDN 簡単に解説すると perf
最初にいっておく。これは負け惜しみだ。 SPAとPWAの現状 自分は日本でReactの勝手エヴァンジェリストみたいなことをやっていて、SPAの重めのコンテンツをよく作ってるからか、「お前らフロントエンドを物事をややこしくして、重いページを量産してウェブを劣化させてるじゃないか!」みたいな批判を、名指しでよく受ける。なんで僕にいうかわからないけど、React = SPA みたいなイメージでスケープゴートにされてるんだろう。それはまあいい。 自分の仕事でSPA技術を使うところは、ちゃんと必要性もあるし理由も説明できる。ただ、やはり近年の複雑化/重量化について思うところはあるので、逆に振って AMP/PWA という選択肢を持っておきたくて、正直言うと依頼されたR&Dの仕事でもあったんだけど、一通り覚えた。なんだけど、今のところ仕事で使うタイミングがない。 PWA技術を仕事で使えなかった理由として
こんにちは、フロントエンドを中心に開発しています、原 (@herablog)です。 昨年10月にアメブロ2016 ~ React/ReduxでつくるIsomorphic web app ~という記事で、アメブロのJavaベースアプリから、Node.js・Reactベースアプリへのリニューアルについてお伝えしました。今回は、より進化した2017年版のWebアプリケーション開発に向けて、その後おこなわれた改善についてお伝えします。 https化 2016年4月に、ameblo.jpのhttps化をおこないました。セキュリティ観点としては当然のこと、SEO効果やブラウザの新しい機能の利用など、https化はWebアプリケーションのクオリティアップには必須といってよいでしょう。 まず、サブドメイン化されたサブシステムのhttps化をおこない、その後アメブロ本体のドメインをhttps化しました。ht
Web サイトっぽい SPA に立ち向かう 大分前の話ですが、Node学園 20時限目 今回もdots!!!!! - connpass で Client Side of なんちゃらfresh.tv としてお話した内容のうち、Web サイトっぽい SPA に関してだけこだわりを再抽出して書き留めます。 本件は、ページ全体のスクロールや頻繁なナビゲーションを伴わず、1画面におさまるレスポンシブな Web アプリを作っている場合はあんまり関係がありません。画面内の局所的な状態更新は、コンポーネントの責務分割やら何やらの設計なので実は別の話です。 総じて、Web サイトっぽいくせに大人の事情で Web ブラウザのネイティブなナビゲーションを積極的に破壊しにいくときの心構えです。 URL が変わっても最低限レンダリングできるまで画面更新を遅延させる 画面遷移に必要なのは、 URL が更新されても次の
Overview Velocity is an animation engine with the same API as jQuery's $.animate(). It works with and without jQuery. It's incredibly fast, and it features color animation, transforms, loops, easings, SVG support, and scrolling. It is the best of jQuery and CSS transitions combined. Download Download Velocity, include it on your page, and replace all instances of jQuery's $.animate() with $.veloci
みんな大好きHaskell風altJS!みんな違ってみんな良いのですが、やはり気になるのは生成するjsの速度やサイズですね! 今回は竹内関数を使用してベンチマークを行ないました! エントリー javascript haste-0.4.3 fay-0.22.0.0 purescript-0.6.2 Elm-0.14 ghcjs-dev idris-0.9.15.1 ベンチマーク条件 ベンチマークには正格評価の竹内関数(Tarai)を使用した コードは以下のHaskell実装をベタ移植した1 2 コンパイルされたコードをuglifyjsにより圧縮した javascriptの実行にはnode-0.10.35を使用した ベンチマークは10回実行し、process.hrtime関数で計測した 実行環境はMac book air Mid 2011(メモリ4GB, CPU 1.8GHz Core i7)
https://www.youtube.com/watch?v=p2F-128e3sI 1 comment | 2 points | by WazanovaNews ■ comment by Jshiike | 33分前 Socket.ioのクリエーターとして知られるGuillermo RauchのBrazilJS 2013での講演です。理想のシングルページアプリをつくろうとすると、JavaScriptが損なってしまうケースはあるとしながらも、一方で、多いに可能性を感じさせるトレンドもあるとして、最優先であるユーザエクスペリエンスを向上させるポイントを紹介しています。 1) 課題 スクリプトやCSSにブロックされることで、レンダリングの際にブランクページを表示してしまう。 Webスクレイピングというコンセプトを壊してしまう。サーバレンダリングしない限りは、フロント側はスムーズにスクレイピ
リアルタイムアナリティクスのサービスを提供しているGoSquaredがエンジニアブログで紹介しているのは、サイトパフォーマンス向上の工夫。今回は、アセットのダウンロードやパースのところでなく、遅延をおこさずにスムーズに描画するかというポイントに絞っています。 典型的なスクリーンの描画フローでは、フレームごとにブラウザがJavaScriptを評価する。もしJavaScriptによって修正されていれば、エレメントのためのスタイルやレイアウトを再計算する。次に、ページをいくつかのレイヤに描いていき、レイヤをスクリーンにあてはめるのにGPUを使う。各ステージごとに、ウェブページやアプリが行うことが違い、それぞれにコストがかかる。スムーズな60fpsを目指したければ、ブラウザは全てを16msで完了させる必要がある。 JavaScriptがレイアウトを変更(margin, padding, width
http://nodeup.com/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約6時間前 「[その1] Groupon: 単一のRailsアプリから複数のNode.jsアプリへの移行」で紹介した取組みについて、Grouponの開発チームがその詳細と最新のテクノロジースタックについて語っています。 Grouponのビジネスは店舗での割引のデイリーディールだけでなく、他の形態のサービス提供(物販、コンサートチケット、体験販売など)にも早めに乗り出していて、トラッフィク的にはそれに対応していたので、Railsでスケーラビリティに関しては実現できていた。Railsからの移行は、どちらかと言うとアーキテクチャ的に、単一の大きなアプリであったことが、機能を追加する際にボトルネックとなっていったから。例えば、サイトのビ
http://calendar.perfplanet.com/2013/rapid-response/1 comment | 0 pointsDigital ArtsとSpeedCurveを兼務しているMark Zemanが、レスポンシブサイトのパフォーマンス向上についてまとめています。 レスポンシブウェブサイトはビジュアル重視でデザインされることが多いので、パフォーマンスは二の次になりがち。320ピクセル幅のレスポンシブウェブサイトは、1600ピクセル幅のものと比較して、8%しかサイズが違わないというリサーチ結果がでている。パフォーマンス上の懸念は、レスポンシブウェブサイトの採用を躊躇する原因となっている。[参考図] Inline the initial experience (within 14k if possible) 最初の留意点は “above the fold” のCSS/J
Webフロントエンドのパフォーマンスチューニングについて全体的な話。javascript、Chrome DevToolsの紹介、ボトルネック、ポイントなど。
エキスパートが手がけたプロダクトを題材に技術的な解説を行っていくシリーズ連載、今回は wri.peです。 難しい機能の実装や、先進的なAPIの利用を通じて、執筆者が得たノウハウを余すところなく紹介していきます。 HTML5を活用したメモ帳アプリ [wri.pe] 最近、仕事で作っているミイルが忙しかったり、趣味で作っているMobiRubyがなかなか進まなかったりして、個人でWebサービス的なモノを作っていない事が自分としてちょっと気になっていました。 そこで息抜きとして、ゴールデンウイークに集中してWebサービスを一つ作ろう!と思い立ち、wri.peというWebサービスの開発に着手しました。 wri.peは自分が使いたいと思えるメモ帳を作ったので、下記の様な特徴を持っています。 Markdownフォーマットをサポート Gmailの様なアーカイブ機能 全文検索 カレンダーへのマッピング iP
[Frontrend Vol.4 powered by CyberAgent, Inc.](http://atnd.org/events/35720)に行って来ました。 とてもテストについてのお話を聞けたのでとても楽しかったです。 誤字、間違いなどありましたら教えてください。 ※アンケートへのリンクを削除しました。 # GUIのお話 ## Chrome Dev toolsのお話 * Chrome DevTools.next http://www.slideshare.net/yoshikawa_t/chrome-devtoolsnext * ショートカット便利 ### Break Point XHRとかで使う ### Timeline ボトルネックな部分調べるのが便利 ## Chromeの隠しURL的なの chrome://chrome-urls で一覧できる ## Charles デバッ
JavaScriptのパフォーマンスを上げる13のテクニック 一部意訳あり。(特に関数についての11と13)。深く理解したい方はスライドや動画を観ることをオススメ。 (元記事) http://www.jonefox.com/blog/2012/07/10/13-javascript-performance-tips/ - 先日、Googleのダニエル・クリフォードは"Google I/O 2012"にて「V8で打ち破るJavaScriptのスピードリミット」と題した素晴らしい講演を行った。その中で彼は、JavaScriptコードで実践できる13のシンプルな最適化手法を紹介している。それらはChromeのV8 JavaScriptエンジンのコンパイルや実行速度を上げ、コードを速くするものだ。彼はそれらについての多くの説明を行なっているが、もしただシンプルTips一覧が欲しいというなら、以下を
jsPerf — JavaScript performance playground What is jsPerf? jsPerf aims to provide an easy way to create and share test cases, comparing the performance of different JavaScript snippets by running benchmarks. For more information, see the FAQ. Create a test case Login with GitHub to Create Test Cases
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く