ウェブのYouTube動画埋め込みは遅延読み込みで

WordPressには、記事の作成エディタで1行の中にYoutubeの動画URLだけを書くと(ページ表示には)自動的にYoutube動画の再生画面にしてくれる便利な機能(oEmbed)がある。
コンテンツを作る側としてはメッチャ簡単なので嬉しいのだけど、これがページ表示の速さという面では非常によろしくない。ページ表示が遅いということは第一に閲覧者にとって良くない。そして、本来はオマケではあるが、Googleさんの評価が悪いのでそれはすなわちコンテンツを提供する側(記事を作る側)にも良くない。

WordPressの記事中にYoutubeの動画URLを書く。
https://www.youtube.com/watch?v=動画ID (同じ行に動画URL以外の文字を書くとおそらくNG)

これはページ表示時には以下のように展開され、Youtubeの動画プレーヤーが表示される。
<iframe title="動画タイトル" width="624" height="351" src="https://www.youtube.com/embed/動画ID?feature=oembed" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

見れば判るがiframeの動画埋め込み形式になっている。これを普通に表示させようとするととても遅い。

Youtubeプレーヤー
こんなのが表示される。なお、上はただの画像なのでクリックしても何も起きない。

iframeタグのlazyload 1
このiframeのYouTube動画を埋め込んだページをGoogleのPageSpeed Insightsで採点してもらうと42点という驚きの低評価。「診断」の項目で「第三者コードの影響を抑えてください」という項目があるので展開すると、YouTubeのJavascriptがページ表示を邪魔していることが判る。YoutubeのCSSは、それ自体がページ表示の邪魔をしている時間はゼロということになっている。影響しているのは YouTubeの base.js と www-embed-player.js。

対策方法をググると、数行のJavascriptを書いてiframeタグのsrc="Youtubeの動画URL"をsrc=""に変更し、data-set="Youtubeの動画URL"を追加するという記事が多くヒットする。
でも、このやり方は他にLazy load系のスクリプトを使っているとコンフリクトする可能性があるし、何より2020年夏よりiframeの遅延読み込み(lazy-load)対応がウェブ標準になっている(Chromeなどの一部ブラウザでは2019年夏から)ので無駄な感じ。
シンプルにiframeタグ内に loading="lazy" を書くだけ。これで古いブラウザで表示する場合以外は問題無いしWordPress側を改造したりプラグインを加えて汚す必要もない、そして簡単。

ただし、WordPressでYoutube等の動画をURL1行記述にしていたらそれをiframe手書きに書き換えなきゃならないけど。

<iframe loading="lazy" width="854" height="480" src="https://www.youtube.com/embed/Q2zcPxCn3vg" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
黄色の文字列を追加するだけ。

それか、YouTubeの動画リンクの展開用のoEmbedの関数をオーバーライドするとか。 記事の最後に追記しました

iframeタグのlazyload 2
このページのYoutube動画の埋め込みは元から1つだけ。
そして、YouTubeの動画をURL1行書きからiframeタグのLazy Loadありに変えただけ。他は全く弄っていない。それだけで、42点から50点加点されて92点になる。というか、これまで無駄に50点減点されていた。いきなり点数が倍以上なのは笑う。
ちなみに、少し前までであればこれで100点になるのだが、最近は画像サイズと特にTTFBの判定が辛めになっているので100点にはならないことが多いかと。TTFBは、Googleさんは日本からの計測ではないようなのでCDNを利用していない日本だけにサーバがあるウェブサイトはちょっとキビシイ判定になる筈。この「がとらぼ」をKeycdnのPerformance Testで計測すると東京(Tokyo)での判定は120ms程度なのでサーバーが非力とはいえGoogleさんに指摘される程は悪くない筈なのよね。

この記事ではWordPressでYoutubeの動画URL1行記述を例に挙げたけど、YouTubeで表示される埋め込みコードを使う場合も同じこと。iframeタグにloading="lazy"を追加しましょう。
あと、YouTubeだけでなく、iframeは多くの場面で遅延読み込みで良いと思う。iframeがファーストビューの範囲にあると効かないと思うけど。

