(jp) =
<!–
–>
今日は、Web パフォーマンスについて調べます。 このトピックに関する専門的な経験が豊富な人々によって書かれた記事やチュートリアルへの便利なリンクをいくつか紹介します。 私は、この知識の一部を実践した開発者の観点から書いています。 私はその過程でいくつかの教訓を学びました。あなたもそこから学ぶことができます。
連絡を取りたい、パフォーマンスについて話したい、またはこの投稿に追加したい場合は、いつでもメールで連絡できます。
これ以上苦労することなく、Web パフォーマンスの神秘的なテーマに飛び込みましょう。 パフォーマンスの高い Web サイトを構築する際に持つべき考え方について説明します。 次に、多くの実用的な例と、他の学習リソースへのリンクに進みます。
# パフォーマンスの考え方
この投稿から 1 つ学ぶべきことがあるとすれば、それはすべての Web 開発者が持つべき考え方です。 業界は、開発者の生活を楽にするツール、フレームワーク、およびシステムを構築しています。 その間ずっと、Web 開発とは実際には何なのかを忘れています。 私たちはもはや職人技の芸術作品を作っていません (たぶん、そうではなかったのでしょうか?)。 私たちは通常、迅速な開発と迅速な結果を目指しています。 最終的に重要なこと、つまりウェブサイトとその訪問者を忘れています。
この投稿は、その考え方を持つ人々を対象としています。 最高の開発者になりたい人。 より良い最終結果を得るために、常に自分を次のレベルに押し上げます。 これに関連する Web 開発者であれば、パフォーマンスを理解することは、構築すべき最も重要な柱の 1 つです。
この投稿の哲学的な部分は以上です。 もちろん、私はITの世界のビジネス面を完全に無視しています。 ここでは、お金、時間、範囲について話しているのではありません。 私は、自分の開発スキルを向上させて、その知識と経験を余暇のプロジェクトや実際のクライアントや仕事に活用できるようにすることについて話している.
# ウェブの基本: HTML
Web パフォーマンスを理解して改善するための重要な要素の 1 つは、ブラウザーが HTML をレンダリングする方法を知ることです。 想像以上に多くのことがあり、これらの手順を理解することで、独自のコードについてまったく別の方法で推論できるようになります。 Google には、このトピックに関する最高のクラッシュ コースがあります: https://developers.google.com/web/fundamentals/performance/。
理解すべきもう 1 つの重要な概念は、静的 HTML ページです。 最終的に、それらはユーザーに提供されるものです。 ユーザーが結果を待っている間、その場でページを生成する必要はありません。 動的な Web サイトは、開発を容易にするためにユーザーの時間を浪費します。 動的な Web サイトが悪いと言っているわけではありません。 私が言いたいのは、すべての動的システムは、要求/応答サイクルから動的フェーズを排除するためのテクノロジーを導入する必要があるということです。 そのトピックについては後で詳しく説明します。 実際の静的 Web サイトに興味がある場合は、https://staticgen.com で、ニーズに合った適切なツールを見つけることができます。
レスポンシブ画像への移行: 帯域幅の使用に関しては、おそらく一番の最適化です。 レスポンシブ画像の仕様は、大きな画像の問題に対処したり、JavaScript の回避策をブロックしたりするように設計されています。 これは完全に下位互換性があり (Edge と話している)、Web サイトの読み込み時間を改善する可能性が高いです: https://responsiveimages.org.
# バックエンド開発
動的 Web サイトについては、前のセクションで既に説明しました。 もちろん、それらは現代の Web では必須です。 ただし、オンザフライでレンダリングする必要があるページと、キャッシュ可能なページを検討する必要があります。 サーバー側で可能なキャッシングのレイヤーは多数あります。 たとえば、次のように説明します。 この投稿の後半でキャッシュをニスにします。 バックエンド コードのキャッシュは、使用している言語とフレームワークの種類に大きく依存します。 キャッシングについて言及すべき最も重要なことは、キャッシュをアプリケーションの「最上位」のレイヤーと見なしてはならないということです。 これは、作成するすべてのコードの不可欠な部分である必要があります。
PHP 開発者として、私はすべての PHP Web アプリケーションが通過する厳密な要求/応答ライフサイクルに慣れています。 Web アプリケーションに同じロジックを提供する言語は他にもたくさんあります。 このアプローチは非常に簡単に理解できますが、リクエストごとにアプリケーションをゼロからブートストラップする必要があることを意味します。 ReactPHP や AMP などのライブラリは、開発者が単一のブートストラップ アプリケーションから複数のリクエストを処理できるようにすることで、この問題に対処しています。 非同期および並列アプリケーションは、最初は複雑さが増し、理解するのが非常に難しい場合があります。 しかし、これは応答時間が大幅に短縮されることを意味する可能性があります。
＃ サーバ側
キャッシュの話題に戻ると、サーバー側でできることはたくさんあります。 まず第一に、必ず実装すべきキャッシング ヘッダーがあります: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control。
次に、すぐに提供できるコンテンツを提供する必要があります。 実サーバーの前で CDN と Varnish を使用します。 このようにして、以前に生成された画像やコンテンツ ページなどをすぐに提供できます。 Varnish のようないわゆる「プロキシ」を使用することの危険性の 1 つは、多くの開発者がそれを「自分のアプリケーションの上にあるレイヤー」と見なす可能性があることです。 実際には、独自のアプリケーション内から Varnish と多くの通信を行う必要があります。 Varnish の詳細については、https://varnish-cache.org を参照してください。
独自のサーバーのメリットは? これは あなたのサーバー. 使用および利用可能なリソースを制御できます。 サーバーに処理させることができる場合は、クライアントに余分な負荷をかけないでください。 もちろん、これはリソースに関する非常に単純化された考え方です。 ただし、クライアントが使用しているハードウェアを制御できない場合でも、サーバーのハードウェアをアップグレードすることは常に可能です。
最後に、まだ HTTP/2 を実装していない場合は、HTTP/2 を実装してください! なぜかわからない？ https://sitepoint.com/what-is-http2.
# フロントエンド開発
免責事項: 私はバックエンド Web 開発者です。 私は CSS と JavaScript のコードをたくさん書いてきましたし、今でも書いていますが、フロントエンド Web 開発に関しては決してプロではありません。 したがって、常識と推論だけを使用して、パフォーマンス向上のいくつかの概念を共有します。
ページが本当に必要とするリソースは何かを考える必要があります。 その特定のページが 100 キロバイトの CSS のうち 5 キロバイトしか必要としない場合は、残りの 95 キロバイトをロードしないでください。 JavaScript についても同様です。
また、少なくとも HTTP/2 サーバー プッシュがまだ主流になっていない間は、HTML ページの重要なリソースをインライン化することも検討してください。
ここから行くには、Tim Kadlec のブログ (https://timkadlec.com) が適しています。
＃ 要約すれば
- パフォーマンスを第一に考えてください。
- HTML がどのように読み込まれ、レンダリングされるかを理解します。
- すぐに提供できるコンテンツを提供します。
- 必要のないときにオンザフライで動的にレンダリングして、ユーザーの時間を無駄にしないでください。
- サーバー側の要求/応答サイクルを改善します。
- クライアントではなく、サーバーに負荷をかけます。
- キャッシングを最上位のレイヤーとしてではなく、アプリケーションの統合された部分として考えてください。
- ブラウザのキャッシュ ヘッダーを設定し、CDN を使用して、Varnish を調べてください。
- そのページで 10% しか必要ない場合は、縮小された CSS または JS をすべて読み込まないでください。
考えることがたくさん。 これは、私がウェブサイトを開発する際に、専門的にも余暇にも心に留めておくべき個人的なチェックリストです。 この投稿の冒頭で述べたように、理由だけで常にすべてを実行する必要はありません。 ただし、これらの概念を理解し、いつ使用するのが適切かを知っておく必要があります。 そうすることで、ウェブの改善に貢献できます。
//platform.twitter.com/widgets.js