ウェブページ – 業務改善コンサルティング情報ブログ

Chrome68の警告に認識不足も

Shingo Takahashi — Fri, 20 Jul 2018 10:20:37 +0900

2月に投稿した『Chrome68は非HTTPSに警告』という記事でもご紹介した通り、来週の7月24日リリース予定のGoogleのブラウザ『Chrome 68』では、『非HTTPS』に対して全面的に警告が行われます。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

このブログでも何度となく取り上げてきた『WebのHTTPS化』に関して、2月にもお伝えした通り、Googleのブラウザ『Chrome』では全面的な警告が行われるようになります。

しかし、これに対する認識が不足している事業者もまだまだ残っているため、再度お伝えすることにします。

Chrome68では全面的な警告になる

以前からお伝えしている通り、Googleのブラウザ『Chrome』の『バージョン68』からは『非HTTPS』サイト（ページ）に対して全面的な警告表示を出します。

そのようになってしまう『Chrome 68』は来週の7月24日にリリース予定となっています。

現時点では、お問い合わせフォームなどのフォームに文字入力をした時に『！保護されていません』と警告するにとどまっていますが、来週リリース予定のバージョンではそうはいきません。

お問い合わせなどのフォームに文字入力するか否かは関係なくなり、シンプルに『非HTTPS』サイト（ページ）すべてに警告表示をするようになります。

これはGoogleのブラウザ『Chrome』に限った話しではなく、Mozillaのブラウザ『Firefox』においても同じ方向へ切り替わります。

あなたがそのウェブサイト（ウェブページ）を閲覧しようとするユーザー（訪問者）であった場合、それはどのように感じるでしょうか？

おそらく、大半の方は『危険』とか、『怪しい』とかのマイナスのイメージを持ってしまい、直ぐにそのサイト（ページ）から離れてしまうことでしょう。

それが自社や自店のサイト（ページ）にて起こってしまう。

つまり、『イメージダウン』、『信用低下』といったことを招くことになってしまいます。

それを回避する方法は1つしかありません。

ウェブサイト（ページ）を全面的に『HTTPS化（暗号化）』することです。

余談ですが、このような話しを何度お伝えしても理解を示さない方がおられるのも事実です。

おそらく、実際に何かが起きてみないと実感がわかないのだろうと思います。

ウェブページは速いほど高評価

Shingo Takahashi — Tue, 03 Jul 2018 11:39:57 +0900

あなたがユーザーの立場であった場合、ウェブページが表示される速度は速い方が良いですか？遅くても問題を感じませんか？

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

Googleが今月導入を予定しているアルゴリズムはウェブページの表示速度に関わるもので、やはり、ユーザーにとってより良い状態にあるものが評価が高くなるとされています。

ウェブページの表示速度は速い方が高評価

ウェブページの表示速度は、ある程度ストレスのない範囲で表示されているのであれば問題ないと判断されている方、今回のアルゴリズムは少々違うようです。

シンプルに、表示速度は速ければ速いほど高評価になるアルゴリズムが導入されるようなのです。

今までの場合、論外的なページ速度でなければあまり影響はありませんでしたが、今回は別です。

逆に言えば、パフォーマンス改善にも力をいれてきた方にとってはそれが報われる時が来そうです。

そして、Googleのスタッフは質問に対してこのようにコメントしたようです。

Q：ページ速度が速くなればランキングに良い影響を与えるのか？

A：多少影響する。

ということは、極論、同じ評価を受けていた2つのページが存在したとします。

その際、AのページとBのページに若干であっても表示速度に違いがあった場合、表示速度の速い方がランキング的に上に位置することになります。

どの程度変化していくのかはわかりませんが、いくつかの情報を見ている限りでは、少しずつ変化していく（評価が上がっていく）感じのようです。

まずはページ内の情報の質などがあっての話しではありますが、それ以外の加点項目があるというのは非常に良いことだと感じます。

ウェブの表示速度をさらに追求

Shingo Takahashi — Mon, 26 Mar 2018 11:30:48 +0900

このブログでも何度か取り上げていたかと思いますが、今の時代、ウェブサイト（ページ）の表示速度は結構重要な要素となります。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

最近、ウェブの表示スピードの話しがよくでるようになってきています。

理由は簡単です。

