読者です 読者をやめる 読者になる 読者になる

ランキングファクターセッション@SMX Advance 2014

Search Engine LandのSMX Advance2014レポートを読んだ際のメモ。
大枠はずれていないけれど細かいトレンドのキャッチアップとしては非常に充実した内容。幾つかあるレポートの中でも一番長い(充実してる)です。


Up Close @SMX Advanced: The Periodic Table Of SEO Elements

ランキングファクターセッションでは、例年通りSearchmetrixによる調査の発表の他、2人からUXの重要性が発表された。

マーカス・トバー@Seachmetrix inc.によるランキングファクターの関連度調査

  • サイトスピードは重要で、特にモバイルではUXに直結するので大切にしよう
  • ブランドは1位2位には有効だがそれ以下の争いでは無意味。まずはネット以外でブランドを確立する事が大事。
  • 少なすぎる多すぎる内部リンクは不利(平均は180くらいだが数千のサイト調査の結果なので一概に言わない方がいい)。
  • どんなにスピードや内部リンクを最適にしても、コンテンツが貧弱ならどうにもならない。
  • コンテンツについては長めの文章が有利な模様
  • G+やFacebookのシェア数も影響度が大きいが、昨年よりは低下
  • バックリンク、量に関しても引き続き重要。
  • スマートフォンの場合はテキスト量少ない方が有利
  • さらに、バックリンクの数が影響するのは5〜6位まで
  • PCとモバイルの両方で20位以内に入るのは64%程度
  • サイト滞在時間はややポジティブな影響
  • 直帰率とランキングに影響は無い
  • CTRは非常に影響力が大きい

最近のSEOはユーザーエクスペリエンスだ!

マリアン・スウィーニー@PortentによるUXがSEOに与える影響

  • 検索者は年々なまけものになっている
  • UX観点からの重要なポイント4つ
    • 選択(ユーザーはあなたを選ぶか?)
    • エンゲージメント
      • ファーストビュー
      • 分かりやすいか(Proto-Typicality:よくあるデザインで斬新すぎないように)
      • 複雑すぎる見た目になっていないか
      • ナビ:検索を使うようになっているので、最低限で分かりやすくすること
      • ユーザーは必ずページ中央をまず見るので、そこに最も重要なコンテンツを配置する事
    • コンテンツ
      • あり物のコンテンツを活かす
      • 古くて不要なコンテンツは消すべし
      • コンテンツのオーナーにコミットメントさせろ
    • リンク
      • キーワードリサーチは陳腐かしたがそれでも重要
      • Google Trendなどを使ってクエリーの向こうにいる人間を想像する事
  • 90%のユーザーはスクロールしない(Google Analyticsで調べられる)
    • あなたのコンテンツはスクロールする価値があるのか?

マシュー・ブラウン@MozによるSEOを成功させる要因

  • 単純なSERPsはもうほとんど存在しない
  • ランキングへのハミングバードの影響は強く、相関性も複雑になった
  • SEO担当者は計れるもので考えて、計れない物は無視してしまいがち

  • 重要じゃなくなったもの

    • タイトルタグとメタタグ中のキーワード
    • キーワードの言い替え(“hotels in Paris,” “Paris hotels,” “top Paris hotels” etc.)
    • やり過ぎなスニペットを意識したマークアップ
    • 単純な順位ではなく、検索結果面に一緒に表示されるユニバーサルサーチを確認しよう
  • これから重要(になりそう)

    • エンティティ(ナレッジグラフ)最適化
    • ローカル情報(モバイル検索の成熟でさらに重要に)
    • ナレッジグラフはどんどんローカルに
  • エンティティとリレーションシップを最適化しよう

  • SEOはこれからどんどんサイトに独自化していくのでSEOの重要性は上がっていくと思う

QAセッションでのダニーサリバンのお言葉

  • ソーシャルでの関連度をあげろ、ランキングをあげるためではなく、(コンテンツの評価などを)評価するために

