デザクロ技術メモ（HP･CSS･SEO）

２本立ての「パンくずリスト」

2011-01-13T23:00:00.007+09:00

化粧品・サプリメントの通販売上No.１サイト、

DHCのホームページを覧てたら、

ページの中の、あるおもしろい部分に思わず目がとまった。

次のウェブページの画像をみてください。

「パンくずリスト」が２本立てになっています！

レギュラーな「パンくずリスト」が上段で、

イレギュラーな「パンくずリスト」が下段に配置されています。

なるほど。こんな手もあったわけですね。

初めてお目にかかりました。

ちなみに、パンくずリストとは、

ウェブサイトの中で、自分が今どの（階層の）ページを閲覧しているのか分かるようにするための記述のこと。

通常、上画像のように、

トップページ（＝HOME）から階層を下る記述となっています。

閲覧者がウェブサイト内で迷子にならないようにということで、

グリム童話『ヘンゼルとグレーテル』の中で、

主人公が森で迷子にならないように通り道に

パンくずを置きながら進んだ、というエピソードに由来しています。

2004年６月、ウェブ・アクセシビリティを規定した

日本工業規格（JIS、正式名称は「JIS X 8341-3 高齢者・障害者等配慮設計指針 - 情報通信における機器、ソフトウェア及びサービス - 第3部:ウェブコンテンツ」）が交付された際、ホームページへの「パンくずリスト」の設置が推奨され、一気に拡がったという経緯があります。

現在は、検索エンジンGoogleも「パンくずリスト」のホームページへの設置を推奨しています。

（「検索エンジン最適化スターターガイド」PDFファイル）

ただ、パンくずリストはその問題点を指摘されることが結構あります。

その問題点についてはまた筆を改めて別の機会に取り上げたいと思います。

とは言え、このDHCのホームページにある

２本立ての「パンくずリスト」は

ある意味、「パンくずリスト」の問題点のひとつに対する

斬新な解決策と言えなくはありません。

ここで言う問題点とは、

ウェブサイトのコンテンツの中には、

色々なページからたどれるコンテンツや

分類が重複するコンテンツが結構あり、

その場合、単一の「パンくずリスト」のような分類構造では

そのコンテンツの位置を確定できなくなるというものです。

２本立ての「パンくずリスト」は、

この「単一のパンくずリスト」を覆すやり方なんでしょうか。

少なくとも、DHCの２本立ての「パンくずリスト」は、

絶妙な記述だと思います！

最下層のコンテンツ「バスタオル」から

「キャンペーン商品一覧」ページへの誘導を可能にしていますから。

理論的な是非より、実際にお客様を誘導し、

売上に貢献する仕組みのほうが優先されるのが通販サイトでしょう。

ちなみに、コーディングは次のようになっています。

最初、下段の「パンくずリスト」に nofollow があったらスゴイと思っていましたが、残念ながらそれはありませんでした。

実際のコーディングは、

「定義型リスト」内に入れ子で「並列列挙リスト」の入れ子、入れ子、入れ子… となっています。

考えた上でのコーディングだというのは分かりますが、

パンくずリストのコーディングとしては何とも微妙ですね。

Yahoo! JAPANが一部スパム行為を明確化…虫眼鏡SEOやキーワード入力補助の人為的操作はスパム

2010-12-11T20:34:00.005+09:00

Yahoo! JAPAN が検索における一部のスパム行為（キーワード入力補助スパム・関連検索ワードスパム）を明確化し、取締りを強化すると、Yahoo!検索スタッフブログで本日（12月11日）発表していました。

　　▶「Yahoo!検索の品質向上に対する取り組み」

以前から「キーワード入力補助スパム」と「関連検索ワードスパム」に対するヤフー検索の弱さは随分指摘されていました。

ちなみにグーグル検索においてはある程度（検索システム上の）スパム対応がきちんとできているため、ヤフー検索のように大きな問題になることはありませんでした。

スパムの手口ついてに触れる前に、

「キーワード入力補助」と「関連検索ワード」について少々。

画像を見てもらったほうが早いですね。

【キーワード入力補助】

検索キーワードの入力途中に表示される他の検索キーワード候補が

キーワード入力補助と呼ばれるもの。

（さらに詳しくは、Yahoo!検索ヘルプ「キーワード入力補助機能とは」）

【関連検索ワード】

ウェブ検索の結果の下に、関連検索ワードとして表示されるのが

CSS3 PIE（PIE.htc）が上手く動作しない際の注意点

2010-11-17T16:09:00.009+09:00

マイクロソフトのブラウザー Internet Explorer（６・７・８）に
一部のCSS3のスタイルを機能させる
CSS3 PIE（PIE.htc）はとても便利なJavaScriptです。

CSS3 PIE（PIE.htc）によって現在、
IEに機能するようにできるCSS3のスタイルは次の通りです。
（「lojjic's PIE at master - GitHub」）

border-radius（ボックスを角丸にする）
box-shadow（ボックスに影をつける）
border-image（境界線に画像を使用する）
multiple background images（背景に最大４つの画像を使う）
linear-gradient as background image（背景にグラデーション）

文章を読みやすく、伝わりやすくデザインするという点では、
充分ありがたいスタイルですね。

CSS3 PIE（PIE.htc）のダウンロード先

　　▶ Downloads for lojjic's PIE - GitHub

通常は、一番上の「PIE-1.0beta2.zip — PIE distribution, version 1.0 beta 2」をダウンロードし、「PIE.htc」を使います。php用の２ファイルは使いません。

（ダウンロードするのに、サインアップする必要はありません。）

ところが、CSS3 PIEのホームページに書いてあるように設定しても、
以下の事柄に注意しないと、上手くいかない場合があります。

注意点１
CSSにはCSSファイルから「PIE.htc」への相対パスではなく、
「PIE.htc」を使用しているHTMLファイルから「PIE.htc」への相対パスをCSSに書き込む必要があります。
（絶対パス＝フルパスを設定しても自分の場合、動作しませんでした。）

注意点２
各要素に以下の設定をしないと、CSS3 PIEが上手く動作しない場合や、同じセレクタ内の他の要素のエラー原因となる場合があります。

　　position:relative;

注意点３
サーバーの仕様によって動作しない場合があるので、
その場合は「.htaccess」ファイルにて以下の設定が必要になります。
（この設定でサーバーに、拡張子.htcのファイルがテキスト形式のファイルであることを伝え、サーバーで適切に使用できるようにする。）
（その他の「.htc」ファイルの際も有効。）

　　AddType text/x-component .htc

（なお、注意点につきましては、「CSS3PIE（PIE.htc）が効かないと思ったら」を参照させていただきました。感謝です！）

URL末尾のスラッシュについてのグーグル検索での扱われ方

2010-11-05T15:17:00.004+09:00

URL末尾のスラッシュの有無と検索エンジン側の扱いについて

グーグルが結構わかりやすく、詳細に取り上げていたのでメモ。

　　▶「URL 末尾のスラッシュは必要？」

　　　（2010-11-05、グーグル・ウェブマスターブログ）

その中でも一番のポイントとなるは次の２つ。

１．ウェブサイトのトップページの場合

ドメインにおけるトップページ（＝ルートURL）については、

末尾にスラッシュがなくても、スラッシュがある場合と同一に扱われる。

　　http://example.com

　　http://example.com/

上の２つの例の場合、２つのURLは同一のもの（一般にはスラッシュのある方 http://example.com/ ）として扱われます。

２．ウェブサイトのディレクトリの場合

ドメイン以下の階層（＝ディレクトリ）レベルの場合、

URLの末尾のスラッシュ有無により、それぞれ別物として（そして、同等に）扱われる。

