portal shit!

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

誰がこのブログのフィードを読みに来ているのか

ブログのフィード閲覧ログを解析し、上位アクセス元が想定外にSlackbotや各種リーダーのクローラーだったことを報告。FeedlyよりFastladderや有料サービスの存在が目立ち、購読者数をUAで

portalshit.net

フィードは 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 のすぐ後ろにセミコロンを付けている。

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

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

なんと一位はフィードリーダーの 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 で見る限り直帰率は改善してない）。人間は、文字だけを読むよりもイラストや画像など視覚的な情報を一緒に見ることで物事の理解度が高まると本で読んだ。自分で過去記事を読み直していても画像があると関連記事をクリックしてみたくなるし、満足感のある改修だった。

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

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

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

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

写真や画像があると文章だけよりも記憶に定着しやすいらしい。なのでヘッダー画像のバリエーションを増やしてみることにした。これまで自分が撮ってきた写真の中で気に入ってるもの、ヘッダー画像にちょうど良さそうなやつを 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 で実現できそう。良い世の中になってきてる。

このブログのマークアップを改善して BlogPosting - schema.org に対応させた。

2年くらい前に BreadcrumbList - schema.org には対応させていて、 Google の検索結果にパンくずリストの情報が表示されるようになってたんだけど、 Search Console から「お前のパンくずリストのマークアップは不正だ」ってメールが来たので、ついでに BlogPosting にも対応させた。

Google が提供している 構造化データ テストツール が便利だった。

Google のコアアルゴリズムアップデート - portal shit! にも書いたけど、 6 月の Google のアルゴリズムアップデートの影響でサイトへのアクセスが激減してしまった。ヘルスケアやお金関係の記事だけでなく、その他のジャンルの記事も検索結果に表示されにくくなってるように感じる。インプレッションはご覧の通りほぼ半減している。

マークアップを改善してインプレッションが増えるかどうかはわからないけどしばらく様子を見てみたい。

最新の Rebuild.fm のエピソードを聞いてたら Automattic による Tumblr 買収の話から Medium 、 WordPress から古の Blogger 、 TypePad 、 MovableType まで話が及んで楽しかった。

Rebuild: 246: You Are Welcome (fumiakiy)

Fumiaki Yoshimatsu さんをゲストに迎えて、Netflix, Tumblr, ブログ、コードレビュー、Android, Jackquard などについて話しました。

rebuild.fm

エピソード内で miyagawa さんがインディーなインターネットユーザーとして独自ドメインは重要だけど、誰も使わないから当てられるサービスがなくなってきた、その意味で WordPress は独自ドメイン使えるので悪くない選択だと思う、的なことを言っていたのが印象的だった。エピソード中でも触れられていたけど、 Medium は新規登録ユーザーに対して独自ドメイン利用を利用不可能にしている模様。

Just a moment...

help.medium.com

ブログプラットフォームとしての知名度を高めるためには一目で「あ、このブログは Medium 使ってるんだ」とわかった方が良いはずで、となると独自ドメイン名を使われるのは良くないと判断したんだろうなぁ。

加えて Medium は確かに最近よくログインを求めてくる。旧型の iPhone 7 で見ると画面の 1/3 くらいの領域をユーザー登録導線にしてる感じ。読みづらい。なんらかのプラットフォームに乗っかると、やはりプラットフォームに「こう使って欲しい」と制約をかけられることになりがちだ。ステークホルダーが書き手、読み手、プラットフォームの三者になるので当然といえば当然か。一方でセルフホストのブログなら基本的には書き手と読み手の二者しかステークホルダーがいない。

ブログは自分で作るのが一番満足度高いと感じる。意に反して広告が出るようになることはないし、読者にログインを強要したりもしない。足りない機能があれば自分で作ればよいというのもよい¹。自分はセルフホストのブログを同じドメインで 14 年やってて、最初は P_BLOG 、 そしていまは Lokka を自分で細々と改修しながら使ってる。時々更新が途絶えることはあるが、ほぼほぼ毎月一本は何かしらを書き続けることができている。サーバーの運用は発生するが、まぁプログラマーなら自宅サーバーか VPS くらい飼ってるだろうし、運用は趣味の一環かなという感じがする。