フロントエンドのパフォーマンスの最適化

ブレーキサイトは、ユーザーだけでなく開発者にとっても苦痛です。 状況を修正する方法、キャッシュに依存する必要がある場合、プロセッサを信頼できる場所、およびこれらすべてが複雑なフロントエンドアプリケーションのパフォーマンスを最適化するのに役立つ方法、JSエキスパートでありHTMLアカデミーの教師であるIgor Alekseenko（@ iamo0）が実際に説明する準備ができています。 Frontend Conf 2017での彼のレポートのカットデコーディング中。









スピーカーについて

Igor Alekseenkoは、HTMLアカデミーで基本および高度なJSコースを提供する長年の開発者です。 彼は、Lebedev Studio、Islet、JetBrainsで働いていました。



今日、私は開発者の問題について話したかった。 私自身の痛みを分かち合いますが、あなたがそれを分かち合うことを願っています。







インターフェイスが遅くなると嫌いです。 そして、私はサイトのユーザーとしてだけでなく、開発者としても嫌いです。







なんで？ 開発者として、私たちは、人々がサイトで経験する感情、その経験に対して責任があるからです。 人がサイトに来て、ある種の否定的な経験を得た場合-これは私たちのせいです。 これはデザイナーではなく、洗練された技術ではありません-これが私たちです。







さて、インターフェイスが遅くなるだけです。 まあ、ユーザーは私たちのオンラインゲームに来ますが、敵を狙って殺したり、ぴくぴくしたアニメーションを見たりすることはできません。







しかし、実際には、すべてがはるかに複雑です。 より多くのサイトがあり、より複雑な問題を解決するからです。 銀行業務アプリケーションを開発していて、データを再送信し、ユーザーがお金を失った場合、またはオンラインストアを所有しており、ユーザーが必要な製品を購入できなかった場合、このユーザーは失われます。 そして、これはすべてあなたのサイトが遅いという事実によるものです。



ユーザーの損失とは、お金の損失、会社の観点からの収益の損失、そして場合によっては解雇です。



したがって、一般的に、スローダウンサイトは深刻な問題です。 それで対処する必要があります。

しかし、問題を解決するには、敵を直接知る必要があります。 サイトにブレーキがどのようなものがあるのか​​、なぜサイトが遅いのか、どこからブレーキが発生するのかを見てみましょう。







サイトでのブレーキは、ユーザーの操作が均等でなくなると発生します。 これはどういう意味ですか？ 実際、ユーザーがサイトを閲覧すると、ある種の静止画像以上のものが表示されます。 このサイトは単なる写真ではないため、ユーザーが提供するインターフェイスとユーザーがやり取りするプロセスです。







ユーザーは、私が話したのと同じアニメーションを見ることができます。 サイトを簡単にスクロールできます-これも動的な相互作用です。 彼はボタンをつついたり、テキストを入力したり、アイテムをドラッグしたりします。 すべて動的に機能します。







なぜ動的に機能するのですか？ なぜサイトは長期間存続できるのですか？

これは、イベントループなどの設計がすべてのブラウザーエンジンに組み込まれているためです。







実際、イベントループは非常に単純なプログラミング手法であり、特定の周波数で無限ループを開始するだけです。 スタックにとらわれず、何らかのパフォーマンスが得られるようにします。



すべてのステップでこの無限ループは外部条件をチェックし、特定のアクションを開始します。 たとえば、ユーザーがマウスをスクロールし、ページをわずかに移動する必要があることを理解しています。







ブラウザエンジンに組み込まれているイベントループを使用すると、スクロール、その他の処理、長期的に実行するコードなど、すべてのユーザーインタラクションが同期されます。 つまり、すべてこのイベントループに依存します。



イベントループフレームに入る方法は？



特定の周波数で回転するサイクルがあります。 しかし、私たちは、フロントエンドの入札者として、この頻度を制御できず、それを知りません。 私たちは、すでに準備された、私たちの従業員を対象としたものを使用する機会しかありません。 つまり、周波数を制御しませんが、それに適合させることができます。 これにはrequestAnimationFrameコンストラクトがあります。



