CSSとJS技術の結合/連結は非推奨と見なされていますか？
Googleは、Webマスターに外部CSSファイルとJSファイルを組み合わせてページ速度を向上させることを推奨していました。これらのページの1つはここにありました： https://developers.google.com/speed/docs/best-practices/rtt#CombineExternalCSS その間リダイレクトされていて、キャッシュされたバージョンが見つからないようですそのページの。
この推奨事項は、GoogleガイドラインとGTMetrix（「PageSpeed：Combine external CSS（deprecated）」）やKinstaなどのソリューションプロバイダー（「WordPressで外部CSSを結合する方法」）などのプラットフォームから廃止されたようです。
それは本当に非推奨であり、これについて心配するのをやめるべきですか？（ベストプラクティスが尊重されている場合）
まだ良いことです。ファイルを1つずつ要求すると、要求を送信する時間や最初のバイトまでの時間（異なる要求ごとに）などの余分な遅延が追加されます。そうは言っても、重要なファイルと重要でないファイルを分けることも良い考えです。最初に重要なファイルをダウンロードし、ページがロードされた後に残りをすべてダウンロードします。
HTTP/2 採用が増加している割合（2018年7月時点で上位1,000万のWebサイトのほぼ30％）で、私はそれにあまり努力しません。 HTTP/2により、そのような実装の詳細に対処する必要がなくなります。メリットを得るには、ホストがHTTP/2を介してコンテンツを提供できることを確認する必要があります。
ウィキペディアから：
効率的なWebサイトは、画像やスクリプトなどのリソースを縮小する（機能を低下させることなく、コードの量を減らし、小さなコードをバンドルにパックする）ことで、ページ全体をレンダリングするために必要なリクエストの数を最小限に抑えます。ただし、縮小は必ずしも便利でも効率的でもないため、ページと縮小されたリソースを取得するために別のHTTP接続が必要になる場合があります。 HTTP/2を使用すると、サーバーはコンテンツを「プッシュ」できます。つまり、クライアントが要求したよりも多くのクエリに対してデータで応答できます。これにより、サーバーは、ブラウザーが最初の応答を調べるのを待たずに、WebブラウザーがWebページをレンダリングする必要があることがわかっているデータを提供でき、追加の要求サイクルのオーバーヘッドもありません。
HTTP/2の最初のドラフト（SPDYのコピー）での追加のパフォーマンスの改善は、要求と応答の多重化によるもので、HTTP 1（HTTPパイプライン化が使用されている場合でも）のヘッダーの圧縮問題を回避します。 、およびリクエストの優先順位付け。 HTTP/2は、独自のより効率的なデータストリーミングメカニズムを提供するため、HTTP 1.1のチャンク転送エンコードメカニズムをサポートしなくなりました。