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

こんにちは。

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

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

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

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

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

To べえさん

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

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

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

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

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

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

サムネイム画像について

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

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

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

To しのさん

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

こんにちは。

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

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に書いてある要素は全て一度に読み込まれますので、その中から画像だけは省いておきましょう、というのが目的ですからロード自体は確実に負荷が軽減されているはずです。
なのでデザインコントロールの面で「体感として遅く感じる」のかなぁ、と思います。
わかんないけど(笑)