また1つ技術ブログの記事を書きます。前回のAlibaba CloudのCDNとRDSサービスの使用およびWebサイトのアクセス速度最適化に続き、まだ改善の余地があったため、引き続き試行錯誤してサイトのさらなる高速化を図りました。
まずはAlibaba CloudのOSSサービスの使用です：
当サイトは画像が多いため、現在各ページの読み込みには約2〜4MBのデータが必要です。しかし、サーバーの帯域幅はわずか2Mしかなく、単一ユーザーが全速力でページを読み込むだけでも8〜16秒かかり、到底許容できるものではありません。CDNを使用しても、ユーザーがそのファイルをキャッシュしていない新しいノードからアクセスした場合、ECSからデータを読み取る必要があります。この時、2Mの帯域幅は深刻なボトルネックとなります。そのため、OSSの使用は非常に良い選択です。Alibaba Cloud OSSの出口はBGPマルチラインであり、帯域幅制限もありません。
Alibaba Cloud OSSの価格は非常に安価で、料金は3つの部分に分かれています。
- ストレージ：50TB以下の場合、1日あたり0.0058元/GB、1時間あたり0.00024元/GBです。Alibaba Cloudの課金方式は時間単位で計算され、端数は切り捨てられます。最小単位は0.01元であるため、45GBに達して初めて毎時1分钱（0.01元）の課金が開始されます。それ以前は無料です。
- トラフィック：8時から0時までは0.75元/GBです。これを換算すると約0.0007元/MBとなり、1時間あたり約14MBのトラフィックごとに1分钱（0.01元）課金されます。14MB以内は無料です。0時から8時は半額となります。
- リクエスト：1万回あたり0.01元です。同様に、1時間以内に1万回未満であれば無料です。
私のサイトのようにストレージが1GB強で、毎時のリクエストが数百回程度の場合、課金される可能性があるのはトラフィックのみです。CDNのトラフィック料金はOSSの半分であるため、OSS+CDNは高速かつ安価な優れた選択肢となります。これにより、ユーザーがCDNノード上にキャッシュされていないファイルにアクセスした時のみOSSへリクエストが行われ、その際にOSSの課金が発生します。CDNノードにファイルがキャッシュされていれば、CDNの料金のみが計算され、OSSのトラフィックは発生しません。
実は1ヶ月以上前からOSS+CDNの使用を開始しており、実際のところ費用はCDN単体使用時とほとんど変わりませんでした。したがって、クラウドサーバーECS + リレーショナルデータベースRDS + オブジェクトストレージOSS + CDNこそが究極のソリューションと言えます。もちろん、アクセス数がさらに増えれば、複数のECSを使用して負荷分散を行うことも可能です。
次に実際の操作について説明しますが、データをOSSに移行するのは簡単なことではありません。まずはサービス有効化ですが、この部分は簡単です：
新しいバケットを作成します：
オブジェクト管理では、基本的なファイルのアップロードや削除などの操作が行えます：
設定画面の説明に従って、独自のドメインをバインドできます：
次にCDN設定で、バケットをオリジンとする新しいドメインを作成します。
CDNを使用するバケットとドメインを選択し、少し待つとCNAMEが取得できます。ドメイン管理画面で設定を行えば使用可能になります。
次のステップは、当サイトのすべての画像をOSSに保存することですが、これは決して容易ではありません。ファイル数が非常に多く、フォルダ階層構造も複雑な上、OSSにはFTPのようなアップロードツールがありませんでした。その後、OSSExploreというツールを見つけました。Windows上でFTPライクなOSS管理を実現でき、少なくともフォルダ単位でのアップロードが可能です。実際にはバグも多かったものの、何とか画像をアップロードできました。その後、データベース内の画像アドレスを検索・置換しましたが、こちらは比較的簡単でした。
Alibaba CloudのWordPressプラグイン
WordPressの管理画面からアップロードしたファイルを直接OSSに転送し、アクセスURLもOSSのものに変更するには、対応するプラグインが必要です。これが本当に探すのが大変でした。ネットで見つかるものはダウンロードできないか、すでに古いものばかりで、結局使えるものは一つも見つかりませんでした…。
最終的にAliyun OSS Supportというプラグインを見つけました。比較的新しく更新されており、いくつかバグを見つけて作者のIvan Chou氏に連絡したところ、すべて無事に解決しました。そこで、ここでこのプラグインをお勧めします。ファイルを削除するとOSS上でも削除され、OSSへのアップロードと同時にローカルディスクにバックアップを残すオプションもあります。現時点でWordPressにおいてOSSを比較的良好にサポートしている唯一のプラグインと言えるでしょう（改善の余地はまだありますが）。作者の努力に深く感謝し、今後さらに良くなることを期待しています。
プラグインの削減
ご存知の通り、WordPressは多様なプラグインと使いやすさで知られていますが、プラグインには問題も多くあります。特にバージョン互換性の問題や、複数のJS/CSSファイルの参照によるリクエスト数の大幅な増加などです。一度でも中国のファイアウォール外にあるファイルを参照してしまうと、さらに厄介なことになります。MinifyなどのJS/CSS結合プラグインを試してみましたが、大きな効果はありませんでした。
そこで、プラグインを使わずに解決できる問題は使わないようにしました。多くの機能はテーマのfunctions.php内のコードで実現可能です。例えば、Google FontsのURLの置き換え、コメント返信通知メールの送信、標準搭載jQueryの読み込み禁止、検索対象からページを除外するなどです。
以前はAddThisなどの共有プラグインを使用していましたが、後にブロックされたためJiaThisに切り替えました。その後、共有にはWeiboとWeChatだけで十分だと考え、Weiboのネイティブ共有ボタンを直接使用することにしました。これにより、投稿元として自分のサイトを表示することもできます~~~。Fancyzoomも修正を行い、リクエストされるリソースをすべてCDNに転送しました。
その結果、現在精简後に使用しているプラグインは以下の数個のみで、大部分はバックエンドで使用されるものであり、フロントエンドでは全く読み込まれません：
WP Super Cache
これが主に解決したのは、TTFB（Time To First Byte）が長すぎるという問題です。トップページで呼び出すデータが多すぎるのかどうかは分かりませんが、各ページのTTFBが常に300〜500msの間で推移しており、かなり長い方でした。このサイトにはインタラクティブな要素が少なく、記事公開後も頻繁に変更されることはないため、完全な静的キャッシュ化は非常に有効な解決策です。
WP Super Cacheプラグインはまさにこれを実現するものです。URLリライトを通じて、本来動的に生成されるページを一度だけ生成してキャッシュし、他のユーザーがアクセスする際はキャッシュされた静的ページを直接提供することで、TTFBを大幅に短縮します。同時に、wp-includesおよびwp-contentフォルダ内の静的ファイルをCDNに移動する機能もサポートしており、当サイトでもこの機能を有効にしています。
最適化の結果、現在TTFBは基本的に100ms以内となっており、実測ではしばしば20〜50msと大幅に改善されました。ページ全体の読み込み時間も以前の1〜2秒から0.5〜1秒に短縮されました（初回訪問以外）。初回訪問時間はユーザーの帯域幅の影響を強く受けます。1秒以内を達成するには少なくとも20Mbpsのブロードバンドが必要ですが、最近になって全国の大部分の地域ではこの速度に達していないことに気づきました…
サポート