コードをコールバックrequestAnimationFrameに渡すと、次の更新フレームの先頭に到達します。 更新フレームは異なります。 たとえば、MACでは、これらのフレームは60 Fに収まろうとしますが、周波数は常に60 Fに等しいとは限りません。 例でさらに説明します。







Javascriptは、時間の経過とともに更新される無限ループに基づいていることがすでにわかっています。 これで、ブレーキがどこから来るかを推測できます。



時間の経過とともに更新されるフレームがあります。 サイトでいくつかの計算を実行します。 どれでも。 Javascriptで記述しているのは、実際にはコンピューティングだけです。 これらの計算に表示される1つの更新フレームよりも時間がかかる場合、ユーザーには遅れが表示されます。







つまり、一連の連続したフレームがあり、1つのフレーム以上を要する長い計算があります。 ユーザーにはわずかな遅延が見られます。 彼はアニメーションをぴくぴくさせます。







または、計算が大きくなりすぎて、ページがフリーズし、何もできなくなります。



わかりました。ブレーキとは何か、なぜサイトが遅くなるのかを理解しました。 それでは問題を解決しましょう。







私たちはプログラマーなので、コードを実行するツールがあります。 プログラマの主なタスクは、プロセッサとメモリの間の負荷分散を正しく分散することです。

私たちは皆、プロセッサーとは何かを知っています。 これは、インスタントコンピューティングを担当するコンピューター内のデバイスです。 つまり、記述するコマンドはすべて、プロセッサの命令に変換され、このコマンドが実行されます。



しかし、何らかの素晴らしい結果をもたらす一連のコマンドがある場合（たとえば、複雑な値を計算した場合）、このシーケンスを繰り返したくない場合は、このコマンドの結果をメモリに書き込み、メモリ読み取りと呼ばれる別のプロセッサ命令を使用できます。



私はこれについて話したいだけです。







論理的と思われる最初の最適化は、計算を使用しないためにメモリを使用することです。



原則として、このような戦略は有利に聞こえます。 さらに、これは優れた戦略であり、すでに使用されています。







たとえば、Javascriptには、数学とコンピューティングで動作するように設計された組み込みのMathオブジェクトがあります。 このオブジェクトには、メソッドだけでなく、計算された一般的な値も含まれているため、再カウントされません。 たとえば、特定の文字まで保存されている数値πの場合のように。



第二に、昔の良い例があります。 80年代のプログラマーは、効果的なソリューションを書いたので本当に大好きです。 鉄は弱く、彼らはいくつかの良いものを考え出さなければなりませんでした。



3Dシューティングゲームでは、常に三角法が使用されます。距離とサイン、コサイン、その他の類似のものをカウントするためです。 コンピューターの観点から見ると、これらは非常に高価な操作でもあります。



以前は、コンパイル段階のプログラマは、サインとコサインのテーブルをプログラムコードに直接挿入していました。 つまり、彼らは三角関数のすでに計算された値を使用しました。 シーンをレンダリングするためにそれらをカウントする代わりに、それらを定数として取りました。

このようにして、世界中のすべてを最適化できます。 アニメーションを事前に計算して、どのように見えるか、何でもできます。



原則として、非常にクールに聞こえます。







ここにフレームがあります。いくつかのフレームを使用する計算を開始する代わりに、読み取りのみの計算を実行します。完成した値を読み取り、置換し、使用します。 そして、インターフェースは非常に高速であることがわかりました。

理論的には、これは非常にクールに聞こえます。 しかし、フロントエンドがメモリでどのように機能するかを正確に考えてみましょう。







ブラウザのタブを開くと、特定の量のメモリが割り当てられます。 ところで、私たちも彼を知りません。 これには制限もあります。



しかし、それだけでなく、この記憶を制御することもできません。



別の特性があります-何かがこのメモリに既に保存されています：

