goods and life +

Less is More デビューのススメ

梅雨…(´・ω・`)

玄関先のマスコットといえばツバメのひな、かわいい。
いまちょうど燕が巣立つシーズンで、玄関先の天使も今日はみんな巣から出て飛んでた。
でもまだお尻の羽が短いんだなー、くちばしも黄色いの残ってるし。

ツバメが巣立つ頃といえば、いよいよ梅雨の始まりも近いってことで、レンズ専用防カビ剤とかゲットしておきました。
まあ気休めだけど古いレンズがカビたら大変だし、バッグにもひとつ入れときたかった。

inali はハクバのを 2袋ほど買ったんだけど、フジカラーのカビ防止剤 14742 の方がたくさん入ってるみたいだし、レンズ以外にも使えるのでお得だったのかもしれない。

 

Less is More ?

ところで、このところなんでかサーバーが重くて調子悪く、どうしようもない感じだったので WordPress の軽快化の設定を見直そうかといろいろと取り組んでたわけですけど、一番効果を期待したメモリーベースバックエンドのオブジェクトキャッシュがどうも PHP7 ではまるでダメみたいで、余計に重くなってショボーン。

で、なんかよく探したらこういう情報もあってこっちの方が正しそうな気が…。
やっぱネット上の個人に毛のハヤクナッター!話は眉唾でってことで、妙に納得(笑)
だって情報が古すぎたり使っているサーバーのスペックが不明だったりするし、そもそも一般化できない話が多かったりするし、書かれた時期的に PHP 5.4 以前の頃までの話だったりするかもしれない。

https://gato.intaa.net/archives/4519
APC Object Cache Backendプラグインのobject-cache.phpをwp-content/下に置いてTribe Object Cacheを入れるというのを何処かで複数見たけどそれはおかしいと思う。

試行錯誤のあげく速度が出ないどころか、セッティングを変えたらより遅くなってしまったり挙動が不審になったりもして…。
inai が使ってるレンタルサーバーで APCu拡張モジュールの追加導入がされるのは 2016年6月24日(金)だから、今んとこ APC関係はできないだけなのかもしれないけど。

いろいろできるだけ省いてみたり組み合わせたりやってみてたんですけど、あるプラグインでブロック要素を減らしたら、ついでに余計なブロック要素になる場所に CSS が生成されたり、代わりになる似たような機能のプラグインでブロック要素を減らしてみたら今度は存在しない Array を生成して 404 だと文句言われたり。

いよいよやれることにも限界があって、しかも元々のセッティングに近いものが結局一番速度出てたみたいだし、もう疲れた(笑)

でも Safari なら表示も速いし、もしかして重いのは Google Chrome のせいで、次期バージョンだったら Fix されてるのかも?な〜んて思って、次期バージョンの機能でテスト動作するという Google Chrome Canary を使ってみたりもしたけど、動作速度は特に変わらない。
変わったのはブラウザCSSとか文字表示の関係だけ。

 

あとやれること、残るはもう写真データの圧縮をきつくするしかないというか。
でも以前 Jetpack の Photon を使ったら、点光源やらエッジの細かい写真が目に見えてすごく汚くなり、たいそうガッカリしたことがあった。
そういうわけで画像データをむやみにへつって軽くするのは懲りごりだったんですけど、仕方なくまたそこに手をつけて(r…。

サーバーの反応が妙に重かったのは、もしかしたら大々的に攻撃されていたのかも。
サーバー屋さんの一部の IPアドレスのサーバーで異常な負荷上昇があって著しい速度低下があり、緊急で MySQLサーバの再起動などもやってたみたいだし。

それはうちの入ってる IP じゃなかったんだけど、たまたまそこまでの負荷にはなっていなかっただけで、中華アタックは同じようにやられてたんじゃないかな〜と。

つい最近、WordPress のわりとメジャーなプラグイン 2件、WP Mobile Detector と Jetpack 4.0.3 以前のものがゼロデイ攻撃にさらされていたのとかも関係あるのかも?
メジャーなプラグインなので使ってる人も多いだろうし。

 

軽くするために情報量を減らすという後ろ向きな作戦…。
まあたくさんメディアを載せるのなら、最初からもうちょっと速いサーバーを使えやってことなんですけどね(笑)

EWWW Image Optimizer
今までも一応は画像のアップロード前に Ps で Web用に軽量化していて、さらに EWWW Image Optimizer を使ってそれなりに画質を落とし軽量化していた状態。

WP Smush
で、今回そこからさらにロスレス圧縮(可逆圧縮)してみよう!、ってことで、ロスレス圧縮ができるプラグイン WP Smush を使って画像を圧縮してみたところ…、普通のロスレスではあんまり効果がない、というかほぼ変わらない。
宣伝は調子よすぎ(笑)

 

 

Pro版を買わなきゃスーパーロスレス圧縮が使えないため、多くてせいぜい 14% くらいまでしか圧縮されないし、PageSpeed Insights ではいい結果が出ず。
理由は、一覧の見出しの写真サイズが切り出しで決め打ち生成されたサイズではなく、元画像が縮小表示されている状態で、それが 10個並ぶというのが原因かな。

Adaptive Images Settings
てことで、Adaptive Images Settings を使って、まだそこからさらに 25%ほど画質を落としてみました。
…ただし、それでも速度ほぼ変わらない、変わらないんですよ!

 

ファーストビューとアバブザフォルドだけ意識するとかいう後ろ向けのアイディア
もうね、こんななら逆手にとってトップページだけウイジェットやいろんな表示をなくして、扉絵をひとつデカく配置して、みたいな情報の少ないページ構造にしてしまえば点数が出るのは間違いない。

 

 

どっちみちファーストビューの読み込みがサクッと速ければ点数がでる仕組みなんだし、個別のページもそういう構造にすれば点数はよくなるはず、ていうかそんなことやったらもう別のサイトみたいになっちゃいますけど。

みんなだいたいレンダリングブロックになる要素が並列同時読み込みを止めてしまい、その結果待ち時間を増やして、あとは画像のデータ量×個数がロードタイムの足を引っ張ってる。
てなると、不具合が出ないように確認しつつ読み込みの順を変えるか、それで手詰まりなら結局いろいろ減らす方向なんですよね。

あと、Googleは広告配信がメインビジネスだから利用機会の多いモバイルを重視するわけですけど、モバイルファーストのご時世とはいえ、小さなデバイスの画面で写真をみたってよくわかんないし不向きなのだなー、出先から閲覧するならともかくとして。

 

Smush it
そういえばちょっと前までは米 Yahoo! の Smush it っていうオンライン越しに圧縮するサービスがあって、Firefox を使って Yahoo! Smush it と通信して圧縮してたから、古い記事の写真は計3度目の圧縮になるのかなー。

古い写真はすべて CCD の小さいので撮ったものばかりだし、ブログに掲載する写真はもとより画質とかそんなには良くなかったし、もうこれ以上圧縮できないってものは Previously Optimized って出てきてなにもされないので安全だろうけど。

でも画像のクオリティをどんどん落としていったら Photon で点光源やらエッジの細かい写真がもろもろしてきて、オレンジや黄色系の鮮やかさもくすんで意味のわかんないことになったみたいなのが再現するだろうなあ、ああそれはいやだなあ…。

reSmush.it
今は米 Yahoo! の Smush.it 代替の reSmush.it もあるみたいです。
だけどもう比較してる元の写真がすでに (*´・ω・)(・ω・`*)ネー、って状態なんだな〜。

 

ひょっとして世の中これでいいのかも?
超圧縮前提だと、わざと彩度を上げてコントラストも強めにして明瞭度とシャープネスをきつくかけてり作り込んだようなザラッとした暗めの絵しかパッとみで見栄えしないんじゃないかなー、というかあんま人工的なわざとらしいのは個人的に好きじゃないんですよね、HDR 丸出しとかもどちらかといえば嫌いだし。

そこらから適当にもらってきて、ただ意味なくとってつけたような、写真としては別にどうでもいいようなアイキャッチ画像の超圧縮ならともかくとして、Web上の写真(一応は)てどこらへんまでの汚さが許容できる範囲で、どこらへんまでが速さとトレードオフなのかな〜って悩ましい感じで、ね〜。
世の中と自分の思うところギリギリ下限との折り合いをつけるのは難しい。

圧縮やりすぎるとボロボロになるよ、自己責任でね(´・ω・`)

お買いもの忘れはないですか?

コメントはこちらから

Return Top