2023-10-22

Fable でブログを再構築する pt.18

Fable で作ったブログに乗り換えたけど、まだ気になるとこをいじったりしている。

まず画像の Lazy loading をつけてみた。画像貼ることあんまりないけど。何ができるかなーと MDN を調べてみてすぐできそうだったので。

要は ![...](...) こういう画像リンクの場合に以下のように loading="lazy" をつけるだけ。

<img src="..." alt="..." loading="lazy" />

Marked の Renderer にオプションを渡して img タグ出力を担う image 関数を上書きしたら良いだけ。Using Pro - Marked Documentation

コード長いので該当のオプションの箇所だけを転記する。コレで可視範囲外の画像が遅延読み込みされるようになるらしい。実に単純な変更だ。

            let image (href: string) (title: string) (text: string) =
                // NOTE: add lazy loading attribute.
                $"""<img src="%s{href}" title="%s{title}" alt="%s{text}" loading="lazy" />"""

            let mops =
                !!{| heading = heading
                     link = link
                     listitem = listitem
                     checkbox = checkbox
                     image = image |}

試しにいっぱい画像があるページの昔 Planck を組み立てた記事なんかを開いてみたら、意外と画像読み込まれてて実際にコレで効果あんのか？という感じがした。でもスクロールダウンしていくと、確かに 1 枚だけ遅延読み込みされてきた。すご。 1 枚かーという気もしなくはないけど、いつか異常に大量の画像を貼る機会があったら効果を実感するだろう。機会なさそうやけど。

他に、 GitHub Pages へ deploy する workflow で NuGet package のキャッシュを試してみた。

Caching NuGet Packages | actions/setup-dotnet

初回は単にフラグオンでいけるかなと思ってやったが NuGet package の lock file を作ってなくて失敗した。これ当然の話しでドキュメントにも lock file 無いとエラーするって書いてた。けど読まずに体当たりしたため。

そも NuGet package の lock file のことあんまりわかってなかったので、ひとまず fsproj に出力するための設定をしてみたり。以下で勉強した限りオプション入れるだけっぽい。

lock file さえあればちゃんとエラーすることなく正常終了した。初回でキャッシュが無いから、ログにもそう出てた。

#72 のログを転記。

Run actions/setup-dotnet@v3
  with:
    global-json-file: ./global.json
    cache: true
    cache-dependency-path: src/packages.lock.json
  env:
    GITHUB_PAGES: true
/home/runner/work/_actions/actions/setup-dotnet/v3/externals/install-dotnet.sh --channel 7.0
dotnet-install: .NET Core SDK with version '7.0.402' is already installed.
Dotnet cache is not found

Actions タブの Caches を見たらキャシュが作成されてたので、キャッシュがなくなる前に次の workflow 実行したらキャッシュ有り版のログになるかな。

ちょうど bug があったので直したやつ #73 を merge したところ、キャッシュ使われてた。ただ workflow 全体を見て速くなった感じはなさそう。 Fable だからなのか。

#73 からログを転記。

Run actions/setup-dotnet@v3
  with:
    global-json-file: ./global.json
    cache: true
    cache-dependency-path: src/packages.lock.json
  env:
    GITHUB_PAGES: true
/home/runner/work/_actions/actions/setup-dotnet/v3/externals/install-dotnet.sh --channel 7.0
dotnet-install: .NET Core SDK with version '7.0.402' is already installed.
Received 131171387 of 131171387 (100.0%), 161.8 MBs/sec
Cache Size: ~125 MB (131171387 B)
/usr/bin/tar -xf /home/runner/work/_temp/bf7a4381-abc4-4d1d-90af-6c72251bb2dd/cache.tzst -P -C /home/runner/work/blog-fable/blog-fable --use-compress-program unzstd
Cache restored successfully
Cache restored from key: dotnet-cache-Linux-73204c40d9255ea97458df81ea64893c7b0c7130549819b8ae0fb308360b2d25

この方法で NuGet package のキャッシュできそうなので、同じ方法を krymtkts/pocof にもやってみたのだけど、そっちはまだ模索中。 platform が違うと生成される contentHash も違うらしく NU1403 というエラーで頓挫している。

NU1403 と cross-platform 周りで調べた内容。 NU1403 が出たら DisableImplicitNuGetFallbackFolder で大体解消するってのが定石らしいけど、 cross-platform なので話は別ぽい。調べたが理解が浅くてわからん。 cross-platform な lock file を置いても nektos/act でテストすると hash が合わないエラー NU1403 が解消できない。

なんで Fable の方は Windows で生成した lock file が ubuntu の runner でうまくいったんだろうか。 NuGet Package への理解が浅い。

あとやりたいこととしては、以前から気になってる Bulma の css 軽量化。

ただ前に書いたように Bulma がちゃんと SCSS 対応されてないことで @use を使った場合にスタイルを部分的にするとビルドエラーするから、それをなんとか解消できないと先がない。妥協案としては @use を諦めて @import にしたら良いのだろうけど、 SCSS で非推奨やからなあ...悩ましい。

続く。

<< 2023-10-15 Fable でブログを再構築する pt.17 2023-10-29 Fable でブログを再構築する pt.19 >>