記事公開数時間後に追記

過去記事のYouTubeのURL1行記述と、手書きのiframeを探して loading="lazy" を追加しようとしたら、少ない筈と思っていたのが意外と多かった。そして「面倒だな」と思う気持ちが強くなってしまったのでYouTubeのURL1行記述の方はWordPressのfilterでオーバーライドする方が簡単そうに思った。

oEmbedについてはwp-includes/class-wp-oembed.phpを見た。
WordPressのoEmbedで対応する動画サイトやSNS等のURLもこのファイルに書かれてる。
m.youtube.com, www.youtube.com, youtu.be, *.vimeo.com, www.dailymotion.com, www.flicker.com, flic.kr, www.twitter.com, amazonいろいろなど、これはほんの一部で結構多く対応しているみたい。

で、oEmbedのタグにYouTubeのドメイン名(youtube.com, youtu.be)が含まれていたらiframeタグにloading="lazy"を追加するフィルタを作ってみた。

下のコードはWordPressで使用中のテーマのfunctions.phpの中に追加する。(wp-content/themes/使用中テーマ/functions.php)

1
2
3
4
5
6
7
function oEmbed_youtube_lazyload($tag){
  if(strpos($tag, 'youtube.com') !== false || strpos($tag, 'youtube.be') !== false){
    $tag = preg_replace('/iframe /', 'iframe loading="lazy" ', $tag);
  }
  return $tag;
}
add_filter('embed_oembed_html', 'oEmbed_youtube_lazyload');

もしくは、YouTubeだけでなく、とにかくoEmbedでiframeタグだったらloading="lazy"を追加するフィルタを作ってみた。YouTube以外でiframeが使われているのかを含めてこちらは動作未確認。そして、上のYoutube用フィルタとは同時に使わないでどちらか1つだけ。

1
2
3
4
5
6
7
function oEmbed_iframe_lazyload($tag){
  if(strpos($tag, 'iframe') !== false){
    $tag = preg_replace('/iframe /', 'iframe loading="lazy" ', $tag);
  }
  return $tag;
}
add_filter('embed_oembed_html', 'oEmbed_iframe_lazyload');

アッチッチなNanoPi NEO3を冷やしたい パッド交換

サーマルパッド
©いらすとや.

今年の夏に、NanoPi NEO3+標準ケースが熱すぎてヤバいということで大きなヒートシンクを付けたという記事を書いた。 そのときはSoCとヒートシンクの間に挟むサーマルパッドの手持ちが銅製の20mm x 20mm x 0.5mmしかなく、このサーマルパッドをグリスと塗り重ねてミルフィーユ仕立てにした。それが気に入らなくてSoCの大きさに合う15mm x 15mmで厚さが2.0mmの銅プレートを得ようとしたのだが、いつものようにAliExpressで注文したらセラーが勝手に発送キャンセルしたり違うものを送って来たりと8月上旬から今回まともなモノが届くまで4ヶ月もかかってしまった。ちなみに全て違うセラーで注文している。
ようやく念願の15mm x 15mm x 2.0mmの銅プレートを手に入れたので嬉しくて日記。内容も写真もほぼ夏の記事と同じだけど。

銅製サーマルパッドをNanoPi NEO3に取り付ける 1
例年11.11の中国のセールの後は待てど暮せど荷物が届かず「年内に届くかしら?」なんだけど、今年は11月の流通がとても早くて2〜3週間で届く。だから送料無料とか安い便でも運が良ければ11月中に届くくらい。この封筒は中国郵政の安い便だけど、11月下旬に注文して2週間で届いた。9月に注文したのは1.5ヶ月以上かかったから荷物が溢れかえる11月の方が速いのはちょっと納得いかない。
そして、めずらしく汚れやシワのない綺麗な状態で届いてる。

