FC2ブログの高速化は何ができるか

投稿 2018年05月09日
10
カスタマイズ
FC2TemplateSEO高速化初心者向け

Googleの スピードアップデート が2018年7月に来るよ。
ということで、自ブログのスリム化・高速化に勤しんでいる方も多いかと思います。
え?多いかな?どうだろう (´・ェ・`)

今回の記事では

  • FC2のスペックを知っておく
  • 数字に踊らされない
  • 私の(Akira作の)テンプレートで軽量化できそうなところと提案

などについて。
あくまでも FC2ブログで というのが大前提です。

FC2ブログサーバーのスペックは中レベル

低くはないですね。しかし高くもない。
ここについてはやはり 無料会員の方が不利 になっています。

現在ですとあらゆるwebサービスがSSL化しつつあり、FC2も例に漏れずSSL化つまりhttps通信が可能になっています。
httpsは HTTP/2 (Hypertext Transfer Protocol version 2) という高速通信が可能ですが、それは サーバーによります。
FC2ブログの有料会員の場合、画像サーバーについてはアカマイCDNを経由しますのでHTTP/2が利用できます。
無料会員は 個別記事下のテキスト広告を表示させている 場合はHTTP/2が使えます。

ところが有料・無料を問わずブログ全体の通信は HTTP/1.1 のみなんですね。
HTTP/1.1 つまり旧式の通信であり 遅い ってことです。簡単に言えば。
ブログ全体はHTTP/1.1で、中に含まれる画像ファイルやJSファイルなどは、個人の環境(契約内容や選択)によってはHTTP/2が使える、ということです。

参考までに他ブログサービスの場合。HTTP/2の場合は 付けてあります。

  • アメブロ ---
  • はてな ---
  • Yahoo! ---
  • Blogger ---
  • エキサイト ---

てか、Yahoo!(笑)

続いてサーバーのレスポンスについて。
専門用語的には TTFB (Time to First Byte)
リクエストを行なって後、サーバーから最初の1バイトがレスポンスとして届くまでの待ち時間のことです。
数値(秒数)が低い = 速い
応答が早ければ早いほど性能が良いということになります。
GoogleはTTBFを 「200ミリ秒 にしろ」と言っているわけなんですが、FC2は平均400から遅い時は800とか。ダメじゃん(笑)
ただFC2のこの数値も他サービスと比較するならば遅いというわけではありません。
Google御大による絶対評価で言えば遅いのでしょうが ^^;

このサーバースペックについてはもうどうしようもありません。ここを語るならばもうサービス変えようか、サーバー借りようかって話しになってしまいます。
今回の主旨はあくまでもFC2ブログ残留(笑)

スピード計測サイトの数値に踊らされない

製作・提供の立場として画像の遅延読み込みを各テンプレートに取り入れている最中です。
この機会に遅延読み込みの効力も知って頂きたいので、テストファイルを作成してみました。
計測は GTmetrix を利用しようと思います。
各ファイルの測定がすぐにできるよう、以下のブックマークレットをまず登録してください。もちろん強制ではありません。
(スマホアクセスの方はごめんなさい)
黒背景の GT をマウスでドラッグ、ブラウザのブックマークバーにドロップ。

GT

プレーンテキストのみ

まず、遅延読み込みのテストも兼ねていますので コンテンツはスクロールを行うまで出てきません。
アクセス直後は真っ白な状態です。スクロールすると下の方に内容がありますので確認してください。

プレーンテキストのみのページ

ファイルが開きましたらそのまま先程登録したブックマークレットをクリックして Analyze をクリック。検証が始まります。

テスト結果スクリーンショット

YSlowの結果の方は割りと変化しますのでアレですが、テキストのみのページでも 100点取れてない という事実に注目(笑)
これはFC2のサーバーを通してますので、その仕様だと思ってください。
そして主にPageSpeed Scoreの方で言及を行なっていきます。

この「プレーンテキストのみ」のファイルが基本として以降のファイルと比較を行います。

プレーンテキスト + 絵文字

絵文字はFC2エディター(旧投稿画面のツール)からの挿入を前提としています。
ツールバーを利用した掲載の場合、その絵文字は全て 画像(img要素) です。

プレーンテキスト + 絵文字のページ

テスト結果スクリーンショット

AスコアからBスコアへ 1ランクダウン
パーセンテージでは 13%ダウン という結果です。
出発点が97と高いからB84でとどまっていますが、出発点がBからならばCへ。CからならばDへ降格されるということです。

かなり勘違いをされている人が多いと感じるのがこの 絵文字の利用 なんですね。
「小さいから大丈夫。問題ない。」
問題なくない (・A・)
スコアを大きく下げた原因は容量の大小ではなく 通信リクエストが発生している 点です。
いくら小さくとも画像は画像。しっかり通信が発生します。
絵文字1つにつき1%の減点となります。

あなたの記事は絵文字だらけではないですか?

プレーンテキスト + 絵文字 + 画像遅延読み込み

画像の遅延読み込み(lazyloading, delay loading)を行うとどうなるかのテストケース。
内容はすぐ上の「プレーンテキスト + 絵文字」と最終レンダリング内容は全く同じですが、htmlは遅延読み込み用になっています。
そして当然ですが遅延させるためのJSファイルへのリンク(通信リクエストが発生します)が追加されています。

プレーンテキスト + 絵文字 + 遅延読み込みのページ

テスト結果スクリーンショット

スコア落ちてないですよね。パーセンテージが各1%落ちただけ。
これが遅延読み込みの有益性です。

でもね。しかしBUT

Fully loaded time のところ見てください。
451ミリ秒から1300ミリ秒に落ちてます。
スコアは維持できていますが、ページ表示の体感速度は逆に下がっているわけです。
スペード計測系テストツールでは往々にしてこういったことが起こるんですね。
ですから「スコアだけを見て」「スピード秒数だけを見て」何かを判断するのはかえって危険です。
やはり総合的に見ないと (´・ω・`)

