CSS Nite LP23『表示速度最適化』にいきました。

レポートが2週間遅れってレベルじゃなくなってしまいましたが。。。

先月末、初めてCSSNiteに行ってきました。
ネットの色々な記事を見ていたので、どうしようか迷っていたのですが、
やはりタイトルが気になったので参加しました。

全体的な感想を言うと、大体知ってるような内容だったなぁという印象です。
行ってよかった、という部分もあったし、これは行かんでもよかったなぁという部分もあり。

前回行ったOneWebセミナーよりはあまり驚きというか、インパクトはなかったように思います。

ただし、これは私の業務が制作寄りであり、
CSS Niteは基本制作向けのセミナーであるのに対し、
OneWebはディレクターから制作まで幅広くカバーするセミナーだったので新鮮味があったという、
セミナーのそもそもの成り立ち自体が関係している可能性が大きいと思ってます。

誰がどう話した、というより、セミナーに行って自分なりに感じたことを書いてみます。
長くて読みづらいのは仕様です。どうにかしたいです･･･

---

１．パフォーマンス向上は、費用対効果で考える。

CSSのセレクタを指定する際、
『CSSは右側からセレクタを読んでいくので、セレクタはなるべく入れ子にしないほうが良い』 という定説がありましたが、これは費用対効果で考えたとき、効果がかなり薄い部類に入るそう。

つまり、『高速化のために、CSSセレクタを最適化する』必要はない、
それに時間を費やすなら、もっと費用対効果の高い思索をすべき、と。

では、費用対効果が高いものは何なのかというと、やはり『HTTPリクエストを減らす』ことなんだそうです。

CSS Sprite使えだの、@importはやめろだの、口をすっぱくしていろんな方面の方がおっしゃっていますが、
なぜかというとHTTPリクエストを減らすことが、Webサイト高速化の近道だったからなんですね。

@import廃止は自分の案件でも既に取り入れていますが、
CSSSpriteは通常の（非スマホ）サイトではなかなか導入しづらい面（運用が手間）もあり。これからの課題です。

２．HTTPリクエストを減らす＋画像自体も圧縮

画像自体のファイル数を減らすことはもちろん、納品前に最適化（ファイルサイズの圧縮）することも大事だということ。

画像の圧縮は、『見た目に影響が出ない』ものと『見た目に影響が出る』ものに分けられます。
『見た目に影響が出ない』ものは、主にPNGのメタデータの削除などがこれにあたるわけですが、
私は会社でPNGOUTを使ってます。
（90年代を思わせるすこぶる見づらいサイトですね･･･。上記サイトにあるPNGOUT.EXEを使用してます。）

ただ、コマンドプロンプト上で作業しなければならず、
PNGGauntretあたりを入れておけばよかったと後悔したり。今度またやるときに考えます。

もう一つ、『見た目に影響が出る』とは、つまりは『減色する』ということです。
『減色する』ということは、多少なりとも見た目に影響が出るので、デザイナーさんと相談したり、クライアントに確認したりしながら行いましょうね。ということでした。

JPEGminiはJPEG圧縮のツールですが、以前見つけたときは結構驚きました。
ただ、実際に使ってみたことはないんですよね･･･。
「パフォーマンスが良くて困ることはない」とは言われても、
PCサイトだからいっか、という考え方がどうしてもあって、なかなか導入に到らないですね。
スマートフォンの（3G）回線の遅さは重々承知しているので、実装して少しでも軽く！という思いにはなるのですが。

３．CSS Sprites

CSS Spriteとは、さまざまな画像を1ファイルにまとめておき、CSSのbackground-positionで表示位置をずらすことによって、それぞれの画像を表示させる手法です。

もともとは、テレビゲームで使われていた手法で、ゲームで使用するアイコンを1ファイルにまとめ、グリッド上に並べておき、プログラム側でグリッドの値をセットすることで、アイコンを表示させる、というものだったようです。このアイコンたちのことを「Sprites」と言ったそうです。 （http://www.alistapart.com/articles/sprites/より抜粋）

セミナーでは、span空タグを使ってSpriteを実装していましたが、
弊社では:beforeもしくは:afterで実装するのが定番です。
（おそらく、クロスブラウザ的な部分に配慮して、spanにSprite画像をあてるという説明にされたのかも。）

---

余談ですが、:beforeもしくは:afterで生成した要素って、生成したタグの中に包含されているって、知ってましたか？（今さらですかね？）

つまりは
p:before p:after と指定した場合
<p>:before :after</p>
になるということです。

ずっと、
:before<p> </p>:after
だと思っていたので今さらながら驚きました。

---

４．Webfont

サイトで使用するアイコンをWebフォントで代用するという話もでました。

