Vitaly FriedmanでWebを最適化します：ダウンロード速度、メモリ、CPU

これは、フロントエンド開発におけるあらゆる種類のトリックに関する2番目の投稿です。 サイトの最適化、RAMが不十分でCPUが遅いデバイスでの読み込み速度の問題に対処します。



サイトとそれに接続されているサードパーティ製アプリケーションの作業を高速化し、制御するのに役立つツールについての個別の会話。 さらに、メールニュースレターのレイアウトの機能についてのストーリーもあります。







この資料は、 HolyJS 2018 PiterカンファレンスからのVitalyのレポートの転写に基づいています。



最初の部分は次のとおりです。VitaliyFridmanでWebを最適化します-圧縮、写真、フォント、機能HTTP / 2およびリソースヒント 。

第二部：

マスタードとスローデバイス

このパートでは、パフォーマンスに焦点を当てます。 増やす方法は？ しばらくの間、「マスタードを切る」手法を使用しました。 その本質は、スニペットの助けを借りて、古いブラウザと新しいブラウザのどちらを扱っているかを調べることです。 これに応じて、不必要な機能を使用してロードしないように、ロードするスクリプトとスタイルが決定されました。









ブラウザー定義のスニペットの例









その後、querySelector、localStorage、addEventListenerのシーケンスを可視性状態APIに置き換えることが可能になりました。これは基本的に小さなプロジェクトで行ったことです。 しかし、このテクニックには問題がありました-あなたが使用するものを含む他のすべてのテクニックで起こるのと同じです。



問題は、新しいブラウザに美しいスタイルを与えたいとき、それがどれだけうまく表示されるかわからないということです。それは、それが実行されているデバイスに依存するからです。 実際には、RAMが少なく、プロセッサが弱いローエンドセグメント（Motorola Moto G4など）のデバイスがあります。 しかし、彼らは私たちが持っている技術のすべて（またはほとんどすべて）をサポートする新しいブラウザがインストールされています。



したがって、この手法を今日使用することはできなくなりました。

Moto G4をポケットに入れてGoogleをフォロー

レスポンシブレイアウトを、ハードウェアリソースの観点から「プル」するデバイスにのみ表示しないのはなぜですか。 このために、Device Memory APIを使用できます。 このAPIが利用できない場合は、「マスタードを切る」にロールバックできます。



そして、ここにMoto G4自体があります：









次の図では、javascriptが解析される時間の基準によって、電話のランキングでMoto G4がどこにあるかを確認できます。 これは平均です-そして、そのような携帯電話がたくさんあります。 評価のリーダーと比較して、この携帯電話は解析に16倍の時間が必要です。







携帯電話のサイトのデータを見ると、ほとんどの時間がJSの解析に費やされていることがわかります。





黄色はページ解析時間を示します



実際、これは非常に大きな問題です。 1メガバイトのスクリプトをパークするために、Moto G4は35秒かかります。 ほとんどのサイトがサイト上のスクリプト全体の40％しか使用していないことを考えると、解析の時間を短縮するためにこの状況から抜け出す方法を見つけることができます。 たとえば、Gmailでは、すべてのコードにコメントを付けてテキスト変数として送信し、このコードが必要になったときにこの変数はevalでした。



Googleは、いわゆる対話型予算までの時間（ほとんどのユーザーがサイトと対話する機会を待つ時間）を設けることを推奨しています-これはわずか5秒です。 1.6秒がネットワークインタラクションに費やされることを考慮すると、残りはわずか3.4秒です。つまり、平均接続速度400kbpsを使用すると、この間に最大170KBのデータを送信できます。 これは、すぐに使用するのに適したものを送信するのにそれほど多くありません。 これにはフレームワーク、ユーティリティ、クリティカルパス、js、css、htmlが含まれるため、このデータ量は非常に少ないです。







アプリケーションのコアを170 KBに収める方法は？ Googleは、使用可能なさまざまなメトリックを推奨しています。時間ごとに負荷を段階に分けています。最初のバイトまでの時間（ナビゲーションが開始）-最初のバイトが送信される前、最初のペイント-最初の画像がロードされるまで、最初のコンテンツペイント-サイトにナビゲーションが表示されるまで、最初の意味のあるペイント-ほとんどすべてがコンテンツの準備ができて、視覚的に準備ができている-ページ全体をロードする前に、インタラクティブになるまで-ページとやり取りできるようになるまで、完全にロードされた-ページが完全に準備ができたとき







一般に、このようなメトリックは各サイトに特別なものになるため、プロジェクト用に独自のメトリックを作成する必要もあります。 それでは、今日の最適なパフォーマンスベースラインはどのようなものでしょうか？







