CSS と JS はどちらが速いですか anime_html/css_WEB-ITnose

JavaScript ベースのアニメーションは密かに CSS トランジションと同じか、それよりも高速です。どうすればこれが可能になるのでしょうか。 Adobe と Google がネイティブ アプリと同等のパフォーマンスを備えたメディアリッチなモバイル サイトをリリースし続ける中、どのようにしてこれが可能になるのでしょうか?

この記事では、Velocity.js や GSAP などの Javascript ベースの DOM アニメーション ライブラリを見て、それらが jQuery や CSS アニメーション効果よりもどのようにパフォーマンスが優れているかを確認します。

jQuery

基本から始めましょう: JavaScript の間違いjQuery と混同すると、jQuery のアニメーションが遅くなります。なぜ？なぜなら、 jQuery は非常に強力ですが、強力なアニメーション エンジンになることは jQuery の設計目標ではありませんでした。 jQuery のメモリ消費によりガベージ コレクションが頻繁にトリガーされ、アニメーションが時々フリーズします

jQuery は新しいテクノロジーをそれ自体から保護するために requestAnimationFrame (RAF) の代わりに setInterval を使用します。

レイアウトの乱れが滑らかさの原因であることに注意してくださいアニメーションの開始時にガベージ コレクションが原因であり、RAF を使用しないとフレーム レートが低くなります。

実装例

レイアウトの乱れや更新された組み合わせを引き起こす DOM クエリを回避します。 1

2

3

4

5

6

7

8

9

10

1 1

12

13

14

15

16

var currentTop,

currentLeft;

/* レイアウトスラッシングあり */

currentTop = element.style.top; /* QUERY */

element.style.top = currentTop + 1;

currentLeft = element.style.left; /* QUERY */

element.style.left = currentLeft + 1; /* UPDATE */

/* レイアウトスラッシングなし */

currentTop = element.style.top; /* クエリ */

currentLeft = element.style.left; /* クエリ */

element.style.top = currentTop + 1; /*

element.style .left = currentLeft + 1; /* UPDATE */

更新後に発生するクエリにより、ブラウザはページの計算データを強制的に再計算します（新しい更新の影響も考慮されます）。アニメーションにはかなりのオーバーヘッドがかかりますが、それはわずか 16 ミリ秒の実行タイムアウトです

同様に、RAF の実装では、既存のコード ベースを大幅に作り直す必要はありません。 setInterval と RAF の基本的な実装を比較してみましょう。

1

2

3

4

5 6

7

8

9

10

11

12

13

14

var startingTop = 0;

/* setInterval: 60fps (1000ms/60 ~= 16ms) を達成するために 16ms ごとに実行します。 */

