ブログをある程度運営していれば、やがてアドセンスを考える時が来ると思います。
今現在では、Google Ad senceが最初の候補なってきますが、規約には「プライバシーポリシー」をわかりやすいところに掲載とておくことを求めています。
以下の、ブロガーさんが最小限度の「プライバシーポリシー」の雛形を示されています。
是非、必要になればご参考にしてください。当サイトでも、使用させて頂いています。
【2019年コピペOK】グーグルアドセンスのプライバシーポリシーテンプレート(ひな形)書き方の例 2020年1月
https://carbonjam.com/googleadsense/privacy-policy/
編集履歴 2020/01/30 はりきり(Mr)
![[WP]プラグイン- PhastPress Ver.1.33はDatabaseを不適正にいじってしまう](https://harikiri.diskstation.me/myblog/wp-content/uploads/2020/09/F6908C2B-9876-4F48-B958-1D86685C00D9.jpeg)
この記事は、2020/01当時の古い情報です。プラグインをインストールする前にはバックアップを取っておく必要があることの戒めとして当時の記録として以下に残しています。
前回までに、(0)「Autoptimize Ver. 2.6.1」プラグイン(CSS, JavaScript, HTMLの最適化)をペースとして、(1)キャッシュ・プラグイン、(2)画像遅延ローダー・プラグイン、(3)画像最適化・プラグイン、およびFlying Analyticsでとりあえずの最適化を完了した。
今回は、「Autoptimize Ver. 2.6.1」プラグインの代替プラグインとして「PhastPress Ver. 1.33」を試してみた。
方法
結論(教訓)
2020/01/29 ばりきり(Mr)
WP] Autoptimizeの威力 – ブログ・サイトのスピード改善対策プラグイン
https://harikiri.diskstation.me/myblog/wordpress/7804/
Google Console Search – Page Speed Insightsを使う
https://harikiri.diskstation.me/myblog/wordpress/4372/
[WP] WP-Optimizeのcache設定 – Autoptimizeとの併用効果
https://harikiri.diskstation.me/myblog/wordpress/8049/
WP] 遅延読込プラグインはどれがいい? (2020)
https://harikiri.diskstation.me/myblog/wordpress/8071/
2020/01/29, Mr.Harikiri
![[WordPress] PhastPress プラグイン Ver.1.33 – Databaseを不適正にいじってしまう(バックアップ教訓)](https://harikiri.diskstation.me/myblog/wp-content/uploads/2021/04/1D3DD662-8755-453F-BB35-D35DDF461F9C.jpeg)
この記事は、2020/1現時点での記事です。PhastPressプラグインで起きた問題は、当時のものなので、現時点では改善されていると思われます。このプラグインでの不具合は、今後のプラクインの導入時にはバックアップを取ることをお勧めする教訓を含みます。そのために、あえて不具合の詳細を示しています。
前回までに、(0)「Autoptimize Ver. 2.6.1」プラグイン(CSS, JavaScript, HTMLの最適化)をペースとして、(1)キャッシュ・プラグイン、(2)画像遅延ローダー・プラグイン、(3)画像最適化・プラグイン、およびFlying Analyticsでとりあえずの最適化を完了した。
今回は、「Autoptimize Ver. 2.6.1」プラグインの代替プラグインとして「PhastPress Ver. 1.33」を試してみた。
方法
結論(教訓)
2020/01/29 ばりきり(Mr)
WP] Autoptimizeの威力 – ブログ・サイトのスピード改善対策プラグイン
https://harikiri.diskstation.me/myblog/wordpress/7804/
Google Console Search – Page Speed Insightsを使う
https://harikiri.diskstation.me/myblog/wordpress/4372/
[WP] WP-Optimizeのcache設定 – Autoptimizeとの併用効果
https://harikiri.diskstation.me/myblog/wordpress/8049/
WP] 遅延読込プラグインはどれがいい? (2020)
https://harikiri.diskstation.me/myblog/wordpress/8071/
以下の3つの画像遅延ローダーをGoogleのPageSpeed Insightsのスコアで比較しました。
画像遅延処理のPluginの有無でPageSpeed Insightスコアは、以下のように改善できた。
結論から言うと今回の結果から、採用したPluginは、 「Lazy Load – Optimize Images Ver.2.3.2」です。
例えば、以下のアドレスをGoogle Page Speed Insightsに入力して測定します。(https://harikiri.diskstation.me/myblog/wordpress/7804/)
結果は、モバイル : 40程度 → 50程度
少し長文のページのスコアも測定しました。
結果は、モバイル : 25程度 → 35程度
Lazy Load >= Lazy Loaderと、PageSpeed Insightsスコアで若干の差があったが、ほぼ同等。
ただし、Lazy Loadでは、連続でスコアを測定すると、だんだん良くなる傾向がある。cache関係で相性が良いのかもしれない。
パソコンでのPageSpeed Insightsスコアが高く出る傾向がある。長文の投稿ページでは、スコアの改善が殆どなかった。これからのPage作りは、モバイル・オリエンテッドなどで、パソコンでのスコアは、以下の通り良かったが、採用を見送ることにした。
ルート(myblog) モバイル
ルート(myblog) 長文ページ
これまでに、Autoptimize プラグインによるCSS, JavaScriptなどの最適化、WP-Optimizeによるcacheのによる最適化、EWWW Image Optimizerによる画像の軽量化を検討してきました。今回は、画像の遅延表示によるPageSpeed Insightsスコアの改善を検討しました。
まとめに記載したように、ごく最近まで速度に関するスコアについて知識がなかったため、関連するプラグインは、何も入れていなかった。そのときのスコアから現在までのスコアの改善度は、以下の通りです。
まだまだですが、当初のことを思えば、劇的な改善度です。
PageSpeed Insightsスコア: Plugin導入前からの変遷
ルート(myblog)
長文のページ
以上
![[WordPress] WP-Optimizeのキャッシュの設定 – Autoptimizeとの併用効果](https://harikiri.diskstation.me/myblog/wp-content/uploads/2020/01/725BE164-F482-4B88-9EB3-9BC90CA7807E.jpeg)
ID14373
前回のAutoptimizeの設定では、cacheは逆効果でした。
(当時の記事の補足。原理をよく考えるとわかりますが、キャッシュは複数あるとコンフリクトを起こしてしまうため、複数のキャッシュ・プラグインの使用は避けるべきです。導入した結果がよかったとしても, 2021/10/30 by Mr. Harikiri)
ページのスピードアップをするには、以下の知識が必要です。この記事の中では、このことを知らずにテストしていた頃の記事なので、以下の知識について先ずは知っておいてください。
Googleは、モバイル・ファーストとしてAMPという技術/ルールを提唱しています。このルールは、過度なJava, CSSなどのコードをシンプルにするように求めています。それによって、軽量化されてページの読み込みスピードが向上します。AMPに対応させるにはプラグインを使用することができます。その場合、この記事の中で評価しているAutoptimizeプラグインは、使用を避けてください。その理由は、AutoptimizeがAMPに対応していないからです。AutoptimizeもAMPと同様の目的にJava, CSSのコードを軽量化する独自の方法を使っています。おそらくコンフリクトします。blogをAMPに対応させない場合は、Autoptimizeプラグイン、または、その他の同様のプラグインを、AMPに対応させるには、AMPプラグインを使う用にして、それぞで使い分ける必要があります。
キャッシュ・プラグインは、AMPプラグイン、Autoptimizeプラグインとは異なる原理で動いているので、併用は可能です。その場合、AMPプラグインに適するキャッシュ・プラグインがあるとでしょう。同様に、Autoptimizeプラグインに適したするキャッシャ・プラグインがあるはずです。
PageSpeed Insights
https://pagespeed.web.dev
WordPressのdatabaseの最適化に、WP-Optimizeをインストールしました。
このプラグインには、cache機能もあります。cacheをONにしてPageSpeed Insightsで測定しました。
WP-Optimizeには、画像の遅延読み込み「Lazy Load」機能があるため、EWWW Image Optimizerなどを使っている場合、同じ機能がdefaultで有効になっているので、どちらかを無効に設定します。コンフリクトするとPageSpeed Insights (PSI)のスコアが5ポイント程低下します。
その他の設定は、前回の記事を継承しています。
WP-Optimizeプラグインのcache機能をONにしてSPIモバイル・スコアを測定した結果、更なる速度改善の効果があり、Autoptiizeプラグインとの併用効果が確認できました。
WP-OptimizeプラグインのPage cachingをしない場合、ページスピードは、モバイル/パソコンそれぞれ40/68でした。
WP-OptimizeのPage cachingをONすると、ページスピードは、モバイル/パソコンそれぞれ52/82となり少し速度が改善しました。
PageSpeed Insightsによるモバイル・スコアは、cacheをONにすることで、モバイル40→52、パソコン68 → 82にスピードアップしました(2020/01/25現在)。
2020/01/25 はりきり(Mr) 2020/05/29 文言整備、追記(まとめ) 2021/11/20,修正(モバイル/パソコンの測定データのソース写真取り違え)
日々のアクセス状況(検索での表示回数、クリック回数、クリック率など)をグラフやテーブルで示してくれます。
Google Search Consoleへの登録の仕方は、他のBlogerの皆さんに任せて、ここでは述べませんが、最近特に気になっている、ユーザーエクスペリエンスの向上のためのページの反応性の測定です。その測定のために、Google Search Consoleを頻繁に使っています。
サイトの賑わいは、記事の内容、読み易さ、タイムリー性、あと、表示速度が主に考えられると思います。
表示速度については、Googleは、スマートフォンを中心にページをデザインすべきであると言っています。どんどんPCではネットサーフィンしなくなり、スマフォかタブレットになっていますね。
当サイトも、Synology NASにWordPressサーバーを立ち上げて、1年になりますが、GoogleにIndexしてもらうという意味もようやく分かり、この記事を書いています。
まだ試験運用版とのことですが、サイトのペード毎に速度を測定できます。
Google Search Consoleに飛び、左タグから「速度(試験運用版)を探しタップすると、「Page Speed Insights」のリンクが現れる。
入力欄にサイトのページアドレスを入力し、分析をタップする。
しばらくすると、円グラフで、ページの総合的な速度評価(速度スコアは、Lighthouseでの測定に基くとあります)が表される。
下方にスクロールすれば、測定結果と改善可能な問題に対する対策が示されています。自分のサイトの速度的な弱点を客観的に知ることができる。
当サイトは、Synology NASでWordPressサーバーを個人的に立てているので、管理の行き届いたレンタルサーバーではないため、自分で反応速度などのユーザービリティを調整しないといけません。
当サイトの反応速度の改善記事は、以下をご参照ください。
[WP] Autoptimizeの威力 – ブログ・サイトのスピード改善対策プラグイン
https://harikiri.diskstation.me/myblog/wordpress/7804/
Lighthouseは，Googleが提供するwebサイトのパフォーマンス，アクセシビリティ，SEOなどを測定するツール．WindowsのブラウザChromeの拡張機能として利用できる．
Lighthouse（ライトハウス）とは？Google公式のSEOチェックツールをご紹介 (2019)
Lighthouse（ライトハウス）とは？Google公式のSEOチェックツールをご紹介-エムタメ！ (mtame.jp)
2020/01/23, MR.HARIKIRI
![[WordPress] Autoptimize プラグインの威力 – ブログ・サイトのスピード改善対策プラグイン – 更にAMP対応まで進めた結果 [2020/05/15]](https://harikiri.diskstation.me/myblog/wp-content/uploads/2020/01/87644712-4320-4B3C-8D4D-75938D5CA14B.jpeg)
当サイトのGoogleSpeed Insightsで、サイトのスピードを測定(2020/02)したところ、モバイルでのスピードは、4~5%でした。そこで、サイトスピードを改善するプラグインを検討したところ、「Autoptimize」を基本に、その他キャッシャ関連のプラグインを組み合わせると、10倍程度の劇的な改善(40%程度)が可能でした。
自分のサイトのスピードを知るには、Google Search Consoleを使っているなら、速度(試験運用版: PageSpeed Insights)で測定してくれます。
お知り合いになっていただいている観音寺さんから、当サイトの速度が遅いことのご指摘を頂き、測定してみたところ、その結果は、4~5%とさんざんでした。
これでは、誰もみてくれませんね。
また、Chromeの拡張機能(Windows版)の「Lighthouse」でもサイトの速度を測定してくれます。Lighthouseでは、50%程度の結果でした。
(Google Search Consoleは、どうやらLighthouseのエンジンを使っているようですが、測定結果は少し異なっているようです)
そこで、対策としてプラグイン (Plugin)を探してみました。試したのは、
「Autoptimize」
です。
PageSpeed Insightsの測定で、4~5%であった性能が、20~30%に劇的に改善しました。
その後は、微調整を行いました。キャッシュ(cache)も当然良いのでは無いかと思って、キャッシュ・プラグイン (cache plugin) の併用効果として、
「WP Fastest Cache」
で確認しました。当サイトの環境ではこのプラグインでは逆効果でした。
最後に、Google Analyticsが、時間を食っているのがわかったので、
「Flying Analytics」
https://wpspeedmatters.com/how-to-optimize-google-analytics-in-wordpress/
で、Google Analyticsをミニ化してその改善具合を確認しました。
詳細は、以下ご覧ください。
Autoptimizeの有無での測定概要は、以下の通りです。
さらなるスピードアップには、その他プラスアルファのPluginをリコメンドしてくれています。
以下は、JavaScript関連、CSS関連、HTML関連について設定の有無で、どれだけ効果があったかをテストしてみました。
Page Speed Insightsでの測定に際して、Autoptimizeの設定項目は、以下で行った設定検討の結果を元にして決めた項目にて、測定を行いました。
図1. Autoptimizeの効果 – PageSpeed Insights測定結果
設定項目を、(1)CSS, (2)JavaScriptおよび(3)HTMLの順番で、効果の出そうな順に設定し、Lighthoutsで測定しました。
21%のPerformanceしか出ていません。
以下では、Autoptimizeで各設定項目を段階的に有効化したときのLighthouseでの測定結果です。
連続2回措定しました。cacheが効いているので、2回目の結果は少し良い値が出ています。
CCSコード最適化を☑️
Aggregate CSS-files?☑️
インラインのCSSを連結☑️
CCSコード最適化を☑️
Aggregate CSS-files?☑️
インラインのCSSを連結☑️
データを生成 : 画像をURI化☑️
以上の結果から、「データを生成 : 画像をURI化」は、あまり効果がなさそうなので、このチェックは外すことにします。
Aggregate JS-files?☑️
JavaScriptコードの最適化の効果はあるようです。
HTMLコード最適化を☑️
HTMLコードの最適化はそこそこ効果があるようです。
最終的に、以下の通りの設定に落ち着きました。
キャッシュの併用も試してみました。WP Fastest Cacheです。Fee版でも多数の設定項目があります。色々設定して、Page Speed Insightsで測定してみました。結局、無い方がスコアが高く出ることがわかりました。
当サイトのWordPressはSynology DS918+に立てています。SSD cacheも追加で積んでいます。WP Fastest cacheの効果が出なかったのは、おそらく、SSD cacheがあるためと考えれます。二重のcacheは必要ないということですね。
最適な設定の組み合わせを探して、試行錯誤で設定、PageSpeed Insightsで測定を繰り返し、その結果を眺めていると、Google Analyticsが結構じゃましているようなレポートがあるのに気が付きました。
以下の測定結果は、All in One SEOに、Google Analyticsを設定した条件で測定した結果です。
以下の測定結果は、All in One SEOに、Google Analyticsを設定した条件で測定した結果です。レペートの診断結果の項目に「第三者のコードの影響・・・」とあります。次の図には、その詳細を示していますが、Google Analyticsが866msも使っています。
以下の測定結果は、All in One SEOから、Google Analyticsを外して、代わりにFlying AnalyticsでミニサイズのGoogle Analyticsを設定した場合の測定結果です。
以上の設定を全て組み込んで、PageSpeed Insightsで測定しました。
当初、1桁だった速度性能が、モバイルで50%程度、今回の取り組み始めには、パソコンでの性能評価は、気にしていなかったため、パソコンの速度性能値は、参考値になりますが、モバイルよりも 高い値のがでます。
指摘を受けなければ気がつかなかった、サイトの速度でしたが、当初1桁であったのが、50%まで速度性能を改善することができました。約10倍です。
更なる速度改善は、以下の項目が考えられますが、個人サイトで出来るものとそうでないものもリストしました。
その後、いろいと調べていると、Googleは、Mobile Firstであり、モバイルに対して特化したページ作りを求めていることが分かりました。
既存のページをAMP(Accelerate Mobile Page)という技術で、速度改善を可能にする開発を行なっていることも分かりました。
結局のところ、現在のページは、今後、生き残らないと判断し、AMP対応ページに移行することにしました。
2020/2/3からAMPプラグインをインストールして、セッティングを開始しましたが、2ヶ月経過した時点で、広告の表示やページ表示の不具合なども解消できました。
AMPプラグインにより、ページの表示速度は、GoogleSpeed Insightsのモバイルのスコアで、キャッシュプラグインを有効にしてですが、60~70%にまで改善しました。
AMP対応にするには、プラグインを使用しますが、これを使うと、「Autoptimize」プラグインの使用は、必要無くなります。
2020/01/25 はりきり(Mr)
2020/02/13 追記 (Google Fontの削除設定)
2020/02/23 AMPに対応
2020/04/15 「追記」を追記
2020/05/15 文言整備
![[WordPress] 親テーマを変更せずテーマをカスタマイズ – 子テーマを作り変更したを加える – 手始めは、content.phpの編集](https://harikiri.diskstation.me/myblog/wp-content/uploads/2020/01/40DF9B78-432F-4BA0-BE0A-E783141E6BEA-1200x838.jpeg)
いつまで続くか分からない当サイトの構築ですが、プラグインやphpファイルの変更など、他のblogerさんの記事を参考にさせてもらっていいます。
今回は、WordPressテーマ: Twenty Twentyを親テーマとして子テーマを作りました。
作った子テーマが有効になっていれば、「テーマの編集」画面の右上にある「編集するテーマを選択」にその子テーマのリストが出てきます。図1のように、twentytwenty_child (この名前は、実質的にフォルダ名)があるので、このテーマが有効化していれば、表示されます。以下、図1の説明です。
表示の体裁を変更する場合は、style.cssのコードの変更、コードの追加が必要です。以下のコードは、当サイトの目次の体裁を定義したものです。
/** 見出し
*/
/* h2
#contentを付けると左端に表示されるのが、幅に従った左端に改善できる
*/
h1,
.heading-size-1 {
font-size: 3.2rem;
/* font-weight: 800;
line-height: 1.138888889;
*/
}
h2 {
font-weight:600;
font-size:3.0rem;
color: #fff;
background: #2a49a8;
padding: 15px 30px;
}
h3 {
font-weight:500;
font-size:2.8rem;
/* 見出しの飾り */
padding: 0.25em 0.5em;
color: #2a49a8;
background: transparent;
border-left: solid 50px #2a49a8;
}
h4 {
font-weight:500;
font-size:2.6rem;
/* 見出しの飾り */
border-bottom: solid 3px black;
}
h5 {
font-weight:500;
font-size:2.4rem;
/* 見出しの飾り */
/* border-bottom: solid 3px black; */
}
h6 {
font-weight:500;
font-size:2.2rem;
/* 見出しの飾り */
/* border-bottom: solid 3px black; */
}
表示の構造自体を変更する場合は、content.phpのコードの変更、コードの追加が必要です。
content.phpが、WordPressにおける投稿や固定ページの表示を行っているメインのphpプログラムです。図1の例では、content(org).phpやcontent([番号])が、確認できると思います。
これは、プログラミングに際し、僕が格闘した結果の残骸です。捨てられずに残しています。content(org).phpは、オリジナルファイルです。元に戻す場合は、このファイルをcontent.phpに名前を変更したして置き替えます。
基本的に、子テーマでのこれらの修正は、親テーマの上書きになっているようです。
ファイルの複製や名前の変更は、WordPressからはできません。端末ソフトを使ってサーバーに入り、コマンドにより名前を変更したり、複製したりする必要があります。
当サイトでは、自宅のSynology NASにWordPressを導入しているので、Synology NASにログインして、DiskStation Managerのもとで、名前の変更、複製をします。その後、WordPressにログインして、「テーマの編集」画面に入れり、該当するするphpファイルのプログラムの内容を修正・追加していきます。
修正した後は、左下にある更新ボタンで修正内容を保存します。その結果は、直ぐにblogに反映されるので、サイトをSafariやChromeで表示して確認します。
このcontent.phpでのコードのミスは、即座に表示を崩していまうことを意味しますが、以下に記述したように元のコードに戻したり、追加したコードを削除して元に戻せば表示も元に戻ります。
画面が崩しれたりした場合、「テーマの編集」画面から、Ctrl + zにより元に戻して、更新ボタンを押せば、元に戻ります。
content.phpの編集と言っても、使用しているThemeごとに異なります。当サイトでは、WorpPress version 5以降で公式テーマになっているTwenty Twentyを使っています。標準のcontent.phpでは、表示のが味気ないので、coverタイプ (content-cover.php)をcontent.phpに置き換えています。同じTwenty Twentyのcontentではが、コードを確認してみるとだいぶ作りが異なっていました。
親テーマでは、標準で有効となっている編集時のオートセーブ機能とリビジョン機能ですが、子テーマの「functions.php」にコードを追加することで、無効化することが可能です。以下のリンクをご参照ください。
macoblogさんより
https://macoblog.com/wp-writing-autosave/
親テーマと子テーマの関係性が、まだよくわかっていません。
編集情報 ID 7726 2020/01/21 Mr.はりきり 2020/07/23 追記(concent.phpの編集)
以上
GT3 Photo GalleryはGutenberg editorで使用できるGallery pluginです。
Tooltipsは、日本語と英語の混在でも、単語を適切にサーチして吹き出し化できるpluginです。
Tooltipsを有効にしてある場合、GT3 Photoで20-30個の写真を投稿に入れると、管理画面からの保存も読み込みも著しくその速度は低下します。Tooltipsを無効にすると快適な速度に戻りました(2020/01現在)。
2020/04現在は、AMPプラグインによりAMP対応にしました。AMP下、GT3 Photoプラグインは、綺麗に見せることが売りのプラグインであったため、AMPのルールである、JavaScriptの複雑なコードを許さないことから、エラーするコードが多くありました。
そこで、GT3 Photoプラグインは外すことにしました。Tooltipsプラグインは、使っていませんが、現在は、同様の機能であるEncyclopediaプラグインを導入しています(2020/04現在)。
2021/01/02, AMP対応を更に進めるために、AMPプラグインが検査してAMPに非対応であるとリストされるプラグインを極力アンインストールしようと思い立ちました。まずは、Encyclopedia(せっかく、有償版を購入したが)をアンインストールすべく、これまでに登録したキーワードを、普通の投稿(post)に置き換える作業を進めています。完了すればEncyclopediaはアンインストールする予定です。
改善策は、Encyclopediaを使用することにしました。
CM Tooltip Glossary、GlossaryおよびLuckyWP Glossary,は、いずれも、日本語・英語の混在下では、英ワードを認識できない場合があります。具体的には、「is word単語」の場合、wordを認識できません。英語は単語の間に空白があり、日本語には空白がないことが原因だと考えられます。
2020/01/21, Mr.Harikiri
2021/01/02,追記(Encyclopediaをアンインストールすることに決めた)