この画像は、メトリックを開発するときに考慮すべき側面と目標を示しています。

ダウンロード速度を上げる方法は？

読み込み時間の戦いで使用すると便利なものは何ですか？ たとえば、コードカバレッジツール-ページコードのカバレッジを監視します。 また、使用されていないコードの割合も示します。





JavaScriptバンドル監査を引き続き使用できます。 3番目のライブラリを使用する場合、たとえばwebpack-libs-optimizationsを使用してランタイムから削除できます。 そして、もちろん、gifを放棄する必要があります。 ビデオコンテナ自体の解析にも時間がかかるため、ビデオを拒否することができます。 ビデオを拒否できない場合は、< img src



>コンテナーを使用して配置します。



ページにレスポンシブ画像がある場合でも、レスポンシブ画像ブレークポイントジェネレーターを使用できます。 レスポンシブレイアウト用のレスポンシブ画像または画像のグループから画像を生成するのに役立ちます。 ジェネレーターエンジンを使用して、写真が必要なキロバイト数を指定できます。 また、ツールはサイト上でマークアップ自体を生成します。







画像に重要な部分（顔やオブジェクトなど）がある場合、必要に応じて切り抜きが行われるため、非常に便利です。



たくさんの写真があるとしましょう。 その後、LazySizesの助けに頼ることができます。 これは、前のツールと同じことを行いますが、JavaScriptのみを使用するライブラリです。







解析が行われるときの時間の経過を確認できます。

興味深いツールは優先順位のヒントです。このツールでは、ブラウザに何を早くダウンロードすることが重要で、何を後でダウンロードするかを尋ねることができます。



しかし、重要なCSSをどうするか？ 適切なサーバーとCDNがあれば、ブラウザはHTTP / 1であれば別の接続を開こうとします。 また、HTTP / 2の場合、どのCSSが必要で、どのCSSが必要でないかを「推測」しようとします。 したがって、重要なCSSバージョンがどのように機能するか、および重要なCSSがルートに別のファイルとして保存されている場合は、どのようにテストするのが価値があります。

Guess.js

はい、webpack、バンドル、チャンクがあります。 しかし、予測アルゴリズムと機械学習の助けを借りて、ユーザーインタラクションの次の反復でどのチャンクが必要になるかを予測するのに役立つツールがあるとしたらどうでしょうか。 Googleアナリティクスデータに基づく予測分析の助けを借りてGuess.jsは、ユーザーが次に実行するアクションを理解し、この対話に必要なコードを正確にダウンロードできます。



Webpack用のGuessプラグインを試してみてください。







これらはすべてグローバルレベルで発生します。ユーザーだけでなく開発者の生活を改善できる機械学習と人工知能に基づくサービスがますます増えています。 このようなツールは、たとえばAirbnb：air / shotsにあり、この会社の設計者と開発者が使用できる検索エンジンです。 その中で、タグでコンポーネントを見つけ、それらの接続を監視し、プロジェクトに必要なものを選択できます。



デザイナーにとっての機能は非常に印象的です。デザイナーは紙にスケッチを描き、それをカメラに持ち込み、事前に設計されたコンポーネントから必要なインターフェースが自動的に設計されます。 作業はほぼ完全に自動化されています。







もう1つのヒント：開発用のフレームワークを慎重に選択します。 次のことを考慮する必要があるとします：ネットワーク転送、解析/コンパイル、実行時コスト。 もちろん、このためのツールもあります。たとえば、2G、3G、Wi-Fiなど、さまざまなデータネットワークでアプリケーションがどのように機能するかをテストできます。



問題は、もちろん、HTTP / 2は良い新しい標準ですが、HTTP / 1よりも常に高速であるということです。2番目に、特にモバイルデバイスの場合、低速接続では非常に低速です。 もう1つの問題はサーバープッシュです。サーバープッシュがある場合、重要なCSSの理想的な代替品になります。 この場合、index.htmlを要求するユーザーはcritical.cssアペンデージで取得します。 しかし、サーバーにページを要求するとすぐに、後者は既にキャッシュ内にあるかどうかを常に知るとは限りません。



したがって、キャッシュダイジェストと呼ばれるメカニズムが開発されています。初めてページにアクセスした場合、サーバープッシュが発生します。 これがページへの最初の訪問ではない場合、サーバーは引き続きプッシュします。 これは、QUICを使用して修正することをGoogleが決定した問題です。 これはHTTPを介したアドオンであり、メカニズムをより思慮深くするものであり、UDPプロトコルでTCPの代わりに機能します。







