ChromeTweetこちらのブログではご無沙汰しています。Summitに参加させていただいていました。Insightsなど、例年にも増して盛りだくさんの発表が行われましたが、特に「スピードの改善テクニック」が数多く披露されたように思います。Summitのプレゼンテーションはすべて濃厚で、しかも多くの内容は「web.dev」に詳しく説明されています。ここでは、2日間にわたって行われたセッションを振り返りながら、高速化に関する内容をざっくりと追っていきたいと思います。70で、WebAseemblyがマルチスレッド対応にビデオ用次世代コーデック「AV1」と画像フォーマット「WebP」Webサイトの容量の大半は、画像・フォント・JavaScriptが占めます。これらのファイルサイズをどう削減するかが、Webサイトの高速化にとって重要だということです。アニメーションGIFは非常に効率が悪く、お薦めできません。そのアニメーションGIFを動画(mp4形式)に変換するだけで、たとえば6.8MBあったものは420KBまで圧縮できます。動画の圧縮フォーマットとして、AV1コーデックを用いると、x264と比較しても40〜50%の圧縮を実現されます。Firefoxで利用可能)。この場合、非対応ブラウザーと組み合わせるために、下記のように<picture>タグを利用します。旧ブラウザにおいては、<img>タグの内容が解釈される仕組みです。src="image.jpg"></picture>Webフォントも読み込み時間が長くなる要因の一つです。その対策として、font-displayというCSSプロパティが登場しました。swapと指定した場合、カスタムフォントを読み込まれるまでは、システムのフォントが代わりに表示されるようになります。swap;}font-displayプロパティは、現状Firefox/Chrome/Safariで対応されています。Houdini(動画より)CSSの機能をJavaScriptで拡張できるようにするための仕組みです。OMといった複数の機能から構成されています。APIを用いると、これまでCSSでは表現できなかった描画(たとえば角丸以外のボーダーを持つオブジェクト)を、JavaScriptで描画することができます。Houdiniの実装状況は、こちらのWebサイトから確認できます。Chromeだけでなく、SafariやFirefoxでも開発が進んでいるようです。Loading画像などのリソースを読み込む時間を遅延するかどうかを、lazyload属性を用いてブラウザーに指示することができるようになります。画像とIFRAMEに対して適用できます。lazyload="on">とすると、ブラウザーは実際にそのコンテンツを表示する必要があるまで、画像ロードは行われません。デフォルトは「auto」、よってブラウザーが遅延読み込みを行うかどうかを判断します。要するに、この機能が組み込まれたブラウザーの場合、何もしなくても勝手に遅延読み込みが有効になるようです。(動画より)Preloadingプリロードを用いると、画像やスクリプトなどのリソースを前もってロードすることができます。これにより、例えば次以降のページで必要なアセットを前もって取得しておき、ページ表示速度を高速化することが簡単に実現します。プリロードを設定するには、<link>タグを使用します。rel="preload"属性を使用して、下記の通り記述します。as="script">この機能はChrome/Safari/Edge(一部サポート)で利用できます。Workerを用いなくても、コンテンツのプリフェッチが簡単に実現できますね。Pages)の仕組みにより、たとえばGoogleの検索結果から次のページへの遷移速度を向上させることができるようになりました。この仕組みはGoogleドメイン上で遷移先のページを表示する必要があるため、URLが二重に表示されたり、セキュリティ上の懸念につながってしまいます。Packagingという仕組みを用いると、Webサイトの正当性を担保することで、ブラウザーがコンテンツをプリフェッチし、キャッシュさせることが可能になります。Worker(V8の単位でエッジサーバーで動作させる技術)」を用いてWebパッケージが作成されていました。一つの仕組みとして、IFRAMEに似た「Portal」という仕組みが紹介されました。これは、<portal>というタグを用いて実現されるもので、IFRAMEと同様にページ内に別サイトを組み込める仕組みです。IFRAMEとは異なり、そのコンテンツに遷移する際に、モーフィングアニメーションが表示されます。これにより、ネイティブアプリのような画面トランジションをWebサイト間で表現できます。具体的なデモでは、「となりのヤングジャンプ」と「はてな」による漫画ビューアーが紹介されていました。上に挙げたような施策を、実際にWebサイトに対して適用した事例が、いくつも紹介されました。ここでは、Pinterest、Spotify、StarbucksといったメジャーなWebサイトの改善事例、そしてSquooshというGoogleがデモンストレーション目的で開発したツールについて、その内容を紹介します。PinterestモバイルWebを一から作り直した(その作業は3ヶ月しかかからなかったそうです)。その結果、起動速度が4倍高速化(以前21.2秒だったのが5.6秒に)したとのこと。ServiceWorkerを用いたプリフェッチを行い、これまで23秒かったところが3.9秒まで削減。具体的な数字として、JavaScriptのサイズは、650kbから200kbまで削減できたそうです。Budgetの可視化が重要。Budgetを自動的に測定する仕組みを導入し、開発プロセスに組み込まれています。Spotify1年前(2017年)のSpotifyにはモバイルWeb版がなく、音楽を聞くにはネイティブアプリのダウンロードが必要な状態でした。ブラジルなどの新興国では、モバイル端末のスペックが低く、端末の容量が限られているため、アプリダウンロードのハードルが高い。1曲聞きたいだけなのに、何MBもするアプリをダウンロードしたくない、という反応が多かったそうで、A/Bテストを実施しながら、ユーザーの反応を見ていきました。最初の実験として、アプリのダウンロードを行う前に、1曲だけWeb経由で聴ける仕組みを導入しています。すると、初日再生率は25%向上されました。そこで、次の実験として、モバイルWebプレイヤーを組み込んだWebサイトとそうでないWebサイトの2種類に分離し、ユーザーの反応を確かめました。すると、モバイルWebプレイヤーを組み込んだ場合、初日再生率は54%向上したそうです。APIやPWA対応が行われておりますが、ブラウザーにコンテンツ保護機能が加わったことも重要だったということでした。Starbucks2017年にPWA版をリリースしています。WorkboxやIndexedDBを用いた高速化で、従来よりも2倍の速度を実現されました。APIを用いてログインの仕組みをスムーズになっています。アプリはReactベースで作られています。デスクトップ用WebサイトもPWA対応されており、実際にWebオーダーの25%はデスクトップから行われてるようになりました。Assembly、WebWorkersなどをフルに活用して開発した画像圧縮サイトです。GitHubで公開されており、Chromeだけでなく、Edge/Safari/Firefoxでも動作します。圧縮コーデックであるC/C++のライブラリはEmscriptenを用いてWebAssemblyに変換されています。CPUコストの高い圧縮機能は、WebWorkersを用いてUIスレッドと分離し、画像圧縮中でもスムーズな描画ができるよう配慮されています。Webサイトは完全なPWA実装となっており、モバイルやタブレットでも動作します。2018では、PWA(そしてPWAの真髄であるネイティブ並みのパフォーマンス体験)を具体的に実現するためのノウハウやテクノロジーが余すことなく紹介されたように思います。ブラウザーに対する機能強化が、ペースダウンすることなく進んでいることが印象に残りました。一方で、たとえばHoudiniがEvergreen化された場合にCSS3・SVG・WebGL・Canvasとの棲み分けはどうしたらいいのか、より巨大化するブラウザーのランタイムは全体性能を低下させているのではないか、などの疑問も生まれそうです。~SPAおよびPW...こんにちは、アシアルの塚田です。先月に東京のITS大久保健保会...2019-03-11人工知能を用いてWebサイトのテストを自動化するお久しぶりです、田中です。Progres...明けましておめでとうございます。Project(Vuejsで始めるPW...皆さん、こんにちは!エリスです。byスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。