HexoとWordPressを使用した静的サイトジェネレーターのガイド
公開: 2022-03-11静的サイトジェネレーターは、テンプレートを静的HTMLページにコンパイルするシステムです。 それが効率的に聞こえるなら、そうです。 サーバーの処理やレンダリングがないため、静的Webサイトは非常に高速で軽量になる傾向があり、ユーザーとユーザーの貴重な時間と帯域幅を節約できます。 この効率の向上は、コストの削減と、場合によっては収益の増加に反映されます。
WordPressの最適化から静的化まで
効率的な収益源と言えば、WordPressが思い浮かびます。 インターネットの28%に電力を供給し、プラグイン、テーマ、APIなどの配列に裏打ちされた広範なユーザーおよびコンテンツ管理を含む多くの優れた機能を備えた強力なプラットフォームです。
私たちの業界の大手企業でさえ、WordPressを使用しています。 Smashing MagazineやCSS-TricksなどのWebサイトは、どちらの場合も大幅にカスタマイズされたインスタンスですが、WordPressを使用しています。 ただし、WordPressの操作は、特にパフォーマンスをカスタマイズおよび最適化する場合、面倒な作業になる可能性があります。
私は2015年に小さなブログを始めました。私の最初の本能はWordPressを使用することでした。 私はすでにWordPressで作業していたので、それは私にジャンプスタートを与えました。 私はサーバーとしてDigitalOceanに新しいドロップレットを作成し、ホスティングコントロールパネルとしてVestaを確立し、ブログプラットフォームとしてWordPressをインストールしました。 最終的に、私はまったく新しいWordPressテーマを設計および開発しました。 足りないのは内容だけでした。
当時、この素晴らしいエディターを使用していたので、Atomに関するいくつかのヒントを共有したいと思っていました。 私はそれについていくつかの記事を公開し、コミュニティと共有しました。
最初は、内容に集中しすぎていたので、パフォーマンスにはあまり気を配っていませんでした。 しばらくすると、パフォーマンスの問題に気づきました。 Google PageSpeed Insightsのスコアはひどいものだったので、ウェブサイトの修正と最適化に一生懸命取り組み、99/100のほぼ完璧なスコアを達成しました。
Nginx+ApacheからNginx+PHP-FPMに切り替えました。
私はスピードと保護のためにCloudFlareを使用しました。
Cloudinaryを使用して画像をホストしました。
テーマを微調整し、クリティカルCSSを使用しました。
唯一の警告は、その時点で修正する方法がわからなかったGoogleAnalyticsのキャッシュの問題に関するものでした。
しかし、99/100または100/100でも目的のパフォーマンスが得られない場合はどうなりますか? ここで静的ページジェネレーターが争いに巻き込まれます。
静的ページジェネレーターとHexoを入力してください
では、静的サイトジェネレーターとは何ですか?
名前が示すように、静的Webサイトジェネレーターは静的HTMLファイルを生成するシステムです。 静的HTMLファイルの提供は、その場でページを作成するよりもはるかに高速です。 サーバーのレンダリングやコンパイルは行われないため、ページの読み込みが遅れることがよくあります。
パフォーマンスについて話すときは、キャッシングについて考える必要があります。 WordPressをキャッシュする方法は複数ありますが、静的ファイルをキャッシュする場合とは異なり、これは通常、簡単な作業ではありません。 キャッシュされたファイルの提供は、サーバーから実際のファイルを提供するよりもパフォーマンスが高く、Webサイトをロードする時間を節約できます。
今年の6月、SmashingMagazineのVitalyFriedmanが、私の町のワークショップでJAMstackを紹介しました。 聞いたことがなく、とても興味をそそられました。 セミナーが終わった後、私はこの新しい概念を少し勉強しました、そしてそれがどれほど素晴らしいかを実感しました。 私のウェブサイトはWordPressを必要としないことに気づきました。
最初のステップは、使用する静的ページジェネレーターを決定することでした。 いくつあるかわかりませんでした。 Hexoブログフレームワークを試してみることにしました。 Netlifyにデプロイ可能で、WordPressから移行するためのプラグインがあり、RubyとGoをそれぞれベースにしているJekyllとHugoとは異なり、私がよく知っているNode.jsを使用します。 そして、後で発見したように、それは速く燃えています。
WordPressからHexoへの移行
Hexoのインストールは可能な限り簡単です。 npmを使用してhexo-cliをグローバルにインストールし、 hexo initコマンドを実行し、npmの依存関係をインストールして、次のようにします。
npm i -g hexo-cli hexo init <blog-name> cd <blog-name> npm install
移行するには、hexo-migrator-wordpressプラグインをインストールします。 このプラグインは、XMLファイルをソースとして想定しています。 XMLファイルはWordPressエクスポートツールを介してエクスポートできます。WordPressエクスポートツールは、管理パネルの[ツール]->[エクスポート]->[Wordpress ]にあります。 最後に、 hexomigrateコマンドを入力してインポートを終了します。
hexo migrate wordpress <source>
あとは結果を確認するだけです。 hexo serverコマンドを実行してサーバーを起動し、指定されたアドレスでブラウザーを開きます。
hexo server
マークダウンとその制限
Hexoは箱から出してMarkdownをサポートします。 マークダウンは、READMEファイル、コメント、および投稿をフォーマットするために多くの人が使用するマークアップ言語です。 しかし、それはあなたの記事を書くためにも使うことができます。 その構文は直感的で習得が容易です。
Markdownのもう1つの利点は、クリーンで有効なHTMLを生成することです。 これにより、開発者はブログの記事やページのスタイルを設定するためのクリーンで保守可能なCSSルールを作成できます。
開発者の生活は決して簡単ではありません。 私たちはしばしば、予期しないことに時間を費やす原因となる可能性のある問題に遭遇します。 途中で何かを学べば、今回は無駄になりませんでした。それは良いことです。 同じことが私にも起こりました。 コンパイルエラーがなかったので、すべてうまくいったと思いましたが、期待どおりに動作しないものがあることに気づきました。
たとえば、Codepenのデモは読み込まれませんでした。 Hexoプラグインを検索して、見つけました。 残念ながら、このプラグインは公式ではなく、許容できないHTMLエラーを生成していました。 問題に貢献して修正したかったのですが、最新のプルリクエストは1年半以上解決されませんでした。 リポジトリをフォークし、問題を修正し、プラグインをHexoページに公開して、誰でも使用できるようにする方が簡単だと判断しました。 プラグインが受け入れられ、コンテンツが更新され、Codepenのデモが魅力的なものになりました。