1. このメモリには、言語のランタイム（すべてのコンストラクター、すべての関数）が格納されます。 言語自体はメモリに保存されます。
   
   
2. また、いくつかのデータを使用します。Ajaxから何かをダウンロードし、いくつかの構造を生成します。
   
   
3. DOMツリーがあり、JavascriptがHTMLを読み取ることができず、ブラウザーがそのマークアップをオブジェクトのセットに変換してツリーに変換するため、メモリも取得します。 ブラウザのメモリ内で、タブは、個々のオブジェクトの形式のすべてのタグを含む、マークアップにあるすべてのものを取得します。 テキストが入ります。
   
   

つまり、タグの間にある転送ごとに、ブラウザーメモリオブジェクトがテキストモードとして作成され、ハングします。

私たちはすでに多くのすべてを記憶に持っていることがわかりますが、同時に私たちはそこに自分自身の何かを書きたいと思っています。 メモリが遅くなり始める可能性があるため、これは非常に危険です。







主に2つの理由があります-そして、奇妙なことに、それらは互いに矛盾しています。 1つ目はガベージコレクションと呼ばれ、2つ目はガベージコレクションの欠如です。







それぞれを分析します。



ガベージコレクションとは何かを説明する前に、パフォーマンス、メモリ、その他すべての点で作業をどのように見ているかを説明します。







事実は、これらすべてが測定できるということです。 どのブラウザにも開発者ツールがあります。 Chromeの例を示しますが、他のブラウザーでも表示されます。 「プロファイリング」または「パフォーマンス」タブを確認します。



いつでも開いて、いわゆるブラウザパフォーマンススナップショットを測定できます。 「記録/記録」ボタンをクリックします。 パフォーマンスの記録が作成され、しばらくすると、ページで何が起こっていたのか、メモリとプロセッサにどのように影響したのかを確認できます。



このタブは何で構成されていますか？

• まず、上部には秒、つまりタブの有効期間を示すタイムラインがあります。
  
  
• Fps-その時点でのフレームレート。
  
  
• CPU使用率-共同グラフでは、さまざまな計算が表示されます。
  
  
• スクリーンショット ところで、あなたはそれらを見せないことができます。 スクリーンショットをオンにしてパフォーマンスプロファイルを記録すると、FPSのサグが保証されるため、それらをオフにすることをお勧めします。 つまり、FPSを計算する必要がある場合は、念のためスクリーンショットをオフにします。
  
  
• メモリ。 これは最低のチャートです。
  
  
• 上記と同じ情報の詳細な統計。 つまり、いつでもプロファイラーを増やして、フレームで何が起こるかを正確に確認できます。 フレームに拡大して、コードへのリンクがあっても、そのフレームで実行された操作を確認することもできます。
  
  

そのため、Instagramでこのパフォーマンスをシールで測定します。 誰もが猫を愛し、誰もがInstagramを愛しているので、私はそうすることにしました。







猫はあまりいないので、大きなページを見ていきます。 5ページに5,000個のシールがあり、それらを切り替える方法を学習します。



以下は、シールを生成するコードです。 それらはすべてユニークです。







つまり、標準テンプレートからDOM要素を作成し、一意のデータを入力します。 写真が繰り返される場合でも、テンプレートを使用します。これにより、キャッシュがなくなり、メモリテストがクリーンになります。







すべての要素を作成したら、それらを1つのフラグメントに追加します。これは、皆さんが知っている最適化でもあります。 ページをきれいにするために、チェッカーをむき出しにします！ -コンテナを清掃します。







より速く動作します。



ガベージコレクション。







ガベージコレクションは、メモリ処理を最適化するために設計されたプロセスです。 彼は私たちによって制御されていません。 ブラウザ自体は、このタブに割り当てられたメモリが不足しており、古い未使用オブジェクトを削除する必要があることを認識すると、ブラウザを起動します。



