FC2ブログでのLazyload導入の仕方と注意点【検討編】

FC2ブログでのLazyload導入の仕方と注意点【検討編】

カスタマイズ
2018/01/09 4
vanillaice (Akira)
vanillaice (Akira)
Education Lazyloading Lazysizes VanillaJS 高速化

Lazyloadは自分との闘いです(笑)

まず最初に、初心者向け説明記事ということで、なるべく平たく細かく説明できれば良いな、と思います。
Lazyloadが何か知らない。読み方もわからない (∵`) 」を出発点にして自ら説明のハードルを上げるワタクシ((((笑)

説明すべき点がたくさんありますので、かなりの長文になりますから記事も数回に分けようと思います。
導入の具体的な手順は最終の記事にしますので、それまでの説明をお読み頂きましてご自身の方向性を決めて頂くと良いですね。
Lazyload導入手順自体は多くのサイトさんが既に提供されていますので、私としては FC2ブログで導入した後はこうなるよ という デメリット についての説明も重視していこうと思います。
なので「Lazyloadの意義などはわかっていて導入方法が知りたい方」へ向けてではなく、「Lazyloadという手法を知り、それが自身にとって取るべき道なのかどうかを考える」ところからがスタート地点となる記事です。

Lazyload(レイジーロード)とは

簡単に言うと「画像の遅延読み込み」です。
さらに平たく言うと 画像へのアクセスタイミングを遅らせて、ページ全体の表示速度UPを目指すための一手段 です。
用いる分野は Javascript(ジャバスクリプト) です。htmlやCSSでできるものではありません。JS実装です。

Lazyloadという名前

まずここから。Lazyload(レイジーロード) という名称ですが、これは画像の読み込みを遅らせるために製作されたjQueryプラグインの名前です。
これ商品名(プラグイン名)なんですね (´・ω・`)
有名な作者さんはMika Tuupola(マイカ チューポーラ)氏。あまりに優れあまりに有名なので、商標名と製品名が同一化したパターンです。
なので製品的に言うのであれば「delay loading JS」とかそんな感じでしょうかね。
Masonry(メイソンリー)なんかもそうです。作者はDavid DeSandro(デビッド デサンドロ)氏。
webを離れれば
商標名「ホッチキス」の一般名は「ステイプラー」
商標名「オセロ」の一般名は「リバーシ」
商標名「エレクトーン」の一般名は「電子オルガン」
とかそういうの。

何故この説明が要るかと言うと Lazyloadには多くの種類があり、全てが同じソースコードなわけではない ということです。

ページ表示(ローディング)の仕組み