銅製サーマルパッドをNanoPi NEO3に取り付ける 2
銅プレート10枚がジップ袋に入ってた。

銅製サーマルパッドをNanoPi NEO3に取り付ける 3
厚さは注文通り2.0mm。これが欲しかったのよ。

銅製サーマルパッドをNanoPi NEO3に取り付ける 4
薄い銅板のサーマルパッドは角丸の四角の枠か何かで打ち抜いて作っていると思われるが、これは2.0mmなので打ち抜くのは無理なのか、大きな包丁のようなものでバッサバッサ切って作っていると思われる。そして、切ったらできるバリはサンダーか何かで削って取ってあるみたい。上の写真では光の当たり方で右と下の辺の近く1mmほどが帯状に色が違うのが判るかと。実際には4辺とも磨いてあった。打ち抜くだけと比べると圧倒的に面倒そう。だから厚手の銅パッドは扱いが少ないのかな?

銅製サーマルパッドをNanoPi NEO3に取り付ける 5
夏に大型ヒートシンクに取り付けたNanoPi NEO3を開けてみた。20mm x 20mm x 0.5mmのパッドがそれぞれグリスで重ねられていたのが2枚ずつヒートシンクとSoCの側に分かれた状態。

銅製サーマルパッドをNanoPi NEO3に取り付ける 6
全部取り除いて、SoCにグリスを塗り直した。写真だと厚ぼったく塗ったように見えるが一応薄め。

銅製サーマルパッドをNanoPi NEO3に取り付ける 7
今回購入した銅パッドを置いてその上にもグリス。SoCの大きさが約15x15mmなのでほぼ同じ大きさ。気持ち良い。

銅製サーマルパッドをNanoPi NEO3に取り付ける 8
銅パッドを置いた状態でほぼ真横から見た状態。銅パッドがNanoPi NEO3のケースの縁よりもほんの僅かに飛び出た状態。理想的。1.5mm厚だとぎりぎり足りないので2.0mmが正解。

銅製サーマルパッドをNanoPi NEO3に取り付ける 9
前の写真の状態で上にヒートシンクを置いて、ズレないように上下をひっくり返す。そしてPCのCPU固定用金具の穴にタイバンドを通して固定。

銅製サーマルパッドをNanoPi NEO3に取り付ける 10
反対側も同じようにCPU固定金具の穴(マザーボードのCPUソケットの凸に嵌める部分)にタイバンドを通して、もう1本のタイバンドのロック部分だけを利用して固定。CPU固定金具のバネを利用して少しだけテンションをかけるのがコツ。

銅製サーマルパッドをNanoPi NEO3に取り付ける 11
右上はこれまで使ってたのと同じ20x20x0.5mm。バーコードの袋の方は別の店で注文して、違う品が届いた15x15x0.3mmの10枚入り。見た瞬間に明らかに違う品だと判ったので開封すらしていない。
「こんなもの!」by アム口。

ちなみに、銅板は空気中で放置していると銅の色がくすんでくる。ピカールなどで磨けば光り輝くようになるが、ピカールの代わりに安物のサーマルグリスを少しつけてキムワイプやショップタオルで擦ってやるとピカピカに綺麗になる。(グリスの素材によるかも)

銅製サーマルパッドをNanoPi NEO3に取り付ける 12
パッド交換後48時間以上過ぎてからの24時間温度計測結果。
薄い銅パッドとグリスのミルフィーユ仕立てから厚い銅パッド1枚に変更したところで温度は上がりも下がりもせず全く同じだった。ただし、夏場にPC用ヒートシンクを付けて約50度に下がって喜んでいた頃と違い、12月は気温が低く、現在は1日ほぼ30度程度で推移しているのでパッドの違い程度では温度差が出にくそうな感じではある。再び暑い時期になったらホンの僅かでも差が出るのかもしれないが、ミルフィーユに戻す気はないので温度差が出るのか出ないのかは謎で終わりそう。

