AdSense を設定してみるがサブドメインあかんみたい?

さて、最近このサイトを自宅サーバに引っ越すためあれこれ準備をしています。

自宅サーバになったら、AdSense もやってみたいなと思って登録しようと思いました。

Google AdSense
https://www.google.com/adsense/

が、登録中、以下のようになります。

Google AdSense

マニュアルによれば、サイトの追加からできるようですが、これをやるにはまずメインのドメインを追加して認証させないとだめみたいです。

サイトリストでサブドメインを追加または削除する
https://support.google.com/adsense/answer/9130110?hl=ja

メインのドメインっていうと、gpl.jp や http://www.gpl.jp というものですがこれはとりあえず運用していません。しかし、とりあえずサイトを起動させておかないと許可が降りないのかな? ま、そういうのはやってみればわかりますね。やってみましょう!

次のステップでは、マルチサイト機能を使ってメインドメインを動作させてみようと思います。ClassicPress でもできるはずですので動作確認も兼ねてみましょう。あと、ローカルの MAMP Pro 環境で Let’s Encrytの SSL をワイルドカードで出来るかやってみようと思います。

・ClassicPress で マルチサイトを立ち上げる

・MAMP Pro 環境でLet’s Encryt のワイルドカードSSLを設定

とりあえず、このようなネタをあげる予定です。

 

高速化その3:画像圧縮してみた!次世代画像フォーマット「WebP(ウェッピー)」を使う

以前、スマホからのアクセスをもっと速くしたいなと思っていたのですが、高速化その3で手をつけることにしました!
まず、手をつける前の状態は以下です。

E383a2e3838fe38299e382a4e383abe382b5e382a4e38388e381aee9809fe5baa6e38292e6af94e8bc83e38197e381bee38197e38287e38186

はい、2.2秒かかっていたようです。レポートには、いろいろ書いてありますが画像の項目は以下のようにアドバイスされていました。

次世代フォーマットで画像を配信する
JPEG 2000、JPEG XR、WebP で画像をエンコードすると、読み込み時間が短くなり、モバ
イル通信のデータ量も少なくすることができます。フォールバック用に PNG 画像や JPEG 画
像も用意し、未対応ブラウザにはそちらを配信するようにしましょう。

ということで、WebP に変換することことにしました。変換には方向性として2つあり、1つはクラウドサービスでWebPに変換してもらうのを利用する方法。もう1つは、自サーバの機能を使ってWebP に変換する方法です。後者は、PHPがimagemagic をサポートしていてそのフォーマットにWebP がある場合に有効です。

phpinfo.phpにアクセス → サーバー設定のレポートを見る。
「imagick」項目の “ImageMagick supported formats” という行に「webp」があればサポートしています。

現在はまだテストサーバで mamp でやっていますので、これはサポートしていないことがわかりました。自分でサーバを作るときは対応させる予定ですが、今のところは外部クラウドのWEBサービスを使って高速化がどのくらい進むか確認してみようと思います。

パッと思いつくのは、https://tinypng.com/ のサービスです。

TinyPNG Compress PNG images while preserving transparency

これをWordPress(ClassicPressでも利用可)で利用するPlugin があるので使うことにします。

Compress JPEG & PNG images
https://ja.wordpress.org/plugins/tiny-compress-images/

Plugin を有効にして、API をゲット(月に500まで利用可)です。メディア設定の自動リサイズを無効にして、medium_large_size_h のパラメータも以下から0 にしておきます。

https://yourdomain/wp-admin/options.php

設定は以下のようにしておきました。

高速化 アリエクでポチった JunkHack と Compress JPEG PNG images アリエクでポチったJunkHack ClassicPress

どのくらい高速化が進んだか確認してみましょう!

モバイルサイトの速度を比較しましょう

結果、1.7秒です。0.5秒改善しましたね!

あとついでなので、Autoptimize プラグンで JS と CSS の最適化をしておきました。これは有名なんで説明は省略。

Autoptimize
https://ja.wordpress.org/plugins/autoptimize/

結果、高速化その3では最終的に、1.2 秒にまで改善できました。

モバイルサイトの速度を比較しましょう

あと、0.3秒ほど頑張れば1秒以下になって「速い」の部類に入るかと! あとはサーバ側でがんばりましょうか。

・・・高速化その4 に続く

高速化その2:ClassicPress を入れてテーマを調整

宅内サーバのテスト環境で、テーマの調整とClassicPress を試しにインストールしてみました。Classicpress logo wordmark gradient on transparent

