斉藤祐也の海外WEBテク定点観測＜Issue.14: 2014/05/01-2014/05/31＞

今月の定点観測はURLバーの改善、Object.observe()、アクセシビリティに足りないことなどを紹介します。

注目ニュースピックアップ

URLバーの改善 – JakeArchibald.com

原題: Improving the URL bar

iOS SafariではURLの表示がドメイン名になっています。(URLを表示しているエリアをタップするとURL全体を表示します。)
Google Chrome Canaryの、しかもExperimental Flagのオプションを有効化することで同様の機能を利用できるようにしています。
この機能と記事の筆者であるJake Archibald氏の『一般的なユーザにとってURLはノイズです。プロトコル、オリジン、パスを混ぜ合わせたものです。このターミナルのコマンドのようなものをユーザにそのまま送り返すUIはよいUIであると言えない。URLは共有のしやすさを失わないように、セキュリティにフォーカスしていくべきだ。』という記事の最後に書いた意見は、下記の関連リンクで様々な意見を集めています。

関連リンク:

• URLy warning – Adactio
• On Chrome hiding URLs to protect users from phishing – remy sharp’s b:log
• URLs are already dead – NCZOnline
• Do we really need to hide the URL? – FT Labs

Object.observe()を使ってデータ・バインディング革命を – HTML5 Rocks

原題: Data-binding Revolutions with Object.observe()

JavaScriptでMVCを、というムーブメントが発生し、実際のプロダクトでも利用されるシーンが増えてきています。そんな中で生まれたデータ・バインディングと呼ばれるような機能へのニーズの高まりは必然ともいえるでしょう。そんなニーズに答えるObject.observe()という機能がChrome 36ベータ版にて利用できるようになりました。このAddy Osmani氏によるHTML5 Rocksの記事では、そのObject.observe()の使いどころから、現状の多くのMVCライブラリでの解決との比較など非常に詳細にわたる解説をしています。

『なぜ』と問うことが常に最適な戦略とは言えない – Inside Intercom

原題: Asking why is not always the best strategy

『なぜ』を繰り返すことは本質的な問題にたどり着く方法だと言えると思います。しかし、HubSpotのプロダクト・デザイナであるDaniel Ritzenthaler氏は、闇雲に『なぜ』を繰り返すことは生産的ではないとしています。
記事では、より生産的な『なぜ』を問うには3つのレイヤーを意識するべきだとしています。
1つ目は利便性レイヤー。ここはある機能を使って実際に何を行おうとしているのかを問うレイヤーです。
2つ目はユーザビリティレイヤー。ここはある機能を使うとどんな結果を得ることができるのかを問うレイヤーとなります。 3つ目は結果の望ましさのレイヤー。ここでは、目的を達した後、何が変化するのかを問うレイヤーです。
Daniel Ritzenthaler氏はプロダクトに対してこの3つのレイヤーを念頭においた『なぜ』はしっかりと時間を取って考え、答えるべきであり、その時間は決して無駄にならないと記事を結んでいます。

アクセシビリティにはなにが足りないのか? – A List Apart

原題: Accessibility: The Missing Ingredient

WAI-ARIAが広くブラウザでサポートされている現在においても、アクセシビリティが必要要件とされるケースは決して多いとは言えないのではないでしょうか?
このA List Apartの記事で、IBMのフロントエンド・デベロッパであるAndrew Hoffman氏はアクセシビリティに足りていない材料は、実装の順番に対する認識であるとし、さらにコード例を通じてWAI-ARIAのroles、states、そしてpropertiesに関する簡単な実装を紹介しています。

1回で正しく – Ryan Clark

原題: Do it once. Do it right.

Webのプロダクトの多くがアジャイルを採用し、短いサイクルのイテレーションで新しい機能をリリースすることは今では珍しくはありません。
Virbのプロダクト・マネージャを務めるRyan Clark氏はそのイテレーションにひそんでいるほころびを3つ指摘しています。

• イテレーションを言い訳にしない / 次のサイクルがすぐ来るからと言って、問題を先送りにしていいわけではない。
• イテレーションの破綻 / ただリリースするだけではなく、きちんと振り返り、フィードバックを次のサイクルに反映すること。
• 中長期計画なきイテレーション / 闇雲に機能をリリースするのではなく、最中的な、あるいは中間のゴールを持って開発をすること。

記事のタイトルにある通り、『1回で正しく』できることはそうするべきです。

海外トレンドコラム

デザインをレビューする時にJason Friedがする質問 – Jason Fried

原題: Questions I ask when reviewing a design

BasecampのJason Fried氏がデザインをレビューする際に質問する事柄。
リストアップされている質問は毎回全て聞くことはないし、順番には意味はありません。自分がデザイナだったらどう答えるか、あるいはデザインを評価する立場なら、聞くべき質問を忘れていないか、優れたチェックシートになるのではないかと。

ツールを使わなくても問題ない – Jonas Downey

原題: It’s OK not to use tools

2連続でBasecampのブログ、Signal v.Noiseから紹介。こちらはJonas Downey氏による記事。
昨今フロントもサーバーもインフラも新しいツールがあふれています。それらツールの取捨選択、そしてもちろん利用することも開発者にとっては重要なタスクであると思いますが、それも時と場合を考えて。単純なHTMLとCSSのページを作るのに大仰なツールは必要なく、シンプルにできるものはシンプルに。適切なツールを適切に使いこなすことが大切です。

モバイルにおけるWebアプリケーション標準化の現状とロードマップ – W3C

原題: Standards for Web Applications on Mobile: current state and roadmap

このW3C作成のページでは、SVGやCanvasなどのグラフィックス、音声や動画などのマルチメディアなど13の標準についての現状とロードマップがまとまっています。仕様そのものの現状はもちろん、実装の状況、開発者向けのドキュメントの有無、テストの状態について一覧できる表があって便利です。

スタートアップにおけるデザインの役割 – Google Ventures

原題: Cheat sheet: Understanding the role of design in startups

記事のタイトルにはスタートアップにおける、とはありますが、Webに関するデザイン全般にも通じるデザインの役割について紹介しています。

A Complete Guide to Flexbox – CSS-Tricks

原題: A Complete Guide to Flexbox

CSSにおいての次世代レイアウト・プロパティともいえるFlexboxですが、弱点が1つだけあるとしたら、機能の全てを覚えきれないことではないでしょうか? このチートシートはそのFlexboxの機能をビジュアルとともに丁寧に解説してくれているので、これから覚えようという方はもちろん、いつもドキュメントを読み返している方もぜひ。

An Introduction to IndexedDB – Dev.Opera

原題: An Introduction to IndexedDB

まだまだブラウザの対応具合には難があるものの、IndexedDBの持つブラウザ側でデータベースを持てるという機能はかなり期待が高いものです。この記事でOperaのTiffany Brown氏は、そもそもIndexedDBとは何か、ブラウザの対応状況を解説し、おなじみTODOアプリを実装していく行程をコード例と共に紹介していきます。

パフォーマンス最適化 #perfmatters

Script-injected “async scripts” considered harmful – igvita.com

原題: Script-injected “async scripts” considered harmful

JavaScriptを非同期で読み込むことが、モダンブラウザにおいてもはやベストプラクティスとはいえない。
Ilya Grigorik氏はブラウザの内部動作を元にこの説について検証しています。

Docs on Performance Considerations – Modernizr

原題: Docs on Performance Considerations

プログレッシブ・エンハンスメントを行うのに便利なModernizrのパフォーマンスを鑑みた上で利用するにはどのようにするべきか。
Paul Irish氏によるアドバイス。

The Illusion of Motion – The Sea of Ideas

原題: The Illusion of Motion

レンダリング・パフォーマンスについて語る上でFPS(Frames Per Second)という単位は欠かすことができないものです。
この記事ではFPSとはなんなのか、そして人が動きを感知する錯覚とはどのように発生するのかについて詳しく解説しています。

Parallax Done Right – Dave Gamache

原題: Parallax Done Right

エフェクトの多い少ないはあるにしても毎日のようにパララックスを活用したWebサイトを見かけます。
皆さんもすでにお気づきのように大抵はパフォーマンスに難があり、時にはブラウザがクラッシュしてしまうこともあるほど。
この記事ではそのパララックスのパフォーマンスを向上させるいくつかのテクニックを紹介しています。

FrameViewerの使い方 – The Chromium Projects

原題: FrameViewer How-To

60FPSのゴールを達成するためには1フレームあたり16msの予算しかありません。
そのゴールを達成するのに必要なことはまず計測することです。
この記事ではGoogle Chrome(Canary推奨)が密かに提供しているFrameViewerという計測ツールの使い方について詳しく解説しています。

クローズアップ“ビデオ/スライド”

スライド/ビデオ

Breaking news at 1000ms – Patrick Hamann

原題: Breaking news at 1000ms

イギリスの新聞Guardianが次世代のWebサイトを作るにあたり実行したパフォーマンス最適化についてのスライド。
そもそもなぜパフォーマンスが大切なのか、よくあるパフォーマンスのボトルネックはどこにあるのかについてよくまとまっています。

Progressive Enhancement for JS Apps – Garann Means

原題: Progressive Enhancement for JS Apps

JavaScriptをメインとしたWebアプリにおけるプログレッシブ・エンハンスメントの仕方についてのスライド。
なぜプログレッシブ・エンハンスメントを行うべきなのかから、アプリケーションの状態の管理についてなど細かい部分についてのノウハウについて紹介されています。

Principles of Mobile Site Design: Delight Users and Drive Conversions

原題: Principles of Mobile Site Design: Delight Users and Drive Conversions

Googleがまとめたモバイルサイトデザインの原則。119時間にもおよぶユーザビリティテストの結果を5つのポイントに集約し、わかりやすく具体的なアドバイスをしています。

★次回の「斉藤祐也の海外WEBテク定点観測」は2014年7月2日にお届け予定です。★

斉藤祐也の海外WEBテク定点観測＜Issue.13: 2014/04/01-2014/04/30＞

今月の定点観測はWeb Componentsベストプラクティス、誰のためのWebなのかについて、そしてソースコード・レビューをどう行うかなどを紹介します。

注目ニュースピックアップ

Web Components ベストプラクティス – WebComponents.org

原題: Web Components Best Practices

Web Componentsはまだこれからの技術であることを念頭に、この記事では現時点でのベストプラクティスを紹介しています。

1. 名前空間: 名前空間が他のWeb Componentと重複しないよう、また3文字以内に止めることが望ましい。
2. すでに存在している要素を可能な限りまねる: ブラウザ側で実装している要素と同じように実装すること。
3. エラーを出さずに失敗する: ブラウザ側で実装している要素と同じようにDOMとのインタラクションはJSのエラーを出さないように。
4. 属性の使い方: Boolean値の属性は selected=“true” ではなく、selected のように指定する。
5. イベントを使ってデータを渡す: データが大きいか、頻度が多くない限りはカスタムイベントを利用してコンポーネント間のデータのやりとりを行う。

上記に加えて、11のリスト、合計16個のベストプラクティスが現時点で上げられています。

関連リンク:

• Accessible Web Components – Part 1 – Polymer
• The Web’s Declarative, Composable Future. – Addy Osmani
• Custom Element Interoperability – Polymer

開発者のためではなく、ユーザのために – The Sea of Ideas

原題: Winning for users, not developers

iOSやAndroidなどのネイティブアプリとWebアプリは様々な観点で比較されてきています。記事の筆者であるPaul Bakaus氏はその議論の多くで大切なポイントを見失っているとしています。
例えばURLの存在がWebの優れた点としてあげられますが、URLそのものが優れているのではなく、URLはユーザにとって共有するのに、またアクセスしやすいものであるからこそ優れているのだとしています。
議論が開発者視点のものになってしまっていて、ユーザの視点を見失ってしまっているのではないかという主張。

タスクにかかるコストと得られる価値について – NCZOnline

原題: A framework for thinking about work

あるタスクにかかるコストが高すぎるという感覚値は、開発者として経験を積んでいけば、ある程度は得られるものです。しかし、単純にリクエストに対して『コストがかかりすぎる』というだけでは、『大切な機能なんだ』と言われると議論が終わってしまいます。Nicholas Zakas氏は、この記事でタスクにかかるコストと得られる価値について、どのように考えるべきかのフレームワークを紹介しています。

ソースコード・レビュー。どうやってますか? – Shane Tomlinson

原題: How Do You Do Code Review?

複数人での開発が当たり前になるにつれ、ソースコードのレビューを行うことも増えてきています。しかし、そのソースコードのレビューをどうやるのかについての情報は、決して多くありません。Shane Tomlinson氏はこの記事で彼が実際に気をつけている点について共有しています。
記事では、どのレベルの精査が必要なのかをどう決めているのか。そして、複雑なパッチに対してどう理解度を深めているのか、小さな変更で副作用を発生させないために、何をするべきか。最後に、どのようにフィードバックを返しているのか。
ソースコードをレビューする人も、レビューを受ける人も参考になる点が多いはずです。