Google（グーグル）がウェブページの表示スピードにこだわっているところがあるからです。

Googleは、『スクロールせずに見える範囲のコンテンツは1秒以内に読み込まれるようにすべき』という見解をもっています。

1秒は1000ミリ秒ですが、『1秒以内に読み込まれるようにすべき』をクリアするには、非常に細かな部分にこだわって表示速度を追求する必要性があります。

数日前、『DNSプリフェッチでの速度改善』に関して書いた記事を覚えていますでしょうか？

それに近いものはありますが、もう1つの方法をお話しします。

ウェブの表示速度をさらに追求する

先日の記事にも書いた通り、昨今のウェブサイト（ページ）では外部リソースの読み込みが多くあります。

FacebookやTwitterなど、SNS系のプラグインを使っているのであれば間違いありません。

そして、先日ご紹介した『DNS prefetch（プリフェッチ）』は事前にDNS lookup（ルックアップ）を解決しておくものでしたが、それより少し先に行っているものがあります。

『preconnect（プリコネクト）』というものです。

この『preconnect』を指定した場合、DNSの解決、TCPハンドシェイク開始、TLSネゴシエーションを事前に行えるようにしてくれます。

では、実際にどのように記述するのか？

内に以下のような記述を加えればOKです。

ただし、『DNS prefetch（プリフェッチ）』と『preconnect（プリコネクト）』では若干ブラウザの対応状況が異なります。

例えば、ChromeとFirefoxはpreconnect、DNS prefetchのどちらにも対応していますが、IE11（internet explorer11）はpreconnectは現時点で対応しておらず、DNS prefetchには対応しています。

従って、メジャーなブラウザに幅広く対応しておくには、preconnect、DNS prefetch、どちらも記述しておく方が得策ですので、

という感じで、preconnectとDNS prefetchを併記しておくことも良いでしょう。

DNSプリフェッチでの速度改善

Shingo Takahashi — Thu, 22 Mar 2018 11:21:14 +0900

DNS prefetch（プリフェッチ）とは、ドメインの名前解決におけるDNS lookup（ルックアップ）を事前に解決しておくこと。これによって、外部ドメインを参照するリンクが多くある場合には速度改善に効果があるとされています。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

インターネット上の多くのウェブサイト（ページ）では、さまざまなリンクが貼られています。

その中でも、Google MapsやGoogle Analytics、FacebookやTwitterなどのSNSとの連携がある場合にはそれぞれの個別のスクリプトファイルを読み込んでいます。

これらにおいて、実行に必要なアクセス先のURLを参照する際に『DNS lookup（ルックアップ）』が発生します。

そのため、外部との連携がある場合においてはホスト名とIPアドレスの変換が生じ、ウェブサイト（ページ）の表示にロスが生じます。

では、それはどのようにして解決すれば良いのでしょうか？

DNSプリフェッチで速度改善を図る

前述のDNS lookup（ルックアップ）における表示ロスを改善するには、DNS prefetch（プリフェッチ）を用いて改善を図ることができます。

ウェブサイト構築によく用いられる『WordPress』においても、バージョン4.6以降からはそれが実装されています。

では実際の対処法ですが、内に以下のような記述を加えることになります。

（WordPress 4.6以降は自動挿入）

WordPress 4.6以降では、が自動挿入されるようになっています。

ただし、この『DNS prefetch（プリフェッチ）』による対処は爆発的な改善を及ぼすことはありません。

また、デフォルトではHTTPSページでホスト名をプリフェッチしないとされています。

（Googleのサイトには未だDNS prefetch（プリフェッチ）の記述が残っていますが。。。）

私が試した限りでは、速度測定サイトにおけるスコアが＋１～＋３アップする程度ではありますが、ごくわずかな変化はありそうです。

現在、ウェブの高速化は軽視（無視）できない時代になっていますので、少しでも速度改善を望まれる方は一度試してみるのも良いでしょう。

Yahoo!カテゴリがついに終了

Shingo Takahashi — Tue, 04 Jul 2017 12:01:25 +0900

以前、『dmoz.orgが利用できなくなる』という記事にも書いた通り、登録型ディレクトリサービスの1つであるDMOZは終わりを告げました。

次はもっとよく知られているサービスまでが。。。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