setInterval( function () {

/ * これは 1 秒間に 60 回刻みなので、上部を分割します。プロパティの増分は 1 秒あたり 1 単位です。 */

element.style.top = (startingTop += 1/60)

;

/* requestAnimationFrame: ブラウザが最適な状態にあるかどうかに基づいて 60fps での実行を試みます。 */

function check () {

element.style.top = (startingTop +=

}

window.requestAnimationFrame(tick);

RAF はアニメーションのパフォーマンスを高める最大の可能性を生み出します。

CSS Transforms

CSS Transforms はアニメーション ロジックを組み合わせることで機能します。これは、jQuery ではなくブラウザ自体に処理させることで、次の点で効果的です: (1) DOM インタラクションとメモリ消費を最適化してラグ (バンプ) を回避する、(2) エンジンの RAF 原理を利用する、(3) ) ハードウェア アクセラレーションを強制します (GPU のパワーを利用してアニメーションのパフォーマンスを向上させます)。

しかし、実際には、これらの最適化は JavaScript で直接実行することもできます。 GSAP はこれを長年にわたって行ってきました。新しいアニメーション エンジンである Velocity.js は、同じテクノロジーを活用するだけでなく、さらに数歩進めたものであり、これについては後ほど説明します。

JavaScript アニメーションが CSS トランジションと競合する可能性があるという事実に直面することは、私たちの回復計画の最初のステップにすぎません。 2 番目のステップは、「JavaScript アニメーションは実際には CSS トランジションよりも高速である可能性がある」ことを理解することです。

ここで CSS 変換の弱点について話しましょう:

ハードウェア アクセラレーションを強制するトランジションは GPU の消費量を増加させ、高負荷条件下では動作が不安定になります。これは特にモバイル デバイスに当てはまります。 (ブラウザのメイン スレッドとフォーマット スレッドの間でデータが転送されるときのボトルネックなどの特殊なケースも、スムーズさを低下させる原因となる可能性があります)。変換や不透明度などの特定の CSS プロパティは、これらのボトルネックの影響を受けません。 Adobe はこれらの問題をここで注意深く要約しています。

移行は IE10 以下では役に立たず、IE8 および IE9 以降に引き起こされたデスクトップ サイトのユーザビリティの問題は現在でも広く蔓延しています。

トランジションは JavaScript によってネイティブに制御されない (ただし、JavaScript によってトリガーされるだけである) ため、ブラウザーは、これらのトランジションを制御する JavaScript コードと同期してトランジションを最適化する方法を知る方法がありません。

逆に、JavaScript ベースのアニメーション ライブラリは、適切な有効化ハードウェアを自分で決定できます。これらは、IE ブラウザのすべてのバージョンをネイティブにサポートしており、バッチ アニメーションの最適化に特に適しています。

私の提案は、モバイル専用に開発しており、単純なアニメーションのみを実装している場合にのみ、ネイティブ CSS 変換を使用することです。この環境では、トランジションはネイティブで効率的なソリューションであり、追加の JavaScript ライブラリを追加せずにすべてのアニメーション ロジックをスタイル シートに実装できるため、ページの肥大化を防ぐことができます。ただし、複雑な UI を設計している場合、またはさまざまな状態の UI を含むアプリを開発している場合は、アニメーションをスムーズに保ち、ワークフローを管理しやすくするためにアニメーション ライブラリを使用する必要があります。 Transit は、CSS 変換の管理に特に優れた機能を備えたライブラリです。

JavaScript アニメーション

それでは、JavaScript のほうがパフォーマンスの面では優れていますが、実際の 3D アニメーションのサンプルを構築するには、最初は十分な速度です。 WebGL の使用。通常は、Flash または After Effects を使用して構築するだけで十分です。

仮想世界を構築するだけで十分です。もちろん Transit (CSS グラデーション効果を使用) を含む主要なアニメーション ライブラリを直接比較するには、VelocityJS.org にある Velocity のドキュメントを参照してください。

疑問は残ります。JavaScript は具体的にその高レベルを実現する方法です。 Javascript ベースのアニメーションの実行を可能にする最適化の短いリストは次のとおりです:

DOM を同期する → レイアウトのジッターを最小限に抑えるためにアニメーション チェーン全体の中央にプッシュします。 DOM クエリの発生を最小限に抑えるための呼び出しのチェーン全体 (これらは、高パフォーマンスの DOM アニメーションの落とし穴です)

同じ呼び出し内の同じレベルの要素全体の単位変換率をキャッシュします (px から % への変換など)。 em など).

更新が視覚的に表示されない可能性がある場合はスタイルの更新をスキップする

レイアウト スラッシングについて前に学んだことを思い出して、Velocity.js はこれらのベスト プラクティスを利用して、アニメーションの終了値をキャッシュします。後続のアニメーションの開始値として再利用するため、要素の開始値を取得するために DOM を再クエリする必要がなくなります。

/*要素を下にスライドさせて表示します。

/* 1000 ミリ秒の遅延の後、要素をスライドさせて表示の外に出します。上の例では、2 番目の Velocity 呼び出しは、不透明度 1 および上限 50% で自動的に開始する必要があることを認識しています。

最終的にはブラウザ自体もこれらと同じ最適化の多くを実行できるようになりますが、そうすることで開発者がコードをアニメーション化できる方法の数が大幅に減少します。したがって、同様に、jQuery は RAF を使用しないため (前述したように)、ブラウザーは RAF を強制的に最適化することはなく、仕様を破ったり、予想される動作から逸脱したりする可能性がわずかでもあります。

最後に、これら 2 つの JavaScript アニメーション ライブラリ (Velocity.js と GSAP) を比較してみましょう。 GSAP は、JavaScript の優れた DOM アニメーション パフォーマンスを実証した最初のアニメーション ライブラリでした。ただし、いくつかの欠点があります。

中から高ストレスのアニメーションでは、GSAP の DOM インタラクション オーバーヘッドにより、開始時にフレームがドロップされます。 Velocity.js は非常に寛容な MIT ライセンスの下でリリースされていますが、GSAP はクローズドソースであり、多くの種類のビジネスに対して年間ライセンス料が必要です。

GSAP はフル アニメーションであるため、ただし、GSAP は機能が豊富なので、アニメーションのスイス アーミー ナイフであるという利点があります。

タイミングを正確に制御する必要がある場合は、GSAP を使用することをお勧めします。 (例: 再マッピング、一時停止/再開) およびモーション (例: ベジェ曲線パス) これらの機能は、ゲーム開発や特定のニッチなアプリケーションにとって重要ですが、通常、Web アプリの UI では必要ありません。

Velocity.js

引用 GSAP の豊富な機能それは、Velocity 自体が機能的に軽量であることを意味するものではありません。逆に、Velocity は、圧縮後のわずか 7kb で、jQuery $.animate() のすべての機能を複製するだけでなく、色のアニメーション化、変換、ループも実行します。

つまり、Velocity は、jQuery、jQuery UI、および CSS グラデーション効果の最良の組み合わせです

さらに、利便性の観点から見ると、Velocity は内部にあります。 (蓋、これはおそらく、パブリック インターフェイスで jQuery の $.queue() メソッドを使用することを意味します)。これにより、jQuery の $.animate()、$.fade()、および $.lay() 関数とのシームレスな相互運用性を実現できます。 Velocity の構文は $.animate() の構文と同じであるため、ページ上のコードを変更する必要はありません

基本的なレベルで、その方法を簡単に見てみましょう。 Velocity の動作 $.animate() と同じ:

1

2

3

4

5

6

$element

.delay(1000)

/* 速度を使用してアニメーション化する2000 ミリ秒にわたる要素の上部プロパティ */

.velocity({ top: "50%" }, 2000)

/* Velocity による上部のアニメーション化が完了したら、標準の jQuery メソッドを使用して要素をフェードアウトします。 */

.fadeOut(1000);

最も高度なレベルでは、ほぼ 2 行の簡単なコードを使用して、3D アニメーションを含む複雑なスクロール シーンを作成できます。 3

4

5

$element /* ブラウザを 1000 ミリ秒かけてこの要素の先頭までスクロールします */

.velocity( "scroll" , 1000)

/* その後回転します要素を Y 軸の周りに 360 度回転します。 */

.velocity({rotateY: "360deg" }, 1000);

終わり

Velocity の目標は、DOM におけるアニメーションのパフォーマンスと利便性のリーダーであり続けることです。この記事では前者に焦点を当てます。 後者の詳細については、VelocityJS.org にアクセスしてください。

結論を導く前に、高パフォーマンスの UI とは、より多くのライブラリを選択することだけではないことを覚えておいてください。ページの残りの部分も同様に最適化する必要があります。 Google トークからさらに多くの夢のようなコンテンツを学ぶことができます:

ジャンクなし

塊のないレンダリング

より高速なウェブサイト