GitHubでオープンソースに貢献する方法 – GitHub Guides

原題: Contributing to Open Source on GitHub

すでにご存じの通り、GitHubはオープンソースへ貢献する場としては最大のサイトとなっています。そのGitHubから、これからオープンソースに貢献したいと考えている人に対してのアドバイスがこちらの記事。
すでにオープンソースに貢献している方であれば、当たり前のことばかりかもしれません。しかし、反対に自らオープンソースとしてるプロジェクトを持っているのであれば、ここで紹介している事柄を揃えておくとオープンソースへの貢献者が増えるとも言えるはずですので、ぜひ。

海外トレンドコラム

Intercomではどうやってデザインをしているか? – Inside Intercom

原題: How we design at Intercom

デザインに関する非常に有用な記事を多く提供しているIntercomのPaul Adams氏による、Intercomではどうデザインをとらえ、そしてデザインしているかの記事。実際のメールとは異なる部分もあるでしょうが、この記事ではPaul Adams氏がIntercomのメンバーに送ったデザインについてのメールを掲載してます。

関連リンク:

• And They All Look Just the Same – Cognition

モバイル・デバイスにおけるリモートデバッグガイド – Telerik Developer Network

原題: A Concise Guide to Remote Debugging on iOS, Android, and Windows Phone

モバイル開発における頭痛のタネの一つであるデバッグ。この記事は実際のモバイル端末でデバッグを行うための手法である、リモート・デバッグに対するガイドをわかりやすく紹介しています。

Web Notifications API 事始め

原題: An Introduction to the Web Notifications API

ネイティブアプリだけではなく、Webアプリでもユーザに対してプッシュ型のお知らせ、いわゆるノーティフィケーションという手法はごく当たり前になっています。この手法に対する実装はサービスごとにさまざまですが、W3CはWeb Notificationsという仕様を発表し、標準化に向けての一歩を進めました。この記事ではその仕様を利用したノーティフィケーションについて紹介しています。

アニメーションを使って支払いに関するユーザー体験を改善する方法 – Michaël Villar

原題: Improve the payment experience with animations

Stripeというサービスで、どのように支払いに関するユーザ体験を改善したのか。5つのアニメーション手法を、実際のアニメーションを見ながら紹介。アニメーションは「間」のデザインであり、支払いのようなフォーム要素で大きな影響を持つ手法ですので、参考にどうぞ。

関連リンク:

• Understanding CSS Timing Functions – Smashing Magazine

Sassを使ったユニットテスト – mts.io

原題: Sass Unit Testing

フロントエンド開発において、JavaScriptのテストは当たり前と言えるほど一般化してきました。しかし、同じくらい複雑なはずのCSSプリプロセッサのテストはどうでしょうか?
この記事では、Sassにおいてのロジック部分についてのテストをどう行うかについて紹介しています。

よりよいコード書くために知っておきたいコツ – Treehouse Blog

原題: Tips for Writing Better Code

より優れたコードを書くために、知っておきたいコツを5つ紹介。中級者くらいの経験者にとってはごく当たり前の5つですが、考えずにやっている事柄こそ、言語化するのは難しいものですので、初級者だけではなく、中級者、あるいは上級者の方にも読んでおいてほしい記事です。

パフォーマンス最適化 #perfmatters

300msのクリック遅延を抑制するための調査 – QuirksBlog

原題: Suppressing the 300ms click delay

タッチデバイスにおける300msのクリック遅延問題には多くの問題が潜んでいます。Chromeは最近この300msをmetaタグに「width=device-width」と設定することで無くし始めています。この記事でPeter Paul Koch氏は例によって事細かに「width=device-width」と300msの抑制について、実際のデバイスを使ってテストした結果を共有しています。

V8に関する資料まとめ

原題: V8 Resources

V8エンジンは言わずもがな、ChromeでもNode.jsにも利用されている非常に優れたJavaScriptエンジンです。V8エンジンのもう1つの特徴はこの種類のツールとしては多くの情報が公開されている点です。
このページではそれら情報を1箇所にまとめて紹介しています。

クローズアップ“ビデオ/スライド/ツール”

スライド/ビデオ

HTTP2.0について

原題: http2 explained

HTTP2.0をプロダクションで利用しているというサービスはまだないかも知れませんが、今後はそれも変わっていくことでしょう。このページでは、そのHTTP2.0をプロトコルレベルから説明しているPDFそしてスライドを紹介しています。

CSS Grid Layout – Alex Danilo

Flexboxの利用が増えてきた、というタイミングですが、このスライドはCSSでグリッド・レイアウトを実装するための仕様である、CSS Grid Layoutについて紹介しています。
なかなか複雑な仕様なので、ビジュアルで解説してくれているこのスライドは非常にわかりやすくオススメです。

静的型付けは過大評価されている!? – Eric Elliott

原題: Static Types are Overrated: Dynamic Duo – Loose Types and Object Extension

ニューヨークで開催されたVelocityにて、Eric Elliot氏による『静的型付けは過大評価されている!?』と題した発表。
型の正しさだけでは、プログラムの正しさを補償するものではないとしています。彼はこの発表で、JavaScriptが持つ動的型付けの性質がアプリケーションを開発する上で、大きな武器になる点について触れています。

ツール

Internet Explorer Web Platform Status and Roadmap – status.modern.IE

Internet ExplorerにおけるHTML5、CSS3などの仕様の実装状況とロードマップを一覧できるサイト。
ちなみに、Chromeにも同様のサイトがあるので併せてどうぞ: Chromium Dashboard

SIZER SOZE

レスポンシブ・デザインにおいて、頭を悩ます問題の一つである画像の取り扱い。この扱いをおざなりにしてしまうと、単にパフォーマンスのよくないページが生まれてしまいます。このツールは、サイトのURLから画像をどれくらい無駄遣いしているのかをチェックしてくれます。

関連リンク: Picturefill 2.0: Use the picture element today – Filament Group, Inc., / Picture要素のPolyfillが最新の仕様に併せてリニューアルしていますので、上のツールの結果が気になるものであれば、導入を検討してみては?

CSS Vocabulary

CSSの用語をインタラクティブに実際のソースと照らし合わせて教えてくれるツールです。チームでの開発における共通認識は非常に大切ですから、しっかり覚えておきましょう。

Animated Bézier Curves – Jason Davies

ベジェ曲線について。アニメーションを使ってベジェ曲線がどのように描かれるかについて解説。アニメーションはD3.jsを利用して作成されているそう。

★次回の「斉藤祐也の海外WEBテク定点観測」は2014年6月2日にお届け予定です。★

斉藤祐也の海外WEBテク定点観測＜Issue.12: 2014/03/01-2014/03/31＞

今月の定点観測はWeb Componentsに関するパネル、WebとDOMとの関係性、ARIAのWeb標準化などを紹介します。

注目ニュースピックアップ

Web Componentsに関するパネルディスカッション

原題: EdgeConf 3: Components

3月21日にロンドンにて開催されたEDGE Conferenceにて議論されたWeb Components。このカンファレンスでの議論そのものも非常に興味深いものですが、このカンファレンスをきっかけに多くの議論がブログなどで展開されました。Web開発の未来を担うとすら表されるWeb Componentsがその未来へと着実に歩みを進めるためにどんな障害があるのでしょうか。様々な領域で活躍するエキスパートたちの意見を以下に関連リンクとしてまとめましたので、興味がある方はぜひそれぞれ一読を。

関連リンク:

• A Detailed Introduction To Custom Elements – Smashing Coding
• Web Components Best Practices – WebComponents.org
• Web Components and the Three Unsexy Pillars – Aerotwist
• The Web’s Declarative, Composable Future.
• Notes on accessibility of Web Components – Bruce Lawson’s personal site
• The Golden Path
• Notes from the edge – Adactio

Shadow DOM – Acko.net

Steven Wittens氏により書かれたこの記事のタイトルはShadow DOMですが、あのShadow DOMではなく、DOMに関する問題点へ指摘と解決策の提言です。React.jsのようにDOMらしいものを生成しDOMを制御するアプローチがあったり、Angular.jsのようにHTMLによく似たシンタックスでDOMへのアプローチを隠蔽するアプローチがあったりと、DOMから離れれば離れるほどWebそのものがよいものになったように思えてくる。氏の狙いは非常に的確なものだと言えると思いますが、以下に関連リンクとして紹介しているCSS TricksのChris Coyer氏による反論も併せて読んでおくと良いでしょう。

関連リンク: Hatin’ on Web Tech by CSS-Tricks

WAI-ARIAがWebのアクセシビリティを拡張する – W3C Blog

原題: WAI-ARIA Expands Web Accessibility

Accessible Rich Internet Applications 1.0 (WAI-ARIA)、そして関連する仕様であるWAI-ARIA 1.0 User Agent Implementation GuideがW3C Recommendationとなりました。つまり、WAI-ARIAはWeb標準となったことを意味します。広範囲に及ぶ、実装だけではなく、テスト、そしてバグ修正を行い、多くのモダンブラウザですでにサポートされ、モバイル・ブラウザにおけるサポートも広がってきています。またHTMLだけではなく、EPub 3.0やSVG 2などの仕様にもWAI-ARIAを適応し、より広範囲でのアクセシビリティを提供していくそうです。

関連リンク:

• We Make the Web. Let’s Make It Accessible. – The Changelog
• What is WAI-ARIA, what does it do for me, and what not? | Marco’s accessibility blog

Browsiness – Adactio

本連載、Issue. 11にて紹介したJeremy Keith氏による「Webに課せられたある1つの矛盾」の考察に対する追記に当たる記事といえるでしょうか。記事はAndroidとiOSの違いについての考察から始まり、ネイティブとWebの差に話が及ぶ。その段になってKeith氏はWebとは何かという根源的な疑問に対し、氏がどのように考えているかについて語っていきます。
氏は次の文で記事を締めくくります。 『分裂として捉えるのを辞め、多様性として捉え始めるべきだ。』
氏の言葉通り、WebとはHTMLやCSS、JavaScriptで書かれたものだけを意味するものではないでしょう。

関連リンク: Why don’t designers take Android seriously? : Cennydd Bowles

Web標準化に貢献するために必要なこと – Anne’s Blog

原題: Contributing to standards

Anne van Kesteren氏はWeb標準化に貢献するためには、Web標準がコミュニティによって作られていることに気がつくことが大切なステップだとし、そのコミュニティでコミュニケーションに利用されているミディアムを追いかけることを次のステップとしています。もちろん貢献しようとしている標準そのものに詳しい必要もありますが、それらを取り巻く環境にまず慣れることが活動の第一歩だとしています。

関連リンク: How to win friends and influence standards bodies – Domenic Denicola / Domenic Denicola氏がLXJS 2013にて発表した彼自身がどのように標準化団体にアプローチしたかについてのプレゼンテーション。

海外トレンドコラム

Picture要素に関するQ&A – An A List Apart

