【重要】全文表示タイプテンプレート総メンテナンス中 中間報告

テンプレート テンプレ不具合・修正など
2017/12/24
6
vanillaice (Akira)
vanillaice (Akira)

既存テンプレートのメンテナンスを進めています。
全文表示タイプ を優先的にやっていますが、作業中の経過報告と主旨の説明です。 主に トップページ への言及だと思ってお読み頂ければ、と思います。

全文表示タイプのトップページ表示速度は記事内容・記事の書き方に大きく左右されます

今回作業を終えたテンプレートについては、各専用記事で以下のような表示速度の基本スペックを表示しています。
sample
GTmetrix計測結果です。
AからFまでのスコアがあり、Fは一般的にも False(不合格) のFですね。
要は「最低ランク」ということになります。
専用記事でのこの計測結果をどんな条件下で行なったのかをお伝えします。

各テンプレート専用記事の「GTmetrixスピードスコア」計測条件

記事が全くない状態 + プラグインは公式の主要なもののみ です。
利用公式プラグインは

  • 最新記事 (サムネイル付)
  • 最新コメント
  • 最新トラックバック
  • カレンダー
  • 月別アーカイブ
  • カテゴリ
  • リンク
  • ユーザータグ
  • プロフィール
  • 検索フォーム

これら必須と思われるものは表示させた状態で取得しています。
公式プラグインの特徴は 最新記事(サムネイル付)以外はJavascriptを含んでいない ところにあります。

記事が1件も無い状態での計測ですので、スクリーンショットサンプルを例に取りますとA(96%)というのがテンプレート + 主要プラグインの基本スペックです。
お使い頂く以上記事が存在しないわけはありませんので、この 基本Aスコアからダウンするか維持できるかは記事内容及び記事の書き方次第 ということになります。

各テンプレートメンテナンス記事の「GTmetrixスピードスコア」計測条件

以下がサンプルです(Sweetieテンプレート)
sample
sample

いずれも同じページ種である「トップページ」の計測結果ですが、前者は「C(78%)」で後者が「A(99%)」と大きく結果が異なります。

C(78%) A(99%)
1ページ内の記事表示件数 8 8
画像掲載数 13 8
画像容量平均 300KB 150KB
動画掲載数 1 なし
追記利用 なし あり
SNSシェアボタン(ブログ個人設定) なし なし

こういった違いがありますけれども、両者間の結果の違いに何が最も作用しているかというと、

  • 追記利用の有無
  • 画像容量対策の有無

なんですね (´・ω・`)
画像掲載数をご覧頂きますと、Cスコアの方が13件、Aスコアが8件。
Aスコアの方は13から8を引いた5件分の画像は「本文」ではなく「追記」に掲載されています。
また、Aスコアの方は動画も「追記」の方へ掲載しています。
トップページに追記は出てきませんので、その分がページ表示負荷から差し引かれているわけです。

また、ページ表示が遅くなる原因のほとんどが画像の容量によるもの です。
つまり全文表示タイプのテンプレートでは
追記を利用せず、画像の容量対策も行わない場合にはすぐに速度が落ちてしまう ということなんです。

これまで何度も口を酸っぱくして言っています。
「追記使え〜画像削減しろ〜」ってなことを(笑)
この2点を実行するだけで テンプレートのスペックを活かすことができる んですよね。
記事の表示のさせかたまで指図するつもりは毛頭ありませんが、もし貴方自身が自分のページが「遅い」と感じているのならば、他人はそれ以上にストレスを感じています。

表示負荷のサインは

  • 画像が上からベロベロ表示される --- 対象画像の容量が大きすぎる
  • スクロールがぎこちない --- ページ全体の負荷が高すぎる(画像点数, 画像容量, 1ページあたりの記事掲載数)

こう、なんというかですね、トップページに全部を書き出したい と思う方が非常に多いようなんですが、そもそもトップページというのはそういう役割のページではありません。
心配せずとも画像も文章も見たい人はちゃんと個別記事を開いてくれますからね (´・ω・`)
トップに全部ぜーんぶ記載しておけば嫌でも目に入るだろう、という考えは間違いです。
読みませんよ。即バックです。