「何故画像の読み込みを遅らせるのか」の説明になる章です。
ページ表示の仕組みで一番押さえておくべき点。
html内容に書かれているものは全て一度に読み込まれる。
ここですね (´・ω・`)

テンプレートのhtmlというのはたくさんの文字列が書かれています。
そしてそこにある内容の全てはみなさんがURLをクリックした際に一度に情報の取得が行われます。
それが描画(レンダリング)されて私たちの元に届けられるわけです。

ところが私たちが実際に目にする「範囲」というのは制限があります。

縦幅がデバイス画面を超えていたら、超えた分は見られない ですよね。
画面の外(下)に居る内容は スクロール を行わなければ目に入っては来ません。
この「スクロールせずに見られる範囲」のことを ファーストビュー または above the fold(アバブ ザ フォールド) と言います。
より馴染みの深い表現は「ファーストビュー」の方ですかね。英語的にはabove the foldです。
見えている範囲は above the fold、見えていない範囲は below the fold。

ファーストビュー外、blow the fold部分についてはどうせ初回表示時には見られないのだから、一度にローディングしなくても良いんじゃないの?
という考え方ですよね。フツーに考えてフツーに辿り着く結論だけれども(笑)
サンプルでも3段目4段目の4つの画像は完全にbelow the foldです。
2段目の2つは画面内に顔を出してますのでabove the fold。

じゃあ、below the fold部分の「html内容」を読み込まないわけにはいかないので「html内の画像」に的を絞って画面外の画像は初回ローディングの対象から外しましょうよ、と。
画像の容量というのはページ表示速度に大きく影響しますので、その影響大要素を省けばページが軽くなるんじゃないの、スクロールして画面の中に入ってから取得すれば良いんじゃないの、と。
単純にページ内に10の画像があり、そのうちファーストビューに含まれるのが2だとします。
1画像100KBの容量があるとしたら、通常のローディングだと画像だけで
100KB × 10個 = 1000KB(1MB 正確には1024KBが1MB)
ファーストビューと無関係な8画像分を排除できると 1000KB - 800KB = 200KB
単純計算で本来1MB取得しなければいけないところが、200KBまで負荷を減らせます。
そういうことをするのがLazyloadです。

まぁ単純に言えばそういうことなんですが、htmlの仕組み的にはそんなに単純な話でもないんです。
原則としてhtml内に何かの要素があるならば、それはローディング「されてしまう」んですね。
それを避けるためには ローディングできないようにする しか方法がありません。今のところ。
Lazyloadは 通常のローディングを「できなくさせる」 という点を知っておくと、以降の内容、特に注意点が明瞭になるかと思います。
そして後程記す「ジレンマ」についての説明の理解も早いのではないかと。

Lazyloadを導入すべき人とそうでない人

誰でも彼でもお勧めするわけではありません。
私個人は「すべきでない人」の明確な定義を持っております。あくまでも個人的意見です。

Lazyloadを積極的に導入すべき人

  • 画像を多く扱っている(記事内の掲載画像が多い)人
  • 記事内でhtmlを手入力することが苦にならない人
  • 自分のブログのページ表示が「遅い」「重たい」という自覚があり、「なんとかしなければ」という意識が有る人
  • htmlバリデーションを柔軟に考えられる人

導入しようかな?と考える方はこれら条件が全て揃っていた方が良いと思います。
特に FC2ブログでの導入はひどく苦労を強いられることがある(個人感によります) からです。
苦労の具体例は後述。

Lazyloadを導入すべきでない人

  • htmlバリデーションがめちゃくちゃ気になる人
  • SEOに完全な安心感・証明性が無ければ納得できない人
  • 画像をほとんど掲載しない人
  • 記事内でhtmlを自分で書くなんてありえないと思っている人
  • 全部テンプレートが(テンプレート製作者が)やってくれるんでしょ?それが当たり前でしょ?と思っている人
  • ブログを書くためだけに難しいことはしたくないという人

ただ「ブログを書く」という行為を純粋に楽しみたい、という方は無理に導入しない方が良いと思います。
でないと記事を書くことすら嫌になってしまう恐れが(笑)
htmlどんと来い、な方にしかおすすめしません。

デメリットとなり得る点について

やっぱり良いことばかりではないんですよね (´・ェ・`)
そして今回は FC2ブログで という縛りがあります。
Wordpressで導入するのとFC2でするのとでは受け皿自体が全く違うわけですから、FC2ブログのシステム・プログラムもある程度理解しておかなければいけません。

FC2ブログはphpが使えません

phpというのはユーザーがページ表示の「リクエスト」を行なって「レスポンス」が返ってくるまでに、サーバーサイドで行なってもらいたい処理をお願いするためのものです。超簡単に言えば、ですよ?
FC2ブログでphpが全く使えないわけではなく、一部ユーザーに開放されているものもあります。
それが 独自変数 です。
例えばテンプレート内に
<%topentry_image_w300>
と書いておくと、
<img src="画像アドレス">
こうしてヘンテコ文字列だったものがimg要素として戻ってくるわけなんですね。その変換処理はサーバー側で行なってくれます。

ここから大事。
LazyloadはLazyload用のhtml記述が必須 です。 そしてその内容は、レスポンスが戻るまでの間にちゃんと記述の処理が済んでなければいけないんですね。
難しめな言葉で言うと「DOM構築時に変換が済んでいなければいけない」
みなさんこれまでに JSでクラス名を追加する、要素を追加する なんてことをやったことがあるかもしれません。
その感覚で「過去記事の画像にもLazyload用のクラス名を付けたり属性を追加する」ことで済むのではないかと考える。
残念ながらLazyloadでは通用しません (´・ω・`)
というわけで一般的な選択肢は二つだけです。

  • 記事を書く時にLazyload用の特別なhtml記述を行う
  • phpで処理をしてもらう

この二つ。
JSというのはサーバー側が実行するわけではなく、サーバーからレスポンスを受け取った後でブラウザ側が行うものです。
JSで要素や属性やクラス名を追加するというのは可能なのですが、所詮は 後付け です。
リクエストをする → レスポンスが返って来る → JSの処理をする
という順番です。Lazyloadを使いたい場合には
リクエストをする → Lazyload用html内容に変換するレスポンスが返って来る
こうでないとイカン (´・ω・`) レスポンスを受け取る時にもう済んでないとダメ。
そしてそれはFC2ブログではできないよ、ということです。
FC2ブログでは一択。

  • 記事を書く時にLazyload用の特別なhtml記述を行う