で、この結果から「結局lazyloadingなんて無駄じゃん」と結論づけるのも無謀です。
実際のページというのはテストファイルよりも遥かに複雑で入り組んだ内容になっているはずですからすぐに逆転現象が起こります。
とはいえスコアについては単純な 理論値 だいうことは言えるかと思います。

具体例を言うとFC2ブログには「全記事一覧ページ」が存在します。
このページは基本的にはサムネイルの取得・掲載が不可なので画像に関する警告は発生しません。
ですからスコアも高いはずです。
が、体感スピードとしてはかなり遅いです。モバイルで10秒超えるとかザラです。
でもスコアは高い。
数値に踊らされるな というのはそういう意味です。

プレーンテキスト + 絵文字 + YouTube

プレーンテキスト + 絵文字 + YouTubeのページ

テスト結果スクリーンショット

A97からC75へ大幅ダウン。

プレーンテキスト + 絵文字 + YouTube + 遅延読み込み

プレーンテキスト + 絵文字 + YouTube + 遅延読み込みのページ

テスト結果スクリーンショット

遅延読み込みはスコアに対して非常に効果が高い、というのをお分かり頂けたのではないでしょうか。

テンプレートの軽量化

言及は私が製作したものに限ります。
提供する立場と利用する立場では取るべき対策も異なりますので、ここからはみなさんのお手元にある内容について「もしかしたらこうすると良いかも」の提案です。

シングルカラムへの変更

レンダリングの性質を考えるとこれが一番良いんですね。
CSSが複雑にならないというのももちろんありますし、最大の理由は ファーストビューに専念できる「かも」しれない というところです。

シングルカラムの場合にはサイドメニューは下の方にありますので、よほどのことがない限りabove the fold(画面内)には入ってきません。
であるならばCSS内容を後回しに出来る可能性があります。

複数カラムだとそういうわけにはいかないんですね。
サイドメニューの上辺とがメインの上辺が同じということは、それなりに整形をしておかないと未完成なページを閲覧者のみなさんにお見せすることになってしまいます。

テンプレートの中からシングルカラムを選ぶ。それ自体は何も難しくないので
難易度

シングルであることを活かしたCSS操作をするならば
難易度

above the fold内で確実に必要となるCSSは インラインCSS として <head></head> 内に style要素 として記載します。

<html>
  <head>
    <style>.xxx{background-color:yellow}.yyy{color: blue}.zzz{font-size:8em}</style>
  </head>
  <body>
    .
    .
    .
    .
  </body>
</html>

そしてabove the foldに関わっていないCSSはhead内には置かず </body> の直前に記載します。
インラインCSSをhead内に用いると同時にlink要素として外部CSSファイルも用いている方をたまにお見かけしますが、それは何の意味もありません。