CanIUse埋め込みでも同様の問題が発生しました。 Hexoプラグインの作成方法がわかったので、そうしない理由はありませんでした。 Cloudinary CDNからロードされたレスポンシブ画像用のhexo-cloudinaryプラグインと同様に、hexo-caniuseプラグインも公開されました。
再設計と最適化
ウェブサイトのデザインはかなり基本的です。 Hexoは公式ウェブサイトで無料でいくつかのテーマを提供していますが、私は自分のHexoサイトにユニークなテーマが欲しかったのです。 ドキュメントを読み、Hexoをカスタマイズする方法を学んだ後、オリジナルのテーマを最初から開発し始めました。
新しいテンプレートを作成するために、テンプレートにEJSを使用することにしました。 EJSを使用したことがないので、新しいテンプレート構文を学ぶチャンスだと思いました。 EJSが気に入らない場合は、Hexoがプラグインを介してSwig、Haml、またはpugのサポートを提供します。
再設計の過程で、私はパフォーマンスに細心の注意を払っていました。 ベストプラクティスに従うことで、静的Webサイトをさらに高速化できます。 ドキュメントの下部にJavaScriptファイルを配置し、クリティカルCSS手法を使用すると、対象者に最高のエクスペリエンスを提供します。
SEOの最適化は、Googleなどの検索エンジンでブログを表示するために重要です。 Hexoには、OpenGraphデータを挿入するためのヘルパーが組み込まれています。 HexoはYAMLファイルを使用してサイトとテーマの構成を保存します。 テーマ構成ファイルを使用して、サイト名、説明、およびさまざまなソーシャルIDを構成しました。
ビルドプロセスにGulpまたはWebpackを追加することは、常に役立ち、推奨されます。 私はGulpを使用してCSSファイルとJavaScriptファイルを縮小および圧縮し、すべての準備が整いました。 私はそれを展開することができました。
Netlify
Netlifyは、ウェブサイトやアプリのホスティングに驚異的な高速パフォーマンスを提供するプラットフォームです。 コードを自動化してパフォーマンスが高く、保守が容易なWebサイトを作成する統合プラットフォームとして販売されています。
コードをプッシュするだけで、残りは私たちに任せてください。
ご想像のとおり、Webサイトの構成は簡単です。
ドメインを設定します。
DNSレコードを変更します。
ビルドとデプロイメントをセットアップします。
SSLをオンにします。
すべての設定が完了したら、Pingdom Webサイト速度テスト、Webページテスト、Testmysite.ioなど、いくつかの基本的なテストを実行してスコアを確認しました。 サイトはすべてのツールで最高のスコアを獲得したため、結果は優れていました。
CloudFlare
優れたスコアにもかかわらず、私はCloudFlareを試してみたかったのですが、それがWebサイトをさらに高速化するかどうかを確認するためです。 CloudFlareは最初は圧倒されるかもしれませんが、それを使用する方法を学ぶことは基本です。 CloudFlareを構成した後、テストを再実行したところ、結果はさらに良くなりました。
最後のテストはGooglePageSpeedInsightsでした。 スコアは、モバイル版とデスクトップ版の両方でほぼ100%でした。 問題は、GoogleAnalyticsブラウザのキャッシュでした。 私はGoogleAnalytics用のCloudFlareアプリを使用して問題を修正することができました。
それはどれくらいしますか?
CloudFlareでNetlifyでHexoを使用するのに費用はかかりません。
Hexoはオープンソースプラットフォームであるため、どのように使用する場合でも無料です。 大きなコミュニティがあり、StaticGenによると3番目に人気のあるオープンソースの静的ページジェネレーターです。
Netlifyには、ホスティングのための優れたオプションを提供するオープンプランがあります。 画像はCloudinaryのオープンプランでもホストされています。 CloudFlareの無料プランでは、すでに高速なWebサイトを高速化できる多数のルールを構成できます。 また、GoogleAnalyticsブラウザのキャッシュの問題を修正することもできます。 政府が提供する無料の個人ドメインを使用したので、ドメインの料金も支払いませんでした。
このプロジェクトの設定により、予算が最小限に抑えられました。 プロジェクトにさらに高度な機能が必要な場合でも、静的ページジェネレーターを使用すると数ドル節約できます。
キャッシュされたファイルを提供することは、CPUと帯域幅の使用量が削減されることを意味します。つまり、より強力でないハードウェアでより安価なホスティングプランを使用できることを意味します。 それだけでなく、Webサイトははるかに高速になります。つまり、ユーザーはモバイルデバイスとデスクトップデバイスの両方でブラウジングを楽しむことができます。 また、ページの読み込み速度がGoogle検索のランキングに影響を与える可能性があるため、ウェブサイトのランキングが高くなり、さらに多くの訪問者を獲得できます。
これはすべて、予算の一部を他の場所に費やすことができることを意味します。たとえば、Webサイトの宣伝や追加のコンテンツの作成に費やすことができ、これにより少し多くの収益を得ることができます。
静的サイトジェネレーターの場合
WordPressから静的ページジェネレーターへの移行は簡単な作業ではなく、すべてのWordPressユーザーが行うべきことではありません。 ただし、Hexoは、プラグイン、優れたドキュメント、およびシンプルなAPIのおかげで、この移行を比較的簡単にしました。
製品を静的ソリューションに移行するかどうかを決定する前に、コンテンツ制限、Markdown学習曲線、バージョン管理など、静的ページジェネレーターに伴う制限に注意する必要があります。
また、Hexoはブログフレームワークであることに注意する必要があります。 テキストエディタとターミナルの使い方を知っている開発者や技術者に最適です。 Webインターフェイスを使用してコンテンツを管理したい場合は、その機能を提供するプラグインもあります。 これはhexo-adminと呼ばれ、非常に人気があります。
すでにWordPressを使用している場合は、停止して、現在使用しているWordPressの機能と、不可欠な機能を検討する必要があります。 複雑なコンテンツ構造がありますか? ユーザー管理を使用していますか? WordPressのインスタンスで多くのプラグインを使用していますか?それらはすべて必要ですか? サイトのパフォーマンスに満足していますか?
これらの質問のほとんどまたはすべてに対する答えが「いいえ」の場合は、静的ページジェネレーターを使用してWebサイトを過給する準備ができています。 ユースケースと要件によっては、静的ページはコストを最小限に抑えながら効率を最大化するのに役立ちます。 一方、WordPressの柔軟性が必要な場合は、おそらくそのような動きを検討していません。