これだけです。
結果、過去掲載画像は手作業でのhtml修正をするか、諦める ということですね。

ちなみにFC2ブログではalt属性の後付も同じですね。
FC2ブログの変数で変換されてくるimg要素にはalt属性がついていません(付けてくださいよマジで…)
そこでalt属性をJSで追加、という作業を仮に行なったとしてもバリデートは元のhtml(JS適用前)のまま行われますので通過しません。従ってエラーです。
「JSでalt追加してる…。」という方は付け焼き刃どころかクソの役にも立っていないので寧ろ無駄なJSは省いた方が良いですね(泣)

とりまこの件についてはhtml記述の手助けになるブックマークレットを作成してあります。
まだ今回は「検討するための記事」ですので掲載はしませんが。

場合によってはバリデートに合格しない(対処法あり)

この点が嫌な人にとってはすっごく嫌だろうと思ふ(笑)
Lintなどの亜流は無視してここではご本家の W3C を前提に話しを進めます。

htmlが正確であるかどうかを検査する「バリデート」ですが、Lazyload用のhtmlを書くことで合格しなくなります。
つまり「エラー がありますよ」と指摘を受けることになります。
ここから理屈・屁理屈の世界になりますが結構重要なので導入を考えている方は必読で。

既に述べましたが、Lazyloadがやることというのは「ローディングできないようにする」という、発想的には至極単純なことなんですね。
その発想はさておき、htmlというのは明確なルールが存在します。
今回のターゲットになるのは「画像」つまり「img要素」です。
Lazyloadはimg要素のルールである src属性は必須 を守ることができないんです。
src属性というのはこれですね ↓

<img src="画像アドレス" alt="">

緑の部分。画像のアドレス(URL)を記す属性のことです。
この属性が何故必須かというと、ものすごく当たり前の話しですが 画像のアドレスが無ければ表示ができんやろが ということです。
でもLazyloadがやろうとするのは「画像は画面内に入るまで読み込まない」という作業ですから、裏を返せば src属性を書いてしまえば読み込まれてしまう ってことです。
この点でバリデートとは相容れない。

一般的な対策として src属性に 無色透明極小画像を代替として入れておく という作業が行われます。
いや、任意です。個人的には「強メンタルならやらんでも良い」(後述)

無色透明極小画像はスペイサーGIFの通り名がありますけれども、別にgifでなくpngでも良いです。
表示させるための画像ではなく、ただ場所取りだけ・代理としてだけ用いる画像なので極小サイズ極小容量であればOKです。

でもねぇ、これって要ります? (´・ω・`)
スペイサーgifなんて表示の必要が無いわけなんですよ。見せなくても良いというか、見せたところで無色透明。
data URIにしても同じこと(data URIについてはまた後日説明しますので今はスルーで)
バリデートで合格印をもらうためだけに見せる必要もない画像を設定する。
これが合理的かどうかですよね (´・ω・`)
極小とはいえ読み込まれますので、ある意味Lazyloadの意義に反してるんでないの(笑)
でも書かないと合格しないからね。めっちゃジレンマやーん (。Д。*)

バリデーションなんてどうでも良いです(微笑み)
という方は「src属性は書かない」という方向で良いと思います。
「一応正しくしておきたいんで…」という方はsrc用の代替を用意する、と。無駄とはいえ。
このあたりのジレンマに耐えられない方も居るかもしれない。わかんないけど(笑)

リアルタイムプレビューで画像の確認ができない

上級者は気にならないと思います。
この章は主に旧投稿画面をお使いの方かな。新投稿画面はそもそもがHTMLモードにはリアルタイムプレビューがありませんし、新投稿画面しか使わないという方がLazyloadを必要とするとは思えない。

Lazyloadのhtmlというのは何度も繰り返しますが src属性を書かない(あるいは無色透明画像を代入しておく) です。
モノホンの画像は data-xxxx というhtml5のカスタムデータという属性に記します。
カスタムデータ属性はhtml4では利用できませんので、テンプレートがhtml4でこの記事を読んでいるという方は無意味ですのでブラウザバックで ←
つかもういい加減html5にした方が良いと思うよ?ん?