冒頭でも書いた通り、DMOZは3月に終わりを告げました。

それに続き、Yahoo!（ヤフー）もディレクトリサービスである『Yahoo!カテゴリ』を2018年3月29日に終了すると発表しました。

また、Yahoo!カテゴリの終了発表に伴い、Yahoo!カテゴリへの登録審査サービスである『Yahoo!ビジネスエクスプレス』も2017年7月31日に終了となります。

さて、最大級の登録型ディレクトリサービスが2つ終了となり、これから先はどのように変化していくのでしょうか？

Googleなどの検索エンジン主流の時代

『dmoz.orgが利用できなくなる』でも書いたと思いますが、DMOZやYahoo!カテゴリなどの登録型ディレクトリサービスは、現代においては普通のリンクの1つに過ぎなくなってしまいました。

その昔はSEO的にも価値はあったのですが、今ではそのような特別な価値はなくなっており、Google、Yahoo!、Bingなどの検索エンジンが主流の時代となっています。

それもあり、Yahoo!においても『Yahoo!カテゴリ』は役目を終えたと考えたのでしょう。

こういったことからも分かる通り、昔は運よくディレクトリサービスに登録されていたことが功を奏していたものも、今では全く影響しなくなっています。

つまり、そういったものを頼っただけのウェブサイトではダメということです。

本来のあるべき姿に今はなり、良質な情報が掲載された、ユーザーに優しいウェブサイト（ウェブページ）であることが重要な時代になっています。

Chrome56で警告表示が始まる

Shingo Takahashi — Fri, 27 Jan 2017 12:49:08 +0900

日本時間の1月26日（米国現地時間の1月25日）、Googleはウェブブラウザの新バージョンとなる『Chrome56』（バージョン56.0.2924.76）をリリースしました。

皆さん、こんにちは。

業務改善を行う業務コンサルタント、高橋です。

先日投稿した『Google Chromeが警告を出す』でもお伝えしたとおり、Googleは新ブラウザのChrome56にて新たな変更を加えてきました。

やはり、予定通り保護されていないウェブサイトへの警告表示を出すようになりました。

Chrome56が出す警告表示

今回のChrome56における警告表示は、ある動作をさせるウェブページに限定されています。

それは、パスワードを入力させるページにおいて警告表示を出すというところにとどまっています。

従って、主にはネットショップ（インターネット通販）サイトにおいて、会員がパスワード入力をするような内容が含まれたページにおいてのみ、ウェブの暗号化を求めたようです。

※　まだ第一段階ですので、今後は他へも展開していきます。

このようなウェブページの場合、アドレスバーのURLの先頭に『！保護されていない通信』という表示がされるようになっています。

例：！保護されていない通信｜http://www.example.com/といった状態になります。

Chromeでのその他の表示

前バージョンのChrome55あたりから、その他の表示もされるようにはなっています。

『！』マークのみの情報表示：これは、プライベート接続（暗号化されていない/httpsではない）ではないことを意味します。

日本においては、このマークが表示されるウェブサイトが大半かもしれませんが、個人情報などの機密情報を入力しないように注意する必要があります。

『?保護された通信』の表示：これが現状でもプライバシー保護がされたウェブサイトである場合の表示です。

現段階において、この表示がされているものが安全性の高いウェブサイトであると認識して良いでしょう。

以前から申し上げておりますが、近い将来すべてのウェブサイトに対して常時SSL化が求められるようになります。

早い段階にて行われることをお勧めします。

追伸：現在、GoogleのChromeはウェブブラウザのシェアでNo.1であることを念頭に入れておいてください。

PHP7.1でパフォーマンス向上

Shingo Takahashi — Tue, 27 Dec 2016 11:09:39 +0900

WordPressなどのCMSを使ってウェブサイトを構築している事業者は多く見受けられますが、これからはさらにパフォーマンスが求められる時代になる可能性が高いです。

皆さん、こんにちは。

業務改善を行う業務コンサルタント、高橋です。

以前、昨今のウェブ事情はパフォーマンス、つまり快適な表示スピードが求められる時代であることを記事に書かせていただいたかと思いますが、今後はそれがさらに求められる可能性が高くなっていきます。

その理由は簡単で、表示速度が遅いウェブサイト（ウェブページ）は誰しもが直ぐに離脱してしまうことにあります。