特にスマートフォンユーザーは指でスクロールを行うわけですから、「どんな記事があるのか探してみよう」と思った閲覧者がトップページで気が萎えることのないような表示コントロールは必要だと思います。
追記を上手く扱えない、という方は今後は寧ろ レスポンシブテンプレートの利用は中止し、スマートフォン専用版を併用する ことをお勧めします。
スマホ版はほぼ強制的に要約表示タイプです。
私の全文タイプをお使いの方でもそのあたりの操作(追記利用などによるトップページコントロール)が上手くできているユーザーさんもお見受けします。
ありがとうございます

「追記使いたくてもそんなのどこにもねーよ!」という方はココ(旧投稿画面の場合) ↓
sample
簡易モードをONにしていると一生追記出てきませんので使えません。OFFにしましょう。

ブログ個人設定で表示させるSNSシェアのボタンについてはC評価・A評価いずれのページでも 表示させていません。
それでもこれだけ差が出ますので、ページ速度に重きを置かれる方は SNS純正APIボタンの利用は避けた方が良い と思います。
APIボタンは非常に重たいです。全文タイプでは各記事にくっついてきますので、それはもう大層重たいです。
1ページあたりの記事表示件数によっては尋常でなく負荷が高まることも。
テンプレートにデフォルトで表示されているものはAPIを利用していませんので軽いです。

まとめ

メンテナンス後は全テンプレート専用記事で各スピードスコアを掲載する予定です。
そのスコアを大きく下回るようなことがあれば、自分の方針に何かしら問題がある と思って頂いて間違いではありません。
基本スペックA(90%)以上は確保しますので、あとはみなさんの使い方次第ということで。

年末で作業に遅れが生じますが、少しづつでもやっていきます。
要約タイプについては後回しとなりますが、画像の遅延読み込みを要約タイプ全テンプレートに導入予定 です。
よろしくお願いします。

Related post

Comments  6

べえ
2017/12/29 (Fri) 13:02

こんにちは。

メンテ作業お疲れ様です。以前使っていたテンプレートは
結局メンテは一度も無かったです。あまり面白くない作業
かも知れませんが、メンテしていただけるのは、すばらしい
ことだと思います。要約タイプのテンプレートのメンテが
楽しみです。

さて、全文表示の件ですが、私も以前は全文表示タイプのテンプレート
を使い、追記は使っていませんでした。要約表示タイプのブログや
全文表示タイプのブログであっても、「続きはこちら」をクリック
するのがなんとなく嫌だったので、自分のブログもそうしていました。

この、クリックするのがなんとなく嫌な感じは今でもありますね。
グーグルで検索したら、その画面だけで済ませるとかw

この、クリックするのがなんとなく嫌な感じというのは、私の場合、
要約タイプのトップページで記事をクリックする場合より、全文タイプで
続きはこちらをクリックするときのほうが、嫌な感じが高い気がします。
それと、FC2のブログなのに、クリックすると他のブログサービスに
飛んだりすると、ものすごく嫌になったりします。どうしてなんだろ?

要約タイプのブログに対する考え方は、ここ一年くらいで変わってきた感じで
知り合いのブログが要約タイプで、思った以上に見やすかったからで、自分の
ブログもこんな感じにしたいと思うようになってからです。

Akira
2017/12/29 (Fri) 15:21

To べえさん

べえさん、こんにちは (o'ω')ノ

> クリックすると他のブログサービスに飛んだりする〜