Volocity.jsを使ってアニメーションのパフォーマンスを比較してみた

CSS vs. JS Animation: Which is Faster?
CSS AnimationよりもJavascriptを使った方がパフォーマンスが出るよ、というこの記事を見たので実際に試してみた。

結論

アニメーションさせる時は、Velocity.jsを使いましょう

デモ

DEMO1 - 画面下からスクロールインしてくるモーダルウィンドウ

DEMO2 - 120個の丸が一度に動く、シンプルなアニメーション

[source code @ GitHub]

機能比較

ライブラリ 特徴 メリット
jQuery(animate()) 標準で組み込まれているアニメーションライブラリ ライブラリの読み込み不要
Velocity.js 標準のanimate()と同じ文法で使える拡張ライブラリ スピード最適化された実装
Transit CSS Animationを制御するためのライブラリ 3d-transformも使用可能

結果

Windows7Mac Book AirChromeでテスト。

ライブラリ DEMO1 DEMO2
jQuery(animate()) △ 動きに引っかかりが発生 × 動きがずれる
Velocity.js ◎ なめらか ◎ なめらか
Transit ○ なめらかだが一瞬ひっかかる ○ 動きのステップが大きい

結果はValocity.jsが圧倒。特にDEMO2でのスムーズさは他を圧倒。
requestAnimationFrameを使用していて、ちゃんとフレーム毎に再描画されるのでスムーズさが違います。
GPUが使えないスマートフォンで見ると、さらに違いが顕著。

解説

Velocity.jsがスムーズな一番の理由はrequestAnimationFrameを使っている事。これはブラウザが画面の再描画のタイミングで呼ばれるフックになっていてきちんとフレーム毎に再描画されるようになり、そのおかげでスピード以上に自然な動きに見えるようになります。その他にも効率化のために色々やっているので、使わない手はありません。既存のanimate()との互換性もあり、呼び出しをvelocity()と書き換えるだけで問題なく動作するようです。

個人的にびっくりしたのはCSSアニメーションがそこまで早くないという事。ブラウザがネイティブで最適化できるんだから一番早いはず!というのは思い込みだったようです。とはいえ、3d-transformをアニメーションさせるにはCSSアニメーション必須なので、使い分けですね。

あと、Transitはアニメーションの終了をフックできません(多分 コメントいただきましたがjQueryアニメーションと同じ文法で書けると明記されていました)。リアクションとしての動きだけなら問題ないけれど、インタラクティブなアニメーションをさせる場合、実装ががやや面倒くさくなりますね。

CSS Animationを使用するタイミング

元記事にも有りますが、シンプルなアニメーションで管理をすべてcssファイルで一元管理できるならあり、とのこと。大量の要素を一度に動作させない限りパフォーマンスも悪くないので、使用する事自体は問題ないでしょう。個人的には飾り的な(なくてもいい)アニメーションはCSS、インタラクションに関連する必須なアニメーションはVelocity.jsを使うのがオススメです。

My recommendation is to use raw CSS transitions when you're exclusively developing for mobile and your animations consist solely of simple state changes. In such circumstances, transitions are a performant and native solution that allow you to retain all animation logic inside your stylesheets and avoid bloating your page with JavaScript libraries. However, if you're designing intricate UI flourishes or are developing an app with a stateful UI, always use an animation library so that your animations remain performant and your workflow remains manageable. One library in particular that does a fantastic job at managing CSS transitions is Transit.

結論ふたたび

コストはたったの8kだけなので、Velocity.jsを使いましょう。
互換性もあるので、不具合あってもすぐに戻せるし。

参考リンク

Velocity.js公式

CSS vs. JS Animation: Which is Faster?

Improving UI Animation Workflow with Velocity.js

compassミニマムスタートの始め方

既存プロジェクトの一部だけにcompassを取り入れてみる。