そこで、今日はWordPressを動かすプラットフォームのお話しをさせていただきたいと思います。

PHPのバージョン選択

以前にも『PHPを使う際のレンタルサーバ』の記事の中でPHPに関しては書かせていただきましたが、PHPは5.×.×よりもPHP7.×.×の方がパフォーマンスが良いです。

PHP5.6.×とPHP7.0.×を比較した場合、かなりのパフォーマンス向上が見られることがわかりました。

また、ここ最近ではPHP7.0.14とPHP7.1.0が12月にリリースされ、前者と後者では、後者の方が若干ではあるものの、さらにパフォーマンス向上がなされています。

これらから考えると、契約しているレンタルサーバにPHPのバージョンの選択肢があるのであればPHP7.1.0を選択することが一番良いパフォーマンスが望めます。

※ WordPressはPHP7に対応していますので、最新のWordPressを使われているのであれば正常に動作します。

モジュール版、FastCGI版、CGI版

さらに、PHPにおいてはモジュール版、FastCGI版、CGI版、3つの提供方法がありますが、これらのパフォーマンスは、同一バージョンであればモジュール版、FastCGI版、CGI版の順になりますが、バージョンが異なる場合においてはその限りではありません。

PHPのバージョンが5.×.×であるならば、それがモジュール版として提供されていたとしてもPHP7.×.×のCGI版の方がパフォーマンスが良いです。

それだけPHP7はパフォーマンスが向上したということです。

まとめますと、PHP7.1.0CGI版＞ PHP7.0.14CGI版＞ PHP5.6.29モジュール版ということになります。

ちなみに、PHP7.1.0CGI版＜ PHP7.0.14モジュール版（FastCGI版）ということになる可能性はあります。

是非試してみて下さい！

注：必ずテスト環境にて動作を確認し、問題ないと判断された時点で本番環境の変更を。

警告表示SHA-1からSHA256へ

Shingo Takahashi — Mon, 21 Nov 2016 10:39:56 +0900

このほどGoogleは、危険性が指摘されているハッシュアルゴリズムの『SHA-1』に対し、2017年1月末にリリース予定の安定版WebブラウザChrome56から同証明書のサポートを完全に打ち切ると発表した。

皆さん、こんにちは。

業務改善を行う業務コンサルタント、高橋です。

『SHA-1』という言葉はあまり聞きなれない方もおられるかと思いますが、『SHA-1』とは暗号化に使われるハッシュ関数（テキストデータから別の固定長のテキストデータ（ハッシュ値）を生成する関数）の種類のことで、これはウェブの世界では暗号化を用いるhttpsの証明書に使われたりしています。

しかし、『SHA-1』のハッシュ値は160ビットと短く、データが発見される可能性が高くなり、安全性が低下することが指摘されています。

SHA256の証明書を使え

前述の理由から、昨今においては『SHA-1』ではなく、『SHA256』が推奨されるようになっています。

『SHA256』は『SHA-2』の1つで、『SHA-1』に比べてハッシュ値が長いことから、現在では『SHA256』が推奨されています。

これを踏まえ、大手が取り扱う電子証明書においては順次『SHA-1』証明書の受入を中止していく方向にあります。

GhromeブラウザのSHA-1サポート打ち切り

これらの流れを受け、Chromeブラウザにおいても『SHA-1』の証明書のサポートが来年リリースされるChrome56から打ち切りになります。

大半の電子証明書においては『SHA256』に移行されている流れもあり、これによって影響の出るウェブサイトは限定的とも言えます。

しかし、まだ『SHA-1』の証明書を使い続けているウェブサイトにおいては『SHA256』に切り替える必要があるとも言えるでしょう。

これらの証明書においては、『SHA-1』から『SHA256』への切替を無償で行っていますので、年内にはそれらの再発行手続きを終えておくことが無難です。

また、マイクロソフトにおいても『SHA-1』の証明書の受入を2017年1月か2月には完全に終了してしまうため、『SHA-1』のまま放置してしまうとウェブページに良くない影響が出る可能性があります。

この先、コンピュータの処理能力はまだまだ向上していきますので、先々はもっとハッシュ値の長いものへの切替も必要になってくることが予想されます。