そういうサイトはありますよね (´・ω・`)
大手でも姉妹サイトに強引に飛ばすとか。
まぁそういったサイトはそれがそのままサイトの信頼度にも影響しているはずなのでユーザーが賢く選択するのが一番です。
「別サイトに飛びます」の一言明示があるか無いかでは大違いですし。無い場合には即ち「狡猾なサイト」というレッテルで良いと思います(笑)

昔はスマートフォンという媒体自体が存在しませんでしたが現在では寧ろスマートフォン勢力の方が強くなっていますよね。
そして新聞よりもネットで「読む」という方も増えている。
各新聞社のサイトがその日の事件を「全文」で1ページ内に掲載したらどうでしょうね。恐らく誰も読まない。
閲覧者には「選ぶ」権利があります。
読みたい記事が1ページ内10件表示の10件目にあり、全てのコンテンツが長文掲載だとします。
しかも区切りへのページ内移動も設けられていない。
9記事を飛ばすためのスクロールってものすごくウザくないですか。
著作主が「読んで欲しい」と思ったとしても、閲覧者が「読みたいと思わない」のであれば邪魔なだけです。

検索で辿り着くページというのは基本は個別記事です。
検索ワードに密接な関係がある場合はサイトのトップページあるいはポータルが出て来ることもあります。
私は例えば「SSL」で検索したとして、「SSLの記事」ではなく「SSLのことを多めに扱っているサイトのトップページ」にたどり着いたとしたら即バックします。
そこからSSLの記事を探すのが疎ましいからです。
Googleの検索は「知りたい情報をいかに素早く得ることができるか」というのが一番の課題ですので、やはり一番大事なのは個別記事の結びつきですよね。
もちろん例外はありますよ。フリー画像を求めている方はそれを提供しているサイトのトップに飛ばすの方が良いわけですし。
それでもやはり「鳥のフリー画像」という具体的な目的がある場合には鳥の画像のページが出て来る方がより親切。
1ページ内に100の画像があり、その中に一つだけ鳥の画像があったならば残りの99は邪魔。
全文表示の場合はその「邪魔」が発生する可能性が高いということですね。
ですから極力邪魔にならないよう「追記」を使おうね、と。

あとはやっぱり情報取得云々はさておいても「ページが重たい」のは体感的にアウトです。
Googleが言う「スピードも考慮」ですが、「ものすごく速い」と「ものすごく遅い(重たい)」は区別されるべきという感じですかね。
全文は「ものすごく遅い」に該当する可能性が高い表示形態です。
追記を利用することで避けることは可能ですので、私がしつこく言うのはそこです(笑)

しの
2017/12/29 (Fri) 16:44

サムネイム画像について

トップページでサムネイム画像を表示したいのですがno-imgになってしまいます

本文記事内で<img src="url" alt="" border="0" width="380" height="" />で書いています。

教えて頂けると助かります。

Akira
2017/12/29 (Fri) 17:11

To しのさん

コメント投稿欄に明記しているお約束事をお守り頂いてから再度ご質問をお願いします。

べえ
2017/12/29 (Fri) 23:50

こんにちは。

書き忘れましたが、「画像の遅延読み込みを要約タイプ全テンプレートに導入予定」
とのことですが、実はナチュログは基本的にLazy Load に対応していまして、
お借りしている、見出しを目次化するスクリプトだと目次をクリックしてもうまく
目的の見出しに飛べない事がありました。現在は私のページはLazy Load を止めてもらっていて
上手く動作しています。体感上はLazy Load の時のほうがスクロールするたびに画像が
読み込まれる感じ(実際そうなんですが)で遅く感じました。突然止まったので、前後で
測定できなかったのが残念です。

Akira
2017/12/30 (Sat) 00:57

To べえさん

根本的にlazyload全般がスクロール系と相性が悪いですよ。
以降の内容はナチュログの仕様は全くわかりませんので当て推量になります。
遅延読み込みはthreshold(スレショルド, しきい値)という概念が必ず必要です。あるいはoffset(オフセット)という呼称でも良いです。
また詳しく説明記事は書きますが、ナチュログさんのthreshold設定がどうなっているかにもよりますし、src属性及びwidth/ height属性が書いてあるかどうかも関わりがあります。

width/ heighについて
本件の場合はwidthよりもheight属性ですね。height="auto"またはstyle="height: auto;"または数値指定なしの場合とheightに具体的な数値(px)が記されている時との違いは、表示場所をhtml解釈時に事前に作っておくことができるかどうかです。
数値指定があるとsrcの読み込みが済んでいなくても場所だけ空白状態で確保できます。
ですがレスポンシブでそれは土台無理なんです。
「レスポンシブデザインテンプレートでは」という意味ではなく、PCテンプレが固定幅であろうとスマートフォンというデバイスが存在する以上、記事は共通でもレイアウトは変えなければいけませんよね。
つまりheightはどのみち流動的になる、ということです。
記事内にhtmlで絶対数値が記されていて横幅が300以上ある場合、スマホでははみ出すか縦横比を保って縮小されるかのいずれかです。
はみ出す場合にはべえさんがおっしゃる「位置ずれ」は起こりません。
ただそれが良いかどうかは別問題。

thresholdについて
画面に入る直前の何pxで読み込みを開始するかの設定です。
lazyload系のデフォルトは大体200〜300px設定が多いと思います。
この数値を増やすとひとつの対処になるかと思います。
その代わり画面の遠くに居る画像も読み込まれることになりますのでlazyloadのパワーはダウンしますね。

結局なんでも「選択」です。そちらについても記事に書くつもりでいますけれど、全て完璧な状態というのは不可能です。
先日も記事にしましたが、例えば「スピード」に重きを置くのであれば500pxで掲載したい画像はCSSやhtml属性で1000px原寸をサイズ指定で操作するのではなく500pxに画像編集をして掲載しなさいよ、と。
でも今度は「解像度」に重きを置くのであれば500pxで載せたい画像は500px原寸にしてしまうとひどくぼやけるので1000pxにしなさいよ、と。
こういった真逆思考が常に存在しますので、自分がどこに一番の軸を据えるかの選択です。

> Lazy Load の時のほうがスクロールするたびに画像が読み込まれる感じ(実際そうなんですが)で遅く感じました〜

これはたぶんね、べえさんが「記事を読んでいないから」です。
記事を書いた人間というのは自分の記事を誤字脱字チェック以外で読み返すことってあまり無いんですね。
じゃあページを開いて何をするかというと「動作確認」です。
スクロールのボタンを押してみる、などがそうです。
でも記事を読んでいる人というのはいきなりガーーーっとスクロールを始めることはまず無いわけなんですよ。
ですから画像がゆっくり表示されても苦にはならないんですね。
閲覧者が一番苦にするのは初回ロードの速さ(遅さ)です。そのための対策の一つがレイジーロードです。
またある人は「ゆっくり表示される」ことを「遅い」と感じる方も居ます。
これは個々の感じ方ですよね。
ナチュログがいきなり表示なのかopacity 0からopacity 1へ移行させることでフワっと感を出しているのかわかりませんが、opacityが気になる場合には完全透明から完全不透明になるまでの秒数を整理するとか。
まぁ色々な対処がありますね (´・ω・`)
lazyloadの意義というのは「初回ロード」であって。
画面に収まっていようといまいとhtmlに書いてある要素は全て一度に読み込まれますので、その中から画像だけは省いておきましょう、というのが目的ですからロード自体は確実に負荷が軽減されているはずです。
なのでデザインコントロールの面で「体感として遅く感じる」のかなぁ、と思います。
わかんないけど(笑)

コメントに関する注意事項
  • テンプレートに関するご質問は各テンプレート専用記事でのみ受付致します。また、よくある質問をまとめているページも事前にご参照ください。
  • 専門的なご質問の場合、記事内容と明らかに関連の無い内容はお控えください(雑談の場合はその限りではありません)
  • 第三者が不快と感じる内容や論調でのコメントはお控えください(性的,高圧的,暴力的など)