enひかりの IPv6 トンネルもかなり有効だと思いますが、なかなか良いスコアが出たので記録しておきます。ちにみに、純粋なClassicPress にした速度向上というのはわずかです。テーマの部分が大きいかなという印象です。

PageSpeed Insights

Google の PageSpeed Insights の結果です。ずっと99% であと1% が上がらなかったのですが、画像の遅延読み込み(※1)を行なったら100% になりました。現在のWordPress.com 上にあるデータと変わりないのに、テーマとかWordPress 本体を ClassicPress にして enひかりの v6ひかり+固定IPの環境にしただけです。 1秒未満なので、とりあえずは十分な結果がPCは出ていますね。ちなみに、開発環境は以下の通り。

WEB:NGINX1.13.2(MAMP Pro)
PHP:php7.4.1(MAMP Pro)
DB:MySQL 5.7.26(MAMP Pro)

Server CPU:AMD Ryzen 5 3600
RAM:32GB
DISK:SSD

CMS:ClassicPress 1.1.2
テーマ:Sustyバージョン: 1.0.0
WP Plugin:
 Akismet Anti-Spam 4.1.4
 AMP 1.4.4
 Broken Link Checker 1.11.11
 Catch Infinite Scroll 1.7
 Lazy Load 0.6.1
 Switch to ClassicPress 1.2.0
 WordPress インポートツール 0.7
 WP Super Cache 1.7.1

 ※1・・・画像の遅延読み込みとは、ブラウザが最初に「スクロールせずに見える」ページの画像のみを表示し、スクロールしたときに画像を読み込むということです。これらを簡単に実現するため、Lazy Loadを使っていますがやり方はいろいろあるようです。

モバイル環境については、まだ向上の余地がありそうです。JS の調整がまだ残っています。

PageSpeed Insights

ClassicPress は、wordpress5.3.2 から switch-to-classicpress プラグインを入れて行いましたがなんのトラブルもなくできました。ClassicPress にして明確になったのが、jetpackプラグインはない方が絶対的に速いです。また、ストレージ容量が ClassicPress は20MB くらい減りファイル数も300くらい減りました。

今の所、可もなく不可もなくといったところでしょうか? しかし、良いなと思うのは ClassicPressバージョン1.xは、長期サポート(LTS)バージョンということで安定して動作してくれそうな気がします。プラグインも同じようにインストールすることができて、動作するものは「Compatible with your version of ClassicPress」と表示されますので目安になりますね。

プラグインを追加 アリエクでポチったJunkHack ClassicPress

というわけで、方針としては ClassicPress を使っていくことにしました。そして、jetpackプラグインはもう使わないことにします。テーマは、Sustyをカスタマイズして使うことにします。

宅内サーバのWEBアプリと高速化のキャッシュ方法を検討!

自宅サーバに適用する構成について、最近のWebアプリ周りのサーバ側事情を調査していました。
まず、このブログを宅内で動作させるには WordPress を動作させることが必要です。で、その構成をどうするか検討することにします。以下のようなことを考えないといけないですね。

OS:Linux で動作させますが、どのディストロビューション
(CentOS とか Fedora とか ubuntuとか)にするか?
Web:NGINX とか apache とか。
PHP:PHP7 とか HHVM とか。またはその動作方法php_fpm とか、mod_php とか。
データベース:MariaDB とか、MySQL とか。

また以下の点については、趣味のブログなので作りながら考えていくことにします。

冗長性:これは当面、1台動作で考えないことにします。落ちたら、なるはやで復旧。
運用監視:外部監視をどうするか?
バックアップ:どっかにデータをバックアップしないとです。
保守:マシンが壊れた時、または停電時など。

めんど臭いですね!(笑)ま、当初からわかっていたことですが改めて書くと考えることが多いです。

で、改めて最新の動向も探りながら、ざっくり検討することにしました。動作させるマシンはもうすでに決定済みで、前回までに決めた Ryzen 5 Pro 3400GE が動作するマシンです。Kernel を最新にしたいということもあり、Fedora かubuntuあたりにしようかと思っています。

肝心の Webサーバは、NGINX + HHVM という構成が有力でしたがどうやら最近は事情が変わっているようです。2013年〜2014年に検討した時、HHVM の高速性にはびっくりしたのが印象的でした。24時間アクセス(vmで2台構成)のベンチマーク耐久テストでも落ちなかったのを覚えています。24時間で、400万PVを達成しました。1秒間に、約46回の処理をした計算になります。ま、その直後は vmホストのSSD がぶっ壊れましたが(笑)しかし、残念なことにHHVM は、今やPHPコードを動作させることができなくなったようです。

