公開日: 2010年11月20日(Sat)
CSS3 の border-image は、これまでウェブデザインが悩まされ続けてきた煩わしい問題を解決してくれる、とっても便利な新機能。しかし、iPhone の Mobile Safari のアニメーション処理を重くしてしまう場合があるようだ。
おそらく、この問題の対象になるのは、iPhone、iPod touch、iPad に搭載されている Mobile Safari。PC版やAndroidのブラウザでは、この現象は確認できない。
border-image を使用した要素や、それを含む、あるいはそれに含まれる要素を、CSS3 の transition などでアニメーション処理したときに、アニメーションがスムーズに処理されず、カクカクになってしまう場合がある。
iPhone 3GS よりも、iPhone 4 の方が症状は深刻なようだ。
実験用にいくつかのページを作成してみた。これを、iPhone の Mobile Safari で表示してみたところ、次のような感じ。
border-imageの影響が確認できる。border-imageを適用した要素がひとつしかないからかも知れない。border-imageが適用される要素は、画面上では静止しているが、それでも重い。結果的には静止しているが、再描画処理を行う必要があるパターンだと思われる。border-image を適用した要素の上空を通過しているときだけ重くなる。それ以外の領域では影響がなさそう。
ここからは、border-image が iPhone のアニメーション処理を重くしてしまう原因についての仮説。
人づてに聞いた未確認情報だが、iPhone の Safari は、HTMLをレンダリングした後、画面のキャプチャを撮って置き換えるような処理をしているらしい(これにより、リアルタイムに画面を再描画する Android のブラウザと比べて、画面スクロールなどの処理がスムーズに動作するそうな)。
だとすると、画面上で要素を動かすようなアニメーション処理を実行すると、1コマずつキャプチャを撮って表示している、と想像できる。
border-imageは画像を9つに分解する
それを前提に border-image の機能について考えてみる。border-image は、1枚の画像を、縦横それぞれ3つずつ、合計9つに分解して、ボックスを囲う機能(しかも、伸ばしたり縮めたりする場合もある)。つまり、画面を再描画するために、画像1枚につき9枚分の負荷がかかるのではないか。
それであれば、Retinaディスプレイで4倍の画素を持つ iPhone 4 が、iPhone 3GS よりも重くなるということも納得がいく。
ただし、実験の結果からするに、闇雲に全画面を再描画しているわけではなさそうなことがわかる。
スライドのような処理では再描画が必要な領域は少なくて済むため、パフォーマンスに大きな影響が出る場合は少なそうだが、アコーディオンのように画面全体の長さに影響するような処理には注意が要る。
このことは、border-image を使わない場合でも、少ないかも知れないが影響はするはずなので、意識しておきたい。
角が丸いボックスや、凝ったボタンなど、これまで相当な苦労を強いてきたウェブデザイン上の課題をスマートに解決した救世主だっただけに、こうしたパフォーマンス上の新たな課題にもなってしまうのはとても残念なことだ。
一方で、これは世界で最先端のモバイルブラウザにとっての次の課題であるはず。ウェブデザインは、飽くまでウェブ標準に沿って毅然とした実装をするべきだと思う。健全なWWWのために。
Apple の次期 Mobile Safari に超絶期待！
以下は関連記事。
公開日: 2010年11月20日(Sat)
