絞り込み条件を変更する
検索条件を絞り込む
有料ブログの投稿方法はこちら

すべてのカテゴリ

20 件中 1 - 20 件表示
カバー画像

CLS対策:ページ上部にAdSense自動広告を表示させない

1. はじめにGoogle 検索のランキング要因の中に、Core Web Vitals と呼ばれる 3つの指標があります。 その中の 1つであるCLS (Cumulative Layout Shift) は、「一旦ページが表示された後に、別の要素が割り込んで表示されるために、もとから表示されていた要素が移動してしまう現象」を数値化した指標です。この現象が起きてしまうと、評価が下がってしまうのです(使いにくいページになるので)。 この現象が起きる原因の1つは広告です。 例えば、Google AdSense の自動広告がページ上部に広告を挿入すると、その下の要素がすべて下方向にずれてしまうため、大幅にCLS が悪化します。 幸い Google AdSense の自動広告は、特定の位置に広告を表示させないように設定することができますので、その設定を行うことをお勧めします。 ※ 広告用のスペースを最初から空けておけば問題は起きません。2. 画面上部に、AdSense の自動広告を表示させない設定方法ポイントだけ説明します。 自動広告の設定画面では、Webページのプレビューが左側に表示され、その中に「自動広告の例」と書かれた広告枠の四角が(恐らく)ページの上部に表示されます。その部分のゴミ箱アイコンを押すだけです。それでも、再度同じ場所に広告の四角が表示されることがありますが、なくなるまで削除しましょう。自動広告の設定画面ゴミ箱アイコンをクリックすると「このエリアから広告を削除しますか?」と聞かれますので、[削除] を押します。この中に、「変更した内容は、サイト内の類似するページにも
0
カバー画像

Chrome 96 で Lighthouse の検査が終わらない問題が修正されました

現時点で最新の Chrome 96 には、Lighthouse が正常に動かない問題があります。Chrome のバージョンLighthouse を実行することはできますが、いつまで経っても終わりません。いつまで経っても終わらない…この現象は1ヶ月以上前に報告されており、多くのユーザーの環境で発生しています。 Not able to generate the lighthouse audit report · Issue #13236 · GoogleChrome/lighthouse(リンクが貼れないので検索してください) その後、状況はなかなか進展しませんでしたが、とうとうバグが修正され Canary にその修正が反映されました。 Lighthouse in DevTools errors/hangs on installability checks · Issue #13396 · GoogleChrome/lighthouse(リンクが貼れないので検索してください)実際には、Canary 98.0.4755.0 の時点で修正されていました。Chrome には、バージョン 97 で修正が反映されるそうです。Canary で正常に動きました。とりあえず、一安心です。ラボラジアンでは、Webに関するサービスを出品しております。こちらもよろしくお願い致します。
0
カバー画像

async script をより早く実行させる

1. はじめに 「async/defer なしの script」と「defer つきの script」は、記述した順番で実行されますが、「async つきの script」はどのような順番で実行されるか分かりません(そういう仕様です)。 「実行順序が分からない」と聞くとネガティブな印象を受けますが、この特徴によるメリットもあります。それは「<link rel=preload>」で script ファイルを先読みさせた場合、順番を気にすることなく実行できる点です。先読みしなかった場合と比較して、実行タイミングが早くなります。 2. async script をより早く実行させる ということで、async な script を早めに実行させるには「<link rel=preload>」で先読みさせます。 例えば、以下のように main.js という JavaScript ファイルを async つきで読み込んでいたとします。 ----- ここから -----<script src="./main.js" async></script> ----- ここまで -----この場合、このファイル名を指定した <link rel=preload> タグを <head> タグ内に記述します。 こんな感じです。なるべく上の方がよいです。 ----- ここから -----<link rel="preload" href="./main.js" as="script"> ----- ここまで -----これで、この
0
カバー画像

Lighthouse が指摘する「Serves images with low resolution」について