RIP WordPress and HHVM – We’ve Had a Good Run

ちょっとショックだったので、オフィシャルサイトのドキュメントも確認しておきました。HHVM v3.30 がPHPサポートの最終とのこと! 2018/12/17 だって。もう1年以上前か。

Ending PHP Support, and The Future Of Hack

改めて最新の動向を見てみると、どうやら LiteSpeed というWEBサーバのほうが良さそうです。2015年のネタなので現在は状況が変わっているかもしれません。

PHP7 vs HHVM Benchmark Series 1: Hello World

そして、現在は HHVM よりもPHP7 が良い結果が出ているそうなので、LiteSpeed のオープンソース版である OpenLiteSpeed を使うことにしました。とりあえず、以下のような構成でいこうかと。openlitespeed-logo-1200x300.png

OS:Linux(Fedora 31 server)
Web:OpenLiteSpeed 1.6.x
PHP:PHP7.x
データベース:MariaDB10.x
WordPress代替:ClassicPress ★代替えの必要があるかちょっと使ってみる
キャッシュ:LiteSpeed Cache WordPress

LiteSpeed のWEBサーバと、WordPress のPlugin であるキャッシュ(LiteSpeed Cache WordPress)は専用設計のようです。そして、このキャッシュはWordPress代替のClassicPressでも動作するようです。

LiteSpeed Cache for WordPress
::
LiteSpeed Cache Works With ClassicPress

LSCache(青いグラフ)がそれみたいですが、速そうですね。

screenshot-1.png

また、OpenLiteSpeed と LiteSpeed との違いは以下に機能比較があります。

OpenLiteSpeed or LiteSpeed Enterprise?
https://www.litespeedtech.com/products/litespeed-web-server/editions

WordPress代替のClassicPress は一度、ローカルに入れて検討してみないとですね。

Get ClassicPress
https://www.classicpress.net/get-classicpress/

ということで、今後の課題が見えてきました。ちょっと目を話すとどんどん状況が変わるからこの業界は面白いんですよね!

CDNを使わずWEBアクセスのロードタイムが1秒を切った!

ちょっと前に、このブログのロードタイム、1秒を切りたいと話していました。

スマホからの表示速度を1秒以下にしたい!

で、enひかりの固定IP配下に作ったテスト環境でこのブログと同等のデータを引っ越して速度向上を検討していました。まず、現在の結果から出してみたいと思います。モバイルサイトの速度を比較しましょう

3.8秒から、2.2秒までアップしました。スマホ表示にはまったく手をいれていませんが、1.6秒縮まりましたね!

また、PCでのアクセスは別サイトで計測しました。まずは現状の確認。

WebPageTest Test Result Tokyo junkhack gpl jp 03 16 20 02 26 41

「LoadTime」の部分が全体を表示するまでにかかっている時間です。では、検証用に立ち上げているサイトでも同様に見ていきます。

WebPageTest Test Result Tokyo hoge gpl jp 03 16 20 03 10 36

なんと、1秒を切っています!4.5秒からなんと0.98秒までアップしました。
CDN を使わなくてもここまでアップできるものなんですね。まだチューニングする部分はたくさんありますが、今年の夏引っ越しに向けて、あれこれ研究していきたいと思います。

今回速度の向上に関して、確認したことといえば以下となります。

・WordPress のテーマは軽いのがいい → Susty WP に変えた
・CDNは使っていないが、Jetpack のCDN機能を使いました → これはあまりよろしくないかも(要研究)
・表示を10から3に変えた → もっと見たい人はほぼいないし、見たければ検索なりしてくれるから
・回線をenひかりの IP固定 v6プラス の自宅サーバにしてみた → WordPress.com はデータセンターがUSにあります。v6網のバイパスはかなり有効!

CDN は、DNS の ns を切り替えないといけなしそれなりに弊害もあるのでたぶんやらないと思います。使わなくてもここまでできるなら、あとは微調整でもっと速くなるかもしれません。Jetpack のCDN機能を使った影響なのか、それ以外が原因なのかわかりませんが、以下のように空白の時間があります。

Latest Performance Report for http hoge gpl jp GTmetrix

ということで、ロードタイムが1秒を切ったという話でした。まだまだ研究する部分がたくさんありますので、継続してあれこれやってみたいと思います。

 

 

 

 

スマホからの表示速度を1秒以下にしたい!

