「Render-Blocking」要素を最適化することは、ページ速度を最大化することとは対照的に、認識される読み込み時間に関するものです。
CSS の場合、重要な cssの CSSをインライン化する必要があります。これはしばしば「スクロールせずに見える」コンテンツと呼ばれますが、その用語は正しくありません - 重要な CSS には、基本スタイル、レイアウト (つまり、グリッド システム) などが含まれます。
オンライン (および GitHub) で入手できる Critical CSS Generator は次のとおりです:
http://jonassebastianohlsson.com/criticalpathcssgenerator/
これを行う理由は、ページの最も重要なスタイルが HTML と共に読み込まれるようにすることと、HTML に追加されたファイル サイズが gzip された Web ページで無視できるようにすることです。
もう 1 つのレンダリングの問題は、非常に一般的な Google フォントに関するものです。これに関するGoogle のアドバイスは無視してください。推奨されるのは、Google フォントをフッターに配置することです。
より良い方法は、 Font Squirrel Webfont Generatorなどのツールを使用して Web フォントを自分で生成し、Google への HTTPS リクエストを保存することです (これにより、アセットの読み込みでトラフィックが渋滞します)。
ただし、Pagespeed ツールは、Web ページの速度が低下する主な理由を無視しています。つまり、68 個の HTTP リクエストがあります。これらの約 3 分の 1 は JS ファイルであり、1 つの .js ファイルに集約するか、 Lab.jsのようなライブラリを使用してjs* レンダリングを延期し、これらのファイルの HTTP リクエストを削減する必要があります。
*Lab.js のようなブロック/読み込みライブラリを使用する場合は、重要な Javascript を HTML のスクリプト タグ内にインライン化するか、重要な js ファイルを遅延から除外する必要があります。
モバイル スコアに関しては、Google Pagespeed ツールが Web サイトをモバイル対応でないと誤解しています。これを別の内部ページでテストすると、モバイルのスコアは ~74 です。
これはおそらく、タイムアウトして、ページ全体がレンダリングされるか、またはそのようなものだと考えているためです。このようなツールを使用する場合、間違いを犯す可能性があるため、常に複数のページを実行します。
モバイルの問題のほとんどは、css をインライン化し、Javascript を延期することで修正されます。
PS スコアにこだわりすぎないでください。あなたに不利な点のほとんどは、画像や CSS などのマイナーな (つまり 5% 未満の) 調整です。