1. Lighthouse での指摘事項Chrome – デベロッパーツール (DevTools) – [Lighthouse] パネル を使って Webページを解析すると、「Serves images with low resolution(解像度の低い画像を提供してください)」と指摘されることがあります。 ※ Lighthouse は、Webページのパフォーマンス解析ツールです。「Serves images with low resolution」が指摘されています2. 必要な対応 上記の解析結果画像を見ると、以下の数値が表示されています。 - Displayed size 600 x 800 - Actual size 400 x 533 - Expected size 1200 x 1600 望まれているのは、「期待されるサイズ (Expected size) 1200 x 1600」の画像を用意することです(「Serves images with low resolution」とは反対のような…)。表示されたサイズ (Displayed size) に対して Expected size が 2倍であるため、デバイスピクセル比 2 のデバイスにちゃんと対応しておけば、Lighthouse 的には問題ないということだと思われます。 ※ デバイスピクセル比とは?- - - - - -例えばある画像の表示幅を 400px と指定している場合、デバイスピクセル比 2 のデイバイスに、幅 800px の画像を提供すると、より高画質な 400px の画像として表示してくれます。
0
カバー画像

ファーストビュー上のアニメーションGIFはMP4に変換して使うことを検討する

1. はじめにファーストビュー(Webページにアクセスした際、スクロールしない状態で表示される範囲)にアニメーションGIFを表示している場合は、MP4 に変換することで LCP 指標 (Core Web Vitals の1つ) を改善できる可能性があります。 ※ LCP (Largest Contentful Paint) は、Webページの読み込み&表示の速さを表す指標です(Google 検索のランキング要因の1つ)。もう少し具体的に言うと、ファーストビュー上の要素の中から一番大きな要素(対象となる要素の種類は決まっています)を選ばれ、その要素が描画されるまでの時間を元に算出されます。2. どういうことか?ファーストビュー上のアニメーションGIFが LCP の対象に選ばれた場合、このGIF画像ファイルがダウンロードされて描画されるまでの時間が LCP を決定します。画像ファイルは LCP の対象です。(Chrome DevTools [Performance]パネルで解析した結果)一方、このアニメーションGIFファイルを MP4ファイルに変換し、<video> タグを使って表示する場合、このMP4ファイルは LCP の対象にはなりません。「<video> タグで指定した動画ファイルは今のところ LCP の対象にならない」からです。この場合、代わりに LCP として選ばれた要素にもよりますが、LCP は改善する可能性があります。 ※ 但し、<video>タグの poster 属性を使って、動画ダウンロード中に表示する画像ファイルを指定する
0
カバー画像

「Web Vitals patterns」の Fonts について

web.dev サイトで公開されている「Web Vitals patters」というページですが、Fonts の項目は注意した方がいいですね。英語のフォントと日本語のフォントではデータサイズが違いすぎます。Google Fonts を外部サーバーから利用する場合、フォントファイルが分割されて、必要なファイルだけがダウンロードされますが、それでもパフォーマンスには注意が必要です。※ 以下の記事もご覧ください。一方、自分のWebサーバーにフォントファイルを配置する場合であっても、日本語フォントファイルのサイズが大きいので、これを読み込ませるとなるとパフォーマンスに大きな影響があります。ということで、ほんとにパフォーマンスを気にするのであれば、「サブセットフォントメーカー」といったツールを使って、そのページに必要なフォントのみのフォントファイルを作って利用するのがよいのではないかと思います。もしくはそのようなフォントの利用を諦めるかです。ラボラジアンでは、Webに関するサービスを出品しております。こちらもよろしくお願い致します。
0
カバー画像

Google Fonts がフォントファイルを読み込む様子を観察する