これらの情報を随時チェックし、適切に安全なウェブサイトを保てるように心掛けてほしいものです。

HTTPS化率が低い日本人の意識

Shingo Takahashi — Tue, 15 Nov 2016 11:29:29 +0900

Googleは、Google Ghromeユーザーから送信された使用統計情報を使ってHTTPS接続の普及状況を追跡した。

また現在、Google Chromeの利用率はMicrosoft Internet Explorerを抜いて1位のシェアがあり、全体の40%以上ものユーザーがいる。

皆さん、こんにちは。

業務改善を行う業務コンサルタント、高橋です。

このブログにおいても何度か取り上げたウェブのHTTPS化に関して、少々興味深い記事を読みましたのでご紹介します。

それによると、『HTTPS ページの閲覧時間はウェブの利用時間の3分の2』に及んでいるのですが、国別の状況を見ると日本はそうでもありません。

HTTPS化に対する意識の低さ

国別の状況を見ると、日本においては他国の1/2程度しかHTTPS経由で読み込まれていません。

実際には、他国が43%～60%程度にまで普及してきているのに対し、日本では21%～32%程度にとどまっています。

これは世界的に見て非常に低い数字で、昨今さまざまなウェブに対する脅威が急増している中、やはり日本においては遅れをとっている感が否めません。

これは日本人の安全性に対する配慮が不足している気もします。

ユーザーファーストであれ

HTTPS化を行うにあたっては当然対応コストがかかりますが、それに対して中小企業や小規模事業者においてはHTTPS化の予算が確保できないのかもしれません。

しかし、ユーザーのプライバシー保護の観点からしても非常に重要なことであるため、是非ともHTTPS化への対応を進めていただきたいものです。

また、GoogleがHTTPSページをHTTPページよりも優先表示することに取り組んでいるのも、ウェブページであってもユーザーファーストでなければならないことからでしょう。

この先、ChromeブラウザはHTTPサイトへの警告表示も予定しています。

となると、それに直面したユーザーへのイメージは悪くなることになります。

今からでも遅くありません、HTTPのままであるウェブサイトは1日も早くHTTPS化されるようお勧めします。

モバイルへの対応が徐々に加速

Shingo Takahashi — Wed, 09 Nov 2016 11:41:33 +0900

Googleが、Mobile First Index（モバイルファーストインデックス）の導入を正式にアナウンスしたことにより、今後はモバイルの世界において順次変化が起きてきそうです。

皆さん、こんにちは。

業務改善を行う業務コンサルタント、高橋です。

Googleは、先週末の公式ブログにて『モバイルファーストインデックスに向けて』と題した記事を投稿しました。

そこからすると、従来PC向けページの評価に基づいてモバイル向けページの評価がされていたのが、主にはモバイル向けページの評価に基づいてランキング決定されるようになると書かれています。

その背景にはいったい何があるのでしょうか？

モバイルユーザーの急激な増加

Googleの判断として、最近におけるGoogle検索使用ユーザーのほとんどがモバイル端末によるものとしています。

つまり、スマートフォンなどの普及により、PCでの検索よりもモバイルでの検索が急激に増加したということです。

しかし、現在のGoogleのランキングシステムは主にPC向けページによる評価になっているため、モバイル向けのコンテンツがそれよりも少ない場合においては問題が発生してしまうのです。

これらの背景からGoogleは、モバイル検索におけるランキング決定はモバイル向けページの評価に基づいて行おうとしているのです。

モバイル対応が急務になってくる

現在、まだまだモバイルへの対応がなされていないウェブページは多く存在します。

しかし、ライバルがモバイル対応していて、自社がモバイル対応していないのであればアドバンテージを取られてしまうことになってしまいます。

もちろん、既にモバイル対応しているところであれば特別気にする必要性はないですが、まだモバイル対応がなされていないのであれば対応は急務になってくると認識した方が良いでしょう。

また、モバイル対応される場合、PC向けのページと同等の対応をしないとライバルに負けてしまう可能性があります。

いつも申し上げておりますが、ウェブサイトにおいてもユーザーには優しいものである必要性があります。

モバイルの利用者がこれだけ増加してきた今、モバイルユーザーに優しいウェブサイトでなければいけないと考えるのは自然なことでしょう。