World of granshe.
[PR]
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
美容師さんとWeb屋
今日、半年くらいぶりに（汗）髪を切りに行ってきました。
いつも家の近くのお店に行っていたのですが、そこがつぶれてしまっていたので、別のお店に行くことにしました。
自分は残念ながらお洒落さんではないので、とくにこういう髪形がいい！という信念はなく、
ただ、せっかく金出して切りに行くんだから雰囲気はちょっと変えたいけどどんな髪型が合うのかよく分からないしなー。
『お任せで』ってできたらそれが一番いいなー
と思っていました。
実際にお店に行きますとお兄さんが対応してくださいました。
どんな感じにしましょうか？と言われて本を渡されました。
渡されたのはよかったんですが自分にどんな髪型が似合うのかさっぱりだったのでとりあえずめくってみるレベルでしたｗ
お兄さん（以下、兄）：
『長さはどうしますかー』
私：
『短いと顔に当たって肌が荒れるので（まじめに）肩より下のほうがいいですねー』
（本をめくりながら）
兄：
『普段ブローとかしないのであれば、肩くらいにしちゃうと髪の毛がはねやすいかもですね』
私：
『じゃあもうちょっと長いところでお願いします。』
兄：
『では7センチくらい切る感じですねー』
私：
『あと、量が多いので少なくしたいです』（既に本は見てないｗ）
兄：
『少なくするにはレイヤー？（うろ覚え）を入れる必要があるんですが、あまり入れすぎると髪の毛を結ぶときにサイドが落ちてきちゃったりします』
私：
『なるほどー髪の毛結ぶときに落ちちゃうのはちょっと嫌ですね』
兄：
『じゃあ、下のほうだけ軽くレイヤー？を入れてみましょうか。これだったら結ぶときに落ちることもないと思います』
（本をめくって、こんな感じで、と示す）
私：
『じゃあそれでお願いします（笑）』
自分自身、
『お任せでってできたらそれが一番いいなー』
などと思っていたくせに、実際にいろいろ聞かれると注文がたくさんあるじゃねーかと軽くあきれました（笑）
そして、Webでもおんなじことが言えるんじゃないかなーと思ったのです。
お客さんの中には、絶対こういう感じのものがいい！という明確なビジョンを持った人もいれば、自分みたいに、なんとなく雰囲気変わればいいかなーという、曖昧な方もいるわけです。
仕事をしていて、
『おたくプロなんでしょ？提案してよ。』
みたいなことを言われた、と聞いたことがあるのですが、
まぁ、まさにそのとおりだなと思いましたよ。
プロだったら、お客さんがどういうシーンでそれを利用していて、
どういう風に使っているのか、知った上で、提案をする必要があるんです。
お客さんはWebについてよく分からないから、いろいろ言ってくることもあると思います。
私たちは、Webについてはお客さんよりもずっと知っているはずです。
でも、お客さんのこと、お客さんのお客さん（エンドユーザー）については、お客さんのほうが知っています。
お客さんがどういったクライアント（またはユーザー）を抱えているのかきちんとヒアリングして、
『そういったユーザーが多いなら、このようにすれば良いと思います。』と提案したり、
お客さんからのリクエストに対し、『ユーザーのことを考えるとこのようなデメリットもありますが、それでもやるんですか？』
といった、デメリットもきちんと伝えられるようになって、
やっとWeb屋やってるって、言えるんじゃないだろうかと思いました。
私は制作という立場なので、自分の技術が、Webサイトにどのような影響をもたらすのか？
どんなメリットがあり、デメリットがあるのか？費用対効果はどうか？
ディレクターに説明するのがプロとしての仕事だということ。
本当に当たり前のことで、何度も言ってるんですけど、
自分のことよりも、お客さんのことよりも、まずユーザーのことを考えるべきで。
私たちの仕事は、Webを作るのがメインじゃなくて、
お客さんに何か良い影響を与えられるようにするのがメインで、
じゃあ何を使っていい影響をもたらすのかっていうツールがWebなだけなんだなー。
と、あらためて思いましたよ。
ということで、結論としては、前回の投稿と同じ感じなんですが（汗）
美容室行っただけなのになんだかすごい人生勉強になって、書かずにはいられませんでした。
仕事との向き合い方
年始から暴飲暴食の日々が続き、休日引きこもりの自分には珍しく予定が目白押しだったので若干体調を崩しておりました。
今週節制したので、何とか持ち直してきました。
今、会社でレスポンシブWebデザインを行う際の案件のワークフローを模索している最中で、
もしその案件がうまくいったら、どのようにやったか書けたらなぁと思っています。
で、今回は『仕事との向き合い方』というタイトルにしました。
最近、自分は社内でもかなりの不良っぷりを発揮し、
仕事を選んだりあれやだこれやだなどと悪態をついたりわがままし放題やっているのですが、
そんな中で、同じ会社の別部署の方とお仕事をする機会に恵まれまして。
技術的な難しいことが要求されたとき、
自分はいつも『この短期間じゃできません』『追加要望は勘弁してください』
というような否定的なことばかり言っていたような気がします。
体調を崩して、心理的に余裕がなくなっているというのもありますが、
仕事に対する消極的な姿勢が、きっとそこに出ていたんじゃないかと思います。
追加の依頼を受けたとき、受ける基準は『自分が対応できるかどうか？』でした。
ですが、その方は
『お客さんとして、そのサイトを使ったときにどう思うか？』『サイトを運用する際、どの方法が楽なのか？』
を一番に考えて仕事をしていました。
普通に考えれば当たり前のことだと思います。
自分自身も、それを考えることはごく当たり前のことだと思っていました。
でも実際に案件が始まり、納期があり、他の案件も同時並行で動く中で、
私はツールを『使うこと』ではなく、ツールを『作ること』に精一杯になっていて、
作り終わった後のことを何一つ考えられていないことを、初めて「実感」しました。
私にとって、それはとても衝撃的なことでした。
今までやって当たり前だと思っていたことを、自分自身が全く出来ていなかったことに気づいたからです。
Webサイトは目標を達成するための『ツール』でしかなく、
本当に大切なのは、何を達成するか、本当にそのツールで目的が達成できるのかだと、
そう思っていた本人が『ツール』を作ることしか考えていなかったのですから。
久しぶりに、自分よりはるかに仕事が出来る人と一緒にお仕事をして、
久しぶりに反省しました。
もっと広い視野で、物事を見ないと。
あとは、心に余裕を持つこと。
叩かれないと伸びないタイプなので、（別に直接的に叩かれたわけではないですが）
今回のことは自分にとってかなりプラスになりました。
来週からまたお仕事がんばります。
レスポンシブ ウェブ デザイン 提案の提案
レスポンシブウェブデザインとかスマートフォン系の記事を書くときにどこのカテゴリに書くか迷ってしまい、そろそろブログのカテゴリ分けの限界を感じてきました。 というか、早くブログを独自ドメインのサーバに移行したい･･･！
ということでさっそく本題ですが、 最近、レスポンシブウェブデザイン（以下、RWDと表記）の案件を2つほどやってみて、思うところがあったので書いてみました。今回は技術的なところというよりも、提案というか、案件の取り方というか、案件の流れについて書きたいと思います。 思いのほか長くなってしまいました･･･。
きっかけ
自分が関わった2つの案件のうち、一つは1ページもののキャンペーンサイト、もう一つは既存のデザインを変えずRWDにするというもの。
サイト構築を行ったわけではありません。
それでも、案件を進めていくうちに、自分のRWDに対する考え方が変わった部分もありましたし、もっとこうすればうまくいくのに、と感じた部分がたくさんありました。記憶の熱いうちに書き留めておかなければと思ったのがきっかけです。
タイトルの内容は一番下にまとまってますので、お急ぎの方はこちらを。
そもそもRWDとは
RWDとは、「Fluid grids」（流動的なグリッド）、「flexible images」（サイズ可変な画像）「media queries」（メディアクエリー）この3点を満たしたものだというのが、自分の頭の中にありました。
ただ、案件をやっている際に自分が感じたのは、RWDを『とりあえず、1つのHTMLがPCで見るとPC用の見た目に、スマホで見るとスマホ用の見た目になってればいいんだ』という考え方の人がいること。
自分はそれに納得が出来なくて、一応社内的には認識してもらえたけれど、お客さんには既にそのような感じで説明している手前、強く補足ができなくて悩みました。
ただ結局は、お客さんが満足すればいいんだ、という考えに到って考えるのをやめました。
自分自身はその考え方には納得していませんが、RWDはあくまで「方法」であり、ワンソースでマルチデバイスに対応するということが「目的」であるなら、「方法」にがんじがらめになって悩むのではなく、「目的」を達成するための「方法」は柔軟に考えていこうよ、という結論に落ち着きました。
本来は「PC用の見た目」「スマートフォン用の見た目」という考えは間違いで、あくまでデバイスのウィンドウサイズによって見た目を切り替えているのですが、以下では便宜的に「PC用の見た目」「スマートフォン用の見た目」等と表記しています。
葛藤1：ワイヤーフレームのチェック
普段、Webページを作るときは、あまりワイヤーを見ることはありませんでした。
ワイヤーの時点で、これは無理だろう･･･というような構成はほとんどないからです。
が、RWDでは別。PC用のワイヤーと、スマートフォン用のワイヤーをしっかり見ないと、
『PCではヘッダーにあるリンク群の一部が、フッターリンクの中に入ってるんだけど･･･』とか、
『気軽な感じで「PCサイトを見る」ボタンが入ってるんだけど』 （この案件RWDだよね？）
『スマートフォン用のワイヤーに、右上に開閉メニューっぽいボタンがあるんだけど』 （さらっとJS書け要求が）
みたいなことに。
ということで、自分で書いていないのなら、ワイヤーはちゃんと見ないとダメです。
1回コーディングしてみる、くらいの心持ちで確認しないと、こういった『実装つまづくポイント』を見落としがちです。
個人的には、ワイヤーができた時点で一回コーディングして、動くワイヤーにしてから、お客さん（だけじゃなくディレクターも）に見せたほうがほうがスムーズにいく気がしました。
葛藤2：デザインとパフォーマンスの間で
「画像を多用すると重くなる」というのはRWDに限ったことではないですが、RWDでは特に気にするべきこととされています。
なぜなら、RWDでは1つのHTMLでPC用の見た目・スマートフォン用の見た目を用意するため、ソースが肥大化しがちだからです。
また、スマートフォンの3G回線はPCのように高速ではないため、ページのファイルサイズを軽くして、表示を高速化することが求められます。（今はLTEがあるのでかなり速度が向上したみたいですが）
ここでは、デザインとパフォーマンスの間で、どっちを取るべきかにとても迷いました。
「画像を使わないほうが軽くなる」ということは理解しているんですが、具体的にどのくらい重くなるのか？がわからない。
「軽ければ軽いほど良い」というのも分かっていますが、「どのくらい速度に影響するのか？」をデザイナーにうまく説明できず、どっちを妥協するか迷いました。
この案件では結局パフォーマンスを妥協しました。
葛藤3：レガシーブラウザでもちゃんと見えるようにね
私は今のところIE8よりも古いブラウザ（主にIE6/7）に対応してくれ、という案件をやったことはありませんが、周りではちらほら聞きます。
1つめの案件に関しては、RWDについてお客さんに説明し、「テキスト情報がちゃんと見えさえすれば、レガシーブラウザで表示が崩れてもいい」というお言葉をもらったので、特に表示に関しては何か言われることはなかったのですが、問題はもう1つの案件。
自分は「メディアクエリーはIE8以下に対応していない」ことをディレクターに伝えたつもりだったのですが、それがうまく伝わっていなかった。
そんなわけで当然お客さん側にもその認識があるわけがなく、コーディングが終わって、確認に出した時点で、IE8で崩れちゃうのは絶対ダメみたいなことを言われて。
正直、そういった要望があるだろうなぁということは、コーディングしていたときから、自分が想定していたことではあったので、respond.jsで対応してどうにかしたのですが。
respond.jsにも限界があるので、何とかごまかしきったところはあります。
このあたりの「RWDしないブラウザでどう見せるのか？」はキチンと認識をあわせないとダメです。
葛藤4：レスポンシブの認識と調整
RWDはワンソースでマルチデバイスに対応する「方法」のひとつであり、ブレークポイントでデザインを切り替えます。
デザインの切り替わるメジャーブレークポイントに注目されがちですが、メジャーブレークポイントに到るまでの過程はどうなっているのか？の考え方に、個人差があるなと感じています。
1つ目の案件は、お客さんが『1つのHTMLがPCで見るとPC用の見た目に、スマホで見るとスマホ用の見た目になるんですよね』という考えだったので、その間の挙動は自分で適当に伸縮させました。
2つ目の案件は、RWDのサイトをかなり見ているお客さんで、PCでブラウザのウィンドウサイズを伸縮させて、動きについて細かく指摘されました。納品直前に『ウィンドウ幅を狭めたときに、この3カラムになっているところを2カラムにするのって時間かかるんですか？』と言われたり。
要件として、「ブレークポイントは一つでいきますよ」と元々決めていて進めていた案件だったのですが、
やっぱり実際に現物を見てみると、ここはカラムが狭すぎるから下に落として欲しい、という要望が出てくるのは当然かなと思いましたし、そこに関してもお客さんと相談して適宜変えていったほうが良いだろうなと感じました。
結局、今回は依頼が急すぎたので対応せずに終わったのですが。
1つ目の案件がそのあたりを握らなくてもすんなりうまくいってたので、同じように進めてしまったのが悪かったです。
こういう点は実際にやって分かることだったのでとても勉強になりました。
葛藤5：RWDで構築する必要あるの？
RWDは基本的に「モバイルファースト」で作るのが一番と言われています。自分自身、最初はなにそれ？という感じでしたが、いろいろな方のお話を聴いたり、実際に案件をやってみたりしてそのメリットがよく分かってきました。
お客さんの要望があって、それを踏まえてRWDでサイトを作るのであれば良いのですが、
周りではRWDありきの提案が多いような気がして、それが一番不安です。
RWDはあくまで「手法」の一つであり、それを前提として持ってくるのはよくないことだと思っています。
RWDの案件です、と話をいただいたのはいいのですが、お客さんから「IE6･7でもちゃんと見えるようにして欲しい」と言われたり、ディレクターからもらったワイヤーが、どう考えてもRWDを考慮されてなかったり。
ディレクターに関しては、社内的な問題なので自分でもフォローしきれるのですが、RWDということで自社から提案したにもかかわらず、お客さんからRWDには向かないような要望が出てくるのであれば、RWDで作るかどうか？から見直すべきだと感じました。
でも、既に「RWDでやるので」と提案しているし、自分にはそれを覆す力もなく。
ここをどうするかが自分の課題です。
レスポンシブ ウェブ デザイン 提案の提案
いろいろ書きましたが、以上を踏まえて、自分なりに『RWD提案の提案』リストを作ってみました。
以下、レスポンシブ（ワンソースでPCとスマートフォンサイトを構築）＝RWD、PCとスマホを分ける＝最適化 と表記します。
キャンペーンページを作るのであれば、最適化のほうがいい。
RWDだと、スマートフォンとPC版での構成を大幅に変えることは出来ず、ある程度の制約は出てくるが、最適化で構築した場合はレイアウトは自由。
キャンペーンページはどちらかというと、見た目のデザインに対するクライアントの要望が強いことが多い、というのも理由の一つです。
PCで画像を多用すると、スマートフォンではどうしても重くなってしまいますので。
キャンペーンページのように、ページ数が少なく、更新もほとんどないようなページなら、最適化のほうが満足度が高そうです。
ページの構成が、PCとスマートフォンとで既に決まっている場合は最適化のほうがいい。
上でも言いましたが、RWDは一つのHTMLを使用するので、レイアウト部分の制約があります。
既にお客さんとの間で既に構成が決まっていたり、お客さんから要望が出ていて、それを変えられないのであれば、最適化のほうが柔軟に対応できます。
パフォーマンス重視なら、最適化のほうがいい。
わずかな差かもしれないですが、最適化サイトよりもRWDが遅い、というのは事実です。RWDでも表示を高速化するための努力は出来ますが、それでもやはり「ワンソース」ですので、最適化サイトには適いません。表示速度が何よりも重要なクライアントであれば最適化サイトをすすめましょう。
レガシーブラウザ（IE6・7）でもちゃんと見えるようにするなら最適化に。
レガシーブラウザに対応するなら、最適化サイトのほうがいいと思います。わざわざRWDで苦労してレガシーブラウザに対応するメリットがない気がします。
（個人的にはIE8もレガシーブラウザに含めたいのですが、IE8はまだシェアもありそこまで強く言えないかなと。）
運用のことを考えるなら、RWDのほうがいい。
大規模な構成変更が頻繁に入るような場合だと、そうとも限りませんが、
RWDではHTMLがワンソースですので、ちょっとしたテキストレベルの修正作業の頻度が高いサイトほどRWD向きです。
ただ、CMSなどを使えば、最適化サイトでも更新の手間を減らすことが出来ます。
SEOに有効なのは、どちらかというとRWD。
Googleが推奨している＝SEOに有効と（短絡的に）考えるなら、RWDの方がSEOに有効と言えます。
Googleの見解では「PCとスマートフォンで同じ内容を提供するのであれば、URLは単一が望ましい」とのことなので、それを簡単に実装できるのはRWDです。
ただ、最適化サイトでも、サーバ側で処理をしたり、canonicalを指定すればカバーはできます。
参考文献：
スマートフォン向けサイトにはレスポンシブ・ウェブデザインを推奨、Googleが公開したスマホサイトの最適化 at #SMX Advanced Seattle 2012
個人的には「Googleが推奨しているのは、PCとスマートフォンのURLが一致しているということで、べつにRWDを推奨しているわけではない。」と解釈していたのですが、こちらの記事を見ると明確に「推奨」しているみたいですね。もちろん、「強制」はしていないですが。
RWDではPC/スマホの切り換えが簡単には出来ない
RWDと最適化サイトを混同している人がいるようで、RWDのワイヤーフレームに「PC版」「スマートフォン版」といったボタンやリンクがついていることがありました。
RWDはウィンドウ幅によって強制的にスタイルが切り替わるので、JSなどの別プログラムをかませない限りはPC/スマホの切り替えはできません。
最適化サイトのように、ユーザが見た目を選べないということです。
この点は確認しておいたほうが良いポイントです。
このリストを見るとRWDにするメリットが少ないように見えるかもしれませんが、
もっと長い目で将来のことを見ると、RWDはかなりメリットがあるように思います。
デバイスによって個別のページを作ることは、現状は簡単かもしれませんが、将来的にタブレットやスマートフォン以外の端末が出てきたとき、端末専用ページがどんどん増えて、サイト構築がかなり大変になる可能性もあります。
RWDには、やろうと思えばHTML側に修正を加えず、出来る範囲でCSSを調整して、端末のサイズや解像度に合わせて見た目を変えられるという可能性があります。
それを考えると、PCありきでサイトの見た目はそのままにしつつ、「このサイトだと、他のデバイスではこういう感じになりますが、どうでしょうか？」という提案をこちらからしていくのもいいかもしれないと思ってきました。（上のまとめと言ってることが真逆ですが）
もちろんリニューアルをするならモバイルファーストがいいと私は思いますが、今あるサイトは残しつつ、マルチデバイスに対応していくという方法（デスクトップファースト）もあるんだなと。
パフォーマンスという課題は確かに残りますが、『今あるサイトを生かして、できる限りのことをする』というのも、これからのWebサイト制作に対するアプローチとして悪くはないのではと感じました。
JSに対するアプローチ
いま、長期休暇をいただいていまして、先週の後半から、今週いっぱいお休みです。
このくそ忙しい時期に恐縮だったのですが、心身ともに限界だったので決断しました。
今までは休みの日も、会社のメールを見たりすることが多かったのですが、今回は一切していません。
そのくらいの気持ちで休みを取らないと、たぶんリフレッシュできないんじゃないかと思いまして。
と前置きが長くなりましたが、今回は特にお役立ち情報などはなく、独り言レベルなんですがふと思ったことを書きます。
私はいわゆるマークアップエンジニアなので、必要に応じてJSに触れているわけですが、
私がJSに触れるきっかけになったのは、大学時代の卒業研究でした。
何かコンテンツを作りつつ研究をする必要があって、当時あまり好きではなかったJS（JQueryベースですが）を使ってコンテンツを作りました。
幸か不幸か、結果的に社内でJQueryを使う機会が増え、ちょこちょこと書いたりすることになりました。
（それがなければJSなにそれ？なんかうざいアニメーションするやつですよね？ヤダヤダ。みたいな感じで入社していたので、本当に運が良いとしか言いようがないのですが）
そんなある日、会社の後輩から『マークアップ見てください！』と依頼されたので、 サイトを見てみると、JSプラグインのオンパレード。
ロールオーバー時には、ボタンがフェードで切り替わるようになっているし、
『ページトップへ戻る』リンクにはいわゆるスムーススクロールがかかっているなどなど、プラグインの多さにも驚きましたが、アニメーションの発想が豊富でとても驚きました。
ここでは、彼のやり方がよくない、と言いたいのではなくて、職種によって、Web制作へのアプローチがこんなにも違うのか、ということなんです。
プラグインを用いてアニメーションを多用した彼は、もともとFlashの方面を得意とする人でした。
HTMLあがりの自分は、Webサイトに対して「アニメートさせる」概念があまりなく、
JSで何を実装するかというと、ロールオーバーだったり、ナビゲーションのカレント表示を自動で行うとか、高さ揃えとか、『必要だから』使うことが多く、アニメーションのように、よりリッチな体験を与えるような『＋α』のスクリプトはほとんど書いてきませんでした。
よほど難しいものではない限り、プラグインも使うよりも、自分でJSを書くことのほうが多く、あまりプラグインは使いたくないなぁと思っています。
Flashあがりの後輩は、Flashに関する知識がベースとしてあるので、何かと動き（アニメーション）に対する発想が豊富です。
そして、何か実装しようと思えば、ライブラリ（プラグイン）を検索し、それをどんどんつけて実装していきます。
たぶん、Flashはいろんなライブラリを組み合わせて動かすことが多いので、たくさんプラグインを使うことに抵抗がないのでは？と思いました。
この二人のアプローチの差が何かというと、「Flash屋がJSやってる」のか、「HTML屋がJSやってる」のか、の差だと感じたんです。
（ただ、彼の他にFlashに造詣の深い同僚がいないので、一概に職種で方向性を分けることはできないのですが･･･。）
私は今までずっとHTMLを触ってきてそろそろ10年たつわけですが、Flash屋の彼のようなアニメーションに対する発想がなく、正直なところ、うらやましく思う自分がいます。
ただ、それをうらやましく思うだけではなくて、今までの自分のアプローチを見直すきっかけにもなったので、後輩にはとても感謝しています。
ベストプラクティスは時代によって変わります。『自分のやり方』をずっと持ち続けるのではなく、その時代、ニーズにあわせて、アプローチの方法は積極的に検討していこうとあらためて感じました。
CSS3でアニメーションが実装できるようになり、アニメーションに無縁だった、私のようないちマークアップエンジニアでも、アニメーションのアイディアとか、見せ方を提案していくような時代になっていくんだろうなと感じています。
お客さん相手の案件だと、あまり前衛的なアニメーションを導入する機会は多くないと思いますが、依頼されたときに、できます！と胸を張って言えるように、これからも精進していきたいと思います。
と、まとめてみました。
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リクエストを減らす（サイトに使用するファイル数を減らす）』こと。
という結論ですかね。
ここまで書いてみて、冒頭で
全体的な感想を言うと、大体知ってるような内容だったなぁという印象です。
行ってよかった、という部分もあったし、これは行かんでもよかったなぁという部分もあり。
などと言っていますが、
こうやって深く考える機会ができてる時点で行った意味はあったのでは（笑）
と冷静に考えて思いました。
ただ個人的には、『高速化、みんなで考えようよ』というテーマが、ディレクター（制作業務をしない人）に高速化のメリットをどう伝えるか、とか、お客さんにどう理解してもらうか、こうするとよくなるよね、ということへの道筋を示してもらえるのでは？というほのかな期待があったので、そういう意味では、少し残念でした。
ま、自分で考えろってことですよね（笑）
今さら感満点ですが、以上、レポートメモでした。
Copyright © 2008 A.Yu-ri all rights reserved.