　　http://example.com/food/

　　http://example.com/food

上の２つの例の場合、２つのURLは別物として扱われます。

通常、

末尾にスラッシュのある http://example.com/food/ はディレクトリを、

末尾にスラッシュのない http://example.com/food はファイルを示します。

ただし通常、ホームページが入っているサーバーでは、

末尾にスラッシュのない http://example.com/food が入力された場合、末尾にスラッシュのある http://example.com/food/ にリダイレクトされるように設定されているため、同じURL（一般にはスラッシュのある http://example.com/food/ ）として扱われます。

また、その場合、

末尾にスラッシュのあるURL http://example.com/food/ が、

グーグルの言うところの “優先URL” ということになります。

なお、末尾にスラッシュのない http://example.com/food がファイルとして扱われるケースは、主にこのURLがプログラムによって書き出された動的URLである場合が当てはまります。

（動的URLと静的URLについては、かなり間違った情報がネット上に出まわっているので、改めて別の機会に取り上げたいと思います。）

ヤフー検索のグーグル検索エンジンのへの移行、先ずはMac版Firefoxから

2010-11-01T16:39:00.012+09:00

数日前、先のブログ「ヤフー検索のグーグル検索エンジンへの移行は年内に切り替え完了へ」で取り上げた時に、ヤフー検索のグーグル検索エンジンへの移行をおこなった検索結果を確認できたらお伝えすると書きました。

どうやら Mac版の Firefox（ver. 3.6.12）から

ヤフー検索にアクセスして検索すると、

グーグルの検索エンジンを使ったヤフー検索結果が表示されます。

今日、いくつかの検索キーワード（=検索クエリ）で試してみましたが、

Mac版の Firefox でヤフー検索すると、

全てグーグルの検索エンジンを使った結果が表示されます。

（米ヤフーエンジンかグーグルエンジンかの違いは検索結果ページの最下段に米ヤフーのクレジットの一文「Search Results provided by Yahoo! Inc.」の有無で判ります。）

下の画像は２つとも今日おこなった検索キーワード「ハロウィン」での検索結果。

【グーグルの検索エンジンを使ったヤフー検索結果（Mac版 Firefox）】

【（米）ヤフーの検索エンジンを使ったヤフー検索結果（Mac版 Safari）】

他にも、同じ検索キーワードを使って、

異なる種類のブラウザーでヤフー検索を試してみましたが、

米ヤフーベースの検索エンジンのままです。

Mac版 Firefox 以外で試したブラウザーは次の通りです。

（以下のブラウザーでヤフー検索しても、グーグルの検索エンジンを使用した検索結果ではありませんでした。Win版の Firefox もダメでした。）

　Mac版

Safari 5.0
Google Chrome 7.0
Opera 10.6

　Win版

Internet Explorer 8.0（７）
Internet Explorer 6.0（XP）
Firefox 3.6（７）
Firefox 3.5（XP）

どうやらヤフーによる検索エンジン移行のテストは、

Mac版の Firefox のみでおこなっているみたいですね。

（特定のブラウザーを識別して、表示させることは簡単。その他にもパソコンのある地域を特定して限定表示させることも可能。）

実は以前、弊社ブログ「ウェブサイト・検索エンジン動向」の中で、

グーグル検索が、「検索結果には同一ドメインから２ページまで」の原則を変更したという投稿を３本書きました。

確か２本目（2010-09-07、グーグルの「検索結果には同一ドメインから２ページまで」の原則を変更は既に日本でも始まっている？）か３本目（2010-10-11、グーグルが「検索結果には同一ドメインから２ページまで」の原則を撤廃した後のウェブ戦略について）のブログ投稿を書いていた頃、

検索結果をチェックするため、

ブラウザーで検索結果を目にした時、

ヤフー検索でも同一ドメインから４ページも表示されている！

と驚き、既にヤフーはグーグル化されたのか、

と思ったのを覚えています。

（その時はそれがヤフーによる移行テストだと気づきませんでした。）

【同一ドメインから４ページ表示されるヤフー検索結果（Mac版 Firefox）】

しかも、検索結果に現れた同一ドメインの全４ページ中、

３ページがインデント表示（＝字下げ表示）されていたのをはっきりと覚えています。

今にして思えば、

それは現在の Mac版 Firefox でおこなったヤフー検索結果と

同じですから、

ヤフーは Mac版 Firefox を使って、

以前からグーグル検索エンジンへの移行テストを

おこなっていたんでしょうね。

日本では、Macユーザーが全パソコンユーザーの約10％で、

そのうち10〜30％位がブラウザーFirefox を利用していると

されていますから、

ヤフーが明かした数パーセントの検索結果にグーグル検索エンジンを

導入済みというのと合致します。

なお、幾つかの検索キーワードを使って、

現ヤフー（米ヤフーベース）と新ヤフー（グーグルベース）の

検索結果を比べてみました。（今の段階の私見です。）

メジャー検索キーワードでは、多少の違いのある場合がみられるが、ほぼ同じ検索結果。
マイナー検索キーワードでは、上位はほぼ全く同じ検索結果。

はっきり言ってしまえば、

新しいヤフー検索は、ほぼグーグルの検索結果と言えます。

（上の画像のように、同一ドメインのホームページが

　検索結果に続く時に、２つ目以降のページがインデント

　表示されるのは、とても見やすく、好感がもてます。）

もう少しヤフー色（＝法人企業サイトやホームページの作りかがしっかりしているサイトが上位表示される）が出るのかなと思っていましたが、今のところそんな傾向は見られませんでした。

上述しましたが、今後はヤフーでも同一ドメインから２ページ以上

検索結果に表示されるようになりそうです。

ホームページの検索上位表示の競争は、

ドメインのブランド力も含めて、

企業ブランド力とバックリンク数（＝被リンク数）の勝負に

しぼられてきそうですね。

もちろん、

きちんとしたホームページ制作が大事なのは変わりませんが . . .

ヤフー検索のグーグル検索エンジンへの移行は年内に切り替え完了へ

2010-10-27T23:23:00.012+09:00

10月22日のヤフー第２四半期決算説明会の場で、

ヤフーの井上雅博社長は検索エンジンのヤフーからグーグルへの切り替えを予定通り年内に完了する方針を発表したそうです。

既に数パーセント（一部情報によると５％という情報も）は、

ヤフー検索において

グーグルの検索エンジンを使用した検索結果を

試験的に表示しているとのこと。

そして、ヤフー検索において

米ヤフー（Yahoo! Inc.）の検索エンジンを使っているか、

それともグーグルの検索エンジンを使っているかは、

ヤフー検索結果の最下段のコピーライトの下の一文

　　Search Results provided by Yahoo! Inc.

が有るか無いかの違いで判断できるそうです。

【ヤフー検索結果画面（最下段のクレジット部分）】

個人的には、グーグルの検索エンジンベースのヤフー検索結果を確認できたことは残念ながら一度もありません。

５％だとすると、20回に１回は検索結果に現れてもよさそうですが。

確認できましたら、お伝えしたいと思います。

▶ ヤフー検索のグーグル検索エンジンのへの移行、先ずはMac版Firefoxから

　　（2010-11-01。確認できましたのでその状況を公開しています。）

　　………………………………………………

検索エンジンの話題からは少し外れますが、

　　Yahoo! JAPAN - IR関連情報

に載っている IR（＝Investor Relations、企業が株主や投資家に対して自社の理解を深めてもらうために提供する企業情報）資料は、

目を通すと興味深い内容になっています。

とりわけ「添付資料」には、

リスティング広告の売上高の業界別シェアや