1. はじめにGoogle Fonts を使った Webページを作成し、フォントファイルがどのように読み込まれるのか観察します。 Google Fonts は Web フォント です。外部のサーバーからフォントファイルをダウンロードして利用します。一般的に Webフォントは、フォントファイルを丸ごと全てダウンロード(しかも外部のサーバーから)するので、「 Webページの読み込み&表示 」が大幅に遅くなるものと見られています(日本語のフォントデータはかなりのサイズになります)。 しかし、Google Fonts の場合、なるべく必要最低限のフォントデータだけが、ダウンロードされるようになっているため、Webページの読み込みパフォーマンスにそこまでの影響を与えません。 この動作を観察します。2. 実験環境これを観察するために作成Webページでは、Google Fonts を適用する部分に、以下の文章を記述しています。----- ここから -----わたくしといふ現象は 仮定された有機交流電燈の ひとつの青い照明です (あらゆる透明な幽霊の複合体) 風景やみんなといつしよに せはしくせはしく明滅しながら いかにもたしかにともりつづける 因果交流電燈の ひとつの青い照明です (ひかりはたもち その電燈は失はれ) これらは二十二箇月の 過去とかんずる方角から 紙と鉱質インクをつらね (すべてわたくしと明滅し  みんなが同時に感ずるもの) ここまでたもちつゞけられた かげとひかりのひとくさりづつ そのとほりの心象スケツチです 「春と修羅(宮沢賢治)」より引用----- ここまで ----
0
カバー画像

ファーストビューに配置したLCP対象画像に loading=lazyはいらない?