すでに公開中のサイトにcompassを導入する場合は、sassフォルダに現状のcssをぶち込んでしまえば良い訳ですが、それは一人で管理している場合。

複数人で作業している場合には、全員にcompassに乗り換えてもらわないと行けないので中々めんどうです。。単発のお仕事でキャンペーンページ作成や新機能の追加などの場合は、自分の担当部分だけでもcompassでやりたい!と思うのですが、準備やコミットが面倒くさい事この上ない、、、

ということで、既存のプロジェクトで自分の作業ファイルだけをcompass採用するためのプラクティスです。

メリット

  • 既存のフォルダを汚さない
  • 作業フローがどんな形でもコンフリクトが起きない
  • フォルダの整理などの事前準備が(ほとんど)不要

どうやるの?

  • compassフォルダを追加で作成
  • htmlのcssファイルへのパスを変更
  • compass w実行
  • 実作業
  • 最後にcommpass compile -e production
  • htmlの記述を戻して、納品!

フォルダ構成

作業フォルダ/
 └ css/
 └ img/
 └ compass/
  └ sass/
  └ img/
  └ css/
  └ config.rb

config.rbはこんな感じ

config.rbサンプル @ Gist

やってること

Gruntが書き出すcssを監視して、親ディレクトリ*1cssフォルダに自動的に移動します。

既存のcssファイルに同じ名前の物が有ったら確認メッセージを表示するので、間違って上書きも発生しません。

注意

  • cssで使用している画像の移動は手作業で
  • commpass compile -e production実行時にcssに変更が無いと変換されないので、--forceオプションを付けるか、grunt cleanを実行してから

最後に

