| @ブログ

一つ前の記事で結構 Feed Crawler からのアクセスが多いことがわかった。

フィードは PubSubHubbub で利用する都合上、キャッシュしていない。しかもいまは 20 件記事を配信しているのでレスポンスが遅い。平均で 4 秒くらいかかっている。何とか効率的にキャッシュできないものかと思って FeedBurner を試してみることにした(サービス終了したかと思っていたけど、 .jp ドメインは終了しているものの .com の方は Google の中のサービスとして生き残っていた)。

FeedBurner からのアクセスの時だけ動的にフィードを生成し、それ以外の UA からのアクセスのときは FeedBurner の URL にリダイレクトするようにしてある。この記事を公開してちゃんと機能しているか確認したい。

追記

PubSubHubbub が機能しなくなってしまった😰 Googlebot に対しても動的なフィードを読ませないといけないのかもしれない…

追記 2020-04-08

PubSubHubbub の Google の Crawler は FeedFetcher-Google という文字列を含んでいるようだったので、以下のような記述を Nginx の設定ファイルに加えた。

if ($http_user_agent ~* (FeedBurner|FeedFetcher-Google\;)) {
    proxy_pass http://puma;
    break;
}

なぜ ; (セミコロン)を付けているのかというと、 Feedly などの Crawler の FeedFetcher-Google を名乗っているから。 Google の Crawler は FeedFetcher-Google のすぐ後ろにセミコロンを付けている。

Screenshot - 2020-04-08 08.58.24.png

Google と FeedBurner の Crawler にのみ本体のフィードを読ませ、それ以外の Crawler には FeedBurner のフィードを読ませるようにしている。

| @ブログ

今宿駅近くのバー

このブログのフィードを誰が読みに来ているのか調べてみた。一ヶ月間で 100 回以上見に来ている上位の UA は以下。

Feed Crawler Ranking

なんと一位はフィードリーダーの bot ではなく Slackbot だった。 Googlebot よりも多い。もはや Slack が一番のフィードリーダーになっているのかもしれない。こうなると PubSubHubbub とかの仕組みに乗っかって無駄なクローリングが発生しないようにして欲しい。フィードを購読する Slack の Workspace が増えるほどクローリング回数が増えてしまうと負荷がバカにならない。

三番目の Hatena::Russia::Crawler/0.01 ってのは Hatena と名前に入っているが本当にはてなのクローラーなのだろうか。 Russia という文字列が怪しい。

Feedly はもっと多いかと思ったが非常に少なかった。意外と Fastladder が多い。みんなどこかのサーバーで運用しているのだろう。ご苦労様です。

今回、ログを調べていて Feedeen といったサービスが存在していることを初めて知った。他に Feedbin などいくつか有料の RSS リーダーが存在しているようだ。 Google Reader や Livedoor Reader が終了した後、国内外で有料のフィードリーダーが開発されサービス提供されているのだろう。 Feedeen は料金が月 200 円で安い。日本人が作っているというのも安心感がある。自分は Google Reader 終了後はまず The Old Reader を使っていたけどいまは Inoreader を使っている。 Inoreader も開発元はルーマニアのインディー感あふれる会社で、フィードリーダーの世界は独立系の企業やデベロッパーによって活況を呈しているようだ。よいことだと思う。昔のインターネットを思い出す。

ちなみにフィードリーダー系の Crawler は UA にそのフィードの購読者数を表示しているのがおもしろい。こんだけ購読者数がいるんですよ、ということをブログ主に伝えて UA でブロックされないようにしているのだろう。

| @ブログ

関連記事

各記事の一枚目の画像をカバー画像とみなすようにして、関連記事にサムネイルを表示するようにしてみた。画像があるだけで記事をクリックしてみたい感が高まると思う(残念ながら Google Analytics で見る限り直帰率は改善してない)。人間は、文字だけを読むよりもイラストや画像など視覚的な情報を一緒に見ることで物事の理解度が高まると本で読んだ。自分で過去記事を読み直していても画像があると関連記事をクリックしてみたくなるし、満足感のある改修だった。

なおカバー画像の判定処理は記事本文を読み込んだ上で正規表現で調べているので多分重い(ベンチマークを取ったらタイトルを表示する処理に比べて二倍くらい遅かった)のだけど、関連記事表示部分はキャッシュしてるのでそんなに体感速度は悪化してないはず。

| @ブログ

dark-mode-and-light-mode.jpg

このサイトのデザインは黒地に白文字でダークモードという概念が出てくる前からダークモードだった。家のパソコンで見るときには見づらいと思うことはなかったが、外出先で日中にスマートフォンでサイトを見ると黒地に濃い赤色のリンクは見づらいなぁと思うことがあった。最近、 Mac や iPhone でダークモードの概念が浸透してきたので、自分のサイトの場合は昼間用のライトモード対応を行うことにした。こういう感じのメディアクエリを書けばよい。

@media (prefers-color-scheme: light) {
  ...
}

ただ、元々の CSS が結構ぐちゃぐちゃな書き方で難儀した。ダークモードとライトモードの切り替えが行えるサイトは必然的に CSS のメンテナンス性が高い状態だと思う。明暗を反転したときにこの色はこうなる、という対応関係が綺麗に提示できるような状態は、利用するカラーをシステマティックに整理できているということだと思う。 Sass で書いてあるなら利用する色はきちんと変数化されていて適切な命名がなされているとかそういう状態だと思う。 CSS の設計健康診断としてダークモード・ライトモード切り替え対応をやってみるのは結構いいと思う。

| @ブログ

background-image random pick up

写真や画像があると文章だけよりも記憶に定着しやすいらしい。なのでヘッダー画像のバリエーションを増やしてみることにした。これまで自分が撮ってきた写真の中で気に入ってるもの、ヘッダー画像にちょうど良さそうなやつを 14 枚選んで、これまで表示していた門司の「平民食堂」のやつと合わせて 15 枚をランダムピックアップして表示させている。本当ならランダムではなく記事ごとにイメージに合う画像を選定すべきなのだろうけどそこまではやってない。「このブログ主はこういう写真の場所に行ったりこういう写真をいいと思ってるんだな」ということが伝われば良いと思ってる。

ランダム表示に関して、最初は JavaScript で CSS の background-image を書き換える方式でやっていたが、 DOM の読み込み完了時に動く都合上、かくつきが出てしまう。それで画像の選定は Ruby で行って data-attribute として指定し、予め CSS にそれぞれの data-attribute に応じた background-image を書いておくことにした。これでかくつきはほぼほぼなくなった。

<div id="header" data-background-image="heimin">
</div>
#header[data-background-image="heimin"] {
  background-image: url(header-bg-heimin.jpg);
}

このほかにも CSS 周りを結構いじってて、パンくずリストが載る部分は文字が読みにくくなるのでグラデーションでシャドーを掛けてる。これまで float でやってた配置の制御を flexbox に置き換えたりもやった。今のデザインのベースは 10 年前に作ったので、当時はグラデーションなんかは CSS で実現できず横幅 1px の画像をリピートする方法を使ったが、これで画像を捨てて全て CSS で実現できそう。良い世の中になってきてる。