ディスプレイ広告の売上高の業界別シェアなど、

ヤフーにおける公告費の業界別シェアを知ることができます。

　　▶ 2010年度第2四半期決算説明会資料

　　　（PDFファイル、2010-10-22）

さらに決算報告書（決算短信）には、

リスク開示ということで、

ネット広告ビジネスにおける問題点や

リスク（損害賠償請求の可能性のある事案）が

こと細かく載っていて、

インターネットビジネスに関わる者にはとても参考になります。

　　▶ 決算報告書

Internet Explorer が世界シェアで50％を割る

2010-10-22T20:20:00.003+09:00

世界約300万サイトにトラッキングコードを埋め込むことによって

アクセス解析を実施しているアイルランドのアクセス解析調査会社

StatCounter社のアクセス解析データによると、

2010年10月、Internet Explorer が

ブラウザーの世界シェアで、初めて50％を割ったとのこと。

　　▶ StatCounter Global Stats

　　　（スタットカウンター・グローバル・スタッツ）

世界では、Internet Explorer の利用比率は下がる一方ですね。

【ブラウザーの世界シェア（StatCounter Global Stats 発表）】

【ブラウザーの日本シェア（StatCounter Global Stats 発表）】

日本では、まだ60％を切ったところです。

世界シェアに比べ、下降が緩やかですね。

こうしたデータを見るにつけ、

ホームページ制作時のブラウザー毎のチェックが

ますます重要になることを感じます。

なお、StatCounter Global Statsの表の見方については、

当ブログ「ブラウザー、OS、検索エンジン、モバイルのシェアがリアルタイムに判るサイト StatCounter Global Stats」で解説しています。

CSS区切り線＜hr＞を画像で表示する方法

2010-09-18T20:26:00.005+09:00

ホームページの制作中、

区切り線（＝水平線、横罫線）＜hr＞に画像を使いたいことがあります。

（なお、カギ括弧<>とコロン:は、全角＜＞：にしています）

そんな時は、

HTMLファイル側で、

以下のように＜hr＞に対して直にクラス指定するのではなく、

　　＜hr class="definition" /＞

＜hr＞を＜div＞タグではさんで、

以下のように＜div＞に対するクラス指定で制御するよにします。

　　＜div class="definition"＞＜hr /＞＜/div＞

後は、CSSファイル側で、＜hr＞を非表示にし、

＜div＞のクラス指定で、背景に区切り線の画像を指定すればOKです。

（この方法だと、画像だけでなくボーダーも自由に設定可能です。）

　　hr {

　　　display：none;

　　}

　　.definition {

　　　height： 10px;　← 画像の高さ

　　　background： #FFF url(../image/hr-img.gif)　 ← 背景に画像

　　}

本来であれば、

区切り線（＝水平線、横罫線）＜hr＞を全称セレクタ（ * ）で

リセットしておけば、

前者の＜hr class="definition" /＞でも問題なく

背景画像を表示できるはずですが、

MS Internet Explorer （ver.６、７、８）だと

下記画像の下のように

画像に重なって初期設定の区切り線が表示されてしまいます。

＜hr class="definition" /＞と記述した場合でも、

様々なCSSハックやJavaScriptを使えば

意図した通りの表示を実現することは可能です。

ですが設定はかなり手間です。

それと比べ、今回のやり方のほうがはるかに簡単です。

CSS定義リストを横並びの美しいカタチに装飾する方法

2010-09-05T22:23:00.000+09:00

CSSの中でもバグが発生しやすく扱い難い

定義リスト（dl、dt、dd）ですが、

定義リストを見事にコントロールし、

装飾のヒントを挙げてくれているウェブページをメモ。

　　▶「CSS - dtをfloatする場合の注意点」

　　▶「dtをfloatする場合の注意点」

ここで紹介しているような「更新履歴」の他にも

「会社概要」の項目表示などにも応用が利きそうです。

JQuery Cycle Plugin を使った画像のスライド・エフェクト

2010-08-30T22:32:00.007+09:00

JQuery Cycle Plugin（サークル・プラグイン）を使うと、

様々なエフェクトをかけた画像のスライドショーや

少し目立つリンクバナーを比較的簡単に作成することができます。

（ソースをDLもできますが、それは使わなくても作れます。）

JQuery Cycle Plugin の配布元のホームページ（英語）で

主なエフェクトを見ることができます。

　　▶ jQuery Cycle Plugin

サークル・プラグインを設置したベースとなるウェブページの見本は

次のURLとなります。

　　▶ JQuery Cycle Plugin - Basic Demo

このウェブページのHTMLソースをコピーして編集して行きます。

ソールを見ると分かるように、

次の２つのライブラリはフルパスでリンクを張って済ませます。

　　jquery.js

　　jquery.cycle.js

jquery.js の最新バージョンについては、

このブログ「Google AJAX Libraries API の使い方」を参照します。

jquery.cycle.js のバージョンは jquery.cycle.all.latest.js という

常に最新のバージョンになるライブラリへの

便利なフルパスリンクで完了します。

ベースのソースを元に実際に編集するのは

次の CSSと JavaScript の部分です。

　　CSS（.slideshow）

　　JavaScript（以下の部分）