<script>
  var link = document.createElement('link');
  link.href = 'CSSファイルアドレス';
  link.rel = 'stylesheet';
  link.type = 'text/css';
  var head = document.getElementsByTagName('head')[0];
  head.appendChild(link);
</script>

こうして後回しにします。
link要素はhead内にしか記載できない決まりですのでJSを利用して差し込みます。

ソースコードの書き方が難しいのではなく「above the fold(画面内)」と「below the fold(画面外)」のCSS内容の切り分けが非常に難しいので難易度MAX。

汎用ページ送りの使用を辞める

「汎用ページ送り」というのは私が勝手にそう読んでいるだけです。
全記事一覧・個別記事以外のページで表示されるページネーションのことです。

この使用を取り止めて、簡単な前後ページの遷移(prev, nextリンクのみ)にすればJSファイルを減らせますので軽くなります。
ただし個人的にこのタイプの送りは 必要 だと思います。
全30ページあるところ、目当てのページが10ページあたりにあると予測が立っているのに1ページづつ送るとかマジでストレス。

難易度

jQueryの使用を辞める

これは難しいかなぁと思います。
難易度

jQueryプラグインが総じて利用不可になるのと、プラグイン以外でもJS実行コードがネイティブJS(vanilla JS)で書かれていない場合には全て書き直しになります。
そこがクリアできるのならば脱jQueryを考えてみるのも良いと思います。

個別記事下のサムネイルつきページ送りの使用を辞める

こちらはいくつかのテンプレートに導入しています。
FC2ブログでは今のところ前後ページのサムネイルを取得する変数が存在しません。
そしてphpも使えませんので、ajax(非同期通信)を利用してOGP情報の取得を行なっています。
前後のページにバックグラウンドでアクセスしているわけです。
情報取得に赴いたページからプレーンhtmlあるいはプレーンテキストを取得し、その中からOGP設定画像を取り出してページ送りの背景に適用、という流れ。
非同期ですから取得先のJSを実行したりはしませんが、画像データなどは取得されます。
というわけでGTmetrixでも指摘を受けます。

ajax通信を辞める、というのが一つの提案。
難易度
辞める事自体は簡単でも代用htmlとCSSが必要になるためこの難易度にしておきます。

もう一つの提案は ajax通信のタイミングをスクロールした後に設定する
寧ろこちらの方が簡単かな。
難易度

type:'GET' で検索するとひとかたまりのJS内容を発見できます。
それを以下の通り修正。

$(window).one('scroll',function(e){ここに元々あったJS内容$(this).off(e);});

ここでちょっと大事なこと言いますけども。

重要キーワード・ポイントは「スクロール」である

こういったテストツールだけでなくGoogle botもそうなんですが、スクロールを行わない んですね。
botはここでは置いといて、テストツールもスクロールという動作を行いません。
なのでスクロールで発火するJSについては実行コード自体は解釈しても、実際に動かすことはありません。
ajaxは情報の取得のために利用していますがスクロールしない限り別ページへのアクセスが行われなくなりますので、従ってスコア減点対象から除外される、というからくりです。

テスト系ツールはこの「スクロール実行」が大きなキーポイントになってくるかと思います。
この点を覚えておいて損はない (´・ω・`)

コメント装飾のツールバー使用を辞める

コメント投稿欄にありますよね。こんなの。

使用取りやめの場合
難易度

これからご紹介する方法を取る場合
難易度

このコメントツールバーが実はめちゃくちゃ重たいんですよねぇ (´・ω・`)
仕組みとしてはJSの document.write という方法でもって DOMを生成する というもの。
DOM というのはhtml要素の集合体です。テンプレート管理画面の上段「xxのHTML編集」というボックス内にズラーっと文字列ありますよね。アレのことです。
本来レンダリング(描画)される要素というのはこのDOM内に記述されてしかるべきものですが、それが出来ない場合もあります。
そんなときにJSでもってhtmlを書き出すという手法が取られることがあります。
まぁ今後は非推奨になっていくというか、既にGoogleが「document.write使うな!(怒)」って言ってますので廃れていく運命なのかも。