xxxx の部分は不特定文字列です。
どの(誰が製作した)Lazyloadを利用するかで異なります。
「カスタム」の意味を考えればわかると思いますが、これは共通属性名ではありませんので、数多あるLazyload系のどれを使うかによって違います。
ともかく共通しているのは src属性を空にしておく ことですので、src属性が無い = 描画されない
この理屈ですね。従ってリアルタイムプレビューに出てくるはずもなく。
確認をするためにはリアルタイムのそれではなく記事下にある別タブで開く「プレビュー」を利用することになります。
初心者さんはここらへんの特徴で断念するかもしれないなぁ (´・ω・`)
上級者は基本なんでも脳内補完だよね。いやたぶんだけど(笑)

ページ内スクロールと相性が悪い

これはLazyloadのJS設定、サーバーの性能、htmlの書き方などの要因が絡み合うのでズバリこうですとは言えないのですが、総合的に見てやはりスクロール系のJSをは相性が悪いですね。
理由はおわかりかと思いますけれど、ページ内スクロールは読んで字のごとくページ内をスクロール移動するためのJSです。
対し、Lazyloadというのはスクロールしてから読み込む系ですので、ページ内スクロールが始めた時点でまだ画像が読み込まれていない可能性があります。
となると スクロールの指定位置がズレてしまう かもしれませんよね。

読み込まれていない = 場所を占有していない
これ「ほぼ」同義ですので、スクロールされていくうちに画像の読み込みが行われ、到達点がガクっと下へ下がることは大いにあり得ます。それまで無かった画像が出てきて場所取ってこんにちはーってなるわけだから。

こちらの問題点については対策ができます。

  • src属性を省かない(代替画像 or data URIを利用) --- 初心者向け(簡易)
  • 縦横比を予め指定しておく --- 上級者向け(確実)

まず初心者向け。
ジレンマの話しをしましたけれども、目的を重視するとsrc属性は邪魔です。
delay loadingのJSが実行された後にはsrc属性が追加されますが、バリデートはしつこいようですがJS実行前のhtmlソースで検証が行われます。つまりsrc属性が無い状態ね。
ここさらにしつこいですがみなさんご自身でよく考えておいてください。個人の意思に委ねられる部分です。

で、今スムーススクロールの話しをしているわけですが、ページ内移動の「到達点」のズレが気になるという方は src属性を省略しない 道を取られた方が良いですね。
画像にsrc属性が与えられており、かつ、width/ height属性が記載されている場合にはレンダリング時に場所の確保が為されます。
当たり前っちゃ当たり前ですが (´・ω・`)
代替画像として原寸1×1の無色透明を利用しますが、それが拡大されて一旦表示されることになります。
そしてそれが場所取りになる。

以前「ナチュログのlazyloadがtoc(見出しスクリプト)のスクロール位置をずらしてしまう。」というお話をコメント欄で伺いました。
他サービスのdelay loadingについてはまた後日まとめますが、ナチュログさんのlazyloadをちょっと調べてみたところ
src代替画像無し(src属性無し)
のようですね。どうも。
ナチュログのエディターの仕様を存じませんので絶対とは言えません。ごめんなさい。
src属性が入っていれば多少軽減でき、大きくずれることはありません。
「小さく」はずれる(笑)

「小さく」ともずれるのは、スペイサーGIFは正方形だからです。
オリジナル画像が横長や縦長であった場合、結局はどうやったってずれるよ (´・ω・`)

このスクロール系との相性の悪さは対処するというよりも特徴・性質と捉えて我慢できるかできないかの選択かなぁ、と思います。
それでもやはり気になるという場合には記事作成の際に少し面倒なhtmlを書くことになります。

面倒な方法、上級者向けの内容はコチラ ↓

Lazyloadingでページ内スクロールの到達位置がずれる件を解消する方法 - カスタマイズ

正直あんまりおすすめではない (´・ω・`) すすめない理由は 要素が増える めんどくさい 記事内でstyle属性あるいはstyle要素を必ず使う必要がある pタグ内の画像はどうする(セマンティクス面) こんなところでしょうか。 特に要素が増えてしまう点ですね。無駄なラッパーが増えるというか。 結局は自身の記事内容の管理能力であったり理解力であったりに関わってきますので、html初心者にはおすすめしません。 ...

SEO面での根強い不信感

これは個人的に「解消されている」と思っていますが絶対とは言いません。
根本的に「不信感が少しでもあるのならば使わない方が良い」と思います。
これは今回のLazyloadに限らずテンプレート選び・プラグイン選びにしても何にしても同じです。