QUICには多くの興味深い点があります。4Gの高速接続では高速です。 同時に、接続が遅い場合は遅くなります。 さらに、UDPを使用するため、JavaScriptの場合は大きなCPUリソースが必要です。 これは次の画像を反映しています。

サービス労働者

たぶん彼らは私たちを助けることができますか？ 統計から判断すると、キャッシングに使用すると、具体的なパフォーマンスが向上します。 1つ目はフォントの最適化、2つ目はサービスワーカーのカスタマイズです。







Service Workerを作成する方法は？ PWA Builderを使用できます。アプリケーションをより進歩的にするためのアイコンとマニフェストも生成します。







PWAの使用に関するさまざまなストーリーや事例を収集する素晴らしいPWA Statsサイトがあります。

サードパーティのスクリプト-悪への一歩？

サードパーティのスクリプトをサイトにインストールした場合、パフォーマンスを改善する意味はありますか？サイドから追加のスクリプトをロードし、最終的にユーザーのデバイスを過負荷にしましたか？









これらのスクリプトが収集するデータもわかりません。 彼らはページの読み込み間で変更できる動的リソースを読み込むことができます。 したがって、サードパーティのアプリケーションが使用するホストもリソースも不明です。 また、スクリプトタグに読み込むと、サイト上のすべての情報にアクセスできます。



この情報を見つけるために、リクエストマップツールがあります。







リクエストの送信先が表示され、これらのリクエストに割り当てられているリソースを確認できます。 サードパーティのスクリプトがデバイスのCPUを使用してビットコインをマイニングしていることが判明した場合、特に驚くでしょう。 サプライズ！



Chromeは、独自の広告ブロッカーで不公平な広告をブロックしようとします。 最高の広告連合に基づいています。



GDPRのようなものもあります-個人データの処理に関する合意。 サイトのオーディエンスにヨーロッパ人がいる場合、個人データの処理に関する合意を遵守し、要求に応じてそれらを削除し、保存する各Cookieを説明する必要があると述べています。 サードパーティのスクリプトがこの契約に違反し、問題が発生した場合-あなたは応答し、責任を負います。



では、サードパーティのスクリプトを見ていないときに、サードパーティのスクリプトが何をしているのかをどのように理解していますか？ ツールを使用してそれらを制御します。たとえば、requestmap.webperf.toolsを使用して、サイトおよびサードパーティのスクリプトを監査できます。 後で統計情報をIDで確認できます：requestmap.webperf.tools/render/[ID]



以下のページには、レポートを含むCSVファイルをダウンロードするためのリンクがあります。







その後、ターミナルを介してデータを解析できます。







また、Webページのテストブロックに挿入する必要のあるコードを取得し、サードパーティのスクリプトを使用するアプリケーションと使用しないアプリケーションのパフォーマンスの違いを測定します。 違いは明らかです。 これは、それらを削除する必要があるという意味ではありません。 それらを最適化する方法を理解する必要があります。



いつものように、このためのツールもあります。 このCSVをExcelに挿入すると、使用しているサードパーティアプリケーション、それらの重量、ロード量のかなり詳細な概要を取得できます。 さらに興味深いのは、ブラックホールサーバーであるIPを試すことです。







すべてのサードパーティアプリケーションがタイムアウトになった場合のアプリケーションの動作を調べるには、このIPをhostsファイルに追加して、アプリケーションに何が起こるかを確認します。







もう1つのヒント：scriptタグを使用してサードパーティのスクリプトを追加しないでください。 iframeを介してこれを行うことをお勧めします。iframeを使用すると、ページ上のDOMにアクセスできなくなるためです。 ところで、iframeにはサンドボックスプロパティがあり、ページ上のスクリプトで実行できることとできないことを指定できます。 セーフフレーム仕様も作成されました。これは、外部スクリプトがアプリケーションデータから分離され、そのアクティビティが監視されていることを示しています。 このトピックに興味がある場合は、セーフフレームプロジェクトであるgithubで情報を入手できます。







サービスワーカーを使用して、フリーズしたサードパーティのスクリプトをブロックまたは削除します。



Intersection Observerを使用すると、広告がビューポートの隣に表示されたかどうかを確認できます。 これにより、ユーザーがページを表示しているときに広告ユニットに近づいたときに、広告ユニットを読み込むことができます。 広告ユニットまでの距離はピクセル単位で指定できます。



それについては、Denis Mishunovの記事「Now You See Mee：How to Defer、Lazy-Load and Act with Intersection Observer」、Harry Roberts 「It's My（Third）Party、and I Cry if I want to I」で読むことができますYoav Weiss「サードパーティのコンテンツの制御を取り戻す」。