1. はじめにimg タグ(画像を表示するHTMLタグです)に「lazy という値を指定した loading 属性」を指定すると、その画像はすぐにダウンロードされません。ブラウザで表示している領域 (viewport) に、画像が入ってきたときにダウンロードが開始され表示されます。この動作により、Webページの読み込み&表示が高速化されます。 ところが、ファーストビュー(最初に画面に表示される範囲)上の画像はすぐに表示される必要があるため、loading=”lazy” を指定すると却ってWebページが遅くなってしまいます。 この動作を確認しようというのが、本記事の目的になります。2. 実験環境大きめの画像を画面上部に配置した Webページを用意します。 PC、スマートフォンのどちらからアクセスした場合でも、ファーストビューにこの画像が表示されるようにレイアウトを調整します。また、ファーストビュー上に表示される中で一番サイズが大きい要素がこの画像になるようにします。こうすることで、この画像が LCP (Largest Contentful Paint) の対象となります。今回の解析においても、この画像が LCP (Largest Contentful Paint) の対象となっていることを確認しています。 この画像の img タグに指定する loading 属性値を “eager” (こちらがdefault値です)、”lazy” のそれぞれを指定した場合とで、それぞれ Performance を解析します。この解析には、Chrome ブラウザのデベロッパーツール (DevToo
0
カバー画像

<script>タグのdefer/async属性について(その2:実例)

1. はじめに先日書いた以下の記事の補足です。&lt;script&gt;タグの属性によって、JavaScript ファイルがどのように読み込まれるのか、以下の3パターンを実際のWebページを使って比べます。(1) defer / async 属性を指定しない場合(2) defer 属性を指定した場合(3) async 属性を指定した場合2. 方法Chrome ブラウザのデベロッパーツール (DevTools) が持つ [Performance] パネルにて、読み込み処理を解析します。以下のHTMLファイルを読み込ませます。60行のファイルです。画像の中で示した、3つの &lt;script&gt;タグで JavaScript ファイルをそれぞれ読み込ませます。この &lt;script&gt;タグに defer / async 属性を指定します。また、以下の記事も参考にしてください。3. それぞれの読み込み処理を観察する(1) defer / async 属性を指定しない場合以下が解析結果の画面です。defer / async 属性を指定しない場合 (拡大する場合は、右クリックして別タブで画像を開いてください)画像の中で [0...48] とあるのは、HTMLファイルの0行目から48行目に対するパース処理です。以前書いた記事でも説明しましたが、1つのHTMLファイルを上からいくつかに分割して、上の部分からパースされます。それぞれのパース処理の間で別の処理が行なわれることもあります。今回の場合、1回目のパース [0...48] 対象行の直後に、&lt;script&gt;タグが
0
カバー画像

Webページが読み込まれる際、HTMLは分割されてパースされます

1. はじめにこの記事では、Webページが読み込まれる際、HTMLが分割されて段階的にパースされる様子を観察します。2. 前提知識(1) (HTML)パースは、HTMLを読み込んでDOMツリーという「HTML要素から構成される木構造」を構築する処理を指します。(2) これとは別に、CSSを元に CSSOMツリーが構築されます(装飾を担当)。(3) DOMツリーとCSSOMツリーから、レンダリングツリーが構築されます。(4) レンダリングツリーができた上で、画面のレイアウトやレンダリングが行なわれ、画面にWebページが表示されます。(5) HTMLファイルの途中までの情報を元にしても、以上の処理を行うことができます。以下の記事も参考にしてください。3. 方法Chrome ブラウザのデベロッパーツール (DevTools) が備えている [Performance] パネルで、Webページの読み込み処理を解析させ、その結果を観察します。4. 解析した結果を観察するとあるWebページを、[Performance] パネルで解析しましたので、その結果を紹介します。まず、このWebページのHTMLファイルは、654行あります(下画像参照)。[Sources]パネルで htmlファイルを表示していますここから、[Performance]パネルで行った解析の結果画面を載せていきます。1回目のHTMLパース処理※ 横軸は時間で、左から右に時間が進みます。画面中央左端あたりの青い四角の部分で、HTMLファイルが読み込まれています。そこから下の部分では、Mainスレッドで実行された処理が時系列で表示
0
カバー画像

Webページ読み込み高速化に対する<script>タグのdefer/async属性について(その1)

1. はじめに「Webページの読み込み高速化」という観点から、「&lt;script&gt;タグの defer / async 属性」について書いてみます。2. &lt;script&gt;タグに defer / async 属性を付けた場合のブラウザの動作まず、HTMLの仕様である HTML Living Standard から画像を引用します。HTML Living Standard - 4.12.1 The script element から引用※ 拡大する場合は、右クリックして別タブで開いてください。※ 関係ない部分には影を付けました。この画像では、以下の3種類の動作についての違いについて説明されています。(1) ただの &lt;script&gt;タグ(2) defer 属性付きの&lt;script&gt;タグ(3) async 属性付きの &lt;script&gt;タグここで図示されている違いを言葉で説明すると以下になります。(1) ただの &lt;script&gt;タグ1. HTMLのパース(*1)を止める2. JavaScriptファイルをダウンロードする3. JavaScriptコードを実行する4. JavaScriptコードの実行が終わったら、HTMLのパースを再開します。(*1) HTMLを読み込んでDOMツリーを構築する処理(2) defer 属性付きの&lt;script&gt;タグ1. HTMLのパースを止めず、並列に JavaScriptファイルをダウンロードする2. HTMLのパースが完了したら、JavaScriptコードを実行する (DO
0
カバー画像

Webページの高速化とSEOの関係

「Webページの表示を高速化すること」と「SEO」との関係を私なりに簡単に説明してみます。私はSEOの専門家ではないため、間違っているところがありましたら教えていただけると大変ありがたいです。まず、SEOで重要となる「Google検索のランキング要因」を表す図を載せます。(Google検索のランキング要因)※ GoogleがWebページを評価するアルゴリズムは公表されていませんが、考え方はガイドラインとして公開されています。また、社員の方が語ってくれることもあります。ということで、ざっくりとした項目になっています。Google検索のランキング要因はいろいろな項目があるようですが、ページの読み込み速さなどは「ページエクスペリエンス(*1)」という「ユーザーが気持ちよく使えるページか?」を表すカテゴリに分類されます。このページエクスペリエンスの重要度は高くありません。コンテンツの品質の方が重要です。(*1) 厳密には、「Search signals for page experience」といいます。このページエクスペリエンスの中に、Googleが提唱する「CWV (Core Web Vitals)」という3つの指標が含まれています。以下の3つです。(1) LCP(ページの読込が速いか)(2) FID(すぐに操作できるか)(3) CLS(最初の画面描画時に、画面上の要素が動かないか)ここで大事なポイントは、ランキング要因となっているのは、ただのCWVではなく「CWVのフィールドデータ」となっている点です(図を参照)。フィールドデータというのは、日頃ユーザーがそのWebページにアクセ
0
カバー画像

PageSpeed Insights による「スクロール パフォーマンスを高める受動的なリスナーが使用されていません」について

1. 問題点PageSpeed Insights (PSI) や Chrome の Lighthouse といったツールで、Webページのパフォーマンス測定をしていると、「スクロールパフォーマンスを高める受動的なリスナーが使用されていません」という指摘を受けることがあります。日本語での指摘内容英語での指摘内容2. 原因メッセージ 最下部に ファイル名と行数が記載されているので、その箇所を見てみると 以下のような JavaScript コードが見つかるはずです。- - - - - ここから - - - - -document.addEventListener("touchstart", () =&gt; {   // ここに色々処理が書いてあります  // … });- - - - - ここまで - - - - -この JavaScript コードは、「”touchstart” という名前のイベントが発生したときに実行する処理」を記述しています。”touchstart” 以外でも「画面のスクロールが発生するイベント」であれば、同様に指摘されるはずです。 スクロールが発生するイベントで実行されるコードなので、ここで重い処理が実行されてしまうと、スクロールの動作がもたついてしまう可能性があります。 ここで記述されている addEventListener() メソッドには、この問題を避けるための引数が用意されています。このメソッドの第二引数として「{ passive: true }」を指定すると、イベントリスナーに書いたコードをスクロール処理とは別扱い(別スレッド)で実行してくれるので
0
カバー画像

Webページの読み込み&表示の高速化(重い処理は「専用Worker」に任せる)

1. 専用Worker による JavaScript コードの実行についてWebページを読み込む際に、(1) JavaScript で何か重い処理を実行している。(2) その処理は画面上の要素を必要としない。(3) 画面の描画される時点で、その処理は必ずしも完了している必要はない。という場合は、その処理を 専用Worker に任せることで、そのページの読み込み&表示を高速化することができます。通常、Webブラウザを使ってあるWebページにアクセスする場合、「そのWebページが持っている JavaScript コードの実行」と「そのWebページの描画処理」とは、メインスレッドと呼ばれる「同じプログラムの流れ」の中で実行されるため、前者に時間が掛かかると、後者が遅くなってしまいます。※ Chrome デベロッパーツールの [Performance] パネルで検証を行うと、メインスレッドを確認することができます。下画像の「Main」とある部分がそれです。(Chromeデベロッパーツールの [Performance]パネル)「Main」の部分を展開すると、いろいろ忙しそうに処理を実行しているのが分かります。(Main を展開したところ)なのですが、専用Worker というものを使って JavaScript コードを実行すると、メインスレッドとは別の「プログラムの流れ」の中で実行されるので、画面の描画処理に影響を与えることはなくなります。※ 下画像は、上とは別のページで [Performance]パネルの検証を行った結果です。「Main」の他に「Worker」という項目が表示されています
0
カバー画像

Webページを表示する際に、時間の掛かったタスクを調査する

1. はじめに前回の記事(以下)に引き続き、Chromeブラウザ「デベロッパーツール (DevTools)」の [Performance]パネルについて書きます。今回は、この Performance 検査を使って、時間が掛かった処理を見つける手順を紹介します。2. Performance 検査で時間が掛かった処理を見つける手順まず、以下の手順で Performance の検査を実行します(下画面参照)。(1) Chrome デベロッパーツールの [Performance] パネルを開きます。(2) 各種設定項目を調整します。今回は省略します。(3) 左上のアイコンをクリックして、検査を実行します。(拡大するには、画像を右クリックして、別タブで画像を開いてください)検査が完了したら、以下の画面に書いたように操作します。(拡大するには、画像を右クリックして、別タブで画像を開いてください)(1) 左側に "▼Network" と書いてある領域の白い部分をクリックします。これにより、Performance 測定した全体にフォーカスを当てたことになります(特定の時間範囲や特定のタスクではなく)。(2) 画面下にある領域にいくつかタブが並んでいますが、[Bottom-Up] をクリックして表示します。これにより、Performance 測定で検知された各処理が、時間が掛かった順に並びます。(3) "Group by Activity" を選択します。アクティビティ(activity)というのは、ある一定の粒度の処理の塊を指しますが、このアクティビティで分類表示します。(4) 各アクティビテ
0
カバー画像

Chrome デベロッパーツール [Performance]パネルにおける箱ひげ図のような四角の意味

1. はじめにChromeブラウザには、Webサイトを解析するための「デベロッパーツール (DevTools)」というツールが用意されています。このツールの [Performance]パネルには、箱ひげ図のような四角が表示されるのですが、この四角が何を表しているのかについて説明します。  箱ひげ図のような四角がたくさん表示されています2. 前提知識デベロッパーツールの [Network] パネルでは、Webページにアクセスした際にダウンロードされたファイルについての情報を確認することができます。1つのファイルを選択すると、右下にその詳細が表示されます。また、[Performance]パネルでは、Webページにアクセスした際のパフォーマンスを検査することができます。3. 箱ひげ図のような四角についてでは本題の「四角」ですが、これは [Performance] パネルでの検査結果の中に表示されます(下画像)。四角1つは1つのファイルを表しており、なぜ箱ひげ図のような形をしているのかと言うと、「ブラウザがこのファイルに対して行った各処理の工程」を表しているからです。この四角は、以下のように A から D の4つの領域に分かれます。ここで、[Network] パネルでは、ダウンロードした1つのファイルについての詳細情報が表示されていたことを思い出してください。その中の [Timing] タブ(下画像)では、そのファイルについてブラウザが順番に行った処理とそれに掛かった時間が表示されます。先程の四角は、この情報を視覚的に表していると言えます。つまり、各処理の段階を4つに分け、それぞれに掛
0
カバー画像

Webページが表示されるまでの処理の流れ

Webブラウザが、Webページの中心であるHTMLファイルを取得してから、その内容がWebブラウザ上に描画されるまでの流れを、下の図を使ってざっと説明します。※ かなり簡略した説明です。※ 画像を拡大するには、画像を右クリックして、新しいタブで画像を開いてください。(1) Webブラウザが HTTPリクエストを送信し、Webサーバーが HTML を返します。(2) Webブラウザは、HTMLを分割して(大きい場合)上の部分から以下の処理を行います。(3) HTMLをパースして DOMツリーを構築します。(4) HTMLの中にCSSファイルのリンクがあれば、CSSファイルをダウンロードしてパースし、CSSOMツリーを構築します。(5) HTMLの中にJavaScriptファイルのリンクがあれば、JavaScriptファイルをダウンロードして実行します。(6) HTMLの中に画像ファイルのリンクがあれば、画像ファイルをダウンロードします。(7) DOMツリーとCSSOMツリーから、レンダーツリーを構築し、画面にレンダリング(描画)します。※ 分割されたHTMLによって、描画処理は省略されることもあるようです。(8) 分割されたHTMLの次の塊に対して、(3)から(7) を繰り返します。(9) 最後のHTMLが処理されて最終的なDOMツリーが完成したタイミングで、DOMContentLoaded イベントが発生します。(10) すべてのリソースファイルが読み込まれたタイミングで、Load イベントが発生します。※ 実際は、「Aが処理されている間は、Bの処理はブロックされる」、「pre
0
カバー画像

2021年のPageSpeed Insightsスコア改善にあまり意味がない理由

ウェブサイト高速化の話をするとPageSpeed Insigthsスコアが低いから改善したいという声を頻繁に聞いたり目にしたりします。ただ改善したところでそれがSEO上のメリットがある訳でもないです。そもそもGoogleはスコアを高速化判断に使用しないと何度も明らかにしていますから。それでも何故か点数が低いと気になってしまい100点を目指したくなるというのは人間の性でしょうか。あとスコア算出基準は1年~数年で変わります。なので例えば今100点を目指して改善しても基準が変わると1年後にはまた改善が必要になります。既に高速なサイトをPSIスコアが低いだけで何度も改善をするというのは、お金に余裕があれば良いのですがその費用対効果を考えると微妙とも言えます。じゃあ高速化を無理にしなくても良いのか?と言うとそれは違います。2021年であればCore Web Vitals(コアウェブバイタル)対策を実施すべきですし、実際にページが表示されるまでの時間は速ければ速いほどストレスを感じません。PSIスコアを改善する事と、CWV対策や体感速度を改善する事は似て非なるのでそれぞれの特徴を理解して対策することが大事です。実際に恐らくは今年中にLighthouse 8が登場するとCLS改善が不完全だとPSIスコアは今より下がります。CLS以外の部分が良好で結果としてスコアが90以上になったとしても、将来の仕様変更で同じスコアにはならないのです。なのでスコア改善ではなく、高速化へ向けてサイトの課題をしっかり解決する事が何よりも大事。問題ある箇所を改善して結果としてスコアがあがるくらいに考えるのがちょうど
0
カバー画像

サイト高速化ご契約前の確認事項および、必要な情報まとめ

お忙しい中ご覧いただき、誠にありがとうございます。作業前にご確認およびご了承いただきたい点、また必要な情報をまとめましたので、必ず最後までご確認をお願いいたします。【 ご契約前確認事項 】■ 作業後ほとんど改善が見られない、または効果が目に見えない場合がございますWordPressの一般的なテーマやプラグインは、汎用性を持たせるため、あなたのサイトには直接関係のない情報を読み込むことが多々あります。またサーバーのスペックが足りないと、レスポンスに相応の時間を要します。そのため、利用されるテーマやプラグイン、サーバーなどによっては、物理的に高速化が難しい場合がございます。下記のような制限がある場合、ほとんど改善が見られない場合がございます。予めご了承ください。・テーマの機能を最大限利用したい・プラグインはどれもアンインストールできない・広告やカルーセル等、処理の重い要素の設置や配置を見直すことができない・サーバーのスペックが足りないまた一般的な表示速度計測ツールは、サーバーの状況や通信環境、ブラウザの拡張機能等の影響を受けます。スコアはあくまで参考値であり、サイト高速化=スコア向上ではございませんので、ご理解ください。※作業前と作業後にGoogle PageSpeed Insightsのスコアキャプチャをお送りいたしますが、前述の環境差異により、ご自身でのテストと数値が異なる場合がございますので、こちらも併せてご承知おきください。■ ページによって効果の度合いが異なる場合がございます高速化施策には、「該当ページのみに有効なもの」と、「サイト全体に影響を及ぼすもの」がございます。基
0
カバー画像

【WordPress高速化】PageSpeed Insightsスコアはモバイルとパソコンどっちが重要?

Googleが提供する表示速度の改善度合いを示すPageSpeed Insightsスコアにはモバイルスコアとパソコン(デスクトップ)スコアの2種類があります。(ココナラの高速化改善度合いです、低いですね。けど指名検索が多い場合はこれでも大丈夫です。)皆さんはこのどちらがより重要かご存知でしょうか?正解はモバイルスコアです。先ずパソコンスコアについては80点~90点と言った高得点が出るのが普通です。よってほとんど無視しても構いません。現在はモバイルファーストインデックスや大半の閲覧がモバイルからなのでモバイル重視と考えてください。巷にはPSIスコア点数のみの画像を貼ってあるブログ記事が溢れていますね。けどあれだとモバイルスコアなのかパソコンスコアなのか分かりません(記事次第ではちゃんと説明されている)。ココナラのWordPress高速化サービスを選ぶ際に注意していただきたいのは、改善してくれるのはモバイルなのかパソコンなのか?です。ちなみにパソコンのPSIスコアだけを改善するなら無料のプラグイン組み合わせれば良いので依頼する必要はありません。逆にモバイルスコア改善はサイト設計にもよりますが結構ハードルが高いです。インチキでもしない限り最低でも3日~1週間はかかりますし、ウェブデザインの一部(レイアウトやコンテンツ配置)を変更する必要もあります。なおこのPSIスコアと呼ばれる100点満点の点数ですが、これだけ見ていたのでは全く意味がありません。それはまた別記事にて。
0
20 件中 1 - 20
有料ブログの投稿方法はこちら