はじめに
以前、このブログのドメイン最適化設定に関するいくつかの説明]という記事を書きましたが、その中のいくつかの方法はもう使われておらず、代わりに他の方法が追加され、このJekyllブログに適用されています。その中には注意が必要な細かい点もあるため、この記事を書きました。
CDNサービス
以前のCDNサービスについては、百度CDNサービスと七牛静的リソースホスティングの使用]で、img.xheldon.comを七牛雲に解析し、七牛雲上で関連する静的リソースを追加していました。しかし、周知の理由により、七牛雲のこの個人向け無料CDNサービスはICP登録が必要で、さらに国内の物理サーバーも必要だったため、この案は断念しました。
長い間、私は画像や静的リソースを直接プロジェクトに配置していました。GitHubの無料リポジトリには1GBの総容量制限があるため、できるだけテキストで説明し、画像を使わないようにしていましたが、非常に制約がありました。最近、偶然GitHub Pagesをベースにした別のブログを訪れ、そこでは多くの画像が使われており、画像のリンクがjsdelivr.netに関連していることに気づきました。そこで、これは海外の無料CDNサービスではないかと推測し、調べてみると、実際にその通りで、国内にもサーバーがあり、無料で加速できることがわかりました。GitHubリポジトリ内のリソースの前に固定のパスを追加するだけで、初回リクエスト時にリソースがS3に保存され、その後GitHubがダウンしても正しいリンクにアクセスできます。S3上にリソースがない場合は、直接GitHubの内容をリクエストする、つまりCDNの基本的な操作です。
私は膝を叩き、~~「これはプロだ」~~と思いました。無料のCDN加速で、複雑ではなく、jsdelivrの特徴の一つは、中国で合法的なICPライセンスを持つ海外の公共CDNサービスプロバイダーであり、中国国内に数百のサーバーを保有していることです。
すぐに取り掛かり、以下の手順を実行しました：
専用静的リソースリポジトリの追加
このステップは、jsdelivr CDNサービスが正しく解析できるようにするためです。例えば、ローカルの画像の参照パスが/static/img/in-post/logo.pngの場合、その一意のパスは/img/logo.pngです。内容をGitHubリポジトリにプッシュすると、アクセスパスはhttps://github.com/Xheldon/x_blog-static/tree/master/img/logo.pngになります。私のユーザー名はxheldonで、リポジトリはx_blog-staticなので、jsdelivr CDNサービスを使用した後のアドレスはhttps://cdn.jsdelivr.net/gh/xheldon/x_blog-static/img/logo.pngになります。jsdelivrサービスに登録する必要もなく、何も設定せずに使用できるので、非常に便利です！
ブログリポジトリの変更
主に以下の手順があります：
staticフォルダを削除し、このフォルダを新しく作成したGitHubリソースリポジトリx_blog-staticにプッシュした後、削除できます。- リソースリポジトリ
x_blog-staticをブログリポジトリのサブモジュールとして追加：git submodule add https://github.com/Xheldon/x_blog-static.git ./static、そして静的リソースリポジトリ（先ほどのstaticフォルダの内容）をstaticフォルダに配置します。 _config.ymlファイルを修正し、設定オブジェクトstatic_url: https://cdn.jsdelivr.net/gh/xheldon/x_blog-staticを追加して、次のステップで静的リソースの絶対パスを修正しやすくします。- ローカル開発設定ファイル
_config.dev.ymlを追加し、設定オブジェクトstatic_url: /staticを追加して、次のステップで静的リソースの絶対パスを修正しやすくします。 - ローカルの絶対パスで参照されている静的リソースをグローバルに置換します。例えば、imgのsrcが
/static/img/in-post/logo.pngや/static/css/main.cssなどのパスの場合、`https://static.xheldon.cn/img/logo.png`などに置換します。ここで注意が必要なのは、Liquid構文のタグ`{{}}`は、markdownファイル内でも使用できるという点です。素晴らしいですね。 - 頻繁に修正するファイル、例えば
main.scssファイルは、やはりローカルに置いた方が良いです。理由は後述します。 - 修正をリモートにプッシュします。
既知の問題
いくつかの問題を解決した後、別の問題が発生しました。Jekyllはscssをサポートしているため、ローカルではresoruce/css/main.scssにsass構文を記述し、htmlで直接resoruce/css/main.css（ファイル拡張子に注意）を参照できます。Jekyllは自動的にscssをcssに変換します。しかし、これにより、このスタイルファイルはローカルに保存する必要があり、リモートに配置できません。
したがって、この2点について、頻繁に修正するファイル（css、jsなど）は直接ブログリポジトリに配置し、静的リソースリポジトリには置かないようにしました。
また、説明が必要なのは、ローカル開発時にデフォルトのdefault layoutテンプレートでLiquidのグローバル変数（例：static_url）を定義し、記事のmarkdownファイルで直接`{{static_url}}/img/logo.png`のように使用しようと考えましたが、実験したところうまくいきませんでした。調べてみると、Liquid、Jekyll、またはGithub Pagesのいずれも、siteやpages、paginatorのようなレベルの変数を定義することをサポートしていないことがわかりました。
そこで私はdefaultレイアウトファイルにassign変数を直接定義し、defaultレイアウトを使用しているpostレイアウト内のmarkdownファイルからアクセスしようと試みましたが、やはりうまくいきませんでした。次にJekyllがサポートする環境変数JEKYLL_ENV=devを使って実現しようとしましたが、前述と同じ理由で、レイアウト間（どちらがどちらをネストしていても）で変数を共有できないため断念しました。調べたところ、Jekyllはまず記事をレンダリングし、その後でレイアウトファイルをレンダリングするため、markdownファイルが外部レイアウトの変数を取得できないことが原因でした。
実際には、各markdownファイルの前にテンプレートコードを追加し、jekyll.environmentの値をチェックしてstatic_urlのような変数を割り当て、その後markdown内でその変数を使用することも可能でした。しかし、すべてのmarkdownファイルのヘッダーにこのような奇妙なロジックを追加するのは避けたかったため、この方法も断念しました。同様に、static_url変数を使用するすべての場所でenvironmentを個別にチェックする方法も考えましたが、例えば画像を挿入する場合、次のような疑似コード`{{if environment=dev 'static' else 'https://jsdelivr.net/xxx/'}}/img/logo.png`を書く必要があり、さらに煩雑になるためやめました。
そのため、最終的な解決策として、2つのJekyllのyml設定ファイルを作成しました。1つはデフォルトの_config.ymlでGithub Pagesのオンライン生成用、もう1つは_config.dev.ymlでローカル開発用です。両者の唯一の違いは、static_urlという設定値で、_config.dev.ymlでは/static、_config.ymlではhttps://cdn.jsdelivr.net/gh/xheldon/x_blog-staticという値が設定されています。
なお、公開後に一部の画像で403エラーPackage size exceeded the configured limit of 50 MB. Try https://github.com/xxx insteadが発生する可能性があるため、最終的にバージョン番号タグまたはブランチ名を追加する必要があります。私はブランチ名https://cdn.jsdelivr.net/gh/xheldon/x_blog-static@masterを使用しました。
Gitalkの追加
GitalkはGithub Pages専用のコメントツールで、cssとjsを導入し、tokenを設定するだけで使用できます。新しい記事が追加されるたびに、著者が一度ページを開くと、自動的に該当するGitHub Pagesリポジトリのissueに現在の記事名でissueが作成されます。その後、記事の下にコメントが投稿されたり、issueにコメントが追加されると、それが記事の下に表示される非常に便利な仕組みです。ここで使用するcssとjsにもjsdelivrのcdnサービスを利用しており、これは公式にサポートされています。
ページレイアウトの変更
まず、記事を閲覧する際に左側に大きな空白があり、アバターとナビゲーションが表示され続けるのがスペースの無駄だと感じました。しかし、ホームページ、プロジェクトページ、プロジェクトカテゴリページでは、アバター、ナビゲーション、検索機能を表示する必要がありました。そのため、ホームページ、プロジェクトページ、プロジェクトカテゴリページなどでは、ブラウザの幅が1080px以上のときにナビゲーションを左側に表示し、検索ボックスも表示するようにしました。それ以外の場合は、ナビゲーションバーを上部に表示します。
また、記事ページを閲覧する際に、画面の幅が1080px以上の場合はtable of content（目次）を表示し、ユーザーが興味のあるセクションに素早く移動できるようにしたり、外部サイトのユーザーがページの特定のアンカーに直接リンクできるようにしました。これはSEOにも有利です。
記事段落の見出し変更
SEO上の理由から、1つのページにはh1タグを1つだけにし、h2以上のタグを複数使用するようにしました。これにより、検索エンジンがコンテンツを認識しやすくなります。
プロジェクトページの追加
個別のプロジェクトページを追加し、私が関わったすべてのプロジェクトを掲載しました。外部リンクに飛ぶものもあれば、個人説明プロジェクトもあります。
あとがき
最適化は続きます…妻が個人ブログのデザインを完成させたら、NodeJSでレンダリングするブログにすることも考えています。お楽しみに！
ブログ主より：
人生の重要な選択に直面したとき、最善の方法を誰かが教えてくれて、貴重な時間を無駄にせずに済めばと、私はよく願っています。だからこそ、自分の経験を踏まえて頻繁にブログを書き、広大なインターネットのこの小さな片隅に、私にとって一度きりの人生経験を記録し、助けを求める人々の力になれればと思っています。
