1-ое октября 2008 Профит может путем ускорение indicatory скорости home page?
Недавн очень интерес расширял в поле что он ускоряет ход home page странно.
Факт что indicatory скорость home page увеличена remodelling по мере того как она вызвана в автомобиле.Покупающ миниые 4 [puramo] времени 600 иен студента начальной школы, дорабатывая в гипер моторе черточки к широкой автошине, ......
Без изменять, оно делает что оно пыталось побежать даже маленькая быстрая и что вы делаете основно.
Основно, я люблю remodelling.
ミニ四駆を例に出しましたけど、ホームページも表示するスピードは速い方が得することがあると思います。物販サイトであれば、特にその恩恵は大大大！だと思います。
先日、私のブログを読んだ購読者の方から
ホームページの表示スピードを高速化することによって得られる利益はいくらですか？
という質問をいただきました。
正直ホームページの表示速度を速くしても利益が増えるなんてこれぽっちもありませんが、速くしなければならない原因が分かっているのであれば、高速化することによるメリットは大きなものになると思います。
説明するまでもないですが、ホームページの表示が遅ければ、ユーザーは次のページが表示するまで待たされることになります。これが1秒以内ならまだしも、2秒、3秒となるとその“もたつき“が原因でイライラし、ホームページを閉じてしまうか、他のサイトに行ってしまうと思います。（私ならサイトを閉じます）
これが年に数回ならまだいい方ですが、1日に5回も6回も“もたつく“減少がみられる場合、かなりの機会損失をしていることになると思います。損失金額に直すと….（想像してみてください）
機会損失を防ぐためにホームページが常に一定の表示速度が保たれるような保守メンテナンスが必要だと思います。そして現状の利益を圧迫しない程度の運用コストで、この品質が保たれるのであればECサイトの新たな投資対象の分野になるかと思います。
話はちょっとズレますが、SEOは検索エンジン最適化ですが、勝手に命名しましたが、SEOと連動して、WOSO（Website Optimization and Speed Optimization）も必要なのかなと..。
ただSEOはすべてのサイトでパフォーマンスが上がるのに対して、WOSOはECサイトなどのユーザーに何かのサービスを提供するホームページでないとあまりその効果のリターンがないのでやってみてもしょうがないのかなと。
もう少し突っ込んで、
ホームページの表示を早くする手段はいろいろありますが、一番手っ取り早いのはサーバにつながっているネットワーク速度を上げて、サーバのスペックをいいものにすればとりあえはすぐに速くできますよね。
ただ、この方法だと出力部分のフロントであるHTMLとかを最適化したわけではないのでハードウェアによって高速化されただけなので、HTMLレベルやサーバのアプリケーションレベルで最適化してあげるとこの前書いたようなパフォーマンスが確実に出ます。
あなたのサイトはいかがでしょう？
これをビジネスでなんてことはまだ考えていないのですが、みなさんが身近に使われているosCommerceやZencartにWOSOを施術した場合、WOSOによってどの程度ユニークユーザー数、ページビューが増え、日あたりの注文件数がどれだけ変化するのかを実験していきたいと思います。ここはとても興味ある所だと思います。
2008年9月30日 2時間の作業で34%ホームページを高速化
先日ブログでレビューした、「高速サイトを実現する14のルール」の件ですが早速自社サイトでやってたのでレビューしておきます。
タイトルに書いたとおり、結果的には34%の改善ができたわけですが、書籍には50%以上の期待ができるとか書いてある割には、そこまでは行かなかったものの、本当に高速化されたのには確かにビックリ。
高速化の対象にしたサイトは[eSupport] のホームページ。このサイトは全部で30ページほどある単純なHTMLで作成された静的サイトなので今回の試し台にはピッタリ。
14のルールがある内の今回トライしたのは以下の4項目
・ルール1 HTTPリクエストを減らす
・ルール3 Expiresヘッダを設定する
・ルール4 コンポーネントをgzipする
・ルール10 javasciptを縮小化する
計測はWebSiteOptimization.com にある分析ツールを利用し、Download Timeという項目で実行前と実行後の時間差でパフォーマンスを計測することにした。
他にもルールが書籍には掲載されているが今回のサイトには当てはまらなかったので、とりあえず上に挙げた4つのルールを実行した結果が以下の表。
作業にかかった時間は約２時間、主に画像の再スライスと、CSSの再設定、Apacheの設定変更である。
T1接続で4秒も高速化に成功し、34%改善されている点に注目。128K接続は今の時代にはないが、実際には約6秒の高速化に成功。
| Connection Rate | ダウンロードタイム
（改善前） |
ダウンロードタイム
（改善後） |
|---|---|---|
| 14.4K | 282.44 seconds | 240.88 seconds |
| 28.8K | 146.32 seconds | 123.74 seconds |
| 33.6K | 126.87 seconds | 107.01 seconds |
| 56K | 80.20 seconds | 66.84 seconds |
| ISDN 128K | 31.64 seconds | 25.05 seconds |
| T1 1.44Mbps | 12.06 seconds | 8.20 seconds |
確かにサイトは見るからに高速化されていて、表示スピードが早いのには体感できる。
今までホームページの制作過程の中では一度も見直すことがなかったホームページの高速化であるが、商用サイトの場合で数百から数千ページを動的生成させているサイトなんかだと、ページを高速化することで、日当たりのページビューが増え、１日あたり、年間あたりで計算した場合には相当なPVの増加を期待することができる。また検索エンジンフレンドリー、ユーザーフレンドリーなサイトになることは言うまでもない。
今回試したこの手法のもっとも気に入った点は、サーバのハードウェアをカスタマイズしたり、データベースへのSQL文などハードやアプリの根幹を一切いじらずして、Apache系のカスタマイズだけで高速化を実現できる点が制作側からするとフレンドリーである点だと思います。
ユーザーからサイトのスピードに文句言われる前に、少なくとも商用サイトであればこの手の手段はできる限り早い段階でやっておくことをオススメします。
Tags: website optimization
2008年9月27日 3年後くらいのECサイト業界はサービスとしてのソフトウェアへ変身できるか
SAASモデルは2012年までに8000億円市場になるらしい..。（本当か？.）
だとすれば、（旧来のオフライン）パッケージソフトの販売を行ってきたベンター達はサーバにパッケージソフトをインストールし、フロント部分をHTML化するだけで、ユーザーへデスクトップ環境と同じ形でネットワークを介したさまざまなサービスを再び提供するのではないかと思われる。90年代後半に盛り上がったASP時代が再び到来するようなもでしょう。
ネットワークを介してサービスを提供するとなれば、これはもはや非OS依存型のサービスになるので、Windowsの存在はどうなるのやら..。
最終的に、デスクトップに残るアプリケーションは、インターネットとメールだけになってしまうのでしょうか。
これを私の業界に当てはめて考えてみると次のような構図が見えてくる。
ウェブデザイン
ウェブデザインはクリエイティブな感覚が必要とする人間味あるサービスであるため、ソフトウェアとすることは難しい。ウェブデザイン自体の作成方法や作成技術は進化するかもしれないが、デザインを考案するクリエイティブな部分はどんなに時代が進もうとソフトウェア化できないのでSAAS化されることはありえない。
ECサイトの運営形態
ECサイトのソフト自体は自社サーバにインストールする自社運営型とモール型（楽天やYahooなど）の両方にそれぞれのメリットがあるため、今後も同時に進行されると思われる。これは今とそんなに変わるものではないと思われる。
ECサイトの販促系機能
ECサイト構築ソリューションとして、広告、アフィリエイト、アクセス解析、動画配信、アンケートフォーム、ヘルプデスクなどの各機能を補完すること自体が無意味なものになっていき、これらの機能ははいずれも全てSAAS化またはプラグイン（機能保管モジュール）化され、すべてが月額制で利用できるようになる。
受託システム開発だと、要件定義を出す側も、それを受ける側もそもそも共通言語を使ってだれも難しい話し合いなんかしたくない。日本にはいまだに共通のフォーマットがないから、プログラマと発注者でお互いが同じ言語感覚で話し合うことなどしたら、喧嘩になりがち。
受託はバージョン管理も、バグ管理も全てにおいて手間がかかる。受託がなくなることはなくても、受託を発注するプロセスやそのフローが何かSAASモデルによって改善されたらいいなと願ってます！
ECサイトの販売・顧客管理系機能
ここは、大幅に変更される可能性の秘めた領域だと思う。もっともベンダーの参入が多いと思われる。
現状のデスクトップアプリケーションで管理している受注管理や販売管理ソフトはすべてネットワークを介してサーバで管理されることになるだろう。業務系ソフトをSAAS化することにより、エンドユーザーは注文の編集やキャンセルを行いたいときに、メールや電話で連絡するのではなく、ログインをして自分の注文状態を確認し、自由に注文変更やキャンセルができるようになる。
懸念事項としてSAAS化することで全データをネットワークの向こうにあるサーバに保存することの抵抗感やセキュリティー不安の問題がある。
２重、３重のバックアップや、99.9%のアップタイムを保持できるだけの保守体制基盤作りにＳＡＡＳ業者はコスト増を強いられ、この部分がSAAS化産業の成長の鍵になると思う。データセンターやセキュリティー系ベンダーがSAAS化を促進できるだろうか。専用サーバのホスティングサービスはホームページのホスティングから、データ保管のホスティングサービスに変化するのだろうか？
顧客サポート系機能（ヘルプデスク）
電話対応、メール対応などの顧客対応履歴を含むカスタマーサポートに必要な機能はSAAS化される。ホームページに必要なフォーム機能は、すべて月額制で利用できるようになる。
Tags: SAAS
2008年9月8日 自宅や社内でサーバ機を設置している企業や個人向けの年間６万円のサーバ障害保険？
約年間６万円で、意外にもサーバ障害時に保険的役割を担ってくれるソフトウェアがあったのはご存知でしたか？
データセンターに設置して、保守契約を結んでいれば話は別ですが、
そうでない場合、特に自宅や社内でサーバ機を設置している企業や個人にとって、寝ている間におこる障害が悩みの種であることは間違いないはずだと思います。
これを解決するにはサーバ系ベンダーとの保守契約やデータセンターレベルでの保守契約となるとおもんですけど、その額や高額になることがあります。サーバ1台の24時間オンサイト、オフサイト監視・一時対応、OSレベルでのセキュリティーパッチ更新、までやると最低でも月額5〜10万円程度でしょう。
サーバ費用以外に、これは痛たたたた…。
そこで、
ベンダー系のガッチリした保守までとはいかなくとも、もサーバに障害が発生したときにソフトウェアレベルで自動的に復旧してくれたらなんていいだろう。そんなソフトは果たしてあるのか？
実は弊社がサーバ管理ソフトとして販売しているcPanelでできてしまうんです！
この機能はサーバ管理者しか知らなくて、今まではホームページに紹介することはありませんでした。
今回cPanelのページに、サーバ保守系のページを新たに作成し、サーバ保守に対しする格安なソフトウェアとしても利用いただけることがわかったのでこの際、社内のサーバ保守にご活用ください。
2008年7月29日 Skypeでのお問い合わせ - 遠方、海外のお客様の為に
今までスカイプというツールを社内部のコミニケーションツールとしての利用目的で使っていましたが、昨日からウェブサイトにもオンラインステータスを表示し、本格的にスカイプをお問合せのフロントラインとして使い始めました。
遠方や海外にお住まいの方で、対面での新規打ち合わせが現実的でないお客様はこちらをのページをどうぞ。
ＩＴ製品の場合、画面を見ながらサポートや商品の説明をしないと、相手に本当の理解は伝わりずらい。
お互いが同じ画面を見ながら、音声付で説明し、一緒に動作を体験することが、最も効率的な商品説明になると思います。
それにはスカイプがとても便利だと改めて感じます。
ＵＲＬを直接送ったり、画像ファイルを送るのにもドラッグ＆ドロップでできるので、これが電話だとＵＲＬを説明したりするのにも一苦労。。。
お問合せのページは次の通り。
新規のお客様の場合はこちらのような画像が表示されます。オンラインの場合、スカイプのオンラインボタンをクリックするだけで使えます。
サービスをご利用中のお客様はサポートセンターのページで部署を選択するときに、スカイプボタンを新設したので、直ぐに回答を求めたい時には役に立つと思います。
今回書いた海外、遠方のお客様をスカイプでサポートするという件ですが、会社案内のデジタルスタジオでは… にも追加しましたので、今後遠方のお客様にはぜひ活用いただければと思います。
2008年7月20日 時差のなくなるコンテンツ業界？
世界中のありとあらゆるコンテンツサービスにおいて、時差はますますなくなってきたと思う。
アメリカ発のベンチャー企業が何らかのWEB2.0的サービスを公開したとすれば、その1ヶ月後、2ヶ月後には日本の品質で同じサービスが生まれる。サー ビス品質（顧客サポート、画面デザイン、説明補足）は異なるものの、アイディアやロジックは全部アメリカ生まれのものになる。違うのは日本人の品質に直す 必要があるだけだ。 (more…)
2008年7月8日 ECサイトで販売機会の損失をしかねない5つの失態
最近ブラウザが新しくなったこともあり、Eコマースサイトのウェブサイトを徘徊しているとたまに、SSLの有効期限切れウェブサイトやSSLにインストールされたドメイン名とウェブサイトのドメイン名があっていなかった為にエラーが表示されたり、またウェブサイト上のあらゆる所に不適切と思われる個所がいくつか見つかったりするものです。
特にEコマースに関しては、自分が制作するサイトと比較しながら見てしまう癖がありますが、少なくとも確認したほうがいい事項があるので今回紹介しておきたいと思います。
1.コピーライトの日付が古い
ユーザーは意外にフッター領域にある Copyright © 会社名< 開始年” の文字列を見ることがあると思います。
この”年”の部分が古い場合（たとえば1995 - 2005）、
・このホームページに掲載されている情報は確かか？（正しいのか）
・この会社は本当にビジネスをやっているのか？
コピーライトの日付が古いだけでユーザーはウェブサイトを疑ってしまう可能性があります。
解決策
PHPプログラムを利用すると次のように書ける。
1995年から開始している場合
Copyright © 1995 - <?=date(”Y”)?> 会社名
次のように表示される
Copyright © 1995 - 2008 会社名
2.SSLがドメイン名と一致していない
SSLがドメイン名と一致していない場合、これは致命的です。IE7、Firefox3のどちらに関してもSSLのインストールしたドメイン名と実用しているドメイン名が違っていたり、SSLの有効期限が切れている場合、下記のような画面が表示されてしまう。
ユーザーがこの画面を見た時、もしかしたら以下のことを想像してしまうだろう。
・フィッシング詐欺にあったのか？
・インターネット回線のトラブルにでもあったのか？
・パソコンが壊れてしまったのか？
ここでこのユーザーはブラウザを閉じることは間違いない。今すぐSSLが正しくインストールされているかどうか確認しておこう。
3.配送方法、決済方法に関する視覚的表示（バナー画像等）をしていない
どのような方法で支払ができるのかをすべてのページに表示すべきです。ユーザーは会社案内やFAQのページなどは実はほとんど見ないです。
商品をクリックしたら、後は購入完了まで一直線にクリックするだけだ。その過程でユーザーが考えることは次の3つくらいしかない。
・何日で届くの？（納期について）
・送料はいくら？（送料について）
・支払方法は何？
クレジットカードのロゴマークや配送業者のロゴマークがあればユーザーは視覚的に理解でき、支払手続きをスムーズに進めることができる。
4.「カートに入れる」などの各ボタン類のデザインへの配慮
ウェブ2.0の流行があってか、ウェブサイト上に置かれるボタン類や素材になんでも影を付ける傾向がある。これはこれでウェブサイトを美しくしていることに違いはないが、ユーザーがそれをボタンであることを認識できないことがある。
そのボタンがどのような目的で存在しているのかをもう一度考えてデザインする必要がある。
ウェブ2.0系のウェブサイトではAJAXについても多用されている。ユーザーがAJAXのアクションを実行したときに、Loaddingしてページを読み込みしていることがわからないとユーザーはその先にあるページを見る前にページを閉じてしまうことがあるかもしれない。
これもAJAXを利用している場合（特にデータ量が多い読み込み）は改善する必要があるだろう。Loadingアイコン素材はこちら
5.貧弱なサイト内検索
Googleは今やとても有名で誰もが使う検索エンジンです。これはGoogleの検索能力の高さが証明しています。また1秒以内に結果をはじき出す高速性も重要です。
サイト内検索機能で、ユーザーがミススペルをしたときに補完語を表示できる機能はありますか？
もしない場合はGoogleをサードパーティーとしてサイト内検索に使うか、それに代わるサードパーティーを探すべきです。
今やユーザーはGoogleが示す「検索する」という傾向にあると思います。
 |  |  |  |  |  |  |
 |  |  |
