こんにちは、Yotchanです。
本日はブログの高速化を目指してXserverからwpX Speedに引っ越した話をしたいと思います。
ブログの読み込みが劇的に改善されました。
XserverからwpX Speedへの引越し
この4月からブログを運営している上で、一つ気になることがありました。
それはブログの読み込みがかなり遅いということ。
記事数も増えたことや、プラグインの影響かなとも思いましたがどうにも2月以降からあまりにも重い気がする。
私のブログの問題というよりも私が利用しているXserverが重いのではないかと思い始めるようになりました。
そこで、調べてみるとXserverの運営元であるエックスサーバー社がWordPressに特化したwpX Speedというサービスを立ち上げていることを知りました。
wpX Speedのページをなんとなく見ているとブログが重い原因がなんとなく推測できるようになりました。
Xserverは謂わゆる共用サーバーであるため、他ユーザーの利用状況によってCPUやメモリが圧迫されて重くなることもある様子。
これが原因であったとしたら私が素人ながらちまちま工夫してブログの高速化に勤しんだところで焼け石に水です。
懸念点のwpX Speedの利用料金は思っていたよりも高くありません。
必要に応じてプランを変更できるので私は月額1200円のW1プランを検討してみることに。
私がXserverで契約していたプランはW10の三ヶ月コース。
月額料金は1200円とwpX SpeedのW1プランと金額は変わりません。
ブログを始めた当初はどれだけ続くか分からないので三ヶ月で選択しましたが、思っていたよりも続いたのでランニングコストを抑えようと12ヶ月のプランにしようとしましたが、何故かできない仕様。
同一プラン内での契約期間の変更はできず、上か下のプランにしか変更できない縛りを謎にXserverがしている模様です。
いずれにせよ運営元は同じエックスサーバー社ですが、Xseverにはほとほと愛想がつきました。
このような経緯で私はXserverからwpX Speedへ乗り換えました。
WordPressの引っ越しにかなり苦労
XserverからwpX Speedへ引っ越すことにした私でしたが、かなり苦労することになりました。
その理由は素人にはwpX Speed公式のXserverからの引っ越しマニュアルの理解が難しかったからです。
移行マニュアル：WordPressの移転
ブログを運営していく上でサーバーに触れることなんてブログの開設の時とGoogle系のサービスでDNSレコードに何かを記載せねばならない時ぐらい。
そう、ほとんど触れることのない領域なので知識が全くないわけです。
そのため、ある程度知識があることを前提に書かれている公式のマニュアルでは何を書いているのかさっぱり分かりませんでした。
そこで、大変参考にさせていただいたのが上記のブログ様。
かなり詳細に書かれているので概ね、このブログの通りに作業を行えば失敗はありません。
それでも詰まる点はいくつかあったので本記事にてそれを補足していくスタイルで書いていきます。
引っ越し作業を行う前に必ずやっておきたいこと
実際に引っ越したからこそ感じる、移行前にやっておけばよかったことをあげます。
- プラグインを極力全て削除しておくこと
- 「Updraft Plus Backups」でWordPressのバックアップを取っておくこと
これら2つの作業は行なっておいた方が移行作業が楽になることが予想されます。
特に、後者の「Updraft Plus Backups」でバックアップを取っておかねば私はブログを引退していたかもしてません。
それほどまでに助けられたプラグインです。
不要なプラグインを極力削除しておいた方がいい理由は移行に際してエラーを引き起こす可能性があるからです。
私の環境で不具合の出なかったプラグインを以下に記します。
- AddToAny Share Buttons (シェアボタン)
- All In One SEO Pack
- AMP
- Google xml sitemap
- Image Watermark
- NextScripts: Social Networks Auto-Poster
- Search Regex
- Throws SPAM Away
- TypeSquare Webfonts for エックスサーバー
- WP 404 Auto Redirect to Similar Post
- WP Downgrade | Specific Core Version
次に、私の環境で不具合の原因となったプラグインも示します。
- Count per day
- EWWW Image Optimizer
- Rank math SEO
- Yoast SEO
これらのプラグインを利用している場合は移行前に停止し、WordPressから削除しましょう。
特に、キャッシュ系のプラグインは相性が悪いようなのでそれに類するものは漏れなく削除しておくのが無難でしょう。
wpX Speedはそれらのプラグインを使わずとも非常に高速であるため、無用になります。
補足としてユーザーが多いであろうEWWW Image Optimizerは移行後にインストールしなおせば利用できることが確認済みなのでご安心ください。
実際にこれらのプラグインがどのような不具合を引き起こしたかはこれから記載していきますので最後までお読みください。
まずはwpX Speedを契約しましょう。
wpX Speedの契約
まず、作業を始めるにあたって行うべきことはサーバーの契約です。
その理由は退路を断つため。
サーバーの移行はかなりめんどくさいので、先に移行先サーバーを契約して意地でも作業せねばならない状況を作らないと先延ばしにしてしまいがち。
ブログを高速化するという強い意志を持つために、まずはサーバーの契約をしましょう。
wpX Speed公式サイト
FTPソフトの選定
まず最初に調べたことはFTPソフトの選定。
参考にさせていただいたブログ様の環境はどうやらWindowsの様子。
私はMacユーザーであるため別のFTPソフトを用いなければなりません。
そこで利用したのがFileZilla。
無料かつ最初に目についたというだけの理由で選択しましたが、サーバー移行において支障は全くなかったのでFTPソフトにお悩みの方は使って見てはいかがでしょうか。
FileZilla：公式ページ
ドメインの追加
wpX Speedへの引っ越しの最初の関門はドメインの追加。
認証方法は 4つあり、参考ブログ様はWeb認証にしていたので私も踏襲することに。
ぱっと見Web認証が一番簡単そうに見えたんですよね。
しかし、指定の通りに「wpx.html」をアップロードしても反映されません。
そこで、私はCNAME認証を行うことにしました。
CNAME認証の説明も意味がわかりませんでしたが、サーバーパネルをいじくり回しているとやり方が分かりました。
この手の作業は本当に素人には優しくない。
Xserverのサーバーパネルにログイン。
ドメインの「DNSレコード設定」を選択します。
DSNレコードの新規追加を選択。
種別から「CNAME」を選択し、必要事項を入力します。
これで楽勝かと思いきや、まさかの罠がありました。
ここに書いてある通りに入力してもエラーが発生します。
その原因はコンテンツ部分にありました。
コンテンツはDNSレコードにおける「内容」に相当する項目ですが、ここに記載する内容がコピペ通りというわけにはいきませんでした。
wpXにはコンテンツ「www.wpx.ne.jp.」となっていますが、実際にDNSレコード内容に入力するものは「www.wpx.ne.jp」でした。
たかがドット、されどドット。
解決した際に何の罠やねんと思わずツッコミながら次の作業へと進みました。
wpX Speedでのデータベースのインポート
データベースからのエクスポート・インポートの項の「インポート」からの復元では何度試行しても成功したのか失敗したのかすら表示されずにある程度時間が経ってからwpXの管理パネルの画面に戻っていました。
Safariではアップロード状況が見えないのでChromeにブラウザを切り替えても変わらず。
そこで、面倒になったのでWordPress簡単移行を実行してみましたが「バックアップデータの取得に失敗しました」となってあえなく断念。
最後の手段として渋々、XserverからのWordPressデータのエクスポート時に用いた「phpMyAdmin」を介してインポートすることに。
しかし、ここでまたドツボにハマることになるとは・・・。
まず、参考ブログのデータベースのインポートの項の「エラー例1）」のようにサイドバーからインポート先のデータベースを指定していなかったパターン。
そして、最悪に面倒だったのが「エラー例2）」が発生したこと。
エラー
SQL query:
CREATE TABLE
wp_options(idint(10) unsigned NOT NULL AUTO_INCREMENT,namevarchar(100) COLLATE utf8mb4_unicode_520_ci NOT NULL,paramstext COLLATE utf8mb4_unicode_520_ci NOT NULL,
PRIMARY KEY (id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_520_ci;MySQL のメッセージ:
#1273 – Unknown collation: ‘utf8mb4_unicode_520_ci’
私のインポート時に発生したデータはこちら。
これを一つ解決してもまた違うテーブルで同じエラーが出てきました。
そこで、エクスポート元であるXserverの「phpMyAdmin」からWordPressの構造データを見てみると理解できました。
wpX Speedに対応していない「utf8mb4_unicode_520_ci」で構成されているテーブルが大量にあることが判明。
すでにオリジナルデータのバックアップは取っている状態なので躊躇いなく「utf8-general-ci」以外で構成されているデータを削除しました。
wpX Speedで読み込まれずにエラーが出るものを置いておいたら一生進まないですしね。
「Count per day」、「Ewwio images」や「Ranakmath SEO」「Yoast SEO」など割と有名どころのプラグインのデータでエラーが出るみたいですね。
サーバー移行元で移行前に全てのプラグインを削除してから作業を行うのが無難な予感。
移行後にこれらのプラグインをインストールし直せば問題なく動作するので。
何はともあれ、「utf8mb4_unicode_520_ci」で構成されているテーブルを全て削除することで無事にデータベースのインポートが完了しました。
WordPress 記事コンテンツのインポート
前サーバー時点でエクスポートしたデータのインポートですが、私は何度試行しても成功することはできませんでした。
30MB程度のXMLファイルをアップロードしているのにもかかわらず、インポートを実行すると「ファイルがありません」と表示されるばかり。
とはいったものの、何故かインポートできなくとも投稿データなどはダッシュボードにあったので支障はありませんでした。
おそらくは先のデータベースのインポート時にWordPressのバックアッププラグインである「Updraft Plus Backups」から各種データが読み込まれたものと推測しています。
実は私はデータベースのインポートが終わる前に「WP Contents」フォルダをFTPにてwpX Speedにアップロードしていました。
もしかしたらそれも関係しているかもしれません。
先の項のデータベースのインポートに失敗している状態でも何故かダッシュボードにアクセスできたんですよね。
そのため、気にせず作業を進行した結果、データベースのインポートが最後になったという珍しい作業順序に。
記事コンテンツのインポートに失敗しても支障がなかった理由はおそらく、ドメインがサーバー移行前後で同一であるため、wpX管理パネルからダッシュボードに飛ぶと稼働中のXserverのダッシュボードへアクセスされていたから。
WordPressをインストールするだけして放置していた無料ドメインで実験したことによりこれは推測されました。
実験内容
無料ドメインを利用してWordPressサーバー移行のメカニズムを知るための実験。
まずは移行前後でドメインが同一かつ移行先サーバーでデータベースをインポートできていない状態でもダッシュボードにアクセスすると、従来と全く変わらず投稿記事などが表示されることを確認。
その状態で移行元であるXserverからドメインを削除して、wpX管理パネルからダッシュボードにアクセスするとまっさらの状態のダッシュボードとなった。
このことから、データベースのインポートに失敗している状態でもダッシュボードに変わりなくアクセスできていた理由は「wpXの管理パネルからXserverで稼働中のWord Pressのダッシュボードにアクセスしていたから」であることが裏付けられました。
まぁ、この時点ではネームサーバーも変更していないのでドメインが同一であれば移行前のサーバー上のWordPressにアクセスされるのは当然ですよね。
WordPressの引っ越しはまだ作業中で完了していないわけですし。
実際にサーバー移行ができているかの確認
ネームサーバーも書き換えて、一通り作業が完了したら気になることと言えばちゃんとサーバーが切り替わっているのかな？ということ。
一見、ダッシュボードに問題なくアクセスできていても前のサーバーのダッシュボードにアクセスしているからそう見えるだけかもしれません。
そこで、WordPressが稼働しているサーバーの情報を見るプラグインを導入しました。
Server Infoをインストールするとサーバーのホストネームが表示されます。
ホストネームが「wpx.ne.jp」となっていれば無事成功です。
私が最初に確認した時は、作業が完了したにもかかわらず、「Xserver.ne.jp」となっていて非常に困惑しました。
それには原因があり、私の場合はデータベースのインポートに失敗しているにもかかわらず作業を続けたことに起因していると予想されます。
そうとは知らずにネームサーバー自体はwpXに切り替えていたので、もしかしたらデータベースのインポートは関係なく、単純にサーバーが切り替わるまでのタイムラグがあっただけかもしれません。
このサーバーの切り替わりもよくわからないんですよね。
UQモバイルとソフトバンクの回線でダッシュボードにアクセスするとwpXのサーバーに繋がりました。
しかし、WiMax回線でダッシュボードにログインするとホストネームがXserverと表示される。
この現象はあまりにも謎でしたが、意味不明ですし考えるのが面倒になって寝て起きたらWiMax回線でもwpXサーバーに接続されるようになりました。
地獄の幕開け：カテゴリーが消えて新規作成もできない
どの回線でもwpX Speedで稼働するようになったので無事にサーバー移行ができたっぽいしやったぜ！ということで記事を書こうとするとあることに気づきました。
投稿の「カテゴリーデータが消えている」ではありませんか。
消えているぐらいであれば面倒だけど一から設定すればいいやと楽観視していましたが、そうはいきませんでした。
なんと、カテゴリーを新規作成しようとすると「キーワードなし」と表示されてカテゴリーの作成ができません。
それっぽいものは出来上がるのですが、どれもIDの値が0で有効なカテゴリになりません。
作成に失敗したものを削除することも何故かできず、ゴミみたいなデータだけが膨れ上がっている地獄絵図。
データベースインポート時にphpMyAdminでテーブルを消したことが影響しているのかと考えましたが、これはどうしようもない。
消さないとそもそもインポート自体ができないのですから。
WordPressを最新や過去Verにダウングレードしたり、The Thorのテーマを更新したりしても一向に解消されません。
プラグインを全てオフにしてみてもダメ。
何故だ・・・。
こんな地獄のような状況から解放してくれる救世主の存在に私は気づきました。
そう、WordPressのバックアッププラグイン「UpdraftPlus Backups」です。
救世主「UpdraftPlus Backups」
UpdraftPlus Backupsは2ヶ月ぐらい前に何となく導入していたバックアッププラグイン。
記事数もたまってきたし、これからもブログが続きそうなので保険として導入していました。
バックアップとは概して非常時にしか活きない日陰の存在。
私はこのプラグインを入れていたことすらすっかり忘れていましたが、プラグインをオフにしているときに存在を思い出しました。
そこで、サーバー移行前の直近のバックアップデータからデータベースを復元すると・・・。
カテゴリーが復活した！！！
喜んだのも束の間で、カテゴリー復活の代償があることにまたしても気付くことになりました。
それは記事が一部消えているということ。
私はサーバー移行作業に8日の深夜1時から着手していました。
読み込んだバックアップデータは3日の分。
つまり、3日から8日までに執筆した記事データはバックアップデータに存在しないということを意味します。
そこで、再度カテゴリーが消えている8日のバックアップデータを読み込んで3日のバックアップデータから失われていた5記事を別のWordPressの下書きに保存。
改めて3日のバックアップデータで復元し、5記事を再度編集し直して公開するという作業を行いました。
これでめでたくサーバー移行前と同じ環境を用意することができました。
作業時間にして丸一日。
UpdraftPlus Backupsが無ければ私はカテゴリーを設定できないWordPressでぐちゃぐちゃなブログを運営するか、萎えてやめるかの未来を辿っていたでしょう。
ありがとう、UpdraftPlus Backups。
サーバー移行後の読み込み速度
このような苦労を経てXserverからwpX Speedに移行したわけですが、その苦労に見合う価値はあったのか。
価値はありました。
めちゃめちゃブログが軽くなり、読み込み速度が劇的に改善。
Search Consoleの速度の結果でもサーバー移管後は低速が0件になりました。
やはりXserverは他のユーザーによる負荷が大きかったのかなと思います。
体感速度で2倍以上は速くなっているので、ちまちまブログの高速化を試行錯誤するよりも効果的です。
手間はかかりますが、ランニングコストは変わりません。
それにも関わらず圧倒的に読み込み速度が速くなるので正直、Xserverを使う理由はないのではと思うほど。
WordPressユーザーは間違いなくwpX Speedを契約するべきです。
wpX Speed
コメント