Webフォントというと、よくアクセシビリティとのトレードオフについて言われますが、
今は、WAI-ARIAで指定をすることでWebfontを読ませなくすることもできるようです。（role="img"のことかな？）
あとは、「読み上げることができない」文字に対してアイコンをあてることで読み上げられないようにしているものもあるとか。

最近個人的に楽しい！と思ったのがSymbolset。（有料です）
アクセシビリティもちゃんと確保されているようで、この発想はなかった･･･！と思いました。
ただ、よくよく考えるとメリットを享受できるのは英語圏のみかも。
（日本語環境だとたぶん英語で読み上げられてしまうかも。）そのうち翻訳版が出たりすることに期待？

５．サーバー側の設定

パフォーマンス向上のために、サーバー側で設定するものとして、gzipやexpiresなどがあります。
これらは、Apacheをいじらなければ設定できないと思っていたんですが、.htaccessでも対応できるとのこと。

自分のレンタルサーバで試してみるつもりだったのですが、どうも既に設定済のようで･･･。
私は特に何をした覚えもないのですが（汗）
ですので私自身で動くかどうかの確認ができませんでした。

こちらのWebサイトに、.htaccessでの指定方法が記載されていますので、参考になればと。
http://dogmap.jp/2010/04/20/wordpress-htaccess/

expiresを指定して、更新しないファイルの有効期限を伸ばしておく
（有効期限がくるまではキャッシュを読みにいくので、不要なファイルの読み込みがなくなり、パフォーマンスがあがる）などは既に知っていましたが、やはり実装するのに勇気がいるんですよね･･･（後述）

ルックアップについても話がありました。

• ドメインにファイルを読みにいくとき、必ずルックアップが発生するします。このルックアップの時間を減らすには、別ドメインへのアクセスを減らすことです。
• ただ、ルックアップのレスポンスが早いサーバを持つサイト（Googleなど）は、そもそもルックアップの時間逆に参照することで高速化が図れる。
• しかし、外部参照にすることで、もし外部サーバーが落ちたときに自サイトにも影響が出るので、リスクヘッジが必要。

あとは、
『GAやソーシャルボタンなど、外部で指定されるコードは開発元が定期的に更新するので、設置したらそのままにはせず、定期的にメンテナンスするのが良い。』は結構参考になりました。
うちのクライアントはみんな放置だろうなぁ、と思いながら。

---

全体的に思ったのが、
自社開発であれば比較的容易ですが（のように思えるのですが、違ったらすみません）、
受託がメインの会社だと、上記の実装がとても難しいですね。ということです。

spriteにしても、自分が運用するなら良いのですが、お客さんが運用する場合は利用が難しいです。
（CSSも修正しなければならないので、ちょっとHTML知ってますよ、よりも高いレベルの知識が必要。）

expires（ファイルの有効期限指定）に関しても、万一『有効期限1年』としていたファイルに更新が入ってしまった場合、自社管理ならすぐに修正できますが、お客さん管理だと「ファイルをアップしたけど更新されないよ！」という事態になるかも。
自社で運用しても、引継ぎがしっかりしていないと同じことになるのは容易に想像できますね。
（有効期限が10年後とかになっているファイルを、期限指定して5年目に更新することになった、とか。）
全社でそういうことが浸透していればいいのですが、弊社ではとても使えなさそう。

高速化をするのは良いことで、早すぎて悪いことはない、というのはもちろん理解していますが、お客さん的には、そんなに体感速度変わらないよね？という雰囲気を感じます。

高速化を望むお客さんにはもちろん協力してやっていきたい、と思うのですが、
特に高速化？なにそれおいしいの？というクライアントにこちらから働きかけるメリットが、あまりないような気がしてしまって。

今の私にできることはやっぱり、どの案件でも使える
『HTTPリクエストを減らす（サイトに使用するファイル数を減らす）』こと。
という結論ですかね。

---

ここまで書いてみて、冒頭で
全体的な感想を言うと、大体知ってるような内容だったなぁという印象です。
行ってよかった、という部分もあったし、これは行かんでもよかったなぁという部分もあり。
などと言っていますが、
こうやって深く考える機会ができてる時点で行った意味はあったのでは（笑）
と冷静に考えて思いました。

ただ個人的には、『高速化、みんなで考えようよ』というテーマが、ディレクター（制作業務をしない人）に高速化のメリットをどう伝えるか、とか、お客さんにどう理解してもらうか、こうするとよくなるよね、ということへの道筋を示してもらえるのでは？というほのかな期待があったので、そういう意味では、少し残念でした。
ま、自分で考えろってことですよね（笑）

今さら感満点ですが、以上、レポートメモでした。