古い未使用オブジェクトは、参照されなくなったオブジェクトです。 つまり、これらは変数、オブジェクト、配列に書き込まれないオブジェクトであり、一般にどこにも書き込まれません。



確かに、これはクールなプロセスのようです。メモリは本当に制限されており、解放する必要があるため、ガベージコレクションが必要です。



なぜこれが問題になるのでしょうか？ ガベージコレクションにかかる時間はわからないし、いつ発生するかわからないからです。



例を見てみましょう。







ここでは、猫のページを切り替えるためのタイムラインプロファイルを記録しました。 上のグラフは、プロセッサのパフォーマンスの急上昇-CPU使用率を示しています。



下のグラフは、最初にメモリが増加することを示しています（これはメモリ使用量のグラフです）。 これは単なるガベージコレクションプロセスです。



最初の2ページに十分なメモリがあり、10,000個のシールを描きました。 その後、メモリがなくなり、さらに5,000個のシールを描画するために、古いシールは使用されなくなったため削除しました。



原則として、これはクールです。 確かに、ブラウザは私を世話し、私が使用していないものを削除しました。 問題は何ですか？







私がいつも言うように、このジャンプダウンを見て、ガベージコレクションプロセスにかかった時間を見てみましょう。



4つのガーバージ収集エントリを追加すると、ガベージコレクションプロセスに134ミリ秒かかったことがわかります。これは60 Fpsで10フレームです。







つまり、600 Psのブロック移動を一定時間アニメーション化する場合、ブラウザがメモリを消去することを決定しただけで、100 Psの移動を失うことになります。 このプロセスの開始も期間も制御しません。 これは悪いです。

メモリリークは、ガベージコレクションが使用できると考えているため、ガベージコレクション時に一部の未使用のオブジェクトがメモリに残る状況です。

2番目の問題は、最初の問題とは正反対です。 これはメモリリークと呼ばれます。



ブラウザは非常に矛盾しているように見えます。メモリを消去する必要があります-長い時間がかかり、メモリを消去しない-時間がかかります。 なんで？



メモリリークは、ガベージコレクションがない場合のこのようなプロセスです。 つまり、それが起こっているかもしれませんが、必要なものをきれいにしません。 時々私たちはそのようなものを投げることができます-そしてそれを見ると、ブラウザエンジンはそれをきれいにできないことを理解します。



コード例を見てみましょう。







ここでも同じページ切り替えがありますが、ページに新しい要素を挿入するたびに、各写真にハンドラーを追加します。



スペースバーを押す必要があるとしましょう。 念のため、Keydoが消えないようにドキュメントにハンドラーを配置しました。 この場合はどうなりますか？



HTML削除を使用してコンテナをクリーニングすると、DOMノードがDOMツリーから削除されます。 ただし、ドキュメントはページに残るため、ドキュメントのハンドラは残ります。 彼には何も起こりません。 ガベージコレクションが発生すると、ガベージコレクターはこれらのハンドラーを削除しません。

これらのハンドラーの中に何が書かれているのか見てみましょう。



これらのハンドラー内でノードが使用されます。 ノードへのリンクがあるため、ノードはメモリから削除されないことがわかります。 これはメモリリークと呼ばれます。 ロジックの観点からは、ヨウ素やハンドラーは必要ありません。 しかし、彼の観点からはコレクターが使用されているため、コレクターはそれについて知りません。



この場合はどうなりますか？ チャートを見てみましょう。







上昇と下降の波から、スケジュールは成長する梯子に変わりました。 ページを切り替えるたびに、メモリはますます使用されますが、メモリ内にはハンドラとノードがあるため、クリーンアップされません。



メモリは解放されません。 コンピューターの速度も低下し始めます。



なんで？ 大きなメモリは非常に悪いからです。 プロセッサは、大きなDOMで操作を実行中に詰まります。



その結果、メモリの助けを借りて何かを最適化しようとすると、大きなリスクが生じることがわかりました。