ブログの表示速度について、ちょっと調べてみました。

まずは測定結果からどぞ。

111

なぬぅー! 遅いですか。ふぅ。まぁ、3.8秒はちょっとイラっとするかもね。

現在は、WordPress.com の一番安いプランを使って運用していますが、この更新期限が2020年10月16日にくるんですよね。まだあと半年くらい先なんですが、やっぱり自分で運用してみようと、考えています。

まぁお金をあまりかけずに、1秒とか1.5秒とかにできれば嬉しいのですが。そういう目標をもってやっていきたいですね。

テストサイト Googleはこちら。

モバイルサイトの速度を比較しましょう
https://www.thinkwithgoogle.com/intl/ja-jp/feature/testmysite/

MWebを使ってみた

macos で、何かよさげな Markdown エディターを探していたら、MWeb というのがあるので、少し試してみました。Markdown 記法はあまり慣れていないし、苦手です。画像貼り付けなんかは特に面倒なので、このエティターを使ってブログを書くとどんな感じになるかテストしています。


ちょっと実際に画像を貼り付けてみましょう。例えば、このツールで投稿するときに出るダイアログ画面を撮って載せてみます。

この画像は、Skitch というスクリーンショットを撮るツールからドラッグ&ドロップで載せています!かなり便利ですね。実際に、画像を Markdown 記法で書くと以下のように書かないとだめです。面倒ですので、これはツールに頼ったほうがいいですね。
![](media/15819643984967/15819656473963.png)
 ※冒頭の!は、半角の! です。

ライブプレビュー画面もあるのでどんな感じで表示されるかも確認しながら編集できるのはいいですね。

以下は、このエディターを起動したときにデフォルトで記載される内容です。日本語翻訳して実際にブログに反映させてみるテストです。少しづつ使って慣れていきたいと思います。

ようこそMWeb

MWebは、Mac、iPad、iPhone用のプロフェッショナルなMarkdownライティング、メモ作成、静的なブログジェネレーターアプリです。MWebの特別な機能を次に示します。

ソフトウェア

  • サポートするネイティブテクノロジーを念頭に置いて作成されています。これは常にプラットフォームとの完全な統合です。
  • 最新のUIと高性能を目指し、強力で使いやすく、完全な機能を備えています。

Markdown記法

強力な syntax

  • デフォルトでGitHub Flavored Markdown(GFM)を使用します。
  • テーブル、TOC、LaTeX数学、フェンスコードブロック、タスクリスト、脚注などの作成のサポートに含まれています。
  • Graphviz, ECharts, PlantUML, js-sequence-diagrams, およびフローチャートのいずれかでグラフィックを簡単に生成します。

編集アシスタント

  • G画像の挿入を適切に処理します:直接コピーと貼り付け、ドラッグアンドドロップ、およびエディターでのフルカラープレビュー。
  • Markdown互換の構文で画像サイズを指定します。
  • テーブルとLaTeX方程式を簡単に挿入します。

ノートを書く

  • タグ付けシステムを使用して、すべてのドキュメントをツリーのような分類ライブラリに保存および管理します。カテゴリを適切にエクスポートしたり、静的なWebサイトに変換したりできます。
  • 簡単なメモを書けます。
  • ライブラリ全体から即座に検索します。

出力

  • HTML、EPUB、PDF、RTF、Docx、さらには画像など、さまざまな形式でコンテンツをエクスポートします。
  • Wordrpess、Metaweblog API、WordPress.com、Evernote、Blogger、Medium、Ghost、Tumblrに記事を公開できます。
  • 画像アップロードサービスのスムーズなサポート:Imgur、SM.MS、Qiniu、Upyun、Tencent Cloud COS、Aliyun OSSまたはカスタムAPIを使用します。

外部ドキュメント

  • MWebには、ディレクトリ内の既存のマークダウンファイルをインポートできる外部モードがあります。また、Gitbook、JekyII、Hexoのコンテンツも処理します。

MWeb公式ヘルプ

MWebを使用する前に、MWeb公式ヘルプドキュメント: https://www.mweb.im/help.html を最初に読むことをお勧めします。
ライブラリモードを使用する場合は、最初にこのリンク https://www.mweb.im/mweb-library.html を確認してください。

MWebの改善にご協力ください!

  1. 言葉を広める!MWebが気に入ったら、友達に教えてください。
  2. フィードバックを送信: coderforart+2333@gmail.com
  3. Mac App Storeでレビューまたは少なくとも評価を残してください。