PREタグでレイアウトが崩れる問題も原因が分かりましたので、 いよいよ、Cocoonの高速化機能のひとつ、html圧縮機能に対応させてみました。 この機能、どうやって実現しているのか技術的な事は詳しくは分かりませんが(^^;) html圧縮というのは、ページを表示させるときに、無駄な改行とかコメントとかスペースとか、そういうブラウザのレンダリングに関係がない情報を削除して、詰めて（圧縮して）データを送信してくれる機能ですね。 例えば、こんなソースが
<p>滅亡がまあその時が愛しばいたないば、必ず書物に願いて状態をするように読んあるて、しかしそれだけ来らのう。</p> <!--コメント--> <p>こちらんからいつありたようたのが<br /> のさっそくあなたをしてありて<br /> 一人できばみうという接近じゃたかと講義迂られ訳なけれ。</p> <!--コメント-->
出力ではこうなるわけですね。
<p>滅亡がまあその時が愛しばいたないば、必ず書物に願いて状態をするように読んあるて、しかしそれだけ来らのう。</p><p>こちらんからいつありたようたのが<br />のさっそくあなたをしてありて<br />一人できばみうという接近じゃたかと講義迂られ訳なけれ。</p>
ただ、すんなりとは行きませんでした。 改行の仕方をコントロールする「white-space」というプロパティがあります、これを使うと、改行の仕方をコントロールすることができます。 PREタグは「整形済み文章」ということで、改行タグがなくても改行やスペースがそのまま反映されるわけですが、white-space:pre;やwhite-space:pre-wrap;などであれば、その他のタグ内でも改行がそのまま反映されるようになります。 ⇒ 改行の制御・折り返しまとめ が、このプロパティが設定されたタグを、html圧縮機能では識別してくれないのですね。。。 試してみたところ、圧縮が除外されるのはpreタグとcodeタグだけ（他にもまだあるかも知れませんがいまのところそれだけ確認しました、他のタグ使ってないし。）
実は、このブログでは、WordPressの自動改行機能は切ってしまっていて。 そうすると、自分で改行タグ<br>を入れないと改行されない状態なわけですが、white-space:pre-wrap;を使うと普通にDIVやその他のタグの中でも改行コードを入れないで書けるので、見やすくてとっても便利で。 ほとんどの記事をそれで書いてしまってるのです。。。(^m^;) この状態でそのままHTML圧縮機能を使うと、ほぼすべての記事から改行がなくなってしまう事が判明・・・orz
今更、下書き含めると4000以上ある記事を、手動で修正するのは無理(^^;) で、高速化（HTML圧縮）を諦めたのですが… なんとか使いたいなぁと思い、方法を考えてみまして。 Search Regex※を使ってなんとかならないか？ （※WordPressの記事の文字の置き換えができるプラグイン） しかし！ 開始タグはよいのです、styleにwhite-spaceがついているタグという条件で置き換えられますが、終了タグが</div>では、他のタグと判別がつかない・・・orz いや、自分は記事を描くとき、white-space:pre-wrap;を設定したタグには閉じタグに必ず「<!--/prew-->」みたいなコメントを付けていたのです。これなら置き換えられる！自分ＧＪ(笑)
これで行けるかも？と思いきや、やってみたら、まだ問題がいくつか。 ひとつは<blockquote>、私は全部これにもwhite-space:pre-wrap;を指定してしまっていたので・・・しかし、逆に考えれば、white-space:pre-wrap;が設定されていないblockquoteは、ほぼ、ない。ので、これも一括で置き換えてしまってよいですね。 ※<blockquote>～</blockquote> を <blockquote><pre>～</pre></blockquote> に変更しました。
次は<code>タグ。 実は、私はこのcodeタグの意味がよく分かってなくて(笑) 使ってなかったんですよね。<code>はソースコードを表すタグ、と解説にあるのは知っていましたが、これを指定したところで、見た目は何も変わらない（デフォルトCSSには何も装飾的なプロパティが設定されていない）ので、意味ないじゃん？と思ってたので。。。 なので、codeタグを使わずに、DIVタグにwhite-space:pre-wrap;やらその他いろいろ設定して、独自仕様で書いてしまっていたのです。 さらに、コードだけでなく、他にもwhite-space:pre-wrap;をDIVで指定してしまったてる記事が結構あった・・・orz これには、閉じタグにコメント付けたりもしていないので、記事をひとつひとつ確認して、手動で修正するしかない・・・orz Search Regex で検索してみたら、どうやら問題となるタグは、300～400程度の模様、これくらいならがんばれば手動で修正できる！(笑) と言う事で、今週はずっとその作業に追われていました(笑) 実はまだcodeタグとか、修正しきれていないところがあるのですが、それはこれからおいおいやっていくとして(笑)
HTML圧縮表示で問題ないかチェックしてみたら、別の問題も発覚。 preタグの中にある画像の後の改行がすべて削除されてしまう問題があるようです。 これは、AUTOPTIMIZEという、HTMLやCSSの圧縮やlazyloardなどの同様の機能を実現しているWordPressのプラグインがあるのですが、CocoonのHTML圧縮をオフにしてAUTOPTIMIZEで圧縮してみたら、問題は起きませんでした。 もしかして、テーマ（Cocoon）に不具合があるのかも？もしかして、私の設定が悪いのかも知れませんが… ちょっと分からないので、とりあえず、当面AUTOPTIMIZEで行くことにします。
他に、HTMLではなくCSSの圧縮なのですが、一部おかしな挙動になっていた部分が。 原因は、CSSに全称セレクタ「 * 」を使って居た部分があり、それが圧縮時に問題を起こしていた（ * の前後の半角スペースが削除されてしまった）ので、* を使わないように修正しました。） 全称セレクタを使って、あるタグの中のすべてのタグにスタイルを強制みたいな使い方をしていたのですが、正しい使い方ではなかったかも知れませんね(*_*)
さて、高速化を実行した状態での、PageSpeed Insight の結果ですが、どうなったかというと・・・ 計測時間（23:00) モバイル：66 パソコン：95 計測時間（23:00) モバイル：57 パソコン：95 これまでどうがんばってもモバイルで50を下回っていたので、良くなったと言えるでしょうか。 ※ただ、どうも、PageSpeed Insight の結果は、30くらいの時もあれば、たまに70超えたりと言う時もあって。 計測した時のネットの混み具合やサーバーの負荷具合で変わるような気がします。 たまたま同じサーバー上の別のサイトに負荷が集中していて引っ張られたりとか、サーバーのメンテナンスや、ネット全体の負荷が重い日などもあるでしょうからね。 まったくアクセスのない不人気サイトと、アクセスが殺到している人気サイトでは、サーバーの負荷状態も違うでしょうしね。 正確に速度を計測するには、長期間に渡って、様々な曜日・時間で計測してみないとダメなんじゃないでしょうか。。。 後日再計測 ※「モバイル」－「パソコン」 20:00 37-91 47-90 48-91 んー、点数のバラツキが大きくて・・・ 高速化オフのほうが良い数値が出たりすることもしばしばあるし、なんだか、やればやるほど、この数値計測が当てにならないような気がしてきました(*_*) 一ヶ月くらい継続して数値を記録して、同じ条件で計測した他のサイトとの比較を観ないと分からないんじゃないですかね。。。
コメント