レスポンシブメール

メールニュースレターのレイアウトには、独自の特性とルールがあります。 文字で写真を表示しないクライアントのImgタグは、何かを変更する必要があるため、alt属性およびその他のブラックマジックが使用されます。







通常のレターのレイアウトでは、table-header-group、table-footer-group、およびその他のテーブル属性が使用されます。 しかし、メディアクエリなど、何か新しいものが必要な場合はどうでしょうか。一部のブラウザではまだサポートされていますが、メールクライアントのモバイルバージョンでは事態はさらに悪化します。 使用する場合：









そのような魔法の例を次に示します。









ボックスクラスの最終的な値は？ 仕様によると、状況によって異なります。width-valueがmax-widthよりも大きい場合、max-widthが優先されます。



ただし、min-widthがwidthまたはmax-widthより大きい場合、min-widthが適用されます。



これは、メディアクエリがサポートされていない場合に使用できます。 例は次のとおりです。モバイルで4列のうち2列を作成する方法は？ 答えは：







大まかに言えば、幅の値は、最大幅または最小幅のどちらが勝つかを決定します。 これは素晴らしいハックです！



インタラクティブな手紙を作る方法は？ たとえば、そこにライブTwitterフィードを追加します。 はい、可能です！ 2秒ごとにサーバー上で生成されるすべてのツイートを含む画像があり、それをアニメーション化するだけです。 これが解決策です。



注文全体と製品選択を費やすことができるインタラクティブな電子メールを作成する方法は？ 画像を見ると理解できます：







ラベル、チェック、およびinput'ahに関連付けられたロジック。 かなり長いチェーンになりますが、それでも可能です。 使用されている要素の統計情報の例を次に示します。 価格はカウンターと増分でも考慮されます：







それは素晴らしいように思えますが、電子メールを介して人を購入に導くことができることがわかります。 しかし、すべてがそれほど単純なわけではありません。メールでは文字数（12000）に制限があり、サポート：チェックされており、メッセージサイズは102kbに制限されています。



それにもかかわらず、これらは今日のマーケティングの主な傾向であり、これはグラフで見ることができます：







それが、GoogleがAMPを作成した理由です。 希望に応じて、レターに必要なマークアップを自動的に生成する必要があります。

可変フォント

ローレンス・ペニーはこのテーマについて有用なプレゼンテーションを行っています 。必ず見てください 。



フォント仕様を書いた人の一人、Hakon Wium Lieのコメントを以下に示します。









これは次のように聞こえます。「将来的に中間値をサポートする際に（フォントウェイト値の仕様で）3桁の数字を使用することを選択した理由の1つ。 そして、未来はすでに来ています。」



アジアのフォントに関する非常に大きな問題：全体的な多数の文字とそれらの異なるスタイルを考えると。 象形文字に異なるフォントをロードすると、パフォーマンスの大きな問題になる可能性があります。 幸いなことに、仕様を書いた人が話した3桁の値の1つだけを指定できる反復可能なフォントがあります。







デザイナーは、2つのスタイルのシンボルを作成するだけで十分です-非常に太く、値が1000で、非常に細い、値が1です。他のすべてのスタイルは、必要に応じて自動的に作成されます。 ただし、これは幅軸だけでなく、高さでも機能します。







もう一つの驚き：私たちは多くの困難なく自分で車軸を作成できます。 これを行うには、CSSのfont-variation-settingsプロパティを使用します。 font-weight、font-stretchなどの高レベルプロパティの値を設定します。







フォントデザイナーが目的のフォントを設定する例を次に示します。







しかし、どこかでサポートされていない場合はどうなりますか？ 古いバージョンのブラウザでは、いくつかのフォント形式を使用し、ロールバックを処理し、レスポンシブ動作を考慮する必要があります-さまざまな画面に値を正しく設定します。 したがって、フォントにはWOFF2形式を使用し、より進歩的です。 古いバージョンの場合、ブラウザは目的のフォント自体を選択しますが、これはスタイルを制御できないことを意味します。

要約する

要約すると、仕様は以前よりもはるかに速く受け入れられたと言えます。 2か月が経過し、新しい標準、アプローチ、アプリケーションが登場します。 しかし、これは当然のことであり、当然のことながら、さらに発展する機会です。

レポートが気に入った場合は、注意してください。11月24〜25日に、新しいHolyJSがモスクワで開催されます。また、興味深いことがたくさんあります。 プログラムに関する既知の情報はサイトにあり、 チケットはそこで購入できます。