今回、正しい品物を送ってきたセラーと商品のリンク。ただし、常に正しいモノを送ってくるという保証はできません。
購入時 15 x 15 x 2.0mm 10枚が161円。送料が56円。2020年12月13日現在は送料が1円値上げになっている。

Linuxの古いカーネルが残って調子が悪いの対応

PCの調子が悪い
©いらすとや.

自分がメインで使っているデスクトップ用PCはKDE neonというLinuxが動いている。ハードウエアは何年も前のAtom系Pentiumを搭載したローエンドなもの。デスクトップは性能要らなくて省電力サイコーな考え方なので。

で、そのKDE neonなのだが、最近すこぶる調子が良くない。OSの起動時間は以前は電源投入から2分半程度だった(回転数の低いハードディスク使用)のが4分近くかかるし、オーディオデバイスを認識しないとかUSB接続のカメラを認識しないという「認識しない」系の発生頻度が高くなっていた。
今日はいよいよ何度再起動してもオーディオデバイスを認識しない、カメラも認識しないという状態。

マザーボードが古い(来月で満5年)なのでハードウエアの故障の可能性もあるかもしれないが、OS側も何か怪しい。
そこで、KDE Neonのフォーラムで似たような内容で困っている人がいないか探してみた。

そしたら、見つけたのがKDE neon does not fully remove old kernelsというスレッド。

KDE neonを使っているうちにハードディスクを使う量が増えていることに気づきました。 /usr/lib/modules/XXX-XX-generic に古いカーネルのフォルダが残っていることに気づきました。カーネルは apt autoremove (パッケージ管理のaptで不要なパッケージを自動削除)を使って削除済みです。muonを使用してカーネルパッケージを手動で削除できますが、対応するカーネルが削除されたときに自動削除をして欲しいです。これに対する簡単な修正はありますか?
Autoremove(sudo apt autoremove --purge)は、自動インストールとしてマークされたカーネルのみを削除します。アップグレード後、古いカーネルは手動でインストールされたと見なされるようです。これはバグとして扱うものですか?わかりません。
とにかく、解決策は、新しい方から2つ、使用中(最新)のカーネルと最新から2番目のカーネルを除く古いカーネルを消去することです。
将来的には、古いのは自動的に削除されるでしょう。
カーネルが自動的に削除されないという以前の投稿の情報の後に、起動時に実行する用のスクリプトを作成しました。これまでのところ、悪影響はありません。

#!/bin/bash
apt-mark auto $(apt-mark showmanual | grep -E "^linux-([[:alpha:]]+-)+[[:digit:].]+-[^-]+(|-.+)$")
apt-get -y autoremove --purge

このスレッドを読んで、そういえば最近2回ほどカーネルの更新あったな。もしかして古いカーネルモジュールのせいで起動が遅かったり何かのコンフリクト等で調子が悪くなってるのかなと思って、3つめの引用の2行を実行してみた。

$ sudo -s  #行儀悪いけど管理者になった。または以下sudoで
$ apt-mark auto $(apt-mark showmanual | grep -E "^linux-([[:alpha:]]+-)+[[:digit:].]+-[^-]+(|-.+)$")
$ apt autoremove -y --purge

結構時間はかかったが、多くの古いカーネルモジュールが削除された。一部古いバージョンの残骸が残ったけどそれは手動で削除した。 rm -R /usr/lib/modules/5.4.0-42-generic など。なお、最新バージョンと2番目に新しいバージョンには触らないこと。

OSの起動時間は気持ち速め(1分は誤差?)程度だが、オーディオデバイスの認識とUSBカメラの認識は失敗しなくなった。
効果ありと言える。
KDE neonはベースがUbuntuなのでUbuntuでも通用するTipsかな?

理屈で言えば、古いカーネルそのものはパッケージ管理で削除されていて、残っている古いカーネルモジュール等はそこに存在しているだけ、使われてはいない筈で、それらが何か悪さをするというのはヘンな話。素人でも納得できる理屈があれば教えていただければと思います。