Lazyload自体は2010年以前からあります。
で、「SEO面でよろしくない」という情報が出回っていたのが2013〜2015年ぐらいが一番多かったのかな、という印象です。
SEOに良くない、を簡単に説明します。

Googleのbot(検索ロボット, クローラー)というのは、ページのhtmlをダイレクトに見に行きます。
そしてレンダリングも行います。
そのページが実際に描画された時にどうなるのか、コンテンツは収まっているのか、htmlに記述が有るのに閲覧者にとっては不可視の(見ることのできない)隠し内容が有るのか(クローキングというSEOマイナス要因です、というか悪)、などの検査もクロール時に行われます。

ところがbotは スクロールという動作を行わない んですね。
ページ全体を一つの大きな図として見ています。
けれどもLazyloadの仕込まれた画像というのはスクロールをしなければ出てこない。
従ってGoogleが発見できない = 画像のインデックスが行われない
というわけです。

現在2018年を迎えたところですけれども、現状どうなっているかについて。
Googleは昔「window on load function は実行している」と明言していました。
んー。かなり前のうろ覚えなのでソースの保存をしてなくてごめんなさい(探す気力はない ←)
つまりJSも一部はちゃんと実行しているよ、ってことです。
on load function は「ページロード時に実行」するという意味。
Lazyloadは scroll function であり「スクロール時に実行」されるJSです。
で、Googleは今Lazyloadもちゃんと読み取ってますよね (´・ω・`)
それが 「scroll function を実行することによって」なのか「html5のカスタムデータ属性と結びついているJSの解読によって」なのか私はわかりませんけども、ともかくLazyload対象の画像もちゃんと取得しているしレンダリングもしてるしインデックスもされてます。

The lazy loading SEO problem, SOLVED! | dinbror

Since search bots like googlebot started to render JavaScript it can now see and index your lazy loaded content.

こちら2015年の記事ですけども「レイジーローディングのSEO問題が解決!」と題されたもの。
ザッと説明しますと、何故SEOに良くないとされていたかの簡単な説明・これまで主流だった対処法・現在の状況などが書かれています。
対処法を訳しますと

Solution #1, Image sitemaps (no good)
解決策1「イメージのサイトマップを作成する」良くない
Solution #2, noscript (no good)
解決策2「noscriptタグを使う」良くない(html5ではnoscript自体非推奨)
Solution #3, escaped fragments (works but deprecated)
解決策3「エスケープフラグメントを利用する」効果はあるがマークアップレベルで廃止
Solution #4, do nothing (works)
解決策4「何もしない」効果あり

要するに、Googleのbotがかなり正確にJSの解釈をしてくれるようになったので、もう何もしなくて良い ってことを言ってますね。
で、それやはり事実です (´・ω・`)
なのでLazyload系プラグインの作者さんたちが精進してこの結果を導いたわけではなく、Googleが時勢に合わせてくれたことで解決を見た、ということになります。
Google bot進化による決着ってことですね。

ただこの点についてはまだ「良くない」という風潮もありますので、不信感を抱きながら利用する必要はどこにもないと個人的に考えます。

FC2ブログの公式として導入される可能性が無いとは言い切れない

公式導入されることが「デメリット」ではないんだけども、導入済みの方にとってのみデメリットとなり得る点。
もしかしたら今後FC2ブログから「画像の遅延読み込みができるようになりました」みたいなアナウンスが届くかもしれませんよね。
ブログ個人設定でできますよ、プロアカウント限定ですよ、とか。
実際いくつかのブログサービスで運営による導入を確認しています。
(アメブロ(スマホ版のみ), ナチュログ, muragon など)

FC2運営陣による導入があれば、「あの苦労は一体なんだった (;ωq`)」な日が来ることもありますよね。
さらには既存のhtml内容が邪魔になってしまうことも考えられます。
まぁそれは仕方のないことです。実装されるかどうかも不明なものを待つのか、それとも今やるのか。
それは個々の選択で。

これ割りとサラリと書いてますが、後々大きな問題になる可能性もあります。
FC2が公式な機能として導入する場合にはphpでのhtml操作になるはずです。
imgのソースコードがエディターが吐き出す内容と合致していないと処理ができないかもしれませんよね。
その可能性は高いです。
なので今個人導入する方はもしその時が巡ってきたとしても個人のJS内容を引き継がなければいけない、ってことになります。
公式導入のシステムの方が楽に決まってますが使えないと思った方が良いです。

ただ公式導入があるかどうかなんてことは知りようが無いのでどうするかは自分で決める。ゴリゴリの自己責任(笑)

デメリットの補足とまとめ

初心者向けということで、察しの良い方へは説明不要だとは思いますが、恐らく巡り合うであろう嫌な場面をもう少し細かく記しておきます(笑)

テンプレート選びが困難になる… かも

テンプレートを変更したいなぁ、と思ったら公式配布ページで対象テンプレートをクリックして確認しますよね。
でもあなたの記事の画像はプレビューできませーん (´・ω・`)
文章や画像のバランスなんかが容易には確認できなくなるかもしれませんね。