compass/*.csscss/に移動させているだけなんですが、そこがコントロールできるのがポイント。 納品やコミット作業のタイミングまでcompass一式を分離しておくので、共有フォルダで他の人と同時に作業していても問題無いですし、間違って関係ないcssを消してしまう事もありません。

また、最初に色々パスを書き換えて、、、的な準備が不要になるので気楽にcompass導入ができるのではないかと。自動化もされるので、なれないフォルダ構成にあたふたする必要もありません。

画像ファイルの移動ややhtmlのcssパスの書き換えは手作用になるのが難点ですが、ミニマムスタートということでこの形式。完全移行か不採用かっていう葛藤ではなく、とりあえず、コスト0でスタートすることは大事だと思うのです。

*1:config.rb中のcss_distination_dirで指定できます

【翻訳】JavaScriptのスタイルガイドとプラクティス by Addy Osmani

AOLの開発者で、jQueryチームのメンバーでもあるAddy Osmani氏の記事「JavaScript Style Guides And Beautifiers」について翻訳の許可をいただいて記事にしました。意訳の箇所も多いですし、翻訳は素人なので、間違いがあればご指摘ください。


JavaScript Style Guides And Beautifiers

今回のテーマはJavaScriptのスタイルガイドです。なぜスタイルガイドが大事なのか、参考になるスタイルガイド、きれいなコードの製作をサポートするツールについて、そして、実際にスタイルガイドに沿ったコードを解説していきたいと思います。

「スタイルガイド」ってなに?

始める前に「スタイルガイド」の定義をおさらいしておきましょう。

スタイルガイド(スタイルマニュアル)は、コードをデザイン・記述するための標準(ルール)のセットです。スタイルガイドはでコードのスタイルとフォーマットの画一性を提供します。内容としてはインデント(タブか半角スペースか)や変数、関数の命名規則、コードのどの部分に半角スペースを記述するのがよいかなどが定められています。

なぜ一貫したコードスタイルが重要なのか?

多くの人が「よいコードはそれ自身が仕様書だ」といいます。私自身はそれに完全には同意しませんが(仕様書は重要です!)、重要なのは読みやすいコードを心がけることで、コードのメンテナンスもやりやすくなるということです。

一貫したスタイルガイドを適用することで、このコンセプトの実現を容易にすると同時に、コードのクオリティを高めることにもつながります。これによって、他の開発者の手を借りる際に、容易にメンテナンスができ、(コードの解読などに)時間をとられることも減ることでしょう。

読みやすいソースコードは私たちにも理解しやすいものです。目を通すのも楽ですし、バグの発見や修正も容易になります。また最適化もずっと楽になります。また巨大なソースコードの中で、個々のコードがどのように組み込まれているかも、クリアにイメージもできるようになります。これは別にスタイルがきちんとされていないコードが悪い(記述の)コードという意味ではありません。スタイルがほとんど適用されていないにもかかわらず、全体を通してみれば非常に効率的な記述をされているコードをいくつも見たことがあります。

繰り返しますが、スタイルを適用したコードは

・実装を理解するためのリードタイムを減らすことができます。
・コードの再利用ができることを確認するのを簡単にします。
・実装のアップデートをする際にもどのようにスタイルするか、構成をどのようにするかを明確化できる(覚えておいてください。このような一貫性のあるコードは、たとえチームで記述したとしても一人が書いたように見えるものです)。

実際のところ開発者は作業にスタイルガイドを使っているの?

スタイルガイドの利用は多くの人に支持されています。しかし実際のところ全体の1%しかきちんと使っていないとしたら、役になっているとはいえないでしょう。もう少し実体を把握するために、ツイッター上で「JavaScriptを書くときにスタイルガイドを使っているか」開発者にたずねてみました。

結果、多くの参考になる意見をいただきました。以下にそのうちのいくつかを挙げてみます。

Rodney: jQueryスタイルガイドをよく使っているよ。あのばかげた量の半角スペースを除いてだけどね。
Sindre: 当然Idiomatic.jsだよ。シングルクオートとタブインデントにしてね。
D.Cherman: 僕らのグループでは使ってはないね。でも僕自身はideomatic.jsに従うようにプッシュしてるよ。
Marek: 参加しているプロジェクトが別のものを使っていない限り、いつもクロックフォードスタイルを使っているよ。
Jack: 自分で作ったJSスタイルガイドに従っているよ。出回っているガイドラインを組み合わせたもので、大体似ている。
Matt: 使ってる(jQueryとIdiomaticをベースにして)。でもプロジェクトによってはフレキシブルに対応するよ。
Jamie: チームに参加していたときには既存のやつを使った。1人じゃないときは標準を決めるね。一人で作業する限りどんなスタイルでもいいと思うよ。標準を使うと一人が書いたように読めるからね。まぁ僕個人の意見ではあるけど(訳注:訳が間違ってるかも)
Arthifiji: 仕事でgoogleのコーディング&スタイルガイドラインを使おうと計画しているところ。すごく包括的だと思うよ。

お勧めのJavaScriptスタイルガイド

スタイルガイドを使ってみようかな、と思っている開発者の人のために、以下のスタイルガイドをお勧めします。

1.Idiomatic.js
このスタイルガイドは特に強くお勧めされるわけでも包括的なわけでもありません。しかし、これまで私の参加したいくつものプロジェクトで採用してきました。このガイドの開発者にはjQueryコアの開発者であるRick Waldron氏、jsPerfの開発者Mathias Bynensをはじめとして、jsコミュニティーで著名な開発者が参加しています。すべての開発者が100%同意するものではありませんが、#forkしやすいスタイルガイドという点でとくに優れています#。あなたの必要に応じて採用できます。

2.jQuery Core Style Guide
おそらくモダンなJS開発者にとって一番ポピュラーなスタイルガイドで、jQueryコアチーム、jQueryUI、QUnitなど多くのプロジェクトで採用されています。こちらにもRick Waldron氏が参加しており、Adam Sontag氏やJohn Resig氏といったjQueryの有名人が参加しています。

3.Google JavaScript Style Guide
有名なGoogleJavaScript開発者Robby Walker氏(Closure Linter)によるスタイルガイド。特にソフトウェアエンジニアリングの経験を持つ人にとって、読みやすくするためのベストプラクティスが多く含まれています。詳しいコメントはこちらから見てみてください。

4.Dojo Style Guide
dojo toolkitの開発者による、もうひとつの非常に包括的なスタイルガイドです。面白いことにこのスタイルガイドはJava programming conventions guideの構成を基にしています。これを読んで気に入ったのであれば、dojoのinline documentation guideを読んでみるのもよいでしょう。私のお気に入りのJSファイル中へのインラインコメントの記述方法です。

5.Aloha Editor JavaScript Style Guide
このガイドは組み込み型HTML5エディタAloha Editor(the relatively non-trivial contentEditable-based)の開発者によるものです。ガイド中でjQueryスタイルガイドを参照するように推奨されていますが、どのようにAMDモジュールをスタイルするかなど、いくつかの小さな役立つ追加点があります。

6.Crock's Code Conventions For JavaScript
ほかとくらべてサンプルの詳細などで劣りますが、もうひとつの優良なガイドです。見たところIdeomatic.jsによって取って代わられたようです。しかしあなたがIdeomatic.jsやjQueryコアスタイルガイドに同意できないのであれば、代わりとしてこれを使うことをお勧めします。

2人の開発者からNPM style guideをプロジェクトで使用していると聞きましたが、リストには入れませんでした。このガイドラインは邪魔な視覚要素をはぶいて最小限にしてありますが、実際の内容はその他のガイドラインと同等のもので、軽量版ガイドラインと呼ぶのがふさわしいでしょう。おすすめした1~6のガイドラインはより包括的なガイドラインとなります。

注:私は上にあげたガイドラインをすべてレビューしたうえで、簡易であったり明確でないためにあまり役に立たない(私の意見ですが)スタイルガイドを不採用にしました(the GitHub JavaScript style guideなど)。

実際にIdiomatic.jsのスタイルを適用させるチュートリアル

簡単なチュートリアルをやって見ましょう。ここにどのガイドラインも適用されていない関数があります。

function foo(bar,baz,fum){  
    var hello = "Hello";  
    var ret;  
    var num = 1;  
    for(var i = 0; i < bar.length; i++) {  
        var out = bar[i];  
        if (out === ""){  
            ret = fum(out) + baz(out);  
        }  
    }  
    if (!(ret == undefined)) {  
        return ret;  
    } else{  
       return fum('g2g');  
    }  
}

技術的にはなんの問題もなく動作しますが、まだ改善することができます。

一貫して読みやすいコードを適用させることで、どのような効果があるかをよりよく理解するために、このサンプルにIdiomatic.jsの内容をひとつずつ適用させていってみましょう。

変更前と変更後を比較して、スタイルを適用させるとどう変わるか一目で分かるようにして、ステップごとに解説をしていきます。

1. 関数の宣言

適用前

function foo(bar,fum,baz){

適用後

function foo( bar, fum, baz ) {

・すべての引数の前に一貫して半角スペースを追加
・引数を囲む括弧の内側にそれぞれ半角スペースがあることを確認
・引数の閉じ括弧")"とブロックの開始括弧"{"の間に半角スペースを追加

2. 変数の宣言

適用前

var hello = "Hello";
var ret;
var num = 1;

ループ部分にも変数があるのでそれもまとめます

for(var i = 0; i < bar.length; i++) {
    var out = bar[i];

適用後

var ret,
    out,
    hello = "Hello",
    num = 1,
    i = 0,
    l = bar.length;

・読みやすくするためにひとつの関数にひとつのvarで変数を宣言するようにします。Idiomatic.jsによるとゴミ(訳注:"var"?)を減らすことができます。
・ループ部分で宣言されている変数"i"を同じvarの中に含めます。また、bar.lengthを毎回計算しないように変数"l"に代入してキャッシュします。
・ひとつの関数でひとつのvarというルールに基づき、変数"out"もこの宣言に含めるようにします。

3. ループ

適用前

for(var i = 0; i < bar.length; i++) {

適用後

for ( ; i < l; i++ ) {
    out = bar[i];

・ループ宣言で一貫した半角スペースを使用するようにします。
・具体的には(i)"for"と"("の間、(ii)すべての式と文の間、(iii)ブロックの開始括弧"{"の前
・すでに変数"i"に"0"を代入してあるので、これを省略してセミコロン";"だけを記述する。いくつかの開発者はこれでゴミを減らせると主張しています。

注:ループカウンターの宣言を関数の先頭にもってくるのはスタイル的な選択です。これに不都合を感じるのであれば、これを採用しなくても問題ありません。私個人は変数をトレースできるように、普段はインラインで記述します。

4. 条件の評価

適用前

if (out == ""){
    ret = fum(out) + baz(out);
}

適用後

if ( !out ) {
    ret = fum( out ) + baz( out );
}

・"out"が空かどうかの判定は、真偽判定を使用できます(例:"!out")。これによってキーストロークの数も減り、可読性も増します。
・これまでしてきたように、関数呼び出しの引数の前後に半角スペースを記述して、読みやすくします。

5. さらに条件の評価

適用前

if (!(ret == undefined)) {
    return ret;
} else{
   return fum('g2g');
}

適用後

return ret || fum('g2g');

・ここでは"=="による評価は使用しません(どちらにしろここでは"==="を使用するべきです)。
・"!(ret == undefined)"は4.と同様に真偽判定を利用して"!(ret)"と記述できます(ですがこれはさらに改善できます)。
・適用前のような冗長な記述方法ではなく、論理演算子の特性を活かすことができます。"ret"が"undefined"もしくは"false"の場合はつぎの条件にうつるため、これを利用して5行あったものを、ずっと少ない文字数にでき、可読性もあがります。

最終結果

function foo( bar, baz, fum ) {
    var ret,
        out,
        hello = "Hello",
        num = 1,
        i = 0,
        l = bar.length;
    for ( ; i < l; i++ ) {
        out = bar[ i ];
        if ( !out ) {
            ret = fum( out ) + baz( out );
        }
    }
    return ret || fum('g2g');
}

注:このサンプルにはまだまだ改善できる箇所があります。まずは、引数である"bar"、"baz"、"gum"の内容のチェックなどがあるでしょう。ですが、今回はスタイルの適用のチュートリアルということで無視しています。

おすすめのJavaScriptビューティファイア

コードを記述する際に一貫したスタイルを適用するのは非常に重要ですが、フォーマッターやビューティファイアなどのツールを使用することも役立ちます。

(以下略:今度書く)

結論・ティップス

・あなたのコードにおいて、一貫したフォーマットとスタイルを維持することには、いくつものアドバンテージがあります。それには既存のスタイルを利用してもいいですし、自身のオリジナルのガイドを作ってもいいでしょう。多くの開発者が、個人的なガイドラインを作ることが便利と感じていますし、ほかのものより優れていると感じています(訳注:最後のフレーズ違うかもしれません)。
・半角スペースの効果的な使い方をしてください。可読性があがります。
・変数や関数、モジュールの名前には短く意味のある名前をつけましょう。これによって、インラインコメントで詳細を説明する手間を省けますし、開発者がすぐにコードを読み込むことができます。
・繰り返しのコードや、もっと短く読みやすく書き直せるコードを書くべきではありません。これは別に、すべてにおいて第三者のオペレーターを使うとか、今回のサンプル通りにしなければいけないわけではありません。読みやすいのであれば、長い記述でも問題ありません。
YAGNI(You are not going to need it)やKISS(Keep it short and simple)などの原則に可能な限り従いましょう。冗長な記述をさけ、より簡潔で読みやすいコードを書く助けになります。