フロントエンドパフォーマンスの課題：勝者と結果
公開: 2022-03-10数週間前、私たちは読者とコミュニティに、ウェブサイトとプロジェクトを非常に高速に実行するためにできる限りのことを使用するように依頼しました。 本日、私たちはこのチャレンジの結果を披露し、実際にいくつかの大賞を授与される勝者を発表することに興奮しています！
どんな賞品をお願いしますか？ 優勝者は、ロンドンへの往復フライト、高級ホテルの宿泊施設、SmashingConf London 2018のチケット、そして最後に、選択したSmashingワークショップを獲得します。
チャレンジ？ どんな挑戦？
さて、タスクは思ったほど単純ではありませんでした。 競技者は、最終的な外観を前後で同じに保ちながら、Webサイトのパフォーマンスを改善するように求められました。 フォントの読み込みは異なることが許可されており、リフローは最小限に抑えられている限り許容されました。
幸運な勝者を選ぶ際に、LighthouseとWebPageTestによって提示された結果と、もちろん参加者が取り組んだWebサイトの複雑さを調べました。 最初の意味のあるペイントとインタラクティブになるまでの時間は、最も重要な指標でした。
しかし、今のところ十分な難しい事実。 私たちはあなたがすでに好奇心を持っていることを知っています、そして私たちはあなたをこれ以上サスペンスに保ちたくありません。 これが、受賞プロジェクトです。
そして勝者は…
レオナルド・ロソビズ
レオナルドの提出物で提示された最適化手法はすべてDIYであり、ゼロから設計および実装されています。 彼は、Webサイトを構築するためのオープンソースフレームワークであるPoPにすべての最適化を追加し、AgendaUrbanaを使用して実際のプロジェクトのパフォーマンスの向上をテストしました。
この提出物は、単一のWebサイトのパフォーマンスを向上させるだけでなく、多くのWebサイトで使用されているフレームワークを強化しようとすることで、本当に挑戦の精神に入ったと感じました。 PoPがWordPressに支えられているという事実は、LeonardoがJavaScriptフレームワークで利用可能ないくつかのことを実行できない多くの人々と同様の状況にあったことを意味しました。 彼が述べたように：
PoPはWordPressの上に構築されています。 つまり、sw-precacheを介したWebpackやService Workerを使用したコード分割など、Javascriptフレームワークで利用できる多くの革新的な最適化手法は、手の届かないところにあります（少なくとも大きな回避策はありません）。 そのため、以下で説明するすべての最適化手法はすべてDIYであり、ゼロから設計および実装されています。
彼の提出物の本質的な詳細すべてを掘り下げることに興味がある場合は、遠慮なくそうしてください。 私たちは皆、レオナルドの最適化の詳細を読むことを楽しんでおり、このエントリに費やされた膨大な量の作業のために、彼が価値のある勝者であると感じました。
すべての提出物
受け取った提出物の質に非常に満足しており、正直なところ、勝者を選ぶのは簡単ではありませんでした。 提出してくれた他のすべての人に感謝します—素晴らしい仕事を続けてください！
Jorgen Verweij
Jorgen Verweijは、彼の会社のWebサイトPerplex InternetmarketingBVの最適化されたバージョンを発表しました。 彼は、UX'er、フロントエンド、バックエンドの開発者、およびシステム管理者で構成されるチームとともに、パフォーマンスの取り組みに着手しました。
その結果、優れた実装が実現し、全体的に優れたパフォーマンス結果が得られます。SpeedIndexは、設定された目標である1250をはるかに下回り、ロード時間は1秒未満、レンダリングを0.5秒で開始、100⁄100 PageSpeedscore、ほぼ完璧なLighthouse監査を実現します。 。 以前の状況と比較して、ロード時間はほぼ8倍速くなります。 称賛！ このプロセスの詳細については、Jorgenがまとめたこの包括的な記事をご覧ください。
マルコ・ヘンステンバーグ
Marco Hengstenbergは、観光局のWebサイトLand inSichtの最適化されたバージョンを提出しました。 パフォーマンスを向上させるために、マルコはかなり多くの気の利いた小さなトリックとテクニックを使用しました。 メインスタイルシートのプリロードと、サポートしているブラウザでのプリロードを使用した重要なフォントのロードは、そのうちの2つにすぎません。 彼はまた、HTMLを可能な限りフラットでセマンティックでアクセスしやすいものに再構築し、最初の訪問時に最初に転送されるデータの量をデスクトップで約3MBから1.3MBに減らしました（ヒーロー画像にレスポンシブ画像を使用しているため、狭い画面の場合よりもさらに少なくなります）。
サイトをさらに合理化するために、MarcoはBootstrap、jQuery、Modernizrを削除し、Gruntでビルドプロセスを設定し、サイトをオフラインでも利用できるようにするServiceWorkerを導入しました。 その結果、劇的なTTLが32秒から2秒に短縮され、HTTPリクエストと転送バイト数がほぼ50％減少しました（LighthouseレポートのZIP 251KBも参照）。 プリロードとクイックイニシャルレンダリングはどちらも、知覚されるロード時間に役立ちます。 すごい仕事！
ガブリエルマリアーニ
サンディエゴクリスチャンカレッジのウェブサイトは、ガブリエルマリアーニが彼のパフォーマンススキルを適用したものでした。 彼は最適化プロセスを4つのステップに分けました。 まず、彼はすべての画像を実際に必要な最大サイズにトリミングし、モバイルスケールのバージョンを作成しました。 次に、すべての画像を遅延読み込みしました。 2番目のステップは、JavaScriptに焦点を当て、WordPressサイトとそのサードパーティのテーマおよびプラグインに付属していたすべてのインラインスクリプトを削除しました。 次に、Autoptimizeがスクリプトを取得し、それらを1つのファイルに縮小/結合できるように、できるだけ多くのスクリプトをキューに入れました。
Gabrielはまた、使用されているフォントの数を減らし、クリティカルパスCSSが最初に読み込まれるようにGoogleフォントをasyncで読み込むように設定しました。 最後に大事なことを言い忘れましたが、彼は他の小さなオッズに取り組み、WordPressプラグインのカスタマイズのように終わりました。そのため、PHPではなくajaxに依存しています。 これにより、彼はページキャッシュを有効にし、最終的にサイトのCDNを有効にすることができました。 HTTP / 2とHTTPSへの切り替えが最後のステップでした。 完全な結果については、WebPageTestを参照してください。 良い！
アレクサンダー・ザルゲス
Alexander Zargesは、Angular4に基づく単一ページのWebアプリケーションであるCloudPlayerを開発しました。これにより、YouTubeおよびSoundCloudアプリを検索して再生できます。 アップグレードされたバージョンは、Angular事前コンパイラーを使用して、約2.9秒の初期化時間を実現します（ジャストインタイムコンパイラーを使用する場合の5.2秒と比較して）。 コードをさらに深く掘り下げたい場合は、付属のGitHubリポジトリを確認してください。
ブラッドリー挑発
Bradley Tauntは、彼の個人的なサイトを試す機会として私たちの挑戦をしました。 彼の最適化事業の基礎として、彼は彼のホームページと画像の多い記事を使用しました。 記事の読み込み時間を4.2秒に短縮するために、Bradleyは、特にWebフォントを使用する代わりに、デフォルトでユーザーのOSシステムフォントを使用します。
さらにブーストするために、最適化されたバージョンは重要なCSSをインライン化し、レスポンシブイメージを提供し、CDNキャッシングを利用します。 ブラッドリーがどのように挑戦に取り組んだかについて書いたブログ投稿で、舞台裏のより詳細な外観を得ることができます。
ジョン・ビールス
John Bealesは、4RoadService.comのパフォーマンスを向上させることに挑戦しました。 彼が始めたとき、すでにいくつかの最適化が行われていました。 静的画像はImageOptimを介して実行されました。たとえば、CSSとJSは縮小され、CloudFlareを介してCDNを実行し、サイトはすでにシングルページアプリスタイルのローダーを使用しているため、新しいコンテンツは常にXHRによってフェッチされ、ページは完全に再描画されることはありません。
この課題のために、ジョンはCloudflareで画像最適化とWebP圧縮をオンにしました。 更新されたサイトは、HTTP / 2サーバープッシュを使用して、最初のページロードでメインのCSSファイルとJSファイルを送信し、JPEG圧縮をGuetzliに依存しています。 キャッシュを最適化するために、彼はすべての静的アセットのURLを更新して、アセットが変更されるたびにURLが変更されるようにしてから、すべての静的アセットを1年間キャッシュするように設定しました。 画像のキャッシュを改善するために、Johnは動的にサイズ変更された画像のURLも更新したため、CloudFlareはそれらが静的な画像ファイルであると見なします。
結果：最初の意味のあるペイントは2,220msから1,290msに、最初のインタラクティブは5,480msから3,040msに減少しました。 ライトボックスとウェブページのテスト結果の全文はこちらでご覧いただけます。
ショーン・オコンネル
Shaun O'Connelのエントリーは、彼がkiwi.ruby.nzで行った作業でした。 目的は、会議のWebサイトをPWAに変えて、会議の参加者がイベントに関するすべての情報をオフラインで検索できるようにすることでした。 彼が行ったことのいくつか：典型的なGoogle MapsiframeをGoogleStatic Mapsに置き換える、サブセットフォントをセルフホスティングする、CSSをインラインに移動して最初のリクエストを14KB未満に保つ、依存関係を削除する、プリキャッシュService Workerを追加する、snappyのTurbolinksを追加するページ遷移。 そうすることで、初期レンダリング時間が3.9秒から0.3秒に短縮されました。
詳細については、WebPageTestsを確認してください。
Ruslan Julbarissow
RuslanJulbarissowは彼の個人ウェブサイトzerofy.deを提出しました。 コンテストが公開される直前に最適化作業を終えたため、残念ながら結果の前に詳細はありませんが、Ruslanは、微調整によってページサイズが1.6KB、TTFBが197msになった経緯を詳しく説明しています。 キャッシュ、ミニファイ、GZIP、jQueryの調整とは別に、レンダリングのブロックを回避するために後でフォントをロードし、FontAwesomeをカスタマイズされた10個のアイコンのIcoMoonセットに置き換えることで、さらに130KBを節約できました。
スピードインデックススコアを上げ、可能な限り最速のエクスペリエンスを得るために、彼はまた、折り畳み上のビューに影響を与えるすべてのCSSスタイルを含む別のPHPファイルを作成しました。 詳細：小さなスクリプトBarba.jsを使用すると、サイト全体をリロードせずにページ遷移を作成できます。
参加してくださった皆様、ありがとうございました
ふぅ！ さて、それは確かにかなりの挑戦でした！ このような良い挑戦を楽しんでいて、時々脳をくすぐる人のために、次の挑戦にご期待ください。 私たちはすぐに別のものを思い付くでしょう—それは確かです！