一度利用を決めたらブログを閉じるまで継続する必要あり

独自クラスによる装飾なんかもそうなんですが、テンプレートを変更する都度内容の移植をしないとデザインは全て失われてしまいます。
とはいえCSS装飾程度、例えば画像にシャドウをつけるだとか、その程度ならば自分が別に「もうめんどくさいからいいやー。」でもそれで済んでしまいます。
シャドウがつかなくなるぐらいどうってことない。
Lazyloadはそういうわけにはいきません。
Lazyload用に書かれたimg要素の特別なhtmlはLazyload本体の利用を取りやめたら一生表示されません。
シャドウはどうでも良くても画像自体が表示されなくなっても良い、という人はまず居ない。
なので「使うか」「使わないか」を真剣に熟考する必要があります。
軽い気持ちで「ちょっとやってみようかな。」では済まないんです (´・ェ・`)
ここで一度念押しですが、「FC2ブログでは」ですよ?
phpが使える環境です、とかそういう場合は対処のしようがありますのでこの限りではありません。

というわけで、今回は主にデメリット面を中心にしました。
このデメリットを補っても余りあるメリットもありますので、自身の性質(性格)・環境などを考え併せてから導入するしないを決めて頂くと良いかな、と思います。
次回は具体的な導入の仕方、htmlの書き方などを記します。

* 次回公開までまた少し時間を置きたいと思います。
メンテがさぁ〜 ( ̄∀ ̄;)あう

 4

There are no comments yet.
黒猫
こんばんは(^^)

今年もよろしくお願いしますm(_ _)m

なんか複雑そうですね(^-^;
続編を読みながら考えていきます!

2018/01/10 (Wed) 22:31
べえ
遅くなりましたが

あけましておめでとうございます。昨年は、とってもお世話になりました。
このサイトとっても役にたってます。今年もよろしくお願いいたします。

面手作業順調のようにお見受けします。Velonica などの要約タイプの
メンテも近いのかな? Velonica を気に入っていたので楽しみです ^^

でも、Lazyload ややこしいですね。構造化データで画像を普通に書いていたら
ナチュログだと勝手にHTMLを書き直してくれてエラーになったりしました。
画像の表示とは別に画像のURLを直接指定したらエラーは出ないようですが、
面倒な作業です。

2018/01/11 (Thu) 00:34
vanillaice (Akira)
Akira
To べえさん

ご丁寧にありがとうございます。
こちらこそよろしくお願いします :)

そうですね。作業自体は複雑ではないんだけれども、Lazyloadはあまり軽い気持ちで手を出せない部類のアレでソレです。
また近いうちに記事を公開しますので、そちらも併せてお考え頂ければ ^^;

2018/01/11 (Thu) 02:00
vanillaice (Akira)
Akira
To Akiraさん

こちらこそ大変お世話になりました。
本年もどうぞよろしくお願いします :)

今急ピッチでやってますのでお待ち下さいね。
私集中力が続かない人間なので10分やっちゃー他のことやっちゃーの繰り返しで進まないんですよっ!(笑)

要約タイプはLazyloadをトップにデフォルト導入しようと思っていますので、そのままJSを個別記事にも流用して頂いた方が良いですよね。ひとつ手間が減るわけですし。
だからメンテ早くやれって話しなんだけど((((笑)

ナチュログさんはphpでhtmlを操作しているはずですので、それやられちゃうともうユーザー側ではどうしようもないというか (´・ω・`)
一長一短ですかね。そういう意味では。

2018/01/11 (Thu) 02:12

テンプレートに関するご質問・不具合のご報告の際はご自身のブログアドレス記載必須です。
ご質問の前に 必ずお読みください
テンプレートに関するご質問時のお願い

必ず該当テンプレートの専用記事にお願いします。無関係な記事・別のテンプレート専用記事でのコメントはお控えください。
テンプレートカテゴリ
テンプレート一覧

カスタマイズ