Javascriptを作成したBrendan Ike自身は、最近のインタビュー（WebAssembly）で次のように述べています。 それは高速で、時にはパフォーマンスでCと競合できますが、問題はガベージコレクションが発生したときに始まります。これは、コレクターがいつ来るか、どのくらいの期間動作するかわからないためです。」

信頼できないメモリ

メモリに関連付けられているブレーキは、値が書き込まれたり、自動的に消去されたりするときに発生する可能性があります。 ブレーキがいつ発生するかを予測するのは非常に難しい

メモリの最適化-おそらく良いもの-は信頼性が低いことが判明しました。パフォーマンスが低下し、すべてがうまくいかない場合があるためです。







したがって、図の反対側を見てみましょう。これは、メインのコンピューティングデバイスであるプロセッサの観点からアプリケーション速度を最適化する方法を示しました。







プロセッサを高速化するには、主に3つの方法があります。

1. 計算量を減らします。
   
   
2. 速歩-少し後で、それが何であるかを説明します。
   
   
3. プロセッサを使用しないでください。 これもかなり奇妙ですが、プロセッサを最適化する良い方法です。
   
   

猫と一緒に写真を見てみましょう。







私は、5枚のページにそれぞれ5,000のシールを描いていると言いました。 原則として、これは実際のボリュームです。 これらのシールを0.5分間スクロールすると、5,000要素のDOMを取得できます。



しかし、あなたがそれについて考える場合-これは最初の起動には必要ありません。 現在、4行5列のシールが表示されています。 これは20シールです。 ユーザーがページを初めて開くと、5,000枚の写真すべてではなく、20のシールが表示されます。



そして、ブラウザーは5,000を描画します。 20を表示する場合、なぜ5,000のシールを描画するのですか



まあ、私たちは予備を作ることさえできます-ユーザーはサイトをスクロールできます、そして、彼は何かを示す必要もあります。 ただし、100匹の猫を描いた場合、すでに5つの画面になります。







したがって、最初にできることは、DOMのボリュームを減らすことです。 これが最も簡単な方法です。 DOMを削減すると、すべてが高速に機能します。



プロファイラーの観点からあなたにそれを証明させてください。







最初のページに5,000個の要素を描画し、プロファイラーを使用して読み込みプロセスを記録します。 ちなみに、「再読み込み」ボタンがあり、クリックすると、プロファイラーはページの読み込み速度を記録します。 彼はそれをリロードし、ページが完全にレンダリングされ、すべての準備が整ったら、このスクリーンショットの記録を停止し、4秒で5,000のシールを描画します。



そして、ここでスクリーンショットを記録しました。 . , - , .







100 ( ), 0,5 . — .



.



– .







?



, , . .



– , , , ?







, 60 Fps, . 16,5 . – 16,5 ? , .



. 5 000 , 100. . , .







. , , . .



. – , . , 1 000 ps . 500 .







? 60 Fps – . LG Ipad 120 , , 120 Fps, 60. . , « ? ?» – . .



, . 4 ps . , , 1 100 .



, .







, , . ? , , – , .



100 , 20-30 ps, 100 . – 100 ps , .



. . , 60 Fps .



– .







? いくつかのオプションがあります：

1. .
   
   
2. ;
   
   
3. . — , .
   
   

.







, SVG, anvas.



– , disposable , . , . , , anvas.



SVG anvas.







SVG, - , DOM-. SVG – DOM. , , , JS DOM- – , , - .



anvas, . , anvas. — .

anvas — DOM-, - . - , , SVG.



SVG - — API. SVG - , , , .



anvas . , . . SVG – DOM, , — .



, .







– 800600 – . , , – . path. . .



requestAnimationFrame . , Fps . , 1 .



360° – . – 0, .







anvas. -, . GPU. . .



Main. 0 360 – .



.



, , . – 360° 60 — 60 Fps – .







SVG . なんで？ , Raster. , SVG DOM-, , GPU, .



DOM-, , . . , 45 Fps.



45 Fps , , , . : « ? , 24 Fps».



違います。 , 24 Fps, 48 Fps. : «, 24 Fps, ».