　　　　　$(document).ready(function() {

　　　　　$('.slideshow').cycle({

　　　　　 fx: 'zoom'

　　　　　 });

CSS（.slideshow）では、

　　overflow: hidden;

という設定を追加することで、

ブラウザーが JavaScript をオフにしている場合でも

最初の画像１枚だけが表示され、

レイアウトが著しく崩れることを避けることができます。

JavaScript の部分については

　　fx: 'zoom'

の zoom の部分を

　　blindX、blindY、blindZ、cover、curtainX、curtainY、

　　fade、fadeZoom、growX、growY、none、scrollUp、

　　scrollDownscrollLeft、scrollRight、scrollHorz、scrollVert、

　　shuffle、slideX、slideY、toss、turnUp、turnDown、

　　turnLeft、turnRight、uncover、wipe、zoom

に変えることでエフェクトの種類を変更できます。

これらエフェクトの実際の動きは

次のページで fx をクリックして確認できます。

　　▶ jQuery Cycle Plugin - Effects Browser

エフェクトの速度やタイミング、画像の重なり具合などの

パラメーター（＝オプション）は fx: 'zoom' の下に

記述を追加して行います。

例）

　　$(document).ready(function() {

　　$('.slideshow').cycle({

　　 fx: 'zoom',

　　 speed: 500, // トランジションの速度

　　 timeout: 5000, // 次のトランジションが起こるまでの間隔時間

　　 sync: 1 // 1はtrueで重なるように同時に起こる。0だと別々

　　 });

　　※オプションの最終行にはコンマ（ , ）を付けないこと。

追加できるオプションについては次のページを参照。

　　▶ jQuery Cycle Plugin - Option Reference

（オプションの一部について日本語で解説しているホームページ：

　http://shanabrian.com/web/library/cycle.php）

気づいたいくつかの問題点

個々の画像へのリンク方法は通常の a href="" でOK（「jQuery Cycle Plugin - Anchor Demo」も参照）ですが、リンクを張ると一部エフェクトの挙動がおかしくなるケースが見受けられます。（主に zoom が関わるエフェクト）
CSS にしろ JavaScript にしろ、外部ファイル化が望ましいわけですが、外部ファイル化すると Internet Exploter 6（Win）でエフェクトが効かなくなります。

Google AJAX Libraries API の使い方

2010-08-14T15:58:00.007+09:00

世に出まわっている様々なAJAX（エイジャックス、アジャックス）用の便利なライブラリを、当該サイトでダウンロードしてそれを自社サーバーにアップロードすることなく、グーグルのサーバーからライブラリを直接呼び出して利用する方法について。

早い話が、グーグルが Google AJAX Libraries API として、グーグルのサーバーから自由に使えるように公開してくれているのを利用しようというものです。

現時点で提供されている Google AJAX Libraries API

Chrome Frame
Dojo
Ext Core
jQuery
jQuery UI
MooTools
Prototype
script_aculo_us
SWFObject
Yahoo! User Interface Library (YUI)
WebFont Loader

【利点】

一度ダウンロードしたライブラリ（どこのサイトからでもOK）はブラウザーにキャッシュされ、次回以降高速に機能する。
使用するバージョンに対してワイルドカード指定ができるため、マイナーアップデートなどはグーグルに任かせておける。

【難点】

いわゆるフルパス指定になるため、オフラインで機能しない。（制作者サイド）

Google AJAX Libraries API を使うための準備

１．グーグルアカウントを取得

グーグルが提供するすべてのサービスに共通するグーグルアカウントを取得して、サービスにログインする必要があります。

　　▶ Google アカウント

２．Google AJAX Feed API への登録ページで、

　　Google API キーを取得

Google AJAX Libraries API を利用するために、利用するウェブサイトのURLを入力し、「APIキーを生成」ボタンを押します。

Google API キーのコードが書かれてページが表示されるので、その Google API キーのコードをコピペかメモる。

（使用するウェブサイトのURLには、wwwといったサブドメインを書かないほうが無難。サブドメイン名を書かないと、全てのサブドメインに対して有効になる。）

　　▶ Google AJAX Feed API への登録

Google AJAX Libraries API の記述方法

Google AJAX Libraries API を呼び出すための記述方法は２つあります。（カギ括弧<>とコロン:は、全角＜＞：にしています）

１．HTMLファイル内にインラインで記述

〈例〉

＜meta http-equiv="content-script-type" content="text/javascript" /＞

＜script src="http：//www.google.com/jsapi/?key=グーグル API キー" type="text/javascript">＜/script＞

＜script type='text/javascript'＞google.load('jquery', '1.4.2');＜/script＞

２．HTMLファイル内で直接取得、さらに外部ファイル化

〈例：直接取得〉

＜meta http-equiv="content-script-type" content="text/javascript" /＞

＜script src="http：//www.google.com/jsapi/?key=グーグル API キー" type="text/javascript"＞＜/script＞

＜script src="http：//ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js" type="text/javascript"＞＜/script＞

〈例：外部ファイル化〉

document.write('＜script src="http：//www.google.com/jsapi/?key=グーグル API キー" type="text/javascript"＞＜/script＞');

document.write('＜script src="http：//ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js" type="text/javascript"＞＜/script＞');

Google AJAX Libraries API の記述方法：ワイルドカード

〈例〉

１．

＜script type='text/javascript'＞google.load('jquery', '1');＜/script＞

２．

＜script src="http：//ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js" type="text/javascript"＞＜/script＞

既出の例で、1.4.2とバージョン指定するところを、1と記述することで、バージョン1.9.9（＝2未満）までのバージョンの中の最新バージョンを呼び出すことができます。

Google AJAX Libraries API の最新バージョン

以下のページで、提供されているライブラリの種類と最新バージョンを確認できます。

　　▶ Google Libraries API - Developer's Guide（英語）

フルパス指定する際は、“path(u)” ではなく、 “path” を使用すること。

ちなみに、“path(u)” はuncompressed（非圧縮）ファイルで、

“path” の方は、compressed（圧縮）や minified（最小化）がはかられたファイルです。

uncompressed（非圧縮）や minified（最小化）については、

次のホームページが参考になりました。

　　▶「jQuery 開発者向けメモ - 基本・サンプル」

圧縮をしておらず，開発時の状態のままの Uncompressed 版と，圧縮を行った Packed 版と Minified 版があります．
通常は Minified版かPacked版を使うと良いと思いますが，開発中はデバッグがやりにくくなるため，Uncompressed版を利用することをおすすめします．
Minified版とPacked版の違いは，MinifiedはJavaScriptの文自体はそのままに，空白を詰めたものです． Packed版は，ソースコードを圧縮し，ロード後にJavaScriptで圧縮されたjQueryコードを解凍し，実行することで更に小さくしたものです．ファイルサイズはPacked版の方が小さいですが，クライアント側でJavaScriptの解凍処理が走るので，クライアントPCへの負担は大きくなります.

国内検索エンジン比率（ヤフーによるグーグル検索採用の発表を受けて）

2010-08-02T22:02:00.003+09:00

デザクロ-ブログ「Yahoo! JAPAN が Google 検索エンジンの採用を発表」で取り上げたように、国内最大手の検索エンジンヤフーがグーグル検索エンジンを採用することを７月27日に発表しました。

その発表を受け、新聞各紙が取り上げた記事から日本の検索サービスのシェアについておさえておきます。

【朝日新聞（2010年７月28日）】

（ネットレイティングス調べ。2010年６月の検索回数をもとに計算）

ヤフー　50.2％
グーグル　32.8％
インフォシーク　9.2％
マイクロソフト　2.9％
その他　4.9％

【日経新聞（2010年７月28日）】

（日本はネットレイティングスのデータを基に日経推定。世界は米コムスコア）

ヤフー　53.2％
グーグル　37.3％
マイクロソフト　2.6％
goo　1.5％
その他　4.5％

参考までに世界での検索エンジン比率は次の通り。

グーグル　66.8％
ヤフー　7.2％
百度（Baidu）　6.5％
マイクロソフト　3.1％
その他　16.4％

ヤフー検索アルゴリズムの変更がもたらすヤフーディレクトリ登録サイトへの影響とは？

2010-07-22T23:37:00.006+09:00

７月５日に行われた「Yahoo！検索アルゴリズム Update（Yahoo！検索スタッフブログ、７月５日）」を受け、SEO対策リサーチが今回の７ヶ月ぶりとなるヤフー検索の大幅なアルゴリズムの変更の影響を分析し公開していました。

　　▶ テキストは多めに盛っておくべし。7/5以降の新アルゴリズム。

詳しいことは上記ホームページでご確認いただくとして、今回のブログでは以前このブログで取り上げた「ヤフーのトップページから『登録サイト』検索が消える」との兼ね合いを考えてみたいと思います。

偶然でしょうか、ヤフーのトップページにこれまでずっとあった「登録サイト検索」の項目が消えた日と、ヤフーの検索アルゴリズムの大幅な変更の発表があった日は、同じ７月５日です。

SEO対策リサーチの調査結果によると、「ヤフービジネスディレクトリ登録サイト」に対するヤフー検索の評価はこれまで通り、変わらず相当高いものの、「ヤフービジネスディレクトリ登録サイト」からの被リンクの価値については、“全体的に大きく減少。評価がハッキリと弱まる。” とあります。

つまり、これまでは「ヤフービジネスディレクトリ登録サイト」からリンクをもらうことには大きな価値があったのに、今回のアルゴリズムの変更により、その価値が弱まってしまったということですね。

果たしてこれは単なる偶然なんでしょうか、いささか気になるところではあります。

ブラウザー、OS、検索エンジン、モバイルのシェアがリアルタイムに判るサイト StatCounter Global Stats

2010-06-29T22:27:00.006+09:00

アイルランドのアクセス解析調査会社 StatCounter社は、世界約300万サイトにトラッキングコードを埋め込むことによってアクセス解析（ブラウザー、ブラウザーのバージョン、モバイル用ブラウザー、パソコン用OS、モバイル用OS、PC用検索エンジン、モバイル用検索エンジンのシェア、モバイルとデスクトップPCの比率、ソーシャルメディアのシェア）を実施しています。

そのアクセス解析データは、リアルタイムで常にウェブサイト StatCounter Global Stats で見ることができます。

　　▶ StatCounter Global Stats

　　　（スタットカウンター・グローバル・スタッツ）

　　　（Stats は Statisticsの略語・俗語）

ウェブページ内では、以下のような情報を確認でき、かつ出力できます。

【 StatCounter の統計項目】

　　◎ Statistic（＝統計の種類）

　　　　　Browser（＝ブラウザーのシェア）

　　　　　Browser Version（＝ブラウザーのバージョンのシェア）

　　　　　Mobile Browser（＝モバイル用ブラウザーのシェア）

　　　　　Operating System（＝パソコン用OSのシェア）

　　　　　Mobile OS（＝モバイル用OSのシェア）

　　　　　Search Engine（＝PC用検索エンジンのシェア）

　　　　　Mobile Search（＝モバイル用検索エンジンのシェア）

　　　　　Mobile vs. Desktop（＝モバイルとデスクトップPCの比率）

　　　　　Social Media（＝ソーシャルメディアのシェア）

　　◎ Country/Region（＝国・地域）

　　　　　Japan（＝日本）もあります

　　◎ Time Period（＝統計期間）

【 StatCounter のグラフ形式】

　　◎ Line（＝折れ線グラフ）値は時系列

　　　（デフォルトは直近の13ヶ月）

　　◎ Bar（＝棒グラフ）値は統計期間における平均値

【 StatCounter のデータ出力】

　　◎ Save Graph Image（＝jpegフォーマットでの書き出し）

　　◎ Download Data（＝csvファイルでの書き出し）

　　◎ Emned（＝ホームページ埋め込みようhtmlソース）

なお、ここでの値はあくまで参考程度に留めた方が良さそうです。

とりわけ「日本」での情報は信憑性がかなり疑問です。

例えば、統計期間2009年６月〜2010年６月で、

日本における検索エンジンの比率において、Google 77.6%、Yahoo! 19.83%となっており、明らかに間違い。
日本におけるPCとモバイルの使用比率において、デスクトップPCが 98.95%、モバイル 1.05%となっており、これも明らかに間違い。
日本におけるソーシャルメディアの比率において、Facebook が１位で、mixi が入っていない。

少なくとも日本における統計比率は実際のものとかなりかけ離れているという印象です。

トップレベルドメインの違いは掲載順位に影響しますか？（グーグル・サイトクリニックのSEO）

2010-06-25T21:16:00.004+09:00

昨日に引き続き、グーグル・ウェブマスターブログに掲載されたグーグルのサイトクリニックでのSEOネタを。

　　▶ ダブリンで開催された「サイトクリニック」を紹介します

　　　（グーグル・ウェブマスター向け公式ブログ）

SEOに関連して、

グーグルがトップレベルドメイン（TLD）について触れています。

6. トップレベルドメイン ( .com や.info ) の違いは掲載順位に影響しますか？

影響しません。掲載順位で重視されるのはサイトのコンテンツです。

7. 日本向けのコンテンツを有するウェブサイトを運営していますが、サイトのトップレベルドメインは .so です。日本での掲載順位は低くなってしまいますか？

.so はソマリアの国別コードトップレベルドメインで、確かに Google 検索では検索結果がユーザーにとって最適かどうか判断するときにこれを参考にします。とは言え、ウェブサイトの掲載順位はさまざまな要素に基づいて決定されており、トップレベルドメインはそのうちの 1 つに過ぎません。ウェブサイトに日本向けのコンテンツがあれば、日本の検索結果でもランキングされます。ただし、Google の検索エンジンのアルゴリズムが、どのような検索結果にあなたのサイトを表示すべきか判断するのに、通常より少し時間がかかるかもしれないことにご留意ください。

この２つの回答が矛盾していることに気づいた方は、するどいです。

グーグルは、

６の回答ではトップレベルドメインは検索結果の「掲載順位に影響しません」と答え、

７の回答では、「ウェブサイトの掲載順位はさまざまな要素に基づいて決定されており、トップレベルドメインはそのうちの 1 つに過ぎません」とトップレベルドメインが掲載順位決定の１つの要素だと答えています。

答えが矛盾していることにグーグルは気がついていないのでしょうか？

不思議ですね〜。

なお、SEOの世界では一般に、ある国でウェブ展開するなら、その国のトップレベルドメインを取得して運営することが推奨されています。

また、ドメインの取得が困難なもの（＝審査が厳しいドメイン）や限定されるもの（＝取得するのが限定されるドメイン）のほうが、SEO的に有利とされています。一例を挙げると、アメリカ合衆国の連邦政府と地方行政機関が使用できる .gov などは最も価値の高いドメインのひとつとみなされています。

もっともこれには異議を唱えるSEO専門家もいます。

たまたま特定のドメインをとれるような組織が検索結果の上位にくる要素を沢山持ち合わせているのだという理由で。

ひとつだけ言えることは、あまりヘンテコなトップレベルドメインを取得するのはオススメできないということです。

２つほどその理由を挙げておきましょう。

１．見た目では、見慣れないドメインに対するユーザーの違和感が、ブランディングにおいてマイナスに影響します。

２．聞いたことのないような国のドメインの管理がずさんだと、通信アクセスに悪影響を及ぼしかねません。最悪、トップレベルドメインが無くなってしまう可能性も全くないとは言えません。

同じ内容のブログを 3 つ運営しているのですが、問題ありませんか？（グーグル・サイトクリニックのSEO）

2010-06-24T22:12:00.003+09:00

グーグル・ウェブマスターブログにグーグルのサイトクリニックの様子が一部紹介されています。

　　▶ ダブリンで開催された「サイトクリニック」を紹介します

　　　（グーグル・ウェブマスター向け公式ブログ）

SEOに関して役に立つ情報ですが、納得できない点もあります。

１つ目の話題「同じ内容のブログを 3 つ運営しているのですが、問題ありませんか？」を抜粋し、取り上げてみたいと思います。

1. 同じ内容のブログを 3 つ運営しているのですが、問題ありませんか？

コンテンツの内容が全く同じである場合、検索結果に反映されるのは 1 つのブログだけとなってしまう可能性が高いでしょう。また、ブログ運営の労力を分散してしまうと、ブログのリンクも分散してしまいがちです。つまり、複数の同じ内容のブログを運営することは、ユーザーだけでなく検索エンジンにとって、どのブログがメインなのか判断するのが難しくなるというリスクを伴ってしまいます。この場合、リダイレクトや canonical 指定を使って、優先したいブログを指定するとよいでしょう。

これについては、結構迷っている方もおられるのではないでしょうか。

考えられるケースは、同一の投稿を数種類の無料ブログ（例えばライブドアブログ、アメーバブログ、FC2ブログなど）に投稿して、露出を増やそうという目的でしょう。

ところが現状、無料ブログに対しては、リダイレクト設定も canonical 指定（＝URL正規化タグ）も施すことができません。

（設定できるようになれば非常にありがたいのも事実ですが。）

できないことを奨められても意味がありませんね。

というか、グーグルの回答中にある「リダイレクト」設定ってどういう意味なんでしょうか？

301リダイレクトを施したら、少なくともそのブログには本文が存在しません。例えばアメーバブログに載っているタイトルを見てクリックしてジャンプすると、ライブドアブログの行って投稿を読むことになるでしょうか。ナンセンスです。

302リダイレクトを施すとしたらどうでしょう。リダイレクトするまでの設定時間をめちゃめちゃ長く設定したらいいのでしょうか？　それにしても一般に302リダイレクトの検索エンジンの解釈は、「ページの一時的な移転」です。これによりリダイレクト先のウェブページが優先されるのでしょうか。甚だ疑問です。

canonical 指定（＝URL正規化タグ）にてしても、無料ブログでは設定できないし、CMS利用の場合ならプログラムを改良しなければなりません。一般の人ができる作業ではありません。

ちなみに、グーグルが運営する公式ブログでさえ、canonical 指定（＝URL正規化タグ）を適切に使ってはいません。

（それについてはデザクロブログ「URL正規化タグ（rel="canonical"）をきちんと使っていないGoogleのウェブページ」で取り上げていますので、よろしかったらどうぞ。）

さらにはグーグルが運営する無料ブログサービス Blogger でも canonical 指定（＝URL正規化タグ）はできません。

（テンプレートを編集して、自身のURLを正規化するようにはできます。）

この問題の一番の解決法は、URL正規化タグ（rel="canonical"）を投稿時に自由にURLを設定できるようになることです。

ですが、無料ブログを提供する側は、それを可能にすることを好まないでしょう。なぜなら、自社の無料ブログに投稿する人が、別の無料ブログを正規化指定した場合、検索エンジン経由での自社の無料ブログへの集客ができず、メリットがなくなってしまうからです。

実に難しい問題です。

ホームページの規模（＝全体のページ数）を確認する方法

2010-06-21T22:54:00.009+09:00

自社のホームページ戦略を考える上で、または、

これから自社でホームページを作成して成果を上げようと考える場合、

グーグルやヤフーなどの検索エンジンの検索結果で

上位表示されている他社のホームページは当面のライバルであり、

気になるところです。

とは言え、どうして検索結果で上位表示を実現しているかは

なかなか簡単には判らないものです。

グーグルやヤフーの検索結果で上位表示を実現するためには、

次の４つの要素が大きく影響します。

　　１．検索エンジン最適化（SEO）がしっかり行われているか否か

　　２．ウェブサイトの規模（＝コンテンツの質・量ともに）

　　３．ウェブサイトへの被リンク（＝リンクの質・量ともに）

　　４．広告展開などによる自社サイトへのトラフィック

今回はこの中から、〔２〕のウェブサイトの規模（＝コンテンツの質・量ともに）の調べ方をご紹介します。

実際にホームページを開いてみれば、ある程度そのホームページの規模は判りますが、実際の規模、何ページの分量があるのかまでははっきりとは判りません。

ライバルの他社のホームページよりも検索上位を目指すのであれば、

自社のホームページの規模を質と量の両面で他社を上回るくらいの規模を実現することが必要になります。

そのためにもライバルのホームページの規模を知ることは大切です。

一番使い勝手が良いのは次のサイトのウェブツールです。

　　▶ Yahoo! Site Explorer

Yahoo! Site Explorer は英語になりますが、

日本語版（＝サイトエクスプローラー）のものよりも、

現時点では精度も高く、使い勝手が格段に良いです。

ここに調べたいホームページのURLを入力します。

全体の規模を確認するために、この欄にはサブドメインを省いて、

　　http://ドメイン名　を入力します。

　　（www.もサブドメインですから、www.は入力しません。）

ページ総数と実際のページ（のページタイトルとURL）が

ずらりと100件ずつ表示されます。

初期設定では「全てのサブドメインを含む」となっています。

なお、調べるホームページのURLで www. を含めると、「全てのサブドメインを含む」という初期設定では www. 以外のサブドメインが含まれない状態となり、ウェブサイト全体の把握ができない場合が発生します。

サブドメイン www. を省いたURLで調べてください。

なお、グーグル検索では、

検索窓に「site:ドメイン名」と入力して検索すると、

そのウェブサイトの全ページが検索結果として表示されます。

URL正規化タグ（rel="canonical"）をきちんと使っていないGoogleのウェブページ

2010-06-14T16:08:00.013+09:00

SEO界における昨年の一番の出来事と言える

Googleの「URL正規化タグ（rel="canonical"）」の採用。

　　▶「検索結果に優先的に表示させたいページの指定について」

　　　（グーグルウェブマスター向け公式ブログ）

このタグ指定により、重複コンテンツ・重複URLの検索エンジンによる

インデックス化の分散を回避することが可能になりました。

指定の仕方は、

複製コンテンツページのheadセクションに以下の記述を追加します。

（なお、優先させるページ自身に、自身URLを記述して正規化しても構いません。）

＜link rel="canonical" href="http://優先させるホームページのURL" /＞

（山括弧はブログ用に全角にしてあります）

簡単な説明はこれくらいにして、先日、米Googleが新しい検索インデックスシステム「Caffeine」を公式ブログで発表した際、米Googleはいわゆる公式ブログとウェブマスター向け公式ブログの両方で同じ内容のページ（タイトル「Our new search index: Caffeine」）をアップしていました。

実際、本文には「(Cross-posted on the Official Google Blog)」と、

両方のブログにまたがって投稿している旨が記載されています。

▼グーグル公式ブログでの公開

http://googlewebmastercentral.blogspot.com/2010/06/our-new-search-index-caffeine.html

▼グーグルウェブマスター向け公式ブログでの公開

http://googleblog.blogspot.com/2010/06/our-new-search-index-caffeine.html

そこで rel="canonical" が気になり、

グーグルは一体どちらを優先指定しているのかと、

HTMLのソースを確認してみました。

▼グーグル公式ブログのHTMLコード

▼グーグルウェブマスター向け公式ブログのHTMLコード

すると、両ページにおける正規化タグの記述は以下のようになっていました。

（山括弧はブログ用に全角にしてあります）

▼グーグル公式ブログ

＜link href='http://googleblog.blogspot.com/2010/06/our-new-search-index-caffeine.html' rel='canonical'/＞

▼グーグルウェブマスター向け公式ブログ

＜link href='http://googlewebmastercentral.blogspot.com/2010/06/our-new-search-index-caffeine.html' rel='canonical'/＞

同じ内容のページだというのに、

それぞれが自身のウェブページを正規化してしまっています。

グーグルの説明によれば、

本来どちらか一方のURLに一本化すべきはず。

まあ、ブログ投稿のシステムの一環として、

自身のURLを正規化タグに入るように設定してあるのでしょうが、

グーグル自体が正規化タグをきちんと使っていないというのは、

ちょっとした発見でした。

ちなみに、検索クエリ「"Our new search index: Caffeine"」（ピンポイントで検索するため、ダブルクォーテーションマークで囲んで検索）でグーグル検索すると、下画像のように、上述の２つのサイトが１位と２位で表示されます。

検索クエリ「"Our new search index: Caffeine"」での検索結果

グーグルは自社のサイトに対してさえ、ペナルティを与えるくらい厳しい企業です。

まさかグーグルが提唱するURL正規化タグ rel="canonical" を

自身のホームページできちんと使っていないとはね . . .

RSSとAtomのフィードの構文をチェックできるサイト

2010-06-07T22:29:00.007+09:00

ホームページの情報発信の機能として有効なRSSやAtomの

フィードの構文をチェック（検証）できるウェブサイトを２つメモ。

大方のフィードは、ブログや

CMS（＝コンテンツ・マネージメント・システム）の一部として自動生成されるので、普段その構文の正当性・妥当性を気にすることはあまりないかもしれません。

フィードの検証サイトはどちらも英語のサイトです。

“validate（バリデート）” という単語を含みますが、

バリデートとは検証を意味します。そしてバリデートを行うツール・ソフトを “Validator（バリデータ、バリデーター）” と呼びます。

　　▶ Feed Validation Service（W3C）

　　　（フィード検証サービス）

　　▶ FEED Validator

　　　（フィード検証ツール）

検証したいRSSフィードのURLを入力し、

検証をおこない、問題がなければ、

「正当なRSSフィード」と認められ、

「正当なRSSフィード（VALID RSS ）」のアイコン（上画像中の黄色のアイコン）をホームページに貼ることができます。

なお、英語圏のウェブサイトで日本語サイトを検証すると、

上記２つのウェブ検証サービスに限らず、

時々、＜＞記号（半角英数）が意味不明なエラーと認定されることがあります。（検証する時期のよっては同じソースでもエラーにならなかったりすることもあります。正直これだけはいかんともし難いところです。）

iPad・iPhone・iPod touch 用の WebClipアイコンを設定。ファビコンについても

2010-06-03T23:26:00.014+09:00

ウェブブラウザー用のファビコンの設定を修繕し、

iPad・iPhone・iPod touch 用の WebClipアイコン（ウェブクリップアイコン）を設定してみました。

ファビコンの作成・設定については、ホームページ作成の際、

可能な限り行っていますが、

ファビコンの見え具合やファビコン内のレイヤー設定などで

どうも納得できないでいました。

現状、ファビコンは

ひとつのファイル「favicon.ico」の中に、

16×16px、32×32px、48×48pxの３つのサイズを埋め込んだものが望ましいと考えられています。

　　16×16px　…　通常のブラウザー用

　　32×32px　…　一部のブラウザー用

　　48×48px　…　ショートカットアイコン用

これら３つを含む３層のファビコンを生成してくれるウェブサイトや

無料アプリケーションもありますが、

取り込める元ファイルの重さに制限があったり、

pngファイルが読めなかったりで、

なかなか良い方法が見つからないでいました。

（ファビコン制作に余り時間は掛けたくはないところです。）

プロのウェブデザイナーならファビコンの元となるデータは

基本、Fireworks のベクトルデータ（png形式）ではないでしょうか。

pngデータなら透過ファイルを作成するのは簡単です。

実はこれが厄介な事態を引き起こすことになっていました。

png透過データからfavicon.icoファイルを作成すると、

透過部分の背景が真っ黒になってしまいます。

規格上、背景は透過のままであるべきなのですが、

ブラウザー上で黒になるのだから、仕方ありません。

（ウェブ制作上、何もファビコンに限ったことではありません。）

納得できないまま、

試しに透過pngファイルを透過gifファイルにしてみました。

透過gifファイルを元にfavicon.icoファイルを作ると

あっけなく上手く行きました。

キレイなものを作るためには、元データはより質の良いpngファイルで、

という気持ちが却って上手くいかない結果を招いていたんですね。

また、元ファイルのアイコンの形状によっては、

16×16pxのキレイなアイコンを作るのは困難な場合もあります。

実は、弊社のロゴがそれに当てはまります。

16×16pxファビコンではカーブをキレイに表現できないんですね。

なんども試してみて、結局今回は16×16pxファビコンの層を無くして

32×32pxと48×48pxの２層のファビコンにすることにしました。

（結果的にこれが一番キレイに見えたからです。）

もっとも、現時点で透過ファビコンが一番問題になるのは Firefox です。

特にMac版は透過部分のブラウザー背景となる灰色が濃いので、

キレイに透過しないと見栄えが良くありません。

他のブラウザーは背景が白色なので、問題はありません。

実のところ透過にしないで、ファビコンの背景を白色にしてもOKです。

なお今回、様々なファビコン作成ウェブ・サービスを試してみましたが、

次のサイトがベストだと思います。

（機会があれば操作手順も解説できればとも思いますが。。。）

　　▶ FavIcon from Pics（英語）

このウェブサイトでは、同時に

iPad・iPhone・iPod touch 用の WebClipアイコンも作成できますが、

ウェブクリップアイコンのフォーマットは png なので、

Fireworks などのベクトルデータのままでOKです。

ファイル名は「apple-touch-icon.png」にします。

pngのファイルの大きさを57×57pxにすればいいだけのことです。

（後は勝手に iPad・iPhone・iPod touch がキレイにアレンジして表示してくれます。）

注意点は、pngファイルを透過にすると、

iPad・iPhone・iPod touch の透過の背景のデフォルトが黒色だということです。

ウェブクリップアイコンの背景は透過にしないほうがいいでしょう。

後は（X）HTML内のhead内に以下の２行を追加すればＯＫです。

（例のURLは弊社の場合。ブログ表示用に括弧には全角文字を使用。）

＜link rel="shortcut icon" type="image/x-icon" href="http://www.designcross.org/favicon.ico" /＞

＜link rel="apple-touch-icon" type="image/png" href="http://www.designcross.org/apple-touch-icon.png" /＞

特別な意図がなければ、トップページのあるサーバーの階層に

ファビコンとウェブクリップアイコンをアップロードします。

ちなみに iPhone・iPod touch の画面のキャプチャーは

「ホームボタン」を押したままの状態で「電源ボタン」を押して

おこないます。

Mac の場合、

iPhoto 経由でパソコンにキャプチャー画像を取り込めます。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

後日（６月５日）、実際に iPad が届いたので、

自社のウェブクリップアイコンを確認すると、

アイコン画像が明らかに甘い（＝ぼやけている）。

（まあ、なんとなくは予想していました . . . ）

改めてWebClipアイコンについて調べてみると、

以下のことが判明しましたので追記しておきます。

　　57×57px（公式サイズ）

　　60×60px（標準クオリティ）

　　129×129px（最高クオリティ）

これからのこと（iPad対応）を考えると、129×129px が無難だと思われます。（実際にはどんなサイズでも表示されます。）

早速デザクロのアイコンも129×129px に変更しました。

ベースがベクトルデータで作ってあれば、

比較的簡単に変更できます。

57pxか60pxのどちらが最適かという問題については、

アイコンにする元画像の性質によって異なります。

　　「階調が多く直線が少ない画像」では60px

　　「細い直線が多い画像」では57px

のほうが一般にはキレイに表示されます。

最終的には実際に試してキレイなほうを選ぶことをオススメします。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

日本時間６月８日、新しいiPhoneが発表されました。

それを受けて追記。

今度のiPhoneの画面解像度は、

これまでの480×320pxから

960×640pxへと、大幅に高くなっています。

写真で見る限り、ウェブクリップアイコンの見た目の大きさは変わりありませんから、

解像度的には、これまでの57×57pxの２倍相当になっているものと考えられます。

だとすると、129pxあれば充分だと判断つきます。

逆に57pxのウェブクリップアイコンのままだと、

相当ボケボケのアイコンになってしまうでしょう。

グーグルがアクセス解析 Google Analytics によるデータ収集をブロックするアドオンを公開

2010-05-27T22:56:00.006+09:00

グーグルは同社自身が提供する高機能アクセス解析「Google Analytics」による閲覧者のデータ収集をユーザー側でブロックできる新しいアドオン（プラグイン）を公開しました。

このアドオン（プラグイン）をブラウザーにインストールすると、

グーグル・アナリティクスによる閲覧者情報の収集を無効化することができます。

　　▶ Google Analytics オプトアウトアドオンを公開しました

同グーグルのページ内から、ダウンロードページに進み、インストールできます。

なお、現時点で Google Analytics オプトアウトアドオンが利用可能なブラウザーは、Internet Explorer（バージョン７および８、Win）、Google Chrome（４.x 以上、WinとMac）、Mozilla Firefox（3.5以上、WinとMac）となっています。

これにより、このアドオン（プラグイン）をインストールされたブラウザーが増えると、アナリティクスのデータの正確性は低下します。

アクセス解析を行う側にとってはありがたくない話です。

グーグル・アナリティクスによりどんな情報が取得できるかは、

ウェブサービス活用法〔デザクロ｜お得意様用サイト〕の

「グーグル・アナリティクス（アクセス解析）の活用法」を

参考にしてください。

なんだかヘンテコなことになってきていますね。

高機能アクセス解析プログラムを提供する側が、高機能アクセス解析をブロックするプログラムも提供しようというのですから。

ただグーグルの気持ちは分かります。

プライバシーもとても重要な問題ですから。

苦渋の選択だったと思います。

でも、せめてアナリティクスをブロックした閲覧者数ぐらいは教えて欲しいものです！

根幹には、JavaScript の問題もあります。

JavaScript、とても便利なスクリプトです。

現在のホームページではこれを無しには語れません。

Googleマップ、YouTubeもJavaScriptによって機能しています。

JavaScript無しでは、全く機能しません！

ブラウザーの開発競争も、今はJavaScriptをいかに高速処理するかの競争となっていると言ってもいいでしょう。

それくらい JavaScript はホームページページにとって

重要かつ欠かせない機能となっています。

他方、JavaScript はプライバシーの問題も常に抱えています。

次の記事が示すように、閲覧者が自分のプライバシーを守る最善の手段は、JavaScript をオフにすることです。

現時点で個人を識別されにくくする絶対的な方法は存在しないが、識別しにくくするための方法はあるという。１つは JavaScript を無効にするか、無効にするためのツール（例えば NoScript など）を使用すること

（「ほとんどのブラウザーで個人を識別できる“指紋”を残す、米EFFが警告」）

いずれにせよ、ブラウザーにとって新しい仕様（スクリプト）でも

できない限り、この問題は解決しそうにはありません。

外部スタイルシート（CSS）と外部JavaScriptファイルの記述順序も大切〔２〕

2010-05-24T23:00:00.010+09:00

前回の外部スタイルシート（CSS）と外部JavaScriptファイルの記述順序の最適化に加え、今回は更にもう一歩進んで、他の外部ファイルや内部JavaScriptの記述（＝インライン・スクリプト）がある場合の記述順序の最適化について取り上げます。

（Web Performance Best Practices内｜Google code：英語）

グーグルが示唆する最善の参照ファイルの記述順序の原則は次の２つです。

「その他の外部ファイル記述」は「外部スタイルシート（CSS）記述」の後に。
「内部JavaScript記述（＝インライン・スクリプト）」は一番最後に。

最善の記述順序例

このグーグルのサンプルには外部JavaScriptの記述が載っていませんが、グーグルのウェブサイトや他のメジャーサイトを参考にすると、

「外部JavaScript記述」は「その他の外部ファイル記述」の後、「内部JavaScript記述（＝インライン・スクリプト）」の前が最適と言えるようです。

これまでの内容をまとめると、

次の参照ファイル（＝記述）がある場合、

その最善の並び順は、基本的には以下の通りとなります。

（ファイル内容によっては並び順を変更できない場合もあります。あくまで記述の順序がウェブページの表示や動作に影響しないケースにおける記述順序とお考えください。）

外部スタイルシート（CSS）記述
その他の外部ファイル記述
外部JavaScript記述
内部JavaScript記述

なお、前回・今回のブラウザーによる読み込みファイルの順序については、ブラウザーによっては異なってきます。

例えば、Apple のブラウザー Safari には、実際のファイルの読み込み順序を確認する開発者向け機能がついています。

使い方は、調べたいホームページを表示してから、

　　開発 > Webインスペクタを表示

　　「リソース」で「開始時間で並び替え」

で確認できます。

これによると、複数のJavaScriptファイルを、

グーグルの指摘（昨日のブログ内容参照）とは異なり、

並列で同時に読み込んでいるのが判ります。

検索エンジンGoogleは既にホームページの検索ランキングを決める要素のひとつに、ページの読み込み速度（＝ホームページの表示スピード）を加味しています。（「米Googleが検索結果ランキングの決定要素にホームページ表示速度を追加」）

サイトを訪れてくれる人のためにも、検索エンジン対策のためにも、

ホームページ表示のスピードアップを計りたいですね。

外部スタイルシート（CSS）と外部JavaScriptファイルの記述順序も大切〔１〕

2010-05-23T23:27:00.006+09:00

ホームページの作成時、

スタイルシート（CSS）やJavaScriptの記述を外部ファイル化して

HTMLファイルのヘッダー内で呼び出すのは常套手段ですが、

実は、そのスタイルシート（CSS）とJavaScriptファイルの記述順序で

ブラウザーでの読み込み時間が変わってくるという話題。

（Web Performance Best Practices内｜Google code：英語）

スタイルシート（CSS）は複数のファイルを同時に読み込むことができ、

JavaScriptはひとつの読み込みが終わってから、次のJavaScriptの読み込みが始まります。

従って、ブラウザーでの読み込み速度を少しでも早くするためには、

まずスタイルシート（CSS）の参照を先に記述し、

そのあとにJavaScriptの参照を記述したほうが良いと言えます。

良い記述例

悪い記述例

（図の中の時間は仮定した時間です）

案外意識しないないで外部ファイルを記述している

ホームページ制作者も多いと思います。

たったこれだけのことでも、

ホームページ表示のスピードアップが可能なんですね。

パソコンで携帯サイトを見る方法〔１〕

2010-05-19T23:33:00.003+09:00

ホームページの制作に携わるものとしては、

携帯サイトも無視できません。

携帯サイトを作る際に役に立つサイトをご紹介します。

　　▶ サイトビューワ｜gooモバイル

ホームページアドレスをURL入力覧に入力すると、

携帯電話でのホームページの見え方をチェックできます。

ボタンを選択して３キャリア、

docomo（ドコモ）、au、softbank（ソフトバンク）携帯での見え方を確認できます。

とは言え、万能ではありません。

実際の携帯電話では問題なく覧ることができるサイトが

エラーになるケースも多々あります。

あくまで、参考程度に留めてください。

レンタル共有サーバー利用時に共存するホームページ数の調べ方

2010-04-23T23:17:00.007+09:00

独自ドメインを共有サーバー利用で、ホームページ展開されている方は沢山いると思います。

その自分が利用する共有サーバーの他の利用者やホームページ数が気になる時があると思います。

そんな時役に立つのが、DomainTools 内にある次のサービスです。

　　▶ Whois lookup and Domain name search（英語）

検索窓に調べたいホームページアドレス（URL）を入力し、検索すると、次のページが表示されます。

タブの「Whois Recoard」をみると、同一サーバーでどれだけのホームページが共存しているかが分かります。

1300以上のホームページが共存しています。いわゆるレンタルサーバー費が安いサービスの場合です。

「Reverse IP」とは逆引きIPアドレスのこと。必ずしも常に当てはまるとは限りません。

同じ共有サーバーでも、比較的高価なサーバーです。扱いは専用サーバーとなっていますね。

「Dedicated Server」とは専用サーバーのこと。ただし英語圏では VDS（＝Virtual Dedicated Server）や VPS（＝Virtual private server、仮想専用サーバー）と同義で使われたりしています。

取得できるデータが常に一定しているわけではありません。取得できるデータによって、表示される項目が異なってきます。

DomainToolsでは、他にも有益な情報を取得できます。機会があればまたご紹介します。

なお、会員登録しないと、調べることのできる検索数が制限されます。また有料の会員サービスもあります。有料のサービスではより詳しいデータが取得できるようになります。