FC2のコメントツールバーはhtmlの書き出しだけでなく別のスクリプトファイルの読み込みやURLパラメータ付加など、いろいろやってるんですね。そら重たいわな (´・ω・`)

で、このdocument.writeというのはasync deferなどの非同期指定ができないんですね。
DOMが無ければJSは実行できませんので当然ですが。
で、このスクリプトを遅延読み込みさせるための方法をご紹介しようと思っていたのですが、以下でご紹介します記事を拝見しまして、あぁこっちの方が良いな、と(笑)

コメント投稿欄のツールバーをlazysizesで遅延ローディングしてみました。 | 富士宮で貯蓄と資産運用

だからdocument.writeは止めなさいって言ってるでしょ… コメント投稿欄のツールバーが… 先日、個別記事ページをGTmetrixでブログ速度分析したら、【Defer parsing of JavaScript(JavaScriptの解析を延期する)】の項目でズラズラと指摘されてしまいました。 う~ん。トップページではこんなに多く指摘されていなかったんだけどなぁ… 僕のブログの場合、トップページから右カラムにサイドメニューのプラグインが表示され...

手順などは詳細な説明がありますので参照して頂くとして。
注意点だけ書いておきますと、内部的には「そのJS内容は役目を果たせていないよ」という警告を受けます。
がエラーではありません。赤でなく黄色。

発想としては
スクリプトファイルは遅延読み込みを行う

JSファイル内にあるdocument.write内容は無視して先にDOMを手打ちしておく

JSファイルの一部(htmlの書き出し)は不能となるがDOM自体は既に存在しているのでクラス名を頼りにそちらに対し処理が行われる

こういう感じです。
lazysizesは私の要約テンプレートに既に含まれていますし、Axisテンプレートはこの方法で必須となるunveilhooksも含まれていますので割りと簡単に導入できると思います。

確かに警告は発生しますが、このコメントツールバーに関してはFC2の用意している変数をそのまま利用するのがベストだと思います。
筆者様には導入しやすく結果に繋がる良策をありがとうございます ('0')/

で、私個人についてはコメントツールバーの使用を辞めました (´・ω・`)
このツールバーが何をしているかというと、「文字列の追加」なんですが、この文字列は要するに変数です。
ごく簡単な文字列なので辞書登録ですぐに呼び出せますし、スマホから使いづらいこともあり、もう無くてもいいやー (´・ω・`) と ^^;

スクロールアンカーの使用を辞める

サイドメニューがスクロールで流れて行かずに留まるアレ。
不要と思われましたら削除するとJS及びhtmlの一部が減らせます。

webフォントの利用を辞める

webフォントはlinkで読みに行きますので、Windows, Mac双方にバンドルされている標準のフォントを利用することでページスピードが向上します。
ただ両OSの共通フォントはかなり少ないのと、Windowsははっきり言ってかっちょいいフォントが無い (∵`)

日本語フォントにwebフォントを利用しない、というのは基本かなと思います。
(欧文フォントと比較してかなりデータが大きくなるため)

Font Awesomeなどのwebアイコンの利用を辞める

なんか辞めてばっかなんですけど。
そりゃそうですよね。スピードを最重要とするならばhtml, CSS, JSを最小限にするのが一番効果があるのですから。

Font Awesomeのバージョン5、重たいですね。
使わない方が良いような気がしてきました。
いろんな意味で「あんま良くない」です。最近のは。デザイン面も含め。

バージョン5からは推奨のJS + SVGで利用する場合は 疑似要素での利用は非推奨 とのことですが、やはりその通りで使いづらいというよりも場面によっては「使い物にならない」ことも。

IEを捨てる

初回投稿内容にこの章を追加しています。結構大事だけど忘れてました。

IE不要 という場合にはもう切っちゃって良いと思います。
とはいえ日本ではまだまだ使用率が高いようではありますけれど。
それでも「IEなど要らん」という豪気な方は思い切って外してしまうという選択も。

ここでいうIEは当然ですが IE11 のみを対象として言ってます。
それ以下のバージョンとかマジでもう知らんし

IE対応を辞める場合にはCSSのフォールバック及びJSのハックなど多くの内容を削減することができます。

SNS純正アイコンの使用を辞める

この章も追加。

FC2ブログでは個人設定で簡単にSNSボタンを表示させることができるようになってます。
設定ページ

これらのボタンも非常に「遅い」「重たい」のでいっそ辞めちゃう。