, . , 48 Fps.



.



48 Fps. SVG , , .



, anvas SVG. , disposable , , anvas.



.







, – . . , , , .







anvas anvas, 60 Fps. , . 60 Fps – anvas.



, SVG?







24 ! , . . , . .



, , SVG.







, , . , 24 , , -.



, disposable-, , anvas. - , , , DOM-, -.



, canvas.







– . , anvas . - : .







: ? . SVG , – 1ps, - . anvas.







anvas. , , , .



? , :

1. . Canvas – , API .
   
   
2. , . — .
   
   

: «, , – , , :

• ,
  
  
• Python,
  
  
• ,
  
  
• ,
  
  
• ,
  
  
• .
  
  

, , , , . , .



, – . – .







– . , , .



. , , Ace. , , , .



, , : «, » — .



, , ST-, , .



Ace? : « . , . . . Worker».



, Javascript- — , .

. Worker DOM'. DOM' , . .







まとめると。 ?

• D3, ( – . , , , , ) – anvas, SVG.
  
  
• — . , .
  
  
• Googleマップ上の非インタラクティブオーバーレイ-写真。これは単なる法律です。
  
  
• 並列スレッドで何かを数えることができるなら、それをしてください。
  
  

計算を最適化および削減する方法について長い間話しました。しかし、時にはこれを行うことができません。



たとえば、インターネット上の実サーバーは、100ミリ秒よりも速く応答しません。私はそれについて何もできません。たとえ細部まで考え抜かれた非常に美しいインターフェイスを使用していても、すべての計算が最適化され、遅延が発生し、ユーザーは遅れを見ることができます。



遅延をどうするか？2つの方法があります。

1. 透過的なフィードバックを使用します。つまり、「はい、遅延があることはわかっていますが、これは正常です」ということをユーザーに示します。
   
   
2. ユーザーを少しだます。
   
   

次に、その方法を説明します。







正しいフィードバックを検討してください。 Instagramに戻って印を押して、少しやり取りしましょう。







猫がいて、ユーザーはそれを好きになりたいです。 彼はマウスを持ってきて、アスタリスクをクリックします-はい、あなたは好きです、あなたは完了です！ もっといいね！ しかし、これは真実ではありません。 Likeは好きではありませんが、サーバー上では好きではありません。



サーバーには時々これがあります：







この場合、すべての開発者は何をしますか？







誰も透明なフィードバックを行いません。



どうやってやるの？ Optimistic UIを忘れる必要があると言っているわけではありませんが、方向性を示しています。 ユーザーが何かをクリックしたが、結果がすぐに表示されない場合は、表示する必要があります。たとえば、このアスタリスクを強調表示することもできます。 少なくとも表示：「待って。 はい、私たちはあなたが押したものを理解しましたが、すべてがまだ準備ができているわけではありません。」



何かがうまくいかないときは、別のステータスも必要です。 つまり、透明性を保ち、何が起きているのかをユーザーに示す必要があります。 先ほど言ったように、私たちはサイトのユーザーの印象に責任があります。 そして、彼は愚か者ではなかった、彼は何が彼をコンソールに連れてきたかを理解していなかった。







この報告書の準備をしているときに、母に電話をして、何を話したいか話しました。 彼女は私に冗談を言った：



-どうして10個のピザを持ってきたの？ 私は1を注文しました。

-はい、1を注文しましたが、ボタンを10回押しました



馬鹿げた冗談のように思えますが、私はこれに出くわしました。 時々私はコメントを書いてボタンをクリックします-そして、ボタンが曲がらなくても何も起こりません。 私は思う-それはバギー、または何ですか？ もう一度クリックする必要があります。







しかし実際には、すべてが起こり、リクエストはサーバーに送られ（両方のリクエストはサーバーに送られました）、両方のコメントがレンダリングされました。 また、2つの同一のコメントが表示された場合、ユーザーはそれを好みません。