原題: [A Q&A on the Picture Element

Picture要素の復活に尽力したMarcos Caceres氏とYoav Weiss氏に対して、同じくResponsive Images Community Groupに所属しているMat Marquis氏がインタービュー。 Picture要素が以前のバージョンとどこが違うのか、それまでに登場したsrcsetやsrc-nという仕様や提案が現在のPicture要素にどのように影響しているのかなどについて詳しく解説しています。

Srcsetとsizes – ericportis.com

原題: Srcset and sizes

Picture要素の現行仕様はどうしてそのシンタックスを採用したのでしょうか? この記事ではその疑問に対して、具体的なソースコードを見ながら現行の仕様とほかのレスポンシブ画像に対する解決案を比較しています。srcsetに加えて新たに追加されたsizesという属性が重要な役割を担っているのが一目でわかります。

モバイル・ファーストはもう終わった、のか? – Forbes

原題: Mobile-First Is Dead, Says Google Display Ad Chief Neal Mohan

Googleのディスプレイ広告部門の副社長を務めるNeal Mohan氏によると、多くのユーザーはもはやモバイルだけにフォーカスをしているだけでは時代遅れになりつつあるとしています。消費者達は多くのデバイスを駆使して、利用シーンに合わせてタスクを完遂しているとしています。なんと約90%ものユーザーがあるデバイスで開始したタスクを別のデバイスで完了しているとしています。モバイル・ファーストはすでに過去の問題を解決しようとしているに過ぎないと氏は語り、今後はマルチデバイスの最適化にフォーカスを移していくべきだとしています。

若いデザイナー、デベロッパに対するアドバイス – Andy Budd

原題: My Advice to Young Designers and Developers

日本ではそうでもないと思いますが、大学を卒業するよりも業界の経験を積んでいる方が重宝される業界であるWeb業界において、大学に行く意味とはなんなのかをAndy Budd氏がアドバイス。

パフォーマンス最適化 #perfmatters

Paul Lewis氏のパフォーマンスチェックフロー – Aerotwist

原題: My Performance Audit Workflow

Googleの中でもパフォーマンスに注力しているPaul Lewis氏本人のパフォーマンスチェックのワークフローについて。氏はまずPageSpeed Insightsでサイト全体の状態を確認し、WebPageTestを使ってネットワーク周りのパフォーマンスを細かくチェック。それから、レンダリングに関わるパフォーマンスチェックを、このリストを参照しながら行っているそうです。このワークフローは手動で行うものがほとんどですが、自分が担当するプロダクトでは自動化できる部分は可能な限り自動化をしているとのこと。

ブラウザキャッシュは”とても”壊れている – JakeArchibald.com

原題: The browser cache is Vary broken

HTTPキャッシュはURLとHTTPメソッド(GETやPOSTなど)でコントロールするものですが、”Vary”ヘッダを利用してより細かく制限をすることができます。しかし、この”Vary”ヘッダは少々やっかいもので、IEでは”max-age”が無視され、Safariでは少々バグがあったりもします。この記事では具体的な例を見ながら”Vary”ヘッダの挙動について詳しく紹介しています。

CSSアニメーションとトランジションのパフォーマンスについて – Web Platform Team Blog

原題: CSS animations and transitions performance: looking inside the browser

ブラウザ内部がどのように動作しているのかを知ることで、CSSアニメーションやトランジションの記述をする前に、そのアニメーション/トランジションのパフォーマンスがよいものか、そうでないのかを知ることができます。この記事では特にGPUがどのようにパフォーマンスに作用するのか、そしてなぜ特定のプロパティをアニメートすることがパフォーマンスのボトルネックになるのかについて、詳しく解説しています。

WebKitのCSS JITコンパイラについて – Surfin’ Safari

原題: Little overview of WebKit’s CSS JIT Compiler

ブラウザはユーザーに対してよりよい体験を提供するために日々改善を行っています。この記事ではWebKitがCSSの解析にかかる時間をどう改善していくのかについて、JavaScriptの解析では当たり前のように利用されているJIT(Just In Time Compilers)をCSSのセレクタの解析に応用してみた結果について紹介しています。

jQueryはモバイルには大きすぎるのか? – Flippin’ Awesome

原題: Is jQuery Too Big For Mobile?

モバイルWebにおいて、パフォーマンスが特に重要なファクターであることはよく知られています。パフォーマンスの最適化に際し、デスクトップの時代には当たり前のように利用していたjQueryは、そのファイルサイズからモバイルでは利用されない傾向にあります。しかし、本当にjQueryはモバイルには大きすぎるのでしょうか?　この記事では実際のモバイル端末でjQueryを読み込み、どのくらいの時間がかかったのかを詳しく解析しています。また読み込みだけではなく、解析にかかる時間も加味した詳細なデータで疑問に答えてくれています。

クローズアップ“ビデオ/スライド/ツール”

スライド

Viewportとレスポンシブデザインの関係

原題: Viewports or: why responsive design works

Peter-Paul Koch氏がjQUery EUで発表したこのプレゼンテーションは氏の得意とする詳細なテストによるデータを使ったViewportから見たレスポンシブ・デザインに関する実利的なアドバイスについてです。氏はまずピクセルとはなにかから解説し、モバイルとデスクトップのViewportsの違い、JavaScriptやMetaタグによるViewportsの仕組みについて詳しく解説しています。

関連リンク: The Great Table / Peter-Paul Koch氏による本プレゼンテーションで発表したViewportに関連するコンセプトのモバイルブラウザ別の対応状況をまとめた表。

Flexboxを使って一歩上行くレイアウトを – Zoe Gillenwater

原題: Leveling Up with Flexbox

Smashing ConferenceにてZoe Gillenwater氏が発表したFlexible Box Layoutを使ったレイアウトテクニックに関するプレゼンテーション。
仕様として少々バタバタしていたFlexible Box Layoutですが、ようやく様々なブラウザで同じシンタックスが利用できるようにもなってきて、現実的なアプローチとして注目が集まってきています。氏はこのプレゼンテーションで様々なレイアウトテクニックを紹介しつつ、Flexible Box Layoutをサポートしていないブラウザに対するフォールバックについても紹介しています。

関連リンク: Leveling Up With Flexbox presentation at Smashing Conference

Guardian誌のレスポンシブデザイン対応について

原題: Responsive design at the Guardian

イギリスの新聞であるGuardianにて、クライアントサイドWebデベロッパとして働くMatt Andrews氏によるプレゼンテーション。数年前にレスポンシブデザインを採用したBoston Globe誌を始め、最近ではBBCもレスポンシブデザインを採用しています。ニュースサイトにおけるレスポンシブデザインはなかなかハードルが高い部分がありますが、そのいくつものハードルをGuardianではどのように超えていったのかについて詳しく紹介しています。

ツール

HTML5 Security Cheatsheet

HTML5に関連する技術を使ったセキュリティに関する注意点と、その回避についてのチートシート。

CSSynth

CSSアニメーションを実際に目視しながらカスタマイズできるエディタ。特定のアニメーションに限ったエディタではありますが、エディタが作り出すスムーズなアニメーションは見ていて飽きません。

CSS Filters Demo

上で紹介したCSSynthの作者による別プロジェクト。こちらはCSSのフィルタを使ったデモ。

★次回の「斉藤祐也の海外WEBテク定点観測」は2014年5月1日にお届け予定です。★

斉藤祐也の海外WEBテク定点観測＜Issue.11: 2014/02/01-2014/02/28＞

今月の定点観測は、Webが持つある1つの矛盾についての考察、TLSのパフォーマンス最適化Tips、jQueryの未来に対する提言などを紹介します。

注目ニュースピックアップ

Webに課せられたある1つの矛盾についての考察 – Adactio

原題: Continuum

常に進化を続けるWebと、常に停滞しているWebは表裏一体の存在です。その矛盾が存在する理由はブラウザです。新しいCSS、新しいJavaScriptの仕様が、すべてのブラウザで利用できるということはもちろんありません。
Jeremy Keith氏は、この記事でWebが進化をするために、その矛盾の存在は欠かすことができないとしています。その上で、改めてWebサイトがすべてのブラウザでまったく同じ見た目や動作をする必要性がないこと、そしてクライアントや上司がそれを望むというのであれば、そうではないと説明することが開発者の責務であるとしています。

関連リンク:

• This is the web platform – Tales of a Developer Advocate / Keith氏の記事本文からリンクされているPaul Kinlan氏の記事
• Platformed. — Unstoppable Robot Ninja / Ethan Marcotte氏の反応
• River — Stuff & Nonsense, And All That Malarkey / Andrew Clarke氏の反応

TLSはまだ早くならないのか? – Ilya Grigorik

原題: Is TLS Fast Yet?

HTTPSなど、セキュリティを要求される通信のためのプロトコルであるTLSには、パフォーマンス的な懸念があるとされてきました。ページのタイトルにある、「TLSはまだ早くならないのか?」という質問に対して、GoogleのIlya Grigorik氏がこのページで解答します。
その答えはページの一番始めにある一言に集約されています。
『TLSにはたった1つだけパフォーマンスの問題がある: それは十分に利用されてるとは言えない点だ。それ以外の問題は最適化できる』

• GitHub: igrigorik/istlsfastyet.com

jQueryの未来 – Belly Card Engineering

原題: The Future of jQuery

前回、本連載でも紹介したYou Might Not Need jQuery以来、jQueryについての様々な議論が始まりました。この記事はそれらの議論の中でも短く分かりやすい議論をしています。
jQueryがどんな問題を解決しようとしているのか、その解決が現在のブラウザ環境でも必要なのか。jQueryがもたらしたシンプルで理解しやすいシンタックス、抽象化がどこに向かって行くのか。記事の著者であるDave Arel氏はそれらを踏まえて、jQueryが向かうべき未来は現在実装されているよりも、さらにモジュール依存関係の管理を強化していくべきだとしています。

関連リンク:

• jquery_usage.js / Dave Arel氏が考える未来のjQueryのモジュラーアプローチについての素案とそれについての議論
• jQuery’s browser bug workarounds / jQueryのメンバーによるjQueryが回避しているバグのリスト

レスポンシブ・グリッドレイアウトの作り方

原題: Grid

Adam Kaplan氏によってGridと名付けられたこのページでは、レスポンシブ・デザインを念頭においたグリッドレイアウトを作成するために必要な多くの基本を丁寧に解説しています。
ViewportのMetaタグやCSSのBox Modelなどのレスポンシブなレイアウトを制作する上で、ベースとなる部分から最終的な実装例までしっかりとサポートしています。HTML、CSSの初学者はもちろん、コーディングにチャレンジしたいデザイナにもぴったりな内容になっています。

海外トレンドコラム

ECMAScript 6でBackbone.js TodoMVCアプリを書き換える – TasteJS

原題: Rewriting A WebApp With ECMAScript 6

この記事ではAddy Osmani氏を中心にECMAScript 6を使って、Backbone.jsで作ったTodoMVCアプリケーションを書き換えていくステップを詳細に紹介しています。記事ではTraceurというES6をES5コンパティブルに変換するコンパイラとES6 Module Loader Polyfillを利用して実装しています。

新しいCSS Shapeのシンタックスについて – Web Platform Team Blog

原題: New CSS Shapes Syntax

CSS Shapesのスペックが、先日Last Callへと移行しました。その際に変更になったシンタックスについて、この記事で細かく紹介しています。CSS Shapesが実装されているブラウザは決して多いとは言えませんが、サポートしているブラウザで見られるデモも用意されているので興味があればぜひ。

CSS Aliases

Tab Atkins氏による、CSS Aliasesというスペックのエディタ・ドラフト。
CSS Aliasesは、CSSプリプロセッサに慣れた方にとって、Mixinsとして知られる機能に似たスペックです。まだまだドラフト段階ですが、シンタックスに使われている記号など、参考にできる点もあるのでぜひ。

ローディング・インジゲータがどう心理的に作用するのか？ – Mercury Intermedia

原題: The Psychology of Waiting, Loading Animations, and Facebook

パフォーマンス改善は今では欠かすことができないトピックとなっていますが、その中でも忘れがちな『早い』と思わせる心理学について。この記事ではFlipboardのRaphael Schaad氏のTweetである、ローディング・インジゲータのデザインによってユーザがどのように反応するかについて深耕しています。

touchイベントのデフォルトアクションの抑止について – QuirksBlog

原題: Preventing the touch events’ default action

JavaScriptのイベントハンドラはreturn falseとするか、preventDefault()を実行するかでイベントが持つデフォルトのアクションを抑止することができます。Peter-Paul Koch氏はこの記事で、その挙動がtouchイベントでどのようになっているかについてまとめています。

関連リンク:

• Preventing the touch default / touchイベントの抑止についてのブラウザ間でのテスト結果表。

CSSソースマップのサポート、ネットワーク解析などFirefox開発者ツールの最新実装について – Mozilla Hacks

原題: CSS source map support, network performance analysis & more – Firefox Developer Tools Episode 29

Google Chromeの開発者ツールに追いつく日も確実に近づいているFireFoxの開発者ツール。そのツールの最新情報まとめ。 この両者の非常に健康的な争いは我々開発者にとっても利点が多く、最近では用途に応じてFireFoxの開発者ツールを使い機会も増えて来たという方も多いことでしょう。

英語という壁をStack Overflowはどう乗り越えるのか? – Stack Exchange

原題: Can’t We All be Reasonable and Speak English?

開発者にとって欠かすことができないQAサイトの1つであるStack Overflowが、ポルトガル語版をローンチしました。Stack Overflowのゴールは開発者の知見をできる限り多く、そしてそれらを1カ所にまとめることですが、そのゴールと今回の他言語対応には若干の矛盾があります。StackExchangeのJay Hanlon氏は、この記事でなぜ他言語化が必要なのかの理由について、しっかりと説明しています。すばらしいサービスを作る裏側をかいま見られます。

Facebook Paperアプリのジェスチャー地獄 – Scott Hurff

原題: Facebook Paper’s gestural hell

1月末にリリースされたFacebookのPaperはリリースしてすぐに『使いやすい、革新的なインターフェイス』の存在が話題になりました。その『インターフェイス』の使い勝手に関する考察がこちら。この記事では主に親指で無理なく操作できる領域には制限があり、Paperはその制限を飛び越えてしまっているため、使いやすさにつながっていないとしています。

関連リンク:

• Six UX Lessons Learned from the New Facebook App, Paper | UserTesting.com / こちらはユーザテストサービスを提供している会社からPaperのユーザテストの結果から得た6つのUXレッスンについてまとめています。

Firefox OSのUIを作る過程で学んだアクセシビリティについて知っておきたいこと – Marco’s accessibility blog

原題: Some do’s and dont’s we gathered from making the Firefox OS UI more accessible

Firefox OSのUIを作る過程で学んだアクセシビリティについての注意点。ご存知の方も多いでしょうが、Gaiaというコードネームで知られるFirefox OSのUIにはHTML5が利用されているため、記事で紹介されている点は通常のWebのインターフェイスの構築の際にも役に立つでしょう。

より滑らかなUXのためにJavaScriptのコンパイルを並列処理化 – Chromium Blog

原題: Compiling in the background for a smoother user experience

Google ChromeチームのゴールはChromeを最も早いブラウザにすること。そのプロセスの中、V8の最適化は欠かすことができない要素の1つです。この記事ではその最適化の中でも画期的と言えるJavaScriptのコンパイルの並列処理化について紹介しています。

クローズアップ“ビデオ/スライド/ツール”

パフォーマンスを考慮したデザインについて – Lara Swanson

原題: Design for Performance

EtsyのモバイルWebチームのエンジニア・マネージャを勤めるLara Swanson氏によるパフォーマンスを考慮したデザインについてのスライド。
スライドの序盤にある”Web performance is user experience”という言葉が内容を一言で表しています。

JavaScriptのAPIデザイン原則 – Ariya Hidayat

原題: JavaScript API Design Principles

昨年11月に開催された第五回目となるYUI Confにて、Ariya Hidayat氏が発表したJavaScriptのAPIデザインについて。ライブラリ・コードを書く人はもちろん、そうでない方も、CSSプリプロセッサのMixinなどを書く人にもおすすめの内容です。

スライドはこちら

関連リンク: API Design Principles – Qt Project / QtプロジェクトのAPIデザイン原則

実際にNode.jsをプロダクションで使ってみてわかったこと – Great British Node Conf – Paul Serby

原題: Secrets of a Node Team

Clockというイギリスの制作会社のCTOを勤めるPaul Serby氏による、Node.jsを使った実際のプロジェクトから学んだことに関するまとめ。実体験を通じた地に足の着いたアドバイスが多く、失敗談も回避策もまとまっているので参考になります。

スライドはこちら

Chrome開発者ツールの拡張機能ギャラリー — Google Developers

原題: DevTools Extensions Gallery

Google Chromeの開発者ツールそのものだけでも非常に高機能なツールですが、このページで紹介されているのはその開発者ツールを拡張するツール群。Backbone DebuggerやAngular Batarang、そしてEmber InspectorなどMV*系のJavaScriptライブラリでの開発を補助するツールなど、現時点で18のツールが紹介されています。

httpbin(1): HTTP Client Testing Service

HTTPにまつわるライブラリなどのテストをするのは何かと面倒なことが多いですが、このツールでは様々なHTTPのリクエストを送り、レスポンスを確認できます。HTTPSの通信も可能だそう。

• GitHub: kennethreitz/httpbin

ES6 Fiddle

ECMAScript 6で定義される予定となっている新しい仕様を実際に書いてその場で結果を見られるツール。いくつか例もあるので、気軽に試してみたいという方も、まだ先だからと思っている方も、体験してみるとよいでしょう。

★次回の「斉藤祐也の海外WEBテク定点観測」は2014年4月1日にお届け予定です。★

斉藤祐也の海外WEBテク定点観測＜Issue.10: 2014/01/01-2014/01/31＞

今月の定点観測は、CSS Regionsに対する問題提起、新picture要素仕様、Webスタンダードの新フェーズなど合計20件の記事や動画などを紹介します。

注目ニュースピックアップ

CSS Regionsへの問題提起 – An A List Apart Blog Post

原題: CSS Regions Considered Harmful

タイトルからしてすでに議論を呼び込むようなタイトルとなっている、CSSの父であるHåkon Wium Lie氏によるCSS Regionsの仕様に対する問題提起。
時を同じくして、GoogleのBlinkチームがCSS Regionsを実装しないという議論も始まり、大きな議論に発展しています(関連リンクを参照してください)。
この記事でHåkon Wium Lie氏はRegionsはダミーのdivを使う必要がある、レスポンシブではない、テキストフローが分かりづらい、33行にもおよぶほどのコードで実現するしかない、コードの再利用性が低いという5つのポイントを問題点として挙げています。

関連リンク:

• CSS Regions in Blink: status, future work / CSS Regionの実装についての議論
• CSS Regions Matter – Flippin’ Awesome / CSS Regionsを実利的に利用した例を豊富に紹介

The picture Element

レスポンシブ画像に対する飽くなき議論の末、議論の始まりとなったpicture要素の新仕様が発表されました。これまでの議論をうまく集約した提案となっています。フォールバック要素としてのimgではなく、picture要素内に必須となる要素としてimgを利用している点が、以前のpicture要素との違いとなるポイントとなっています。

関連リンク: picturefill – Shawn Jansepar / 新仕様に合わせたPolyfill

2014年、Webデザインは死んだのか? – Jeffrey Zeldman Presents The Daily Report

原題: It’s 2014. Is Web Design Dead?

Jeff Croft氏による「Web Standards Killed the HTML Star」という記事を見かけた方も多いかも知れません。その記事へのJeffrey Zeldman氏からの反論がこの記事です。Zeldman氏は確かにChroft氏が言う通りの部分があることは認めつつ、Webスタンダードには2つのフェーズがあり、現時点ではその内の1つ目がようやくまともになってきたタイミングだとしています。
Zeldman氏はWebスタンダードは当たり前の存在であるべきとしつつ、さらにウェブサイトを構築することを簡易にし、その上でデザイン、コンテント、そして体験を生み出すことにフォーカスしやすくするのが次のフェーズであると主張しています。

関連リンク: Web Standards Killed the HTML Star – JeffCroft.com

フロントエンド開発における問題解決へのプロセス – CSS-Tricks

原題: Thought Process of a Front End Problem

海外の第一線で活躍するフロントエンド開発者であるChris Coyier氏が自身が実際に解決しようとした「Opera mobileでフォントのレンダリングがおかしい」という問題へのアプローチについて詳細を語っています。
共感できる点が多く、やはり第一線にいるCoyier氏でも環境が大きく異なるブラウザの世界では同じように苦労しているのだなというのが分かります。
彼自身がどのように問題に対峙したのかの記録は似た問題を解決する際の参考になるのはもちろん、フロントエンド開発における問題の多くの解決に参考になります。

アルゴリズムはフロントエンド開発者にも必要な知識か? – Aerotwist

原題: Algowhatnow?

フロントエンド開発者の面接に、アルゴリズムに関する問題を出す意味はあるのでしょうか？
フロントエンドに関わる多くの開発者コンピュータサイエンス関連の大学を卒業していないケースもあり、アルゴリズムそのものよりもクロスブラウザに対するアプローチや知見などのほうが優先度が高いという議論もありますが、コンピュータとの対話を行うためにやはりアルゴリズムは欠かすことができないのかもしれません。
ロジカルシンキングの指標としても利用できるアルゴリズムへの知見は持っていて損はしないという主張。

海外トレンドコラム

ボタン要素はいつ使うべきなのか? – CSS-Tricks

原題: When To Use The Button Element

a要素とbutton要素はどのように使い分けて行くべきでしょうか？ CSSを利用して、どんな要素でも自在にスタイリングできるようになったからこそ知っておきたいことです。

EMEの利点と欠点

原題: EME pro and con

W3Cが仕様を策定しようとしていることで話題になっているEME(Encrypted Media Extensions)について利点と欠点をコンパクトにまとめたGoogle Docs。
これまでに多くの議論が行われてきているので、今からその議論に追いつきたい場合に非常に役に立つ文書です。

アクセシブルなアイコンフォントの使い方 – Filament Group, Inc., Boston, MA

原題: Bulletproof Accessible Icon Fonts

アイコンフォントを利用するケースが徐々に増えてきています。しかし、アイコンフォントの利用に際して忘れられがちなのがアクセシビリティ。音声ブラウザがアイコンフォントに使っている文字を発してしまったりするのは避けるべきです。この記事では、アクセシビリティを考慮したアイコンフォントの利用について、詳細に紹介しています。

CSS Will Change Module Level 1

レンダリングのパフォーマンスを向上させるために、利用せざるを得ないtranslateZなどを活用したハック。有効でありかつ手軽である反面、ハックである事実は変わりませんし、それなりのコストもかかります。
このCSS Will Change Moduleはそのハックを必要とせずに済むように提案されている仕様です。

関連リンク: Bye Bye Layer Hacks – Aerotwist

Promisesガイド – w3ctag

原題: Promises Guide

Promisesの仕様を作成しているチームにより、どのようにPromisesは利用するのかについてのガイドラインが公開されました。ライブラリなどを作成する際に参考になるだけではなく、少々とっつきづらい文章ながら、既存のPromisesライブラリを利用する際にも参考になるはずです。

jQueryはもう必要ない?

原題: You Might Not Need jQuery

数年前までは、jQueryなしでのクライアントサイドの開発は想像できませんでした。しかし、レガシーブラウザへの対応の必要性が少しずつ減ってきた今、jQueryは本当に必要でしょうか？
このサイトでは、ネイティブJavaScriptでjQueryが提供しているAPIを代替するスニペットを紹介しています。

関連リンク:

• Why You Still Need jQuery / いわゆるモダンブラウザでもクロスブラウザの問題を解決するのにjQueryが行っているワークアラウンドを示しています。
• Twitter / jeresig: I keep writing and deleting … / jQueryのオリジナルの作者であるJohn Resig氏のコメントにも注目してください。

head要素内にCSSを入れるのは何故なのか? – Aqeel

原題: What’s with putting the CSS in the head?

これまで知られているベストプラクティスでは、CSSは外部CSSファイルから呼び出す。となっています。本質的には現時点でも間違いではありません。しかし、近年CSSをstyleタグ内に記述する例も増えています。なぜそうすることがパフォーマンス観点でプラスに働くかについて、ブラウザのレンダリングの仕組みなどを踏まえて詳細に解説しています。

Promise nuggets – Gorgi Kosev

なかなか理解するのに苦労するPromisesについて、コールバックとの違いを実例を通して解説してくれているのがこのサイト。コールバックを使ったアプローチとの比較のおかげで、Promisesの利点や実装イメージがわきやすくなるはずです。

HTML、CSS、JavaScriptを合わせたモジュールデザイン開発へのアプローチ – Techwraith

原題: Atomic Product Development

モジュールデザインというアプローチは、今ではウェブ開発において欠かすことができないものとなっています。近年はJavaScriptにおけるモジュールデザインが盛んに議題に上がっていますが、CSSについてはあまり言及がありません。この記事では、HTML、CSS、JavaScriptが持つ依存関係の低減に必要なアプローチについて、詳しく解説しています。

CSSOMを使ったCSSの機能テストについて – Ryan Morr

原題: Feature Testing CSS At-Rules

ブラウザでどのCSSのAPIが実装されているかを調べる手法の紹介。この記事では「@」を利用する機能のテストについて紹介しています。

クローズアップ“ビデオ/スライド/ツール”

Promises/A+ 実装を通じて仕様について学ぼう v.1.1対応版 – Modern JavaScript

原題: Promises/A+ Understanding the spec through implementation v1.1

ネイティブでJavaScriptに実装される予定であるPromises。その元々の仕様であるPromises/A+と呼ばれる仕様が、昨年の8月にバージョン1.1に変更されました。その変更を踏まえて、実装と仕様を合わせて解説しているのがこのスライド。細かい部分についても分かりやすく解説してくれているのでおすすめです。

JavaScriptにおけるSOLID – Derick Bailey

原題: SOLID JavaScript In A Wobbly (World Wide Web)

オブジェクト指向における有名な5つの設計原則をまとめたSOLIDを、JavaScriptで実践する際に気をつけておくべきポイントについて、詳しく解説している動画です。スピーカのDerick Bailey氏はBackbone.jsのプラグインMarionette.jsの作者でもあります。

CSSの3D、アニメーションについてインタラクティブに学ぶ – Chris Ruppel

原題: Unfolding the Box Model

CSSの3D Transformsについて、インタラクティブに学ぶことができるサイトです。アニメーションはもちろん、3Dのコンセプトは実際に動いているものを見ることが一番わかりやすいので、初心者、中級者の方はぜひ。

JS: The Right Way

JavaScriptに関する優れた様々な情報を集めて紹介しているサイトです。Superhero.jsと同じようなコンセプトではありますが、記事だけではなくライブラリなどもコレクションしています。

Remote.js – Hage Yaapa

WiFiもBluetoothも使わずに、音を使ってスマートフォンからデスクトップブラウザを操作するためのライブラリ。
実際に動作する(試してみたところ、少々怪しげながら動作します)デモもあり、非常に興味深いツールです。

★次回の「斉藤祐也の海外WEBテク定点観測」は2014年3月3日にお届け予定です。★

斉藤祐也の海外WEBテク定点観測＜Issue.9: 2013/12/01-2013/12/31＞

今月の定点観測は、JavaScriptにおけるPromises実装について、CSSの変数(Custom Properties)、Quartz ComposerのプラグインOrigamiなど合計20件の記事や動画などを紹介します。

注目ニュースピックアップ

JavaScriptにおけるPromises実装について – HTML5 Rocks

原題: JavaScript Promises: There and back again

これまでJavaScriptの『限界』であるシングルスレッドを解決するために、コールバックやイベントを利用してきました。そのJavaScriptにもう1つ、Promisesと呼ばれる機能が追加されます。
Q.jsやwhenなどのようなライブラリを使ってすでにPromisesを利用している人も多いことでしょう。
現時点ではChrome CanaryとFirefox Nightlyにて一部の機能が利用でき、Polyfillも存在しています。
JavaScriptネイティブのPromisesはrsvp.jsのAPIとほぼ同じとなっているようです。

CSSの変数(Custom Properties)で遊んでみよう – That Emil

原題: Playing around with CSS variables – “custom properties”

CSSに変数を追加することは開発者から長期にわたって要求されてきました。CSSプリプロセッサがまだない時代からのこの要求に対し、様々な試みがされてきましたが、ついにFireFox Nightlyに「CSS Custom Properties for Cascading Variables Module」という仕様に則り実装されました。
Emil Björklund氏による記事はその実装に対しての実験を行っています。
詳しい仕様についてはCSS Working Groupのメンバーの1人であるTab Atkins Jr.氏が昨年2013年にCSS Dayにて発表した『Variables & Conditionals』にて詳しく解説しています。

またTab Atkins Jr.氏が2012年に提案したドラフトの頃からCSSに変数が必要であるか否かについての議論が途絶えたことはありません。
それら反論についても知っておくとよいので、以下に関連リンクとして紹介しておきます。

関連リンク:

• About Variables in CSS and Abstractions in Web Languages – CSS-Tricks
• Sasstraction – Adactio

Quartz Composerを使ってのプロトタイプ制作プラグイン: Origami — Julie Zhuo

原題: Introducing Origami for Quartz Composer

Webでもアプリケーションでもデザインに求められることが表層にある見た目だけではなくインタラクションなども含まれるようになって来ています。
Facebookではそのインタラクションを含むデザインを行うのにQuartz Composerを利用してプロトタイプを作成しているそうです。
Quartz ComposerはMac OS Xの開発環境の一部として提供されているビジュアルプログラミング言語で、元々はプロトタイプを行うためのツールとして提供されているわけではありません。
Origamiはそのやや取っ付きづらいQuartz Composerをよりプロトタイプツールとして使いやすくするパッチを提供するオープンソースツール群です。
この記事ではFacebookのプロダクトデザインディレクタであるJulie Zhuo氏がツールの紹介をしています。

関連リンク:

• FacebookのOrigamiグループ
• How to Survive in Design (and in a Zombie Apocalypse)
• Go Big by Going Home

オフライン・ファーストでウェブアプリケーションをデザインする – A List Apart

原題: Designing Offline-First Web Apps

前回の本連載でもとりあげた、オフライン・ファーストというアプローチについての続報。
記事ではなぜオフライン・ファーストを重要視するべきなのか、オフライン・ファーストのアプローチを採用する上でどんな問題点があるのかについて詳細にわたり解説しています。 offlinefirst.orgを牽引するHoodieチームの一員である筆者のAlex Feyerke氏は以下のように述べています。

『オフライン状態のWebサイトやアプリケーションの利用に対する体験はよりよくならなければならないし、もっとがっかりさせないようにしなくてはならない。もちろんもっと便利である方がいい。接続されていない、マルチデバイスの世界についてのガイドやパターンのカタログ、レスポンシブウェブデザインが築いてきたようなUXがオフライン・ファーストを行うためにも必要だ。』

関連リンク:

• Offline First: Learning from native experiences — Dion Almaer
• ServiceWorker & the offline web – Tom Ashworth

ベンチマークに関する注意点について – Aerotwist

原題: Bad Benchmark, Right Result

Googleの中でもパフォーマンスに関するすばらしい記事を常に提供してくれるPaul Lewis氏によるベンチマークに関する注意点。
結論から言うと、現時点では3D Transformsを扱うために非常に便利なCSSMatrixを使うと結果的に（少なくとも）toString()を利用して処理するため、パフォーマンス観点ではあまりプラスにはなりません。
しかしこの記事ではその結論よりも、彼がどのようにAPIを使ってよりパフォーマンスを向上させているのか、そしてそれをどのようにベンチマークしているのか。JSPerfを使ったベンチマークにおける注意点なども含め、一連の流れについて着目していただければ。

海外トレンドコラム

ブラウザへの12個のパフォーマンス要望リスト – Performance Calendar

原題: Browser Wishlist 2013

2013年の年末にSteve Souders氏がまとめた12項目からなるブラウザへのパフォーマンス観点での要望リスト。
この時点で要望されるということは気をつけておく必要があるリストでもあるので、各項目をしっかりレビューしておくとよいでしょう。

Chromeの開発者ツールをFirefoxで使えるとしたら? — Kenneth Auchenberg

原題: What if you could use Chrome DevTools with Mozilla Firefox?

先月の本連載で紹介したremotedebug.orgの中心的人物であるKenneth Auchenberg氏によるFirefoxでChromeのDevToolsを利用する様のデモ。こうして実際に動作するものを見ると、remotedebug.orgが進めるBridgeという概念がいかに強力なものであるかが分かります。

アクセシビリティに合わせたコーディングをしよう – 24 ways

原題: Coding Towards Accessibility

アクセシビリティが重要であることはことさら今改めて伝えることではありませんが、どうしても難しいものというイメージがつきまとうものです。この記事ではそのアクセシビリティについて、習慣化しやすい実利的な手法について詳しく紹介しています。

Chrome開発者ツールを使って60FPSを実現するためのワークフロー – Wingify Engineering

原題: Getting 60 FPS using Chrome devtools

パフォーマンス改善はルールを覚えることより、ツールを使って実測しながら行うのが鉄則です。この記事ではそのツールの中でも最も優れた機能を有しているChrome DevToolsを使って一連の改善に関するワークフローを紹介しています。スクリーンショットも多く非常に分かりやすいです。

Position: fixedに関する最新情報 – QuirksBlog

原題: position: fixed update

モバイルWebサイトやアプリケーションの制作に携わったことがある人であれば、必ず遭遇する問題の1つであるposition: fixedにまつわるバグについての現状を、Peter-Paul Koch氏がまとめています。実際の動作を動画で表示しているので、ぜひ自分の目で確認してください。

MEANスタックをYeomanで素早く構築する方法

原題: Full-Stack JavaScript With MEAN And Yeoman

MongoDB、Express.js、Angular.js、Node.jsそれぞれの頭文字を取ってMEANスタックと呼ばれるフルスタックJavaScript開発フレームワークをYeomanを使って素早くセットアップする方法について紹介。
そもそものMEANスタックとは何かについても理由を含めてきちんと紹介してくれています。

JavaScriptでキネティクス・スクロールを実現するためには – don’t code today what you can’t debug tomorrow

原題: JavaScript Kinetic Scrolling

EsprimaやPhantomJSの制作者として知られるAriya Hidayat氏による、パート4(パート5もあるそう)にまで及ぶキネティクス・スクロールについてのJavaScript実装に関する記事。iOSに見られるような自然なスクロールを実現するために必要な事柄を分かりやすく解説しています。

WalmartにおけるNode.jsセットアップ

原題: Walmart Mobile node.js Setup

PayPal社がバックエンドをJavaからNode.jsに移行したという記事が話題になっていましたが、この記事はアメリカ最大のスーパーマッケットチェーンであるWalmartにおけるモバイルサイトでのNode.jsのセットアップについて触れられています。ブラックフライデーを乗り越えたWalmartのセットアップは今後のNode.jsの可能性を感じることができるすばらしいリソースになるはずです。

クローズアップ“ビデオ/スライド/ツール”

The Need for Speed – Guillermo Rauch at dot.js 2013

今ではWordpressを運営するAutomattic社に買収された、クラウドシェアリングサービスのCloudupのGuillermo Rauch氏による、シングルページアプリケーションにおけるパフォーマンス改善のティップス集ともいえるスライド。

Faster JavaScript web apps – Alex MacCaw at Fronteers 2013

こちらはAlex MacCaw氏による、シングルページアプリケーションにおけるパフォーマンス改善に関する発表の動画。よくあるボトルネックについて丁寧に解説しており、シングルページアプリケーションに限らず利用できます。

CSS module system in Google+ – Shubhie Panicker at CSSconf.eu 2013

Google+は、どのようにCSSをモジュラー化しているのか。2013年の9月に、CSSconf.euにてShubhie Panicker氏により発表されたプレゼンテーションの動画。
単純に1ファイルにまとめるだけでは無駄が多いCSSのこれからの課題がここにあると思っているので参考に。

関連リンク: Your CSS needs a dependency graph – Techwraith

Project Hubs: デザイン・プロジェクトをどう管理するべきか – 24 ways

原題: Project Hubs: A Home Base for Design Projects

プロジェクト管理のツールは多く存在しているが、デザインに関しては便利なツールが存在しません。そこでBrad Frost氏は、Project HubsというシンプルなHTMLベースのツールを作りました。この記事ではそのProject Hubsが解決しようとしている問題とその解決方法について紹介しています。

関連リンク: bradfrost/project-hub

Web Browser Compatibility Tables – Cody Lindley

1％以上のマーケットシェアを持つブラウザについてどの機能が実装されているのかを一覧できるWebツール。
類似のツールは多くありますが、幅広い機能とブラウザについて一覧できるので非常に便利です。

SpinKit – tobiasahlin

Ajaxでコンテンツを取得する際や、巨大なテーブルデータをソートするような場合によく利用するローディングをCSSアニメーションで実現し、例示しているGitHubのレポジトリ。
現時点で7種のローディングのデモをこちらから閲覧できます。

Poly Maker – Aerotwist

ポリゴンシェープを生成するPoly Makerというツールの紹介。
今となってはややローファイさを感じるポリゴンを美しいカラーで表現しているツール。ツールそのものもすばらしいがどう作るかについての紹介のほうが興味深いです。

★次回の「斉藤祐也の海外WEBテク定点観測」は2014年2月3日にお届け予定です。★

斉藤祐也の海外WEBテク定点観測＜Issue.8: 2013/11/01-2013/11/30＞

今月の定点観測は、モバイル開発で考慮したいオフラインファースト構想について、レスポンシブウェブデザインに対する別視点、コンポーネントレベルでのプログレッシブ・エンハンスメントのアプローチなど合計20件の記事や動画などを紹介します。

注目ニュースピックアップ

Offline First!

モバイル・ファーストをさらに一歩進め、”不安定なインターネット接続”や”バッテリー”というモバイルならではの問題を解決に導くためのオフライン・ファーストというアプローチが注目を浴び始めている。
そのタイミングで議論のスタートポイントとなるべく作られたのがこのサイト。
まだ具体的な活動は始まっていないようですが、これから多くの議論が期待されるトピックなので目が離せません。

関連リンク:

• Say Hello to Offline First / HoodieチームによるOffline First!構想のイントロダクション
• Offline Support is Valuable, and You Can’t Add it Later – Aanand Prasad / Aanand Prasad氏による”オフラインサポートが何故重要なのか”についての記事
• “Offline First” – Unstoppable Robot Ninja / Ethan Marcotte氏によるオフラインサポートは技術だけの課題ではなく、UXにおいても課題であるという意見

レスポンシブウェブデザインはスクリーンサイズに依存しすぎていないか – Luke Wroblewski

原題: Responsive Web Design: Relying Too Much on Screen Size

レスポンシブウェブデザインにおけるゴールに世にあふれている様々なデバイスにデザインを適応させることがあげられると思います。この記事でLuke Wroblewski氏は、その適応に向けた指標となっているスクリーンサイズはデザインを決定づけるのに十分な変数にはなりえないと指摘しています。
スクリーンサイズのみでは、ユーザとそのデバイスとの距離を知ることは難しいですし、640pxの幅を持つスクリーンだからといって、それがGoogle Glassから見ているかを知ることも難しいでしょう。
Wroblewski氏は、スクリーンサイズに適応することが無意味であるわけではないが、考慮するべき指標ではないかと結んでいます。

関連リンク:

• Responsive design, screens, and shearing layers — Unstoppable Robot Ninja / Ethan Marcotte氏による上記の記事への反論
• On Using Browser Viewports to Understand Screens – LukeW / Luke Wroblewsk氏によるEthan Marcotte氏の記事への返答
• Of viewports and screens, input modes and event handlers – QuirksBlog / Peter-Paul Koch氏による上記2名の主張の技術的な考証

ブラウザではなく、コンポーネントごとにブラウザ対応を行うアプローチの紹介 – Filament Group

原題: Grade components, not browsers

ブラウザやバージョンによる機能の違いを吸収するためのアプローチを行うのにブラウザやバージョンにグレードを設定し、そのグレードごとの対応を行うアプローチが多く採用されています。Filament GroupのScott Jehl氏は、ブラウザにグレードをつけるのではなく、サイトを構成するコンポーネントにグレードを設けて、それごとにどのように機能を拡張していくかを定義していくアプローチを提案しています。
Jehl氏は、コンポーネントごとにグレードを設けることで、ドキュメントしやすく、もっとも最適な体験を各ブラウザ、デバイスに提供するというゴールを達成しやすいとしています。

関連リンク:

• Scope Components, Not Pages – Brad Frost Web / Brad Frost氏による、上記記事のアプローチを拡張し、ウェブデザインの制作にかかる工数もページ単位ではなく、コンポーネント単位で行う利点の解説

なぜJavaScriptにスタイルガイドが必要なのか? – Harrison Shoff

原題: Why does JavaScript need a style guide?

Airbnbが公開しているJavaScriptのスタイルガイドのIssueに寄せられた、”なぜJavaScriptにスタイルガイドが必要なのか”に対する、AirbnbチームメンバーであるHarrison Shof氏による素晴らしい回答。
この回答を導いた質問も素晴らしく、”もしピカソが絵の書き方を学ぶ際、我々がどのように書くべきかを示唆したとしたら、キュービズムは存在したのか?”、というものです。
これに対してShof氏は、チームとして、または大きなコードベースをメンテナンスする上では、どんなスタイルであろうと一貫性を持つことが重要であるとしながらも、個人でサイドプロジェクトを行う際にはもちろん無視しても構わないとしています。

Asm.jsに関して – Acko.net

原題: On Asm.js

Asm.jsを利用することでJavaScriptでもネイティブに限りなく近いパフォーマンスを得ることができます。実際にそのデモは目を見張るほどのパフォーマンスを出しています。Steven Wittens氏は、Asm.jsを含むLLVMのような”JavaScriptのふり”をする存在の登場はJavaScriptそのものにプラスにならないとしています。

関連リンク:　On “On Asm.js” / Dave Herman氏による上記記事への反論

海外トレンドコラム

リモート・デバッグのAPIを統一するための構想

原題: RemoteDebug, an initiative to unify remote debugging across browsers.

モバイル向けのウェブサービスを制作するにあたり課題であり、現在多くの革新が起こっている分野の一つであるリモート・デバッグについて、ブラウザごとに異なるデバッグ用APIを作るのではなく、共通化することができないか、という目的を体現するための構想。
ビジョンそのものも素晴らしいですが、実際に公開されているブリッジとなるツールの紹介もあるので実利的でもあります。

クロス・モバイルデバイスのテストを手助けするツールたち – HTML5 Rocks

原題: Synchronized Cross-device Mobile Testing

モバイル開発における悩みの1つに非常に多くのデバイスで動作・表示確認を行う必要があることがあげられます。
Addy Osmani氏がその作業をサポートするツール、GhostLab、Adobe Edge Inspect CCなどを詳しく紹介しています。

npm registryをサポートするための寄付を募集しています – scalenpm.org

原題: Help scale the npm registry

Node.jsに関わるツールを利用する際、なくてはならない基本的なツールとなっているnpm。そのnpmregistryを支えるインフラは実はNodejitsuにより無料で提供されています。
ここ数ヶ月の間npm registryが不安定になる事象が起こり、その解決のための寄付を募っています。
現時点でゴールは達成(残21日)していますが、Node.jsを普段から利用しているなら寄付を検討してみてはいかがでしょうか。

pointer-events: noneを使ってスクロールを60FPSにする方法 – The CSS Ninja

原題: 60fps scrolling using pointer-events: none

CSSによるシャドウの描画はブラウザにとってやや不得意な操作であり、それが原因でスクロールパフォーマンスの低下につながることも多い。この記事では:hoverにつけられたシャドウによるパフォーマンス低下を防ぐ手法について紹介しています。

関連リンク: Malte Ubl氏によるGoogle+ポスト / Malte Ubl氏はRyan Seddon氏が紹介した方法はiframeではうまくいかないと指摘、この問題に関してはハックに頼らずブラウザ側で解決することが期待されるとしています。

WebGLを利用する場合に知っておきたいデバッグツールとプロファイルツール – Real-Time Rendering

原題: [WebGL Debugging and Profiling Tools

WebGLを使う際に知っておきたいデバッグツール、そしてパフォーマンスのプロファイルツール達の紹介。
Firefox 27に搭載されているFirefox WebGL Shader Editorの紹介を含む4つ(+アルファ)のツールについて紹介しています。

提案中のsrc-Nの最後の文について詳しく紹介 – Tab Completion

原題: Explaining The Last Clause of the src-n Grammar

Tab Atkins Jr氏が提案しているレスポンシブ・イメージへのアプローチであるRespImg Syntax、通称src-Nについて、これまでのsrcsetと比較して、このシンタックスがシンプルなのかについての解説をしています。

レスポンシブ・イメージについての今年の振り返り – HTML5 Doctor

原題: Responsive images – end of year report

今年多くの前進があったレスポンシブ・イメージに対する問題解決についてBruce Lawson氏がまとめています。
これまでの経緯を含めて今後に関する示唆を含む非常に有用な記事となっています。

関連リンク: レスポンシブ・イメージに関する各ブラウザベンダの現在の状況 / Mat Marquis氏によるまとめ

さらなるページロード速度改善を行うために知っておきたいこと- Steve Souders

原題: Prebrowsing

ページロード速度を最適化するためには、キャッシュをきちんとしてHTTPリクエストを可能な限り減らすことが大切ですが、この記事ではそのキャッシュの次に注視しておくべき、dns-prefetch、prefetch、prerenderなど新たに可能性が模索されているテクニックについてSteve Souders氏が解説。

リファクタリングをする際に覚えておきたいアプローチたち

原題: Refactoring Techniques

“リファクタリング:Rubyエディション“で紹介されていたリファクタリング手法のうち、Mark McDonnell氏がよく使う方法を抜き出して詳しく解説。コードサンプルはRubyのものになっているが、JavaScriptやその他の言語でも同じアプローチができるので非常に参考になります。

フルスタックJavaScriptアーキテクチャ指南 – Smashing Coding

原題: An Introduction To Full-Stack JavaScript

ウェブアプリの構築にアジャイルのような早い開発サイクルに適した選択としてフロントエンドはもちろん、サーバーサイドでもJavaScriptを採用するケースが増えてきています。
この記事ではそのアプローチでツールスタックを構築する際に知っておきたい様々なことを包括的に紹介しています。
もちろんすべてに対する回答ではありませんが、注目のアプローチではあるので要チェックです。

Color Template

ウェブデザインに限らずですが、色がユーザに与える影響は計り知れません。その大切な色に関して覚えておきたい基礎と応用について平易な用語を使って非常にわかりやすく解説しているサイト。リファレンスとしていつでも参照できるようにしておきたいサイトです。

クローズアップ“ビデオ/スライド/ツール”

レンダリング・パフォーマンスケーススタディ – Addy Osmani

原題: Rendering Performance Case Studies

Velocity Conf EUで発表されたAddy Osmani氏による、レンダリング・パフォーマンスに関する203ページに及ぶスライド。FlickrやPinterest、Google+などの実際のウェブサービスを対象にしたケーススタディとなっています。

Node.js Stream Playground – John Resig

Node.jsのstreamは説明を読んだだけで理解するのは難しいコンセプトではないでしょうか? 実際に手を動かしてみるのが理解への近道、ということで、John Resig氏が作成したブラウザ上でsteamについて学べるこのツールを試してみてください。
詳しい利用方法についてはこちらの記事を参考にしてください。

Level Me up Scotty! – Julian Gruber

nodeconf EUで発表されたJulian Gruber氏によるLevelDBを使ったリアルタイムチャットについてのビデオ。氏は15分の発表中に(ごく単純なものですが)実働するチャットシステムをライブコーディングをしています。 完成したソースコードはGitHubにて公開されています。

Pa11y

Nature Publishing Groupによりオープンソースされている、Pa11yは自動でアクセシビリティに関するレポートを収集し作成してくれるツール。

★次回の「斉藤祐也の海外WEBテク定点観測」は2014年1月6日にお届け予定です。★

斉藤祐也の海外WEBテク定点観測＜Issue.7: 2013/10/01-2013/10/31＞

今月の定点観測はW3CがEMEをなぜ標準化したのか、その動きに対する反対と賛成意見を紹介し、AppCacheが解決できなかったオフラインに対する問題を解決すべく立ち上がったServiceWorkerの解説、突如として現れたかに見えるレスポンシブ・イメージに対する解決であるRespImgなど、合計20件の記事や動画などを紹介します。

注目ニュースピックアップ

W3CによるEncrypted Media Extensionの標準化について

今年5月にEncrypted Media Extension(EME)という仕様がワーキング・ドラフトとなり公開されました。
この仕様はなぜW3Cによって標準化されるべきものだったのでしょうか。あるいはW3Cの勇み足だったのでしょうか。
この一ヶ月、MozillaのCTOであるBrendan Eichも氏の立場を明らかにしたりと多くの議論が展開されました。 10月の議論の火付けとなったと思われるAmelia Andersdotter氏の記事を含め、EMEに関する記事を集約したので参考にしてください:

• What is EME?
• DRM/EME in HTML5 – an American thing by Amelia Andersdotter
• A hitchhiker’s guide to the HTML5 + EME maze by No Such Weblog
• The Bridge of Khazad-DRM by Brendan Eich
• Perspectives on Encrypted Media Extension Reaching First Public Working Draft by W3C Blog
• The W3C is a restaurant by Long-term laziness –DRM in HTML5 is a victory for the open Web, not a defeat by Ars Technica

ServiceWorkerとは何か

原題: ServiceWorkers Explained

多くのデバイスが常時接続を保証されない状態になりうる状況の中、オフライン・ファーストという視点での開発が急務になりがらもHTML5 Application Cacheには多くの問題があることが明らかになってきています。そんな中、このドキュメントには次世代の仕様として模索されているServiceWorkersに関する詳細について紹介されています。

RespImgシンタックスの提案

原題: Proposal for RespImg Syntax

Apple社のRetinaディスプレイを始めとする、高解像度のディスプレイと旧来の標準的なディスプレイが混在する中、また様々なサイズのデバイスが利用者の好みによって選択できる世の中で、これまで”レスポンシブ・イメージ”に対する唯一の答えが提案されてこなかったのが現状だ。このRespImageシンタックスはこの問題に対する新しい視点による解決案となるかも知れません。John Mellor氏によるこちらのメーリングリストへの投稿もあわせて読んでおくとよいでしょう。

拡張可能なWebへ – Domenic Denicola

原題: The Extensible Web

Webがこれまでと同じように数ヶ月、あるいは数年にもわたるメーリングリストを使った標準化のプロセスのままでよいのか。そんな疑問から始まった#extendthewebforwardというムーブメントの共同エディタであるDomenic Denicola氏によるJS Conf EU 2013での発表The Extensible Web: JavaScript All the Way Downに関する本人による詳細の解説。

CSSセレクタの命名規則に関する私見 – Adactio

原題: Classy values

複雑化、巨大化の一途を突き進む”ウェブサイト”の中でボトルネックになりつつあるCSSの存在。Nicole Sullivan氏によるOOCSS、Jonathan Snook氏によるSMACSS、そしてYandex社の提唱するBEMとこの問題に対する解決への提案は数多くあります。そんな中、米Yahoo!で働くThierry Koblentz氏によりSmashing Magazineに寄稿されたChallenging CSS Best Practices、そしてその記事に真っ向から反対を表明するBen Darlow氏によるCargo Cult CSS。今回紹介する記事は、その2つの意見を踏まえてのJeremy Keith氏によるまとめ。CSSアーキテクチャに興味がある方はこの3本の記事と合わせて、Heydon Pickering氏によるThe Problem With CSS Classesも要チェック。

Viewportに関するリサーチ報告: heightと@viewportについて – QuirksBlog

原題: Viewport research addendum: height and @viewport

今さらViewportの何を調べる必要があるのか。誰もがそう思っている最中、Peter-Paul Koch氏が改めてViewportの指定が実機でどのような作用をするのかをリサーチした結果がこちらです。
彼のリサーチにミスがあったこと、それを訂正するリサーチ、そして、初期調査の結果とあわせて読むと氏の一連のプロセスが見えてくるのでおすすめです。

海外トレンドコラム

ブラウザがどのように画像をリサイズするか知っていますか？ – Jason Summers

原題: How web browsers resize images

Jason Summers氏が本人が作成したResampleScopeというツールを使って、モダンブラウザが画像をどんなアルゴリズムでリサイズしているかについての調査の報告しています。ブラウザ間で異なるアルゴリズムを使っていることはもちろん、バージョン間でも、拡大、縮小時にも異なるアルゴリズムが利用されているらしいことがここから分かります。

Animation-Proxy: JavaScriptによるアニメーション操作への問題解決

原題: JavaScript-Driven Accelerated Animations

JavaScriptを使ってのアニメーションは非常に柔軟であり、強力ですが、弱点があります。それはJavaScriptが基本的に1つのスレッドしか持たないため、常にアニメーションとは別の処理と競合してしまう可能性があることです。
Animation Proxyは、その弱点に対する解決としてWeb Workerをプロキシのように扱いJavaScriptからCSSのプロパティを操作することを可能にする提案です。

Yeomanを使ってPolymerでウェブアプリを最速構築する – HTML5 Rocks

原題: Building Web Apps With Yeoman And Polymer: Scaffold your webapps with modern tooling

Addy Osmani氏によるPolymerとYeomanを使ったウェブアプリの使い方指南。
Web Componentsはまだまだ実践で利用するには早すぎる存在ではあるかもしれませんが、試しておく価値のあるものです。Yeomanを使って事前の準備を素早く終わらせることができるので試してみてください。

IE11の開発者ツールを使ってガベージコレクションを減らす方法 – MSDN Blogs

原題: Reducing the pressure on the garbage collector by using the F12 developer bar of Internet Explorer 11

ウェブサイト制作におけるパフォーマンス解析といえば、Googleの開発ツールがよく知られていますが、Internet Explorer 11に搭載されているツールもまたかなり優れた機能を有するツールです。この記事ではWebGLを使ったサイトを実際にツールを使ってパフォーマンスのボトルネックの1つであるガベージコレクションを少なくする方法を紹介しています。

Translateプロパティはなぜアニメーションのパフォーマンスをよくするのか？

原題: Why is animating left paint more often than translateX?

アニメーションを高速化するために知っておきたいことの1つに、leftやtopなどのプロパティを操作するよりも、translateを利用するほうが高速であるというのがあります。それでは、それがなぜなのか。
簡単な解答は後者のほうがペイントプロセスが少ないからなのですが、この記事でより詳しく解説されている”なぜ”を知ることはより正確に最適化への道のりで役立つツールとなるでしょう。

“速さ”を演出するために知っておきたい4つのこと – Mobify

原題: A Beginner’s Guide to Perceived Performance: 4 Ways to Make Your Mobile Site Feel Like a Native App

一般的なデスク/ラップトップマシンと比べ、どうしても非力なモバイルデバイスにおけるパフォーマンスの最適化手法の1つとして欠かすことができないのが、”速さ”の演出です。英語では”Perceived Performance”と呼ばれることが多いこの領域において知っておきたい4つのことを紹介しています。

知ってますか？ section要素の正しい使い方 – The Paciello Group Blog

原題: Using the HTML5 section element

section要素の正しい使い方はもしかするとHTML5がもたらした最大の頭痛の種かもしれません。そんなsectionの正しい使いどころをThe Paciello Groupでアクセシビリティエンジニアとして働くLéonie Watson氏が解説。

クローズアップ“ビデオ/スライド/ツール/デモ”

よりよいCSSを作る為にデザイナに知っておいてほしいこと – Harry Roberts / CSSconf.eu 2013

原題: Normalising designs for better quality CSS

Harry Roberts氏によるCSSconf EUでのデザイナとフロントエンド開発者、特にUIレイヤに責任を持つ人間との関係について。巨大なメディアを預かっていた彼ならでは視点が多いが、中大規模でスケーラブルに開発を行うことがある場面で必ず役に立つアドバイスばかり。

Appurifyを使って実機のモバイル端末でデバッグ、最適化、そしてテストをする

原題: Seamless Debugging, Optimization and Testing on Real Devices with Sencha and Appurify

モバイルウェブ開発で大きな課題となっている実際のデバイスを使ったデバッグ、テスト、パフォーマンス解析を解決しようとしているAppurifyというサービスをSenchaチームが実際に利用し紹介しています。

Mozilla Brickでウェブアプリを構築してみよう

原題: Building web apps, one brick at a time! (with Mozilla Brick)

MozillaからのWeb Componentsに対するアプローチであるMozilla Brickを使ったウェブアプリの作り方に関するスライドです。豊富なコード例もしっかりあり、ありがたいことに例は公開されています。Brickのロードマップもあるので興味がある方はぜひ。

asm.js: Webにネイティブの速度を

原題: asm.js: Native Speed on the Web

ネイティブ VS ブラウザの戦いに終止符を打つべくしてMozillaが開発しているasm.js。その存在そのものについてはもうご存知のことでしょうが、このスライドでは、そもそもなぜJavaScriptが”遅い”のか、そしてasm.jsが何を解決するのかについてのオーバービューがまとまっています。
本スライドとは無関係ですが、Felix Dahlke氏によるWhy asm.js is a big deal for game developersもあわせて読んでみてはいかがでしょうか。

Grunt Boilerplate – Mark McDonnell

好き嫌いはあれど、Gruntはウェブ開発におけるビルドプロセスで大きな役割を持ってきはじめています。もはやデファクトスタンダードともいえるくらいの存在でしょう。そんなGruntをこれから使う方にも、もうすっかり使いこなしている方にもおすすめのソースコード。
作者であるMark McDonnell氏による本ツールに関するこちらの記事も一読ください。

Snap.svg

SVGに関するデファクトスタンダードとなっているライブラリであるRaphaëlをゼロから、Raphaëlの作者であるDmitry Baranovskiy氏本人が作成し、公開したのがこのSnap.svg。モダンブラウザのみをターゲットとすることで、より小さなコードベースでありながら、より豊富な機能を搭載し、SVGのjQueryとなるべくしてオープンソース化しています。
Adobe社のWeb Platform Teamブログの記事も合わせて要チェック。

実践! ARIAを使ってフォーム入力をサポート

原題: Practical ARIA Examples

ARIA(Accessible Rich Internet Applications)を使ったアクセシブルなウェブサイトの制作は見方によっては時間の無駄に思えるかも知れません。しかし、Heydon Pickering氏によって作られたこのデモページを見れば、ARIAが非常に実利的な問題解決を行う手法でもあることがわかると思います。

★次回の「斉藤祐也の海外WEBテク定点観測」は12月6日にお届け予定です。★

Colt McAnlis氏による画像圧縮にまつわる詳細な解説、Peter-Paul Koch氏のmodern.IEレビュー、Alla Kholmatova氏によるUIアイコンの認知速度の最適化、Chris Coyier氏のいまさら聞けないTableタグの使い方など、14日間のWeb開発最新ニュース合計20件を紹介します！

注目ニュースピックアップ

Webデベロッパのための画像圧縮 – HTML5 Rocks

原題: Image Compression for Web Developers

CSSやJavaScriptのファイルサイズをいかに減らす事ができるか。それにともなう自動化処理などのセットアップ。それらの努力を無駄だとは思わないが、ウェブページ内の画像ファイルの割合は増加の一方で、CSSやJavaScriptのファイルサイズと比べても3倍以上画像のほうが大きい。
そんな中、HTML5 RocksにてColt McAnlis氏が公開した本記事は、画像の圧縮に関して知るべきことの多くを網羅している。
単純にツールを使いましょう、というだけではなく、画像フォーマットの選択、クオリティとファイルサイズの関係、マルチデバイス対応における画像利用の戦略などについて細かく解説している。

modern.ieレビュー – QuirksBlog

原題: modern.ie

Peter-Paul Koch氏によるmodern.IEのレビュー記事。modern.IEはマイクロソフト社公式のInternet Explorerのテストを行うための仮想環境で、Peter-Paul Koch氏は非常に詳細なJavaScriptやCSSのブラウザ対応表を更新し続けている人。
Microsoft社からスポンサーを受けている記事にも関わらず、非常に公平なレビューとなっており、氏はmodern.IEのライセンス処理が面倒、Windowsのアップデートにあわせて仮想環境もアップデートするべき、JavaScriptのエラーメッセージはデフォルトで有効にしておくべき、仮想環境のサイズをもう少し小さくできないか、など改善案も出している。

UIアイコンをより早く認知させるために知っておきたいこと – Boxes and Arrows

原題: Optimizing UI icons for faster recognition

大きなビジュアルスタイルの変更があったiOS 7が公開された。特にアイコンのスタイルは如実に変更されている。Aubrey Johnson氏はこの変更は、ユーザの認知能力を疲弊させるとした記事を公開。その記事に対して、Alla Kholmatova氏は、「UIアイコンの認識を早めるために必要な最適化はアイコンのデザインスタイルではない」と反論している。この記事も、Johnson氏の記事も、そもそもUIにおけるアイコンの存在意義や、その認識について再度考えさせられるすばらしい記事なので、合わせて読んでほしい。

いまさら聞けない! テーブル要素について – CSS-Tricks

原題: A Complete Guide to the Table Element

テーブルタグを使ったレイアウトをしていたのは、いまや昔になっているといっていいだろう。そんな中、テーブルタグの存在意義である表形式のデータの表示という使い方も忘れてしまいがちだ。
このChris Coyier氏による記事では、見た目の定義のないベーシックなテーブル例から、theadやtbody、そしてtfoot、trやtdの使い方について、テーブルのスタイルや、colspan、rowspanの使い方など非常に細かく、CodePenを使った実働例とスニペットを合わせて紹介している。

45%のパフォーマンス改善。GPUを使ってのJPG画像をデコード – IEBlog

原題: Using Hardware to Decode and Load JPG Images up to 45% faster in Internet Explorer 11

パフォーマンスのボトルネックの1つであり、実装的な回避が難しい部類の画像（記事ではJPG画像について書かれている）のデコードをInternet Explorer 11ではGPUを利用して行い、結果、最高45%のパフォーマンスを向上できたという紹介記事。
記事は単純な結果の共有にとどまらず、そもそもJPGがどのようにエンコードされるのか、そしてよりGPUを使ったデコードを効率的にするために採用した手法についても、詳しく解説している。

海外トレンドコラム

Firefoxの開発者ツール再訪パート1: Web ConsoleとJavaScript Debugger – Mozilla Hacks

原題: Reintroducing the Firefox Developer Tools, part 1: the Web Console and the JavaScript Debugger

Firefox 4からFirefoxに搭載されている、ビルトインの開発者ツールに関する解説をするシリーズ第1回目(全5回予定)。この記事では、閲覧しているページの表示されている情報について確認できるWeb Console、JavaScript Debuggerの2つについて紹介、それぞれ2分程度の動画もあって非常に分かりやすい。

HTML5ゲームにおけるベンチマーク: スプライトアニメーション編 – MSDN Blogs

原題: Benchmarking a HTML5 game: HTML5 Potatoes Gaming Bench

HTML5ゲームを制作するにあたって欠かすことができないのがベンチマーク。この記事ではそのベンチマークの中でもスプライト・アニメーションに特化したツールであるHTML5 Potatoesを使ったベンチマークの取り方について解説。

レイアウト・スラッシングを回避するテクニックとツール – Wilson Page

原題: Preventing ‘layout thrashing’

レンダリングプロセスの中で、ボトルネックとなりやすいレイアウトが複数回連続的に発生することを「レイアウト・スラッシング」を回避するためにWilson Page氏はrequestAnimationFrameを利用したツール、fastdomを作って公開。記事では、ツール制作の裏側について解説している。

Google Chrome開発者ツール: カンバス・インスペクション – HTML5 Rocks

原題: Canvas Inspection using Chrome DevTools

そろそろCanvasを使い始めているというサイトやサービスも増えてきたタイミングだろう。そんな中、この記事ではChromeの開発ツールに追加されたCanvasをデバッグするのに便利なCanvas Inspectionについて、セットアップから利用法まで詳しく解説しているのでぜひチェックしてほしい。

Polymerを使ってカスタム・チェックボックスを作成する – 4waisenkinder

原題: Getting started with web components and polymer.js

Google社が主導しているWeb ComponentsのPolyfillであるPolymerを利用して、実際に動作するカスタムチェックボックスの作り方を解説。実際に動作するデモと詳細にわたるスニペット、そして自身が体験した失敗談と回避方法について詳しく説明している。

見た目が美しくてもアクセシブルなサイトは作れる! – UXmatters

原題: Making Web Sites Accessible Without Sacrificing Aesthetics

アクセシビリティはサイトの見た目が悪い、ターゲットユーザとは違うので、利益にならない、などアクセシビリティに関する多くの『都市伝説』を丁寧に解き明かしていく。もちろんアクセシビリティに関するすべてを学べるわけではないが、入り口や突破口としてすばらしい記事。

Gitのコンセプトをダイアグラムを使って解説

原題: git concepts simplified

Gitのコンセプトをシンプルにダイアグラムを利用しながら分かりやすく解説している。基本から、コミット、ブランチ、タグやリモート・リポジトリについて、マージ、Cherry PickやRebaseについてなどについて広く触れている。

クローズアップ“ビデオ/スライド”

パフォーマンス・チューニングの秘密 – Peter Flynn

原題: Performance Tuning Secrets

スライド: https://github.com/peterflynn/jsconf-2013

Adobe社にてBracketsの開発に携わっているPeter Flynn氏によるJavaScriptのパフォーマンス・チューニングのコツについてのJSConfUS 2013での発表。Chrome開発ツールから、about:tracing、V8のログツールについて解説している。

フロントエンドデベロッパも知っておきたいセキュリティについて — Mike West

原題: Frontend Security

8月29、30日の2日間でスイス、チューリッヒで開催されたFrontrend ConfにてMike West氏が発表したフロントエンド・セキュリティについての動画、スライド、そしてトランスクリプト。

海外で話題の“ツール”

nodeschool.io

コマンドライン上でリアリスティックな問題を解決しながらNode.jsについて学べるユニークなスタイルのレッスンサイト。現在までのところ、『Node.js基礎: 非同期I/OとHTTP』、『.pipe()を使ってstreamのインタフェースを構成』そして、『入門LevelDB』の3つの授業が用意されている。

HTTPFlies

数あるHTTPステータスコード(このサイトによると52!)を美しい蝶に例えて紹介しているサイト。サイトそのものもすばらしいが、制作の裏側について書かれたこちらも合わせてどうぞ。

Basiliq – Abduzeedo Design Inspiration

300以上のパーツに分割された、手書き風のベクターシェイプを集約したワイヤフレーム用UIキット。Photoshopで利用が可能で無料。アイデアを形にし、テストをし多くの失敗を重ねることが、インタラクション／プロダクトデザインの正解への近道。

Semantic UI

Twitter Bootstrapから始まった、フロントエンド・UIツールキットと呼ばれる類いのツールは今や百科絢爛。そんな中、Bootstrapとは異なるCSSアーキテクチャを採用しているSemantic UIが登場。どちらが優れているか、ではなく、どちらのアプローチにもそれぞれの理由があるので、ソースコードリーディングをして見てほしい。

Content Security Policy Header Generator

クロスサイトスクリプティング (XSS) やデータインジェクション攻撃を含む、よく知られた種類の攻撃を検出して軽減する、セキュリティの追加レイヤーであるContent Security Policyで利用するヘッダ生成ツール。

iO 7のアイコン生成における遺伝的アルゴリズムについて – Mike Swanson’s Blog

原題: Unleashing Genetic Algorithms on the iOS 7 Icon

iOS 7のリリースに伴い変更のあったアプリアイコンのデザイン。実際にApple公式アプリの角丸は単純なものではなく、正確に同じ角丸を再現するのはなかなか面倒だ。そこでMike Swanson氏はそのプロセスを自動化するPhotoshop Scriptを公開。この記事は、そのツールでどのように公式アプリの角丸の再現性を高めたかについて解説している。

★次回の「斉藤祐也の海外WEBテク定点観測」から月次更新に変更して、11月5日にお届け予定です。★

前編から引き続き、後編でも最適化のために知っておきたいレンダリングプロセス、計測方法、そして最適化を妨げるよくあるアクシデントとその回避方法について紹介していきます。

アニメーションを高速化するために知っておきたいレンダリングプロセス

ブラウザがどのようにウェブサイトを表示しているのかを知ることは、アニメーションだけに限らず、Webのパフォーマンス全体の高速化を行うために大切なステップです。 イスラエルの開発者であるTali Garsiel氏が公開した『How Browsers Work』は、HTML5 Rocksに転載され、複数の日本語訳も提供されている、ブラウザの内部動作を学ぶために読んでおきたいリソースの1つです。 そのリソースを参考に、レンダリングエンジンのメインフローについて見ていきましょう。

ブラウザはまずHTMLドキュメントを解析し、HTMLタグをコンテント・ツリーと呼ばれるDOMノードに変換します。そして外部CSSやスタイル要素に含まれるスタイルに関するデータを解析し、レンダーツリーを作成します。
このレンダーツリーが色や大きさのような情報を持つ矩形を持っています。

ここから先が特にアニメーションのパフォーマンスに関わりの深いフローになりますが、レンダーツリーが作成された後、レイアウト(リフロー)と呼ばれるプロセスに入り、そしてペイントがそれに続きます。

ここでは非常に大まかな流れしか解説しませんが、Paul Irish氏が言うとおり、ブラウザがHTMLやCSSを画面に表示するまでのフローを理解することは、開発におけるベストプラクティスの背後にある根拠を理解する手助けとなります。少々慣れない用語が多いかもしれませんが、ぜひ先ほど紹介した記事を一読ください。

アニメーション・ボトルネック: レイアウト(リフロー)

Google ChromeやSafariなどのWebKit系ブラウザではレイアウト、FirefoxなどのGecko系ブラウザではリフローと呼ばれるプロセスは、パフォーマンス向上において大きな障害となるプロセスの1つです。
Satoshi Ueyama氏が2007年に『出張 Shibuya.js 24』にて発表した際に使用した以下の動画で見ることができます。様々な大きさの矩形が徐々に配置されていくプロセスがレイアウト/リフローです。

Gecko Reflow Visualization

このレイアウトのプロセスを、どのように最小限に抑えることができるかが、アニメーションの高速化において大切なポイントになります。 レイアウトを引き起こす原因について、詳しくはTony Gentilcore氏による「How (not) to trigger a layout in WebKit」を参考にしてください。
記事のタイトルにもある通り、あくまでWebKit系ブラウザのみに限定されていますし、2011年の記事でもありますので、必ずレイアウトの発生を確認できるツールを利用して確認することをおすすめします。
（執筆時点ではGoogle Chrome、Safariの開発者ツール、そして紹介記事から得た情報でしかありませんが、IE11の開発者ツールでもレイアウトの発生を確認できます）

アニメーション・ボトルネック:ペイント

やや乱暴ではありますが、ブラウザで何かを表示するということは、HTMLやCSSから得た情報を画像化して表示しているのと大きな差はないと言えます。　

CSS3がプロダクションレベルで利用されはじめた今、角丸やシャドウなどを画像を利用せずに表現することが当たり前になってきているかと思います。読み込む画像が少なくなれば、その画像を制作するコストも減り、画像の読み込みにかかるコストも減りますが、その代わりにブラウザがそのコストを背負ってくれているわけです（もちろん1対1の割合ではありませんが）。
この後の段でアクシデントとして紹介しますが、すべてのスタイルが同じコストでペイントを行うわけではなく、また組み合わせによってコストが甚大になるケースもあるので注意が必要になります。

ブラウザは、表示領域をいくつかのタイルとしてレンダリングを行います。それぞれの個別のタイルごとにレンダリングをし、その結果をキャッシュしていきます。
そのため、大きな領域でペイントを行うことを避ける必要があります。レイアウトと同様に、ペイントを行う範囲を最低限にしておくことがポイントになります。

アニメーションのパフォーマンスの計測、デバッグツール/ワークフロー

パフォーマンス最適化において、最も大事なことは計測することです。私自身もよく陥る失敗ですが、どこかで読んだから、以前はうまく回避できた問題だからと盲目的にそれらの情報を頼りにするのではなく、計測する方法をきちんと学び、計測を日々続けることがベストプラクティスです。

開発者ツールについての詳しい記事は今後本サイトで紹介される予定ですので、ここでは私が実際にアニメーションのパフォーマンスについて計測するのに利用しているツールとワークフローを、ほんの一部ですが紹介していきます。

パフォーマンス計測を行う上で欠かすことができないのが、Google Chrome Canaryの開発者ツールです。Chromeではなく、日々更新を続けていくCanaryを利用する理由は、計測ツールとしての機能の多さと深さがChromeとは異なるからです。

アニメーションの最適化という文脈においてタイムラインパネルは、エディタとブラウザの描画エリアと同じくらい見る画面です。

まずは上図の1、Framesタブに切り替えて、上図2のRecordボタンをクリックし、計測を行いたいアニメーションを実行します。

すると、上図のような棒グラフが記録されていきます。その下にある表は棒グラフをより詳細にしたものです。
棒グラフは、背が高ければ高いほど処理に時間がかかっているということになります。計測対象にもよりますが、グラフ上にある2本の線は30FPSと60FPSを示しています。60FPSを目指すのであれば、それ以上の高さになっている棒グラフの周りをドラッグすることで、下にある表にその選択したタイミング内の詳細情報を表示させることができるようになります。

表にある横グラフは、マウスオーバーさせることでその特定の処理についての詳細を見ることができます。
レイアウトやペイントがどの範囲で行われているか、そしてそれにかかっている時間がどのくらいか、などの情報を確認することが可能です。
これらの情報と最前にも紹介したレンダリングの仕組みの情報を踏まえて、トライアル&エラーを繰り返し、最適化を図っていくのが大まかなワークフローとなります。

アニメーションを遅くするよくあるアクシデント

最後にアニメーションのパフォーマンス最適化を妨げる、よくある3つのアクシデントを紹介します。

1つ目は本連載の前編でも少し触れたGPUにまつわるアクシデントです。
GPUを使ってRenderLayerを作成し、そのレイヤー上でアニメーションを行うことそのものはベストプラクティスと言えます。しかしCPUからGPUへのデータ転送にはコストがかかり、特にモバイルデバイスなどCPUもGPUも非力である場面で問題になります。

この問題については、Phamtom.jsの作者としてよく知られるAriya Hidayat氏によるデモが非常にわかりやすいです。デモそのものはこちらのcodepenで実際に動作しているので、参考にしてください。

Ariya Hidayat氏によるGPUへのデータアップロードデモ

それぞれのボックスの右上に数字があり、カウントされているのが確認できたでしょうか？　このカウントがCPUからGPUへのデータの転送数を示しています。このデータ転送が少ないほうがパフォーマンスはよくなります。
ですが、実際にデータ転送を行わないプロパティは非常に少なく、Ariya Hidayat氏によれば、opacity、transform、filterの3つのみと言われています。
アニメーションの表現としてデータ転送が回避できない場面が多いのも事実ですが、同時にデータ転送には相応のコストがかかることを知っておくことも大切です。

GPU関連でもう1つの落とし穴があります。GoogleのJake Archibald氏によるデモをご覧ください。

オレンジ色の矩形が、GPUによって処理されるComposited Layerを示しています。実際にComposited Layerを生成したかったのは左上の緑のボックスだけなのにも関わらず、どういうわけか見出しにもComposited Layerが生成されてしまいます。デスクトップ上であれば、このComposited Layerの生成にかかるコストは気にするほどのことでもありませんが、モバイルデバイスにおいては大きなコストになってしまいます。
この問題を回避するのにはシンプルな解決があります。

先ほどのデモ内においてはアニメーションする要素そのものに、z-index: 1を付与することで回避できます。
このアクシデントは、カルーセルのようなUIパターンによく見られます。自作する際も、すでにあるライブラリを利用する際も、思っていない場面でComposited Layerが生成されていないか確認し、z-indexを使って回避できるか試してみてください。

Ariya Hidayat氏によるW3Confでのプレゼンテーション『Fluid User Interface with Hardware Acceleration』はハードウェア・アクセラレーションを使った最適化を行うのにあたり、見ておくべきリソースの1つです。またThe Chromium ProjectsにてドキュメントされているGPU Accelerated Compositing in Chromeも参考になりますので、ぜひ一読してください。

ここで紹介する最後のよくあるアクシデントが、CSSプロパティの組み合わせによるペイントコストの増大です。このアクシデントはモバイルデバイスでよく見かけるものです。例えば、角丸とシャドウを組み合わせたボックス、非常によくあるスタイルにも関わらず、これらのスタイルがあると、とたんにスクロールが引っかかるように感じてしまうことがあります。この「引っかかる感じ」の原因の多くがペイントです。

どのプロパティの組み合わせがどれくらいのペイントコストとなるかを計測するためのツールは存在はしますが、ここでは紹介しきれませんので割愛します(チャレンジしてみたい方はこちらのドキュメントを参考にしてください。また取得方法は異なりますが、Colt McAnlis氏によるHTML5 Rocksの記事『CSS Paint Times and Page Render Weight』も合わせて参考にしてください。)。しかし前段で紹介したタイムラインパネルでもペイントコストを確認できますので、トライ&エラーを繰り返すことで、最適化を進められるでしょう。

前後編にわたってWebアニメーションの最適化について紹介してきました。
いずれブラウザや端末そのものも賢くなり、これらの知識やテクニックも早晩時代遅れになっていくだろうと思います。しかし、我々はその過渡期にいる最中です。「使いやすさ」を向上する上で欠かすことができない最適化は多くの苦難があっても報われるものです。