私のテンプレートの場合は記事下にリンクで飛ばすシェアアイコンが付けてあり、ほとんど負荷がありませんのでそちらを割り切って使って頂くか。
見た目が純正のそれと同じでなければ気が済まないという場合にはCSSでできますのでカスタマイズするとか。
いずれにしても個人設定のSNSボタンの使用を避けると負荷が下げられます。
「テンプレートが全文表示タイプ」「本文と追記を分けていない」「各記事下に純正ボタン」このコンボは最悪。

まとめ

とりあえず今のところはこんな感じですかね。
他にも気づけば書き足すかもです。
スクロール に注目していくとみなさんも何か思いつくかもしれませんよ。
今回は「それホントに要るの?ホントに使ってる?」という根本的な部分の検討も含め、極端な選択肢「辞める」も敢えて提案しています。
ということで、軽量化についてでした。

あー。あと書き忘れましたが

画像の容量削減は当たり前

ですので必ず行うようにしましょう。
これはもうやって当然。やってなきゃ「えぇ?!」ってなるレベル。

YOU MAY ALSO LIKE
もっと見る
vanillaice (Akira)
vanillaice (Akira)

10 COMMENTS

There are no comments yet.

ぼっちん  

感謝です~ ^^

おはようございます ^^

Akiraちゃん、もしかして私のテンプレートのGTmetrix苦悩(笑)を見るに見かねてこの記事を書いてくださったんですね (^_^; アハハ…
もうもう感謝感謝の思いで読ませて戴いて「うんうん(^-^) そだね~♪」って認識の連続になりました (^^ゞポリポリ

私がGTmetrixの分析に積極的になっている意味は、そのスコアアップ云々ではなくて、現実的な「スマホでの表示高速化」を図るのが最終目的なんですよね (^^ゞポリポリ
現状で、いま弊ブログをiPhone Xから覗いた時に、表示されるまでに若干の「引っかかり」感を感じているんですね (^^ゞポリポリ
この引っかかり感を除去したくて、GTmetrix分析を注視しつついろいろと改善策(笑)を試みていたんですけど、基本を曲解してしまっていたことにこの記事で気づかされました (^^ゞポリポリ

この記事中でブログカードを張られている弊ブログのお友達のmochiさんのご指摘と、Akiraちゃんのこの記事の見事なまでの整合性に「わぉ(笑)」っとびっくりしたり笑わせられたり(笑)

私の「良いものは遠慮しないで取り入れる(真似する)」って気質が、またムクムクと鎌首をもたげて来てます(爆)
年金受給ブロガー(笑)でも「これくらいのことは出来るんだぞ!」って感じでして (^^ゞポリポリ

タイムリーでとってもナイスな記事を書き下ろしてくださって、ほんとにありがとうございました m(_ _)m

2018/05/10 (Thu) 08:24

mochi  

先生に褒められた? (*゚▽゚*) ニパッ!!

はじめまして。Akira先生。
記事ブログカードを貼っていただいたmochiです。

ブログ表示速度改善に対して正攻法をそっちのけにして、搦め手で攻めて遊んでしまっています。(;´▽`A`` アセアセ

document.writeは使い勝手が良いのは分かるんですが、コレを使っているプラグインjsの多さに少し辟易するとともに、時代を感じてしまう今日この頃です。

個人的には無料ブログにおける効率的な表示速度改善は、有料にしてFC2広告表示を出さないことで、特にコードを弄る手間暇との時間的コストパフォーマンスで考えればかなりベターな選択だと思っています。

ただそれをやらずに変則的な手法で速度向上を目指すところに、僕としてはマロンを感じてしまっているわけでして・・・生暖かい目で見守っていただければと思います。 ニャハハ(*^▽^*)

ちなみにですが、僕もコメントツールバーって一回も使った記憶がないんで、取っちゃうというのが最適解だと思いますよ。 (⌒▽⌒)アハハ!

2018/05/10 (Thu) 09:37
vanillaice (Akira)

Akira  

To ぼっちんさん

ぼっちんさん、こんばんは ('0')/

お役に立てたのならば幸いですー。
あとはfancyboxやprismなんかも一つのファイルにまとめてしまうと良いかもしれませんね。
現在既にスコアで90%以上ありますので上出来と言って良いと思います。
お疲れ様です

2018/05/10 (Thu) 20:05
vanillaice (Akira)

Akira  

To mochiさん

こんばんは ('0')/

mochiさんの記事は多くの方にとってとても役に立つ内容だと思います。
ありがとうございます

document.writeは仕方が無いと言えば仕方が無いですよね。
どのサービスでも貼り付ける内容が1行だけならとっつきやすいけども、それが何十行にも渡っていると見ただけで気が萎えてしまう方も。
提供側としてはやっぱり前者を選ぶだろうなと思います。

私個人は「ブログにお金など掛ける必要はない」と思っている人間です(笑)
FC2の月額約300円はコスパ良いですけどね。アメブロやはてなの1000円超えに比べたら良心的。
はてなはプロ向けサービスが多いのでまぁ良いとしてもアメブロの1000円は意味わかんないです (´・ω・`)

コメントのツールバーにしてもそうなんですが、「必要ならば使う、必要ないならば使わない」という選択を割りと皆さん放棄しているように感じます。
使ってないなら消せば良いんやで? (´・ω・`)
というあたり(笑)
なので今回は極端な「辞める」という提案も敢えてしてみました。
たぶん雰囲気だけでウィジェット入れてる方とか結構居ると思うし。
ランキング関係とか特に ^^;

2018/05/10 (Thu) 20:15

-  

管理人のみ閲覧できます

このコメントは管理人のみ閲覧できます

2018/05/21 (Mon) 22:32
vanillaice (Akira)

Akira  

To ページ高速化の件 内緒さん

こんばんは (o'ω')ノ

> 記事内で使用されているセレクタを参考に〜

ちょっと仰る意味がよくわからないです。この記事ではセレクタには触れていないので、なんのことなのか ^^;

* セレクタ = 要素, 全称, id, class, 子孫 など要素の選択・特定のための条件式

------
> いくつかのページでbottomボタンをクリックしてもジリジリっと移動するような感じになります〜

私のブログ上でのことですかね。そうだと仮定して。
ひっかかる感じがするのはJSでDOMを書き出したり(TOCなど)、lazyloadが動作している場合などに発生することがあります。
ページを開いていきなりbottomスクロールするとよく起こりますが、普通に記事を読み進めている場合には気にならない程度だと思います。
スムーススクロールと上記動作とは非常に相性が悪い(この件についてはlazyloadの記事に明記してあります)ので想定内というか。

加えてメイン・サイドのスクロールアンカーをJSからCSSに切り替えました。
こちらもスムーススクロールとは相性が悪いです(アンカーが効く場合はいきなり移動しようとします)
いずれも高速化と引き換えの犠牲というところでしょうか。
スムーススクロールの動作を優先させたい場合にはこの記事内にあるようなスクロール系遅延は一切使わないというのが最適解になるかと思います。

いずれにしろ今改装中でjQueryをネイティブに変更している最中で、テストが済んだ部分から差し替えをしています。
ご迷惑おかけします。

2018/05/22 (Tue) 02:39

-  

管理人のみ閲覧できます

このコメントは管理人のみ閲覧できます

2018/05/22 (Tue) 10:00
vanillaice (Akira)

Akira  

To ページ高速化の件 内緒さん②

こんにちは ('0')/

そういうことでしたか。
しばらくの間ソース内容がコロコロ変わりますのでちょっとお待ち頂いた方が良いかもしれません。
とはいってもなかなか時間を捻出できない状態ですが (∵`)

あと、今私脱jQueryの最中なので、CSSの代替かつJSがあると衝突するものなどもあります。
ちょっとその辺も気をつけて頂いた方が良いかな。
たぶん今夜また作業する予定なので、内緒さんがせっかく確認した内容がガラっと変わっている可能性もあります。
ごめんなさい(笑)

2018/05/22 (Tue) 18:33

-  

管理人のみ閲覧できます

このコメントは管理人のみ閲覧できます

2018/05/22 (Tue) 20:59
vanillaice (Akira)

Akira  

To ページ高速化の件 内緒さん③

こんばんは。

そうですね。記事にするのはともかく、実際にはかなり困難な作業になると思うので現実的ではないかもです (´・ェ・`)
テンプレートに何かしらのJSを追加する場合、大抵の方はjQueryのコードを持ってきますよね。
ネイティブのコードは難解ですし検索でヒットするほとんどがjQueryですしね。
相当な必要に迫られることがない限り手は出さない方向性で(笑)

いつもありがとうございます

2018/05/23 (Wed) 00:53