なんらかの理由で、プログラマーが実際に責任を負うのに、私は責任があると信じられています。 フィードバックを表示するだけです。はい、このボタンをもう一度クリックしないでください。 クリックされたことがわかりました。



答えが来たら、コンテンツをリセットすることもできます。ユーザーは別のメッセージを入力できることを直感的に理解できます。







開発段階では、コストは一切かかりませんが、インターフェースは改善され、遅延はより透過的になります。 ユーザーは気分を害することはありません。 彼はあなたがサーバーに行く必要があることを知っています。 ルイXケイが言ったように：「待って！ それは宇宙に飛び込みます！」とあなたは私のサイトがすぐに表示されないと文句を言いますが。







2番目の方法-ユーザーを少しだますことができます。



たとえば、1982年または1987年にMacintoshを開発した人たちは、Appleがコンピュータを手頃な価格にするために一定の価格に収まるタスクを持っていたため、ハードウェアが非常に弱かったのは確かではありません。 そして、彼らは興味深いソリューションを考え出さなければなりませんでした。







Mac OSインターフェースの最初のバージョンを設計したジェフラスキンは、次のことを思いつきました。 コンピューターがすぐにオンにならず、作業画面をすぐに表示できないことは明らかです。 そのため、画面をオフにする前の最後の状態の写真を撮影し、ディスクのゼロトラックに写真を記録し、オンにすると画面を表示しました。



なぜ機能したのですか？ 人がコンテキストを切り替えるのに数秒かかるからです。 つまり、FPSについて話すとき、プロのパイロットは270 Fpsを参照します。 しかし、人々がタスク間でコンテキストを切り替えると、何が起こっているかを理解するのに数秒かかります。



Mac OSのメンバーが写真を見せたとき、人々は見て、「ここで何かが起こり、何かが変わった」と考えました。 何が起こったかを理解している限り、実際の画面が表示されます。

このソリューションは非常に優れているため、Macでも動作します。 たとえば、macbookの電源を入れると、WI-FIインジケーターが既に完全にオンになっていることがわかります。 そして2秒後、彼はネットワークの検索を開始します。







最初の方法に続く2番目の方法は、トリミングされたスクリーンショットです。 スケルトンスクリーンと呼ばれます。 このことは、Google Imagesによって発明されました。



少し前に説明したのと同じタスクがありました。すべての写真を表示しないと、ユーザーがスクロールします。



彼らは考えました-一度にすべての写真を表示することはできませんが、写真があることをユーザーに約束することはできます。 そして、彼らは絵の大きさの灰色のブロックを描きました。 ユーザーが停止すると、実際の写真が表示されます。 ユーザーがスクロールして灰色のブロックを見たとき、彼はこれを直感的に信じています-まあ、はい、画像はロードできませんでした、これは正常です。



使用することもできます。それは良いことです。







まとめると。 サイトが遅い場合はどうすればよいですか？

• プロセッサから始めます。つまり、コンピューティングプロセスを改善します。
  
  -メモリを削減し、詰まらせないで、小さな操作を行います。
  
  -これらの計算を頻繁に行うかどうかを確認してください。
  
  -プロセッサをアンロードし、ハンサムで書けるにもかかわらず、バックエンドに複雑なアルゴリズムを与えます。
  
  
• インターフェースに正しいフィードバックを追加して、計算が行われていることをユーザーが理解できるようにしますが、これは正常です。
  
  
• そしてその後、私はあなたの記憶を最適化する上で幸運を祈ります。
  
  

---

このトピックの詳細が必要な場合は、聴衆からの質問に対するスピーカーの回答のトランスクリプトを用意しました。





また、 Frontend Conf 2017のパフォーマンスのすべてのビデオ録画へのアクセスを公開したことをお知らせします。 それらのほぼ三ダースがあります。



同時に、5月のRIT ++カンファレンスのフェスティバルでスピーカーになるようプロを招待します。 興味深い開発経験があり、それを共有する準備ができている場合は、プログラム委員会に依頼してください。