after work Lab

好きな事だけをお勉強させていただきまーす

便利でおしゃれなOXOの野菜水切りサラダスピナー

はじめに

 

おひさしブログです。

 

つまらないダジャレをつぶやいてしまいましたが、今回紹介する記事はアングルドメジャーカップで有名なOXOの野菜の水切りサラダスピナーに関するものです。

 

回転式の水切りボールはたくさん種類がありますが、OXOのサラダスピナーは人気ベスト3に入っている製品です。

 

水を切るだけであれば手回しのハンドルをガンガン回す構成の物で十分ですが、あまりおしゃれな感じはしません。

 

テーブルに置いたり冷蔵庫に収納することを考えると、OXOのサラダスピナーが一番バランスが取れているのではないでしょうか。。。

 

これから説明するのは1年前に買い換えたサラダスピナーに関する考察で、OXOのサラダスピナーで作るおいしいサラダの説明ではありませんのでご了承下さい。

 

サラダスピナーの買い換え

OXOのサラダスピナーの値段は決して安くはありません。老朽化したサラダスピナーの買い替えを検討してましたが、単品だと高いのでなかなか手を出しにくい状況でした。

 

しかし、セットで安売りされているものをかみさんが見つけ、即お買い上げとなりました。定価で買うと6000円を超えますがが、セットのセール品なので半額以下の3000円でした。

 

セール品の中身

大きな紙袋から出てきたのはOXOの調理用品で4種類計5点でした。

 

2 pc Mini LockTop Container Set (120 ml) 

ロックトップコンテナ スモール2ピースセット

 

LockTop Container Small Square - 1.7 Cups

ロックトップコンテナ 0.4L Sスクエア 

 

Angled Measuring Cup - 2 Cup

アングルドメジャーカップ(中)

 

Little Salad & Herb Spinner

クリアサラダスピナー(小)

 

OXOは主婦に割と人気がありますが、我が家も昔から何種類か使ってます。

 

使用頻度が高いのは野菜の水を切るサラダスピナーですが、我が家のサラダスピナーはかなり老朽化が進んでおり、カバーの内側に固定されるフタの爪は2/3が欠けてます。

 

あと一カ所欠けると、ボウルの中のバスケットが回転できなくなり埋め立てゴミとなります。

 

また斜め上から目盛が見えて便利なアングルドメジャーカップは壊れてはいませんが、かなり白化が進んでいます。

 

なぞなぞ 

アングルドメジャーカップを新製品と旧製品を並べてみると外観のデザインは変わってませんが、ある部分に違いがありました。

 

皆さんどこが違うかわかりますか。

 

答:cupsの目盛が違うのです。

 

旧製品はアメリカ規格で1カップ:約237mlの目盛となってますが、新製品は日本規格で1カップ:200mlの目盛でした。

 

粉物やお米は計量カップで計って入れてましたが、味がいまいちだったのは入れる量が違っていたのが原因だったかも知れません。

 

今回軽量カップを買い替え、両方を見比べたので気づくことができました。(笑)

 

サラダスピナー

サラダスピナーは旧型は外観がボウル状ですが、新型は円筒形でスタイリッシュな形に変わってました。フタもフラットなのでサラダスピナーの上に物を置くことも可能です。

 

フタを外した状態です。野菜を入れるバスケットは円筒ドラムです。

 

フタです。フタにはバスケットを回転させる内カバーが取り付けられてます。内カバーは中央の白いロッドを押すとロックが解除され簡単に外せます。

 

内カバーを外した状態です。

 

直径は旧型:φ210cm→新型:φ20.5cm、高さは旧型:13cm→12cmに小型化されてました。重量は強度を増した関係で約500gから約674gに増えてます。

 

普通はここでレビューが終わるのですが、OXOのサラダスピナーはなぜデザインが変わったのか気になりました。

 

見た目は新型の方がカッコイイと思うのですが、円筒ドラムは回転が安定しない形状なので水切り器の性能として評価すると低下しているはずです。

 

実際Amazonのレビュを見ると、新型は旧型に比べ回転スピードが低い為か、
水切り力が今一つで不満を持っている方が若干名いらっしゃいました。

 

ところでOXOのサラダスピナーは片手で押すと中のボウルが回転し水切りできるので、このポンピング機構に関してpatentを出しているだろうと米国特許を調べてみました。

 

サラダスピナーの特許

初期型のサラダスピナーのPatent NumberはUS6018883で、
1999年2月18日に出願されてました。後数年でこの特許は切れますね。

Goggle君の迷訳を読んでみると、予想を大きく裏切る内容でした。

 

発明の名称は「Brake for device for drying foods」食品乾燥装置用ブレーキです。

 

ボウル内部のバスケットの回転を停止させるブレーキに関する発明でした。

 

OXOのサラダスピナーは、中央のノブを片手でポンピングして回転できるのが最大の特徴と思っていたのですが、Claim(請求項)の構成要件にはありませんでした。

What is claimed is: 1. A device for drying food comprising:
a container including a bowl having a sidewall terminating at a top edge defining an opening and a cover removably connected to the bowl and substantially covering the opening;
a basket assembly disposed in the bowl and rotatable relative to the container about an axis, the basket assembly including a basket having a sidewall terminating at a top edge and a lid releasably coupled to the top edge of the basket; and
a brake assembly carried by the cover and engageable with the lid to apply a frictional force to the lid for stopping rotation of the basket assembly.

 

何とサラダスピナーの最大の課題はポンピングで回転させることではなく、回転をすみやかに止めることだったのでした。

 

これは目から鱗でした。

 

ハンドルで手回しするサラダスピナーでは想像できませんが、押したら惰性で周り続けるバスケットを安全に止めるブレーキ機構をフタに付け、回転を止めることがOXOのサラダスピナーの最大の特徴だったのです。

 

ポンピング回転機構ではブレーキは必須の構成部品なので、これで特許が取れたのだからとても強いですね。

 

ただかブレーキ、されどブレーキです。

 

新製品の発売に合わせてpatentも出願されてます。これを時系列に調べていくと新製品はブレーキ機構が小改良されているのですが、patentは従来例に対してこの改良された構成で新規性・進歩性を出しているようです。

 

US6018883 …1999年2月18日出願

フタが白色の初期型はフタのボタンを押すと、ボタンの先端のボスが回転する内フタのトップに接触し、摩擦力で止める構成となってます。

US7448315 …2005年3月17日出願

これはサラダスピナーのフタが透明に変わった商品のブレーキです。

より摩擦力を上げる為、回転するフタの上部に摩擦力が高いエラストマー接触面の軌道に設けたものです。

US20120246959 …2011年3月28日出願

これが新型のブレーキ機構で、ボタンを押すと回転する内フタの円周リブを両側からクリップする構成となってます。

ブレーキを押した状態

以上、超簡単でしたがOXOのサラダスピナーの特許の説明でした。

 

サラダスピナーのブレーキの基本特許はもうすぐ切れます。第三者は似たものを発売してくることになるのですが、新しい特許があるから大丈夫とは言えません。

 

OXOが提案している新しいブレーキ機構は容易に回避できるからです。簡単に言えば独自構成のブレーキを付ければよいのです。

 

三者はOXOもどきのサラダスピナーを半額くらいで作ってくるでしょう。そうなるとコスト競争で負けてしまう構図になります。

 

新しい付加価値を持った商品の開発が必要ですね。

 

では最後にきれいなお姉さんが解説する新型のサラダスピナーの動画をおまけに載せておきます。

OXO Salad Spinner

 

 

♡いいねはこちら

この記事が「面白かった・参考になった」と感じた方は、♡いいねを押して頂けると嬉しいです。

 この記事のツイートを♡いいねする

 

それでは今回の記事はこれでおしまい。

 

余談

実は新しいサラダスピナーで1つだけ困ったことがありました。旧型はボウル形状だったので、使わない時は他のボウルに重ねて収納できたのですが、新型は円筒ドラム形状の為、他のボウルに重ねることが出来なくなりました。

 

余分な保管スペースが必要になったのが唯一の欠点です。

 

便利でおしゃれなOXOの野菜水切りサラダスピナー

お知らせ

 

この記事はURLを変えました。

 

12秒後、新URLにリダイレクト(自動転送)されます。

 

もしリダイレクトされない場合は下のブログカードをクリック下さい。

便利でおしゃれなOXOの野菜水切りサラダスピナー - after work Lab

はじめに サラダスピナーの買い換え セール品の中身 2 pc Mini LockTop Container Set (120 ml) LockTop Container Small Square - 1.7 Cups Angled Measuring Cup - 2 Cup Little Salad & Herb Spinner なぞなぞ 新サラダスピナー サラダスピナーの特許 US6018883 …1999年2月18日出願 US7448315 …200...日出願 ♡いいねはこちら 余談 はじめに おひさしブログです。 つまらない…

ブログのカスタマイズが超快適になる方法

はじめに

 

冒頭いきなりですが、最初に少しお注意点を知らせします。

注意1

この記事はブログのカスタマイズが超簡単になる方法ではりません超快適になる方法ですのでお間違えないようお願い致します。

 

 

超快適になる方法ですが、一言でいうと「SCSS+Browsersync」の活用です。

 

実際に出来るようになった状態のスクショをお見せします。

下の画像はSCSSを保存すると自動でCSSコンパイルされ、自動でブラウザがリロードされる様子です。(画像は軽くするためGIFデータは間引いてます)

今までCSSを修正しブラウザを更新するまで最短で約30秒かかりましたが、たったの1秒以下になります。もう感激ものです。 

 

おススメの読者

この記事の方法はブログのカスタマイズ経験ゼロ&黒画面が苦手なガチな「初心者」にはハードルが高いと思います。

そのような方はあわてて自動化する必要はありません。

記事を書くことに専念し、カスタマイズに興味がで出てきたら弄ってみて下さい。

 

「ブログをもっとカスタマイズしたけどガッツリやるのは面倒くさい」と思っている「初心者」や、SCSSに興味を持っている「初心者」にはオススメです。

 

自動化できるまで少し大変ですが一度環境を作ってしまえば、超ラクチンなので後戻りできなくなるかも知れません。時間を作って是非一度お試し下さい。

 

ではここに至った背景を説明します。

 

なぜカスタマイズするのか

サイト閲覧者の利便性・操作性を向上し、かつ独自のカラーを出すことで他のブログと差別化したいからです。

 

と言うのは建前で、今のデザインに少し飽きてきたからです。

 

自分自身がメインの閲覧者なので、多少センスが悪かろうと自分好みにカスタマイズできれば、ブログを少しでも長く続けることが出来るのではと思ってます。

 

また、前々から少し気になっていたことが3つあります。

 

その1

過去このブログで「表示スピードが速いデザインとは」や「あなたのサイトは問題ゼロのRWDですか?」とか、自サイトのことは脇に置いといて偉そうに解説しました。

www.heavy-peat.com

www.heavy-peat.com

 

 

たくさんの方からお褒めの言葉を頂いたのですが、大きな改善は出来てません。

書きっぱなしで自分で実践してないと単なる評論家ですよね。

 

その2

10月29日にブログ名を「Bumble-Bee」から「after work Labo」に変更したのですがサイトのデザインは変えませんでした。

 

ブログ名変更後、時間が経つにつれ「何の為に変えたんだっけ?」「意味あったかなー?」と思うようになりました。(汗)

 

店構えや店内の調度品・メニューは全く変わらないいのに店名だけ変わるのは、やっぱり変ですよね。

 

サイトの大幅な改変ははてなブログSSL化に合わせてやればいいやと後回しにしてましたが、いつ移行するのか不明確です。

 

その3

この記事で説明する自動化は、細かい方法は違いますがすでに先人が実施済で下記サイトでやり方が公開されてます。

 

クリアメモリさん

www.clrmemory.com

 

偽名さんblog.gmork.in

 

最初先人の方法を見た時「あっ。これ素人にはムリ。Windowsで出来るかわからない」とあっさり見送りました。

Windowsで実践したはてなユーザの登場を待ちましたが、そのような記事を見つけることはできませんでした。

 

どんなデザインに変えたいのか?

シンプルでモバイルファーストなレスポンスシブデザインを目指します。トップページはカード型のカスケードレイアウトで記事は1列1カラムをイメージしてます。

 

理由はブログの閲覧は圧倒的にモバイル端末が多いからです。

 

今利用しているテーマはminimalgreen様の「Minimal Green」です。レスポンシブデザインですが2カラムなので”あトん”の理想とは一致してません。

 

1カラムへの修正は可能だと思いますが、上手く行かなかった時に作者さんに問い合わせるのは避けたいので「Minimal Green」のさらなる大改造は断念しました。

 

理想に近い投稿テーマの探索

はてなブログのテーマストア内をリサーチしてみました。

テーマ ストア - はてなブログ

はてなブログのテーマストアには241個のテーマが公開されてます。(2017年12月時点)

 

1カラムのテーマは74個で全体の約31%でした。その中でライセンス上改変できるテーマは31個で全体の約13%です。更にレスポンシブ対応のテーマに絞ると9個で全体の約4%でした。

 

最後にこの9個の中で理想に一番近いと思ったデザインは、rokuzenudonさんが公開したテーマ「Thumbnail」でした。

blog.rokuzeudon.com

 

「Thumbnail」の解説を読むと、はてなブログのカスタマイズ用テンプレート「Boilerplate」をベースに作っれたと書かれてありました。

 

「Boilerplate」とは何ぞやと思い該当サイトを見ると以下の解説がありました。

Boilerplate は、はてなブログのデザインCSSカスタマイズの土台に適したデザインテーマです。

 

はてなブログの必要最小限の見た目が調整されています。このテーマをもとにしてCSSを書くと比較的楽にデザインテーマが作れます

「オリジナルテーマの制作にチャレンジしたいけど、0から作るのが大変」という方は、このデザインテーマをもとにしてCSSを書くと比較的楽にテーマが作れます

 

楽に作れます」と2回も連呼してますね。はてながそんなにお勧めするのなら「Boilerplate」を利用する価値あるかも、と思い始めました。

 

「案ずるより産むが易し」どうせブログをカスタマイズするなら「Thumbnail」を見本にさせて頂き"あトん"のオリジナルテーマが作れちゃうかも、と考えました。

 

しかし実際は「言うは易く行うは難し」でした。。。(後半で詳細を説明します)

 

「Boilerplate」の調査

「Boilerplate」はGitHubで公開されてますが、2つバージョンがあることが分かりました。

v1:Hatena-Blog-Theme-Boilerplate-Less

「Boilerplate」のv1は2013年3月27日に公開されました。

staff.hatenablog.com

スタイルシート言語はLESSで「boilerplate.less」「_mixin.less」「_variable.less」「_media-queries.less」「_normalize.less」の5つのファイルで構成されてます。

 

v2:Hatena-Blog-Theme-Boilerplate

「Boilerplate」のv.2.0.0は2017年10月12日に公開されました。(以下v2と略します)

staff.hatenablog.com

v.2での主な変更点は「レスポンシブデザインに対応」「スタイルシート言語がLESSからSCSSに変更」「Autoprefixer対応」「Browsersyncによる自動リロードの対応」でした。

 

スタイルシートは「boilerplate.scss」「_core.scss」「_variable.scss」の3つのファイルで構成されてます。

 

では、どのバージョンの「Boilerplate」を選択すれば良いのでしょうか。

 

v1ははてなユーザの利用実績はあるようですが、v2は見かけません。

 

そもそもLESSとSCSSは何が違うのか知りません。また、Autoprefixer、Browsersync等、今まで聞いたことがない専門用語もさっぱりわかりませーん。

 

そこでザックリと調べてみました。

 

Sass(SCSS)とLESSの違い

 

「Sass」

Syntactically Awesome Stylesheetsの略で「構文的に素晴らしいスタイルシート」という意味だそうです。

 

2006年に開発されたスタイルシート言語で、記述スタイルはSASS記法SCSS記法があり、それぞれの拡張子は.sassと.scssです。

 

SASS記法セレクタやクラスの後の括弧{ }や値の後ろのセミコロン;を省略し、インデントで依存関係を示します。

 

簡略化した記述ができる為、慣れるとすごいスピードで入力できるようです。

 

「SCSS」

はSassy CSSの略で「SassのようなCSS」とでも言えばよいのでしょうか。

 

SCSS記法は括弧{}を使い入れ子構造で依存関係を示します。書き方はCSSとほとんど同じなので広く普及しておりSassの主流になっているそうです。

 

Sass≒SCSSと思ってよいのではないでしょうか。

 

「LESS」

Leaner CSSの略で「効率的なCSS」という意味だそうです。2009年に開発されたスタイルシート言語で、拡張子は.lessです。

 

「Sass」と「LESS」は変数や関数が使え「CSS」を拡張したメタ言語と呼ばれてますが、「Sass」の方がよりプログラミング言語の様相が強いようです。

 

下記サイトで記述と機能の違いが比較されているので、詳しく知りたい方はご参照ください。

CSS拡張メタ言語「SCSS(Sass)」と「LESS」の比較 - (DxD)∞

 

"あトん"の印象ですが、「Sass」のSASS記法は1構文につき{}2文字を削減できるメリットがありますが、必ず改行しインデントで整えないと見づらくなるのがデメリットだと思いました。

 

「LESS」は「Sass」より後に開発されたのに機能が少ないのが残念だと思いました。

 

これから学習する初心者は「Sass」のSCSS記法がベターだと思います。

 

Autoprefixer

Autoprefixerを理解するにはCSSの歴史を理解しておくと分かりやすいので、CSSのレベルの進化について少し解説します。

 

CSS

CSSCascading Style Sheetsの略で1994年にホーコン・ウィウム・リーにより提唱されたそうです。

 

同年ティム・バーナーズ・リーによりW3CWorld Wide Web Consortium)が設立され、1996年にCSS1.0、1998年にCSS2.0が勧告されました。

 

Windows95が発売されたのは1995年ですが、1996年のIE3よりCSS1.0がサポートされてます。

 

CSSの策定プロセスは、FPWD(初期草案)→WD(草案)→ LC(最終草案)→ CR(勧告候補)→ PR(勧告案)→ REC(勧告)の6段階になってますが、CSS2.0の改定版のCSS2.1が勧告されたのは何と13年後の2011年です。

 

現在CSSはモジュール毎に仕様が策定されている為「CSS3」という標準自体は存在しません。

 

CSS2.1を拡張したレベル3を総称して「CSS3」と呼んでいるそうです。「CSS4」も同じ考え方です。

 

各モジュールのレベルとプロセスの進捗は下記サイトで確認できますので、気になる方は覗いてみてください。

www.w3.org

 

Autoprefixerとは

モジュール毎にレベルや策定プロセスの進捗がバラバラだと、ブラウザの種類やバージョンによって対応済のものと未対応のものが出てきます。

 

これらをCSSで細かく定義・修正するのはとても大変な作業ですが「Autoprefixer」を使うとベンダープレフィックスを適切に自動で付与することができます。

www.npmjs.com

「Autoprefixer」はまだ使ったことがありませんが、大変便利なツールだということが分かりました。

 

Browsersyncとは

「Browsersync」はファイルの変更を監視し、変更を検知すると自動で複数のブラウザのリロードを行ってくれるツールです。

 

例えば、スタイルシートを編集・更新すると、PCとiPhoneのブラウザの両方が同時に自動更新されます。

 

また、PCのブラウザを操作しスクロールさせると、iPhoneのブラウザも同期してスクロースします。その逆も出来ます。

 

面白くて大変便利そうですね。

www.npmjs.com

 

百聞は一見にしかず「Browsersync」の凄さが分かる動画を貼っておくのでまず見て下さい。

cssを変更したら自動でリロードしてくれるBrowsersyncが超便利!

 

この動画ではBrowsersyncの話は3:10以降に登場します。

Cross Device Testing, Totally Tooling Tips (S2 Ep6)

 

どうです、凄いですよね。えっ!Webデザイナーは当たり前に使っているよ、と言う声が聞こえてきますが、はてなブログでこれが使えたらどうなるのでしょうか。

 

「Browsersync」を使用すると、はてなブログでは①~⑦の作業をすべて廃止でき、作業が30倍速くなります。

 

CSS修正→①管理画面に入る→②デザインを選択→③カスタマイズを選択→④デザインCSSを選択→⑤修正したCSSをコピペ→⑥変更を保存→⑦ブラウザを更新


前半のまとめ

Boilerplateのv1とv2を比較した結果、以下の理由でv2を使ってカスタマイズすることに決めました。

 

スタイルシートの変更を検知し自動リロードしてくれる「Browsersync」はメチャ便利そう。

しかも、複数のデバイス(PCの複数ブラウザ、スマホのブラウザ)が同期するのでモバイルのテストも同時にでき凄い!
・プログラムライクなことは苦手ではないので「LESS」より「SCSS」の方が使い勝手が良さそう。
・Autoprefixerはあると便利そう。
・レスポンシブ対応はうれしい。
・normalize.cssはv1はv3.0.1だがv2は常に最新バージョンが読み込まれる。※

※normalize.cssは使わない不要な部分もありますが、ド素人が勝手に削除するのは時期尚早なので、内容が理解できてからコンパクト化を考えます。

 

それでは長い後半です。「Boilerplate」のv.2.0.0の動かし方について解説します。

 

「Boilerplate」v.2の動かし方

まず後半の注意事項です。

 

注意2

無知なまま適当に作業したので、途中何度も上手く行かなくなり泣きそうになりました。

 

無謀な初心者が同じような落とし穴に落ちないよう、失敗した内容と対策の内容を隠すことなく書きました。

 

その為、後半の記事は前半の3倍あります。

 

ご存じの項目があれば、遠慮なく飛ばし読みして下さい。

 

また、じっくり読む時間が無い方は、とりあえずブックマークしておいて、後で読むことをオススメします。

 

なお、最終的にはてなが説明した方法では動かなかったので、自己流で動かした方法を説明します。

 

はてなには質問を投げてますが、回答が来たら答え合わせしたいと思います。

 

セットアップ方法

BoilerplateテーマはGitHubの下記サイトで公開されてます。

github.com

 

セットアップの方法はREADME.mdに書かれてました。

SCSSで開発する場合は、下記の手順でリポジトリのcloneとモジュールのインストールを行います。

 

リポジトリのcloneとは何のことかよくわかりませんが、Node.jsというJavaScriptをインストールし、意味不明の呪文を3行入力すれば良いと勝手に解釈しました。 

 

しかし、分からないことはしっかり調べてからやるべきでした。(反省)

 

Node.jsのインストール

下記サイトでインストーラをダウンロードします。

https://nodejs.org/en/

LTSバージョンをダウンロード 

※ すべて上手く行った後、Currentバージョンも試しましたが、”あトん”の環境ではnpm start後エラーが発生し動きませんでした。

インストーラを起動し次にすすみます

ライセンスは一応読んだことにして次にすすみます

インストールするフォルダを決定します

デフォルトのままで次に進みます

インストールを実行します

インストール中(数分)

無事完了しました

 

バージョンの確認

Windowsコマンドプロンプトで下記コマンドを実行し、node.jsとnpmのバージョンを確認します。

node --version
npm --version

 

nodeはv8.9.3、npmはv5.5.1であることが確認できました。

 

もしコマンドプロンプトの使い方が分からない方は下記記事を参考にして下さい。

www.heavy-peat.com

 

と、順調に出来たのではここまでで、次から気の遠くなるような苦難の連続でした。

 

失敗1:「Git」が動かない

次にモジュールをインストールする為コマンドプロンプトで呪文を入力したのですが「git」のコマンドを認識してくれませんでした。

git clone git@github.com:hatena/Hatena-Blog-Theme-Boilerplate.git

 

node.jsを入れただけではダメなようです。

そう言えば「Git」「リポジトリ」「clone」が何のことか理解してませんでした。

 

ネットで調べてみると下記サイトを見つけました。

www.backlog.jp

一通り流し読みしましたが、入門編でお腹いっぱいになりました。”あトん”はサルより頭が足りないことが分かりました理解したことをまとめてみます。

 

Git

Gitはプログラムソースなどの変更履歴を管理する分散型のバージョン管理システムのことで、Linuxの開発で利用されこれが世界中に広まったものでした。

 

リポジトリ

リポジトリはデータやファイル及び過去の変更履歴が貯蔵された場所でした。

 

clone

cloneはcopyと何が違うのか今ひとつピンときませんが、今回の場合「リポジトリ」のデータをまるごとローカルに保存することのようです。

 

対策1:「Git」のインストール

gitを実行するには「Git」をインストールする必要があるのでさっそくやってみます。ダウンローダは下記サイトにあります。

https://git-scm.com/

 

画面右下のDownloadsをクリックします

 

ライセンスを一応読んだことにして次にすすみます

インストールするフォルダを決めます

必要なコンポーネントを選択します

スタートメニュフォルダの選択

そのまま次にすすみます

コミットメントの編集エディタの選択

後で変更出来るので、デフォルトのままですすめます

環境変数のパス

本例ではコマンドプロンプトを使用するので2番目を選択

コンソールの設定

Windowsのデフォルトコンソールを選択

HTTPS通信のルート

個人使用なのでOpenSSLを選択

改行コードの設定

何もつかないas-isを選択します

Configの設定

とりあえず全部にチェックを入れインストールします

インストール中

セットアップの終了

以上でGitのインストールは終了です。

 

失敗2:コマンドが通らない

それではコマンドプロンプトで呪文を入力します。

git clone git@github.com:hatena/Hatena-Blog-Theme-Boilerplate.git

えっ!上手く実行できません。コマンドプロンプトだからダメなのかな?

今度はGit Bashのコンソールで試してみます。

Git Bashのコンソールでコマンドを実行してもダメなようです。

 

エラー内容を見ると、RSA keyの認証でホストキーの確認に失敗しているようです。

 

GitのChapters「.3 Git サーバー - SSH 公開鍵の作成」を読むと「Git サーバーはSSHの公開鍵認証を使用しておりユーザは自分の公開鍵を作成しなければならない」と書かれてました。

 

.sshというディレクトリに鍵が保存されるらしいのですが、確認すると空でした。

cd .ssh
ls

 

GitHubは安全にリポジトリする為、高度なセキュリティを使っているようですが、ド素人にはチンプンカンプンです。

 

公開鍵はどの様な方法で作成・登録するのでしょうか。。。?

 

焦っていろいろと調べていたら、そもそもGitHubにアカンウトを登録してないことに気づきました。(汗)

 

対策2:GitHubのアカント登録

下記サイトの手順を参考に”あトん”のアカウントを登録しました。

qiita.com

 

 アカウントの登録は下記サイトで行います。

github.com

 

GitHubへの登録

 「Username」「Email」「Password」を入力し「Sign up for GitHub」をクリックします

 なお「Username」は登録後でも変更できます。

 

free planのまま「Continue」を選択

アンケートに答えて「Submit」を選択

アンケートは答えたくなければスキップできます。

Start a projectを選択

登録したメールアドレスを確認

メールの確認

「Verify email address」をクリックします

登録完了の確認

Thanks for verifying your email addressのメールが来たら登録完了です。

以上でGitHubへのアカウント登録は終了です。

 

個人識別情報の登録

GitのChapters「.5 使い始める - 最初のGitの構成」を読むと以下が記載されてます。

Gitをインストールしたときに最初にすべきことは、ユーザー名とEmailアドレスを設定することです。

 

さっそく、Git bashを起動し登録します。

 

登録方法の詳細はGitHub Helpの「Set Up Git」にも記載されてます。

 

ユーザー名とEmailアドレスの登録

下記呪文を入力します。

git config --global user.name "your-name"
git config --global user.email "your.email@example.com"

登録情報の確認方法

下の呪文を入力すると登録情報が表示されます。

git config --global --list

 

SSH鍵の作成

リポジトリをcloneするにはSSHの公開鍵で認証を行うので、公開鍵を作製する必要があります。

 

SSH鍵の作り方はGitHub Help「Generating a new SSH key and adding it to the ssh-agent」に書かれてますので、その中の説明に従って作成します。

 

SSH鍵作製のコマンド

Git bashを起動し下記呪文を実行します。

”your.email@example.com”は前に登録したEmailアドレスです。

ssh-keygen -t rsa -b 4096 -C "your.email@example.com"

パスフレーズを聞いてきますが今回はスルーします。

.sshのフォルダ内に秘密鍵:id_rsaと公開鍵:id_rsa.pubのファイルが作成されました。

 

公開鍵の登録

GitHubのマイページに公開鍵を登録し、秘密鍵で認証できるようにします。

 

公開鍵のコピー

公開鍵の内容をクリップボードにコピーします。

 

公開鍵のコピーはGitHub Help「Adding a new SSH key to your GitHub account」に書かれてます。

 

Git Bashで呪文を実行すると、公開鍵:id_rsa.pubがクリップボードにコピーされます。

clip < ~/.ssh/id_rsa.pub

 なお、テキストエディタでid_rsa.pubを開き公開鍵をコピーしてもOKです。

 

GitHubSign inします

「Settings」を選択

SSH and GPG keys」を選択

「New SSH Key」を選択

Tittleを入れ、Keyをペーストし「Add SSH key」を選択

SHH keyの登録完了

登録完了のメールが届きます

 

モジュールのインストール

さて、やっとリポジトリのcloneができる準備が整いました。

 

リポジトリのclone

さっそく、コンソール画面で呪文を実行します。 

git clone git@github.com:hatena/Hatena-Blog-Theme-Boilerplate.git

今度は上手くいきました。

 

npmのインストール

ディレクトリを「Hatena-Blog-Theme-Boilerplate」にチェンジし、npmをインストールする呪文を入力します。

cd Hatena-Blog-Theme-Boilerplate
npm install

 

コマンドを実行するとnpmのインストールが始まりました。

 

3つワーニングが出てますがエラーはなく、約4分で無事npmのインストールが終わりました。

 

テストサイトの構築

いよいよ作業も大詰めです。

 

テストサイトの準備

本番環境での実行はおススメしません。バックアップをとっていたとしても閲覧者に迷惑がかかる恐れがあります。

 

無料ユーザは3サイト、Proは10サイト登録できますので、テストサイトを1つ用意して下さい。(ローカル環境で実行するので非公開で大丈夫です)

 

ローカルホストの登録

テストサイトが用意できたら、コンパイルされたcssをローカル環境で読み込み自動リロードさせる為、下記をヘッダのタイトル下の欄に貼付けます。

<link rel="stylesheet" href="http://localhost:3000/boilerplate.css"/>
<script async src="http://localhost:3000/browser-sync/browser-sync-client.js"></script>

 

ブログの「管理画面」→「デザイン」→「カスタマイズ」→「ヘッダ」→「タイトル下」にコピペします。

 

SCSSファイル変更の監視とコンパイル

npm startを実行します。

npm start

 

特にエラーも発生せずscssファイルがコンパイルされboilerplate.cssが作製されました。続けてscssファイルの監視がスタートします。監視を停止する場合は「Ctrl」+「C」を押します。

 

テストサイトを開くと「Browsersync」によりboilerplate.cssが自動リロードされました。

無事出来たようです。よかったー!

 

いよいよ最後はscssファイル修正後の自動更新です。

 

background(背景)の色を変更し保存してみます。

・・・

 

・・・

 

・・・

 

うっ!何も変わらない。えー、どうして変わってくれないの?

 

一度npmを停止し再スタートとコンパイル後背景はグレーに変わりました。

しかし、何度scssファイルを修正・保存しても自動リロードされません。

 

「えー、マジ・・・」どこでつまづいているのかド素人にはわかりません。急がば回れで、OS・ブラウザの種類バージョンとスクショを送って、はてなサポート窓口に調査をお願いしました。

 

じっと待っていてもしょうがないので、別の方法がないか探すことにしました。

 

原因調査

どこまで上手く行っているのか再度確認してみました。

 

npm実行後、無理やりboilerplate.cssを直接書き換えると自動リロードされデザインは変わりました。

 

どうやら「Browsersync」君は真面目に仕事をしてますが「npm」君は最初仕事をしたらすぐ持ち場を離れ「scss」君の面倒を放棄しているようです。

(ちょっと酔っぱらっているので勝手に君付けしてます。すみません。)

 

不真面目な「npm」君に変わって、別の人が「scss」君の面倒を見れば上手く行くのでは、と思いました。

 

暫定対応

冗談はここまでにして、scssファイルの変更を監視し自動コンパイルできれ良いはずです。

 

sassを監視し自動コンパイルできるツールを探したところ「Koala」「Prepros」が使い易そうでした。

 

Koala

下記サイトからダウンロードできます。

koala-app.com

詳しい使用方法は下記サイトを参照ください。

uxmilk.jp

 

やって見ると、コンパイルしたいファイルがあるフォルダをドラックするだけで簡単でした。

 

但し、boilerplate.scssに記述されているインポートファイルの一部が読み込めずエラーになったので、下記のように修正しました。

変更前:
@import "node_modules/normalize.css/normalize";

変更後:
@import "node_modules/normalize.css";

 

操作中の様子をGIF画像に収めたので見て下さい。

 

Prepros

PreprosはKoalaより機能が豊富で一番使い易いと言われているようです。

 

下記サイトからダウンロードできます。

Compile Sass, Less, Jade, CoffeeScript on Mac, Windows & Linux with Live Browser Reload

使用法は割愛します。詳しくは下記サイトをご参照下さい。

rfs.jp

 

PreprosもKoalaと同様にコンパイルしたいファイルがあるフォルダをドラックするだけで設定は簡単でした。

 

なおKoalaでエラーになった現象はこちらでも出たので、同じ対応を行いました。

 

操作中の様子をGIF画像に収めたので見て下さい。

 

KoalaとPreprosで遊んでいるうち一週間が過ぎましたが、やっとはてなサポート窓口から回答が来ました。

 

「ただいま確認を行っておりますので、今しばらくお待ちいただけますでしょうか。」と残念な回答でしたが、一応メールは見てくれたようです。

 

年度末で忙しいとは思ましたが、とりあえず催促の返事を出しました。

 

そうこうしている間に、何と勝間和代さんがはてなブログにデビューされたのですが、こっちが気になり、2つもブログを書いてしまいました。(笑)

 

そして気が付くと2週間が過ぎましたが、はてなからは何の連絡もありません。

 

KoalaやPreprosを併用するのは本来の方法ではないので、Node.jsとnpmのみで何とか動かしたいです。

 

のんびり屋の”あトん”も少しイラットしてきたのですが、npmが読み込んでいるジェイソン君のパッケージ(package.json)に何か手がかりがないか調べてみることにしました。

jsonファイルは嫌いにならないよう親愛を込めてジェイソン君と呼んでます)

{
"name": "hatena-blog-theme-boilerplate",
"version": "2.0.0",
"description": "Boilerplate for Hatena Blog theme",
"author": "Hatena Blog",
"license": "MIT",
"scripts": {
"prestart": "npm run build",
"start": "npm-run-all -p watch server",
"build": "npm-run-all scss autoprefixer",
"scss": "node-sass scss/boilerplate.scss build/boilerplate.css --output-style expanded --indent-width 4",
"autoprefixer": "postcss --use autoprefixer -r build/boilerplate.css --map true",
"server": "browser-sync start -c bs-config.js",
"watch": "chokidar 'scss/' -c 'npm run build'"
},
"devDependencies": {
"autoprefixer": "^7.1.4",
"browser-sync": "^2.18.13",
"chokidar-cli": "^1.2.0",
"node-sass": "^4.5.3",
"normalize.css": "^7.0.0",
"npm-run-all": "^4.1.1",
"postcss-cli": "^4.1.1"
}
}

 

scssの監視は"watch": "chokidar 'scss/' -c 'npm run build'"で定義されており、chokidarというコマンドで監視していることは分かったのですが、なぜこの呪文が上手く実行されないのかがわかりません。

 

いろいろ弄って数日過ぎたある日、老眼で気が付かなかったのですがnpm実行中のコンソール画面で少しおかしいところを発見しました。

 

scssをwatchしている行を見たところ、’(シングルクウォート)が変な位置に入っているのです。

 

 

ここが怪しいと思いネットでいろいろ検索した結果、有効な解決策をやっと見つけることができました。

qiita.com

 

何とWindowsではシングルクウォートが無視されるそうです。(涙)

 

解決策はシングルクォートをエスケープしたダブルクォートに変更するものでした。

修正前:
 "watch": "chokidar 'scss/' -c 'npm run build'"

修正後:
"watch": "chokidar \"scss/\" -c \"npm run build\""

 

修正後はscssファイルの監視が上手く行きました。

 

但し、1つ問題が出ました。自動リロードのレスポンスが悪いのです。

 

原因はscssファイル修正後、npm run buildを一から再実行するので3~4秒更新が遅くなるようです。

 

高性能のPCであれば瞬時に変わるのかも知れませんが、”あトん”のノートPCは2009年製でvistaを強引にwindows10に変更した老朽化PCです。

 

しかたがないのでスピードアップの為、scssの自動コンパイルだけを実行するようにwartchを修正しました。

修正後:
"watch": "chokidar \"scss/\" -c \"npm run build\""

再修正後:
"watch": "chokidar \"scss/\" -c \"node-sass scss/boilerplate.scss build/boilerplate.css --output-style expanded --indent-width 4\""

 

修正後はサクサクと動くようになりました。

 

まとめ

時系列にだらだと説明しましたが、ド素人がやる場合の作業は以下です。

①Node.jsをインストール
GitHubへ登録
③Gitをインストール
④Git bashで個人識別情報の登録
SSH鍵を作製
⑥公開鍵の登録
リポジトリのclone
⑧npmのインストール
⑨テストサイトを用意
⑩ローカルホストの登録
⑪npmの実行 ※

①~⑩は一度設定すれば以後必要ありません。

Windowsはpackage.jsonwatch行のシングルクォートをエスケープしたダブルクォートに変更

 

その他

スマホがテストサイトを認識できない場合は、下記記事を参考に設定を見直して下さい。

www.koreyome.com

 

gitを独学したい素人は下記サイトで紹介されている「git-it-electron 実践入門」を一読することをおススメします。("あトん"は半分も理解できませんでしたが。。。)qiita.com

 

余談

ブログのカスタマイズは自動化できる目途が経ちましたが、SCSSについては、まだ勉強してません。使いこなせるようになるまで時間がかかると思いますが、マイペースで勉強していきたいと思います。

 

”あトん”オリジナルのテーマを公開できるのは、まだまだ先になると思いますが、ダークなサイトにしようと思ってます。

 

それでは、良い新年が迎えられることをお祈りしてます。

最後までお付き合い頂き、ありがとうございました。

 

はてなはいつ質問に回答してくれるのかなー?

年内に回答が来なかったら、自己解決できたと言った方がいいのかな。

 

2017/12/29 追記

はてなサポート窓口からやっと下記回答が来ました。

Boilerplate そのものに関する不具合ではなく、使い方に関するご質問でした。

恐れ入りますが、使い方についてはサポート対象外となっております。

回答が遅くなりました上、お力になれず申し訳ございません。

下記は外部サイトですが、ご参考になさっていただけますでしょうか。 

qiita.com

 

動かなかった原因は合っていたので安心したのですが、Windowsで動かなければ不具合だと思うのですが。。。

 

少し納得がいかない回答だと感じました。

 

2018/01/05 追記

README.mdに以下が追記されてました。

Boilerplateは自己責任でご利用ください。お問い合わせははてなブログのサポートフォームではなく、本リポジトリのIssueにお願いします。

 

これって”あトん”に対して遠回しに言っているのかな?

 

こんな追記より、Windows用のpackage.jsonをアナウンスすべきだと思うのですが。

オリジナルテーマを作ろうと思っていたモチベーションが思いっきり下がりました。

 

2018/01/06 追記

rokuzenudonさんがはてなブログテーマ「 UnderShirt 」を公開されました。

blog.rokuzeudon.com

 

新しい公式 Boilerplateを試したとのことですが、SCSS、browser-syncは特に気にならず楽に使えたとのコメントされてました。Macだとすんなり動くんですね。

 

「 UnderShirt 」は2カラムですが非常にシンプルで見やすいデザインです。さすがWebデザイナーさんだけあって隅々まで仕上げもすばらしい。。。

 

またクセがなく無難でカスタマイズしやすい仕様になっているとのことなので初心者にもオススメですね。

 

2018/1/17 追記

12/29に「修正方法について、記載を検討させていただきます。」とはてなより回答をもらってましたが、1/10にREADME.mdにWindows環境での開発案内がアップデートされてました

github.com

 はてなさん、フォローありがとうございます!

ところで、SSL化はとても遅れているようですが、第ニステップの実施は遅くともChrome66がリリースされる春迄にお願いいたしまーす。

 

2018年7月8日追記

npmを使う場合は最新バージョンを確認してください。

 

node.jsは8.9.3 LTSが8.11.3 LTSにバージョンアップされてます。
またnpmは6.1.0にupdateしないと動きません。

 

更にHatena-Blog-Theme-Boilerplateのpackage.jsonに記述されている
npmのパッケージはバージョンが古いので、
定期的に最新バージョンに修正することをおススメします

 

特にnormalize.cssは古いブラウザをサポートする必要が無くなりv7.0.0は2.3KBだったのがv8.0.0で1.8KBに軽量化されてます

Hatena-Blog-Theme-Boilerplateのpackage.json

変更前:

{
"name": "hatena-blog-theme-boilerplate",
"version": "2.0.0",
"description": "Boilerplate for Hatena Blog theme",
"author": "Hatena Blog",
"license": "MIT",
"scripts": {
"prestart": "npm run build",
"start": "npm-run-all -p watch server",
"build": "npm-run-all scss autoprefixer",
"scss": "node-sass scss/boilerplate.scss build/boilerplate.css --output-style expanded --indent-width 4 --source-map build/",
"autoprefixer": "postcss --use autoprefixer -r build/boilerplate.css",
"server": "browser-sync start -c bs-config.js",
"watch": "chokidar \"scss/\" -c \"npm run build\""
},
"devDependencies": {
"autoprefixer": "^7.1.4",
"browser-sync": "^2.18.13",
"chokidar-cli": "^1.2.0",
"node-sass": "^4.5.3",
"normalize.css": "^7.0.0",
"npm-run-all": "^4.1.1",
"postcss-cli": "^4.1.1"
}
}

 

変更後:(2018/07/08時点のバージョン)

{
"name": "hatena-blog-theme-boilerplate",
"version": "2.0.0",
"description": "Boilerplate for Hatena Blog theme",
"author": "Hatena Blog",
"license": "MIT",
"scripts": {
"prestart": "npm run build",
"start": "npm-run-all -p watch server",
"build": "npm-run-all scss autoprefixer",
"scss": "node-sass scss/boilerplate.scss build/boilerplate.css --output-style expanded --indent-width 4 --source-map build/",
"autoprefixer": "postcss --use autoprefixer -r build/boilerplate.css",
"server": "browser-sync start -c bs-config.js",
"watch": "chokidar \"scss/\" -c \"npm run build\""
},
 "devDependencies": {
"autoprefixer": "^
9.0.1",
"browser-sync": "^
2.24.5",
"chokidar-cli": "^1.2.0",
"node-sass": "^
4.9.2",
"normalize.css": "^
8.0.0",
"npm-run-all": "^
4.1.3",
"postcss-cli": "^
6.0.0"
}
}

 

修正後Windows用"あトん"バージョン

watch行のシングルクォートをエスケープしたダブルクォートに変更し、コンパイルを一部スキップし高速化してます。

{
"name": "hatena-blog-theme-boilerplate",
"version": "2.0.0",
"description": "Boilerplate for Hatena Blog theme",
"author": "Hatena Blog",
"license": "MIT",
"scripts": {
"prestart": "npm run build",
"start": "npm-run-all -p watch server",
"build": "npm-run-all scss autoprefixer",
"scss": "node-sass scss/boilerplate.scss build/boilerplate.css --output-style expanded --indent-width 4 --source-map build/",
"autoprefixer": "postcss --use autoprefixer -r build/boilerplate.css",
"server": "browser-sync start -c bs-config.js",
"watch": "chokidar \"scss/\" -c \"node-sass scss/boilerplate.scss build/boilerplate.css --output-style expanded --indent-width 4\""
},
 "devDependencies": {
"autoprefixer": "^
9.0.1",
"browser-sync": "^
2.24.5",
"chokidar-cli": "^1.2.0",
"node-sass": "^
4.9.2",
"normalize.css": "^
8.0.0",
"npm-run-all": "^
4.1.3",
"postcss-cli": "^
6.0.0"
}
}

 

【HTTPS化対応】混在コンテンツ(Mixed Content)の発見と退治方法

はじめに

 

珍しく3日置いてのブログ公開です。一方FC2ブログの方は気づいたら1ケ月以上更新しなかったので広告がトップに躍り出てました。

 

さて、はてなブログは第一段階で予告していたダッシュボード・管理画面のHTTPS化を約7週間遅れで2017年11月20日に実施しました。お疲れさまでした。

 

第二段階は「hatenablog.com」「hatenablog.jp」「hateblo.jp」「hatenadiary.com」「hatenadiary.jp」のドメインHTTPS化ですが、いつ実施されるか予測できない状況です。

 

"あトん"の希望は、来年に持ち越さず、すっきりした状態で年を越した方が良いので、年内実施で何とか頑張って頂き「新年明けましてSSL化おめでとう!」とお祝いし、SSL化初ブログを新年早々に書きたいですね。

 

しかし、はてなHTTPS化が実際上手くいっているのか少し心配です。

皆さんはお気づきだったか分かりませんが、2017年11月21日の早朝のダッシュボード・管理画面は、一部混在コンテンツMixed Content)があり「ありゃ」と思ってました。

 

仕事が終わり夜改めて確認したら混在コンテンツは修正され解消されてました。

 

はてなブログは相当あせっていたのか、一部確認不十分な状態で、ダッシュボード・管理画面のHTTPS化に踏み切ったと思われます。

 

まあ大した問題ではないので気にしませんが、良い機会なので、はてなHTTPS化されたドメインサブドメインはどこまでHTTPS化が進捗しているか一覧にしてみることにしました。

 

hatelabo.jp

11個サブドメインがありますが、HTTPS化が終っているのは「はてな匿名ダイアリー」「LGTM Camera」「大チェッカー」の3個でした。

LGTM Camera」「大チェッカー」は特にお知らせは無かったので、こっそりHTTPS化したのでしょうか。

 

hatelaboは実験サイトなので、残り8個はHTTPS化せず閉じるか、一番後回しになるのではないでしょうか。

 

hatena.ne.jp

14個サブドメインがありますが、HTTPS化が終っているサイトは「ダッシュボード・管理画面」「新着記事」「アカウント設定」「B!KUMA」「Myはてな」「カラースターショップ」「障害情報」の7個でした。

また、「利用規約」「お問い合わせ窓口」「プロフィール」「機能変更、お知らせなど 」の4個はHTTPSが通るのですが、混在コンテンツとなってました。

 

個人的には「はてなブックマーク」を早くHTTPS化して欲しいと願ってます。

 

2020年5月5日 追記

 

現時点でHTTPS化されてないサイトは下記です。

【Quyo】http://quyo.hatelabo.jp/

【機能変更、お知らせなど 】https://hatena.g.hatena.ne.jp/

【プロフィール】https://profile.hatena.ne.jp/aTn/

 

個人的にはプロフィールがいまだHTTPS化されてないのはマズイのでは、と思ってます。

 

混在コンテンツMixed Content)とは

 

HTTP で配信されたコンテンツがHTTPS のページに含まれる時、これを混在コンテンツMixed Content)と呼ばれてます。

 

混合コンテンツには「アクティブ」と「パッシブ」の 2種類があります。

 

「アクティブ」な混在コンテンツは「画像」「動画」「音声」パッシブ」な混在コンテンツは「スクリプト(JS)」「スタイルシート」「iframe」Flashが該当します。

 

この2種類の混在コンテンツはどのような方法で見分ければ良いのでしょうか。

 

混在コンテンツの発見方法

一番簡単な方法はブラウザのアドレスバーでの警告チェックです。但し、PCでChromeを使って下さいね。(注:スマホのアドレスバーには表示されません)

 

HTTP画像等が混じっている場合

このスクションは”あトん”のプロフィールのサイト画面です。

 

httpsが通ってますが、背景画像やファビコンがhttpコンテンツなので、緑の🔓マークではなく(i)となっており、混在コンテンツ有りの警告表示になってます。

 

HTTPスクリプト等が混じっている場合

アドレスバーの左側だけ見ていると見逃してしまうので注意が必要です。右側に注目して下さい。

 

HTTPスクリプト(JS)が混じっていると、Chromeだとアドレスバーの右側に盾マークに×が入ったアイコンが登場します。(Edgeも似たようなマークが出ます)

 

HTTPスクリプト(JS)の実行は危ないのでChromeとEdgeは強制的にブロックしてくれますが、Firefoxはブロックしないようです。

 

SSL化し保護された通信httpsと出ているに関わらず画面の表示がおかしい場合は、HTTPスクリプト(JS)が実行できないことが原因になっているかも知れませんね。

 

混在コンテンツの修正方法

ユーザが自分で埋め込んだHTTPのコンテンツは、ユーザ自身で修正する必要があります。

 

Chromeの開発ツールを使うと簡単に見つけることが出来ます。

 

マウスを右クリックし「検証」を選択し「Console」を選択します。

 

すると下のようなスクションが現れます。ここでは1個のエラーと14個の警告が表示されてます。

 

アクティブな混在コンテンツは黄色で表示されます。

 

警告対象のコンテンツはhttpの画像であることが分かります。

パッシブな混在コンテンツは赤字で表示されます。ここではJSで参照しているアドレスがHTTPであることが分かります。

修正方法は該当のコンテンツを差し替えるか、https化済であれば、アドレスの頭をhttp://→https://に修正するか、http:を抜いて//にします。

 

下記サイトに少し詳しい解説があるので参考にして下さい。

混合コンテンツの防止  |  Web  |  Google Developers

混合コンテンツを見つけて修正するのは、重要なタスクですが、時間がかかることがあります。このガイドでは、このプロセスに役立つツールについて説明します。

 

なお、ページ毎に該当箇所を探してソースを修正するのは時間がかかります。

 

シロマさん (id:shiromatakumi) がはてなブログ用の一括置換ツールを提供されているので、これを利用すると大変便利だと思います。

はてなブログ用の一括置換ツールを作りました

どーもです。 先日、こんな記事を書きました。 はてなブログSSL化(HTTPS化)するまでに準備しておくべきこと | SHIROMAG はてなHTTPS化するということで、それの準備について書きました。 しかし、やる…

 

告知された記憶はないのですが、はてなフォトライフの画像は既にHTTPS対応済なので、はてなフォトライフの画像を使用している場合は、画像は特に何も修正する必要はありません。

https://cdn-ak.f.st-hatena.com/images/fotolife/h/hatenablog/20101106/20101106100658.jpg

確認したい方は、はてなフォトライフの画像アドレスをhttp→httpsに修正して見て下さい。https化されていることが分かると思います。

 

まとめ

混在コンテンツMixed Content)の存在は常時SSL化を妨害します。

 

はてなブログSSL化される迄まだ時間がありますので、自身のブログをチェックし、混在コンテンツを退治しましょう。

 

他のブログに移転する場合も同じ対応が必要ですので、多量に記事を持っている方は早めの作業をお勧めします。

 

♡いいねはこちら

この記事が「面白かった・参考になった」と感じた方は、♡いいねを押して頂けると嬉しいです。

 この記事のツイートを♡いいねする

 

それでは今回の記事はこれでおしまい。

 

余談

はてなブログのログイン画面はSSL化されてますが、100%安全ではないことをご存知でしょうか。(2020/5/5時点)

 

Firefoxが分かりやすいので、これで説明します。

下のスクションは正常な状態のログイン画面です。

 

次にウィンドウを一部変化させると、ある部分に混在コンテンツが出現し「この接続は安全ではありません」に変わるのです。

どこを変えらたこうなるか分かりますか?

 

・・・

 

・・・

 

・・・

 

・・・

 

答を言います。

 

ウィンドウの幅を弄るとフッター付近が変化します。

 

このスクションは変化前です。

 

ウィンドウの幅を狭めてみて下さい。

 

フッター付近にlang.pngとup-arrow.pngのHTTP画像が出現し、アドレスバーに警告表示が出ます。

 

えっ。嘘!」と思われる方は修正される前にぜひお試し下さい。

 

目視チェックだと、このようなケースは見逃してしまう可能性が大きいので、専用ツールで一気に検索し自動変換すべきだと思いますが、テスト環境が無いと完璧な確認はなかなか難しいのかも知れませんね。

 

上着を脱いだら値札を取ってないセータを着ていた感じでカッコ悪いので、気づいたら早めに直した方が良いと思います。

 

なお、lang.pngとup-arrow.pngの画像が安全でないだけでID・パスワードの入力は安全ですのでご安心下さい

 

あなたのサイトはレスポンシブWebデザイン(RWD)ですか?

はじめに

 

Webを勉強していると「SSL」「AMP」「MFI」「RWD」といろんな言葉に遭遇しますが、…何のこっちゃ意味不明?と思われるかも知れません。

 

SEO強化中の皆様にはお馴染みな言葉ですよね。

 

えっ、SEOも分からない。。。

 

実は"あトん"もはてなブログを始める迄はすべて知りませんでした。なぜならアフェリエイトに無関心だったからです。

 

はてなブログを見ると、アフェリエイトユーザが非常に多く、運営報告、収益報告のブログが山のように出てきます。

 

毎日のように「〇〇〇〇〇PV突破!」「〇〇〇記事達成!」等のタイトルを見かけるのですが、すごいなー!と思う反面、PVと記事の両方が少ない"あトん"のブログは完全に落ちこぼれ組だな、と悲しくなる時があります。

 

記事がつまらなく、毎日更新していないので当然の結果なのですが、せめて見栄えだけは良くしようと、SSL化した別ブログで少し気合をいれてサイトをカスタマイズしました。

 

その時「RWD」はやっぱり重要だなー、と感じたので今回記事を起こしてみました。

 

「RWD」なんてどうでもいい方は遠慮なくスルーして下さいね。

 

Web用語の説明

では本題に入る前に、前に登場したWeb用語について整理しておきます。

SEOとは

SEO」はSearch Engine Optimization:サーチ・エンジン・オプティマイゼーションの略で「検索エンジン最適化」を意味します。

 

"あトん"のブログのアクセス解析を調べると日平均約200PVでした。

現在おかげさまで読者数が160名を超えましたが、毎日160名以上の方が”あトん”のブログを見ている訳ではありません。

 

アクセスの95%(190PV)が検索流入で残り5%(10PV)がはてなユーザTwitterからのアクセスと思われます。

 

はてなユーザが見てくれないのは悲しむべき状況かも知れませんが、見方を変えると、良質な記事がたくさんあったら累進的にPVが増える可能性があることを示してます。

 

なぜなら、200PV中、水漏れエラーのブログだけで136PVを獲得しており、このような良記事が仮に10個あったなら1日に1360PV以上になっているかも知れません。

 

そう考えると、良質な記事作成こそがSEO強化の王道の1つと言えます。

SSLとは

SSL」はSecure Sockets Layer:セキュア・ソケット・レイヤーの略です。

 

重要なデータを暗号化して通信する仕組みです。詳しく知りたい方は過去記事をご覧ください。

www.heavy-peat.com


AMPとは

「AMP」はAccelerated Mobile Pages:アクセラレイテッド・モバイル・ページズの略で通常アンプと呼ばれてます。オーディオのアンプではございません。

 

ウェブページが一瞬で読み込まれる技術で、GoogleTwitterが共同開発したものです。詳しくは下記サイトをご覧下さい。

www.ampproject.org

Twitterが高速に表示されるのは「AMP」で構成されているからだそうです。

 

通常リンクをクリックすると、アクセス先のサイトにあるHTMLを読み込んでページを表示しますが、「AMP」ではGoogleがHTMLをキャッシュしている為、読み込む時間が短くなってます。

 

要はGoogleが巨大なキャッシュサーバを構築している訳です。Googleは今後も一人勝ちできるよう、しっかり儲かる仕組みを作っており流石だなと思いました。

 

しかし、最近冗談みたいなニュースを見かけました。

digiday.jp

テキスト表示があまりにも早すぎて広告の表示が追い付かない場合があり、広告のクリック率が下がっているとのことです。(本当かな?)

 

インパクトがある広告はそれなりに作り込まれている為、テキストに比べデータ量も多く、これがアダになっているのでしょうか。

 

利用する側にとっては痛いジレンマですね。

 

個人ブログのAMP化は大して影響はないと思いますが、主に広告を収入源にしているパブリッシャーでは死活問題かも知れません。Googleはどうやって改善して行くのか注目です。

 

ちなみに、はてなブログで最初にhttps化された「はてな匿名ダイアリー」はAMP対応となってます。

labo.hatenastaff.com

 

また、はてなブログProの方は記事をAMP配信できます。

help.hatenablog.com

 

MFIとは

「MFI」はMobile First Index:モバイル・ファースト・インデックスの略です。

 

「MFI」は2016年11月4日にGoogleが正式に導入を発表しました。

webmasters.googleblog.com

今後、Webページの検索結果の評価基準をPC向けのページからモバイル向けのページに変えるという、検索仕様の大変更です。

 

この変更はSEO上とても大きな影響なので、アフェリエイトユーザはモバイル対応に備えることが現在急務となってます。

 

「MFI」は当初は2017年から導入されるのではないか、と思われていましたが、いろいろと問題点が見つかった為、2017年8月22日に開催されたイベント「ISM Spin-off #2」で段階的な導入に変更すると発表されました。

www.suzukikenichi.com

 

更にこのイベントで重要な方針変更の説明があったと記事に説明がありました。

www.suzukikenichi.com

 

今までGoogleはMFI対応について、動的配信、別々のURL、レスポンシブどれでも問題ない、と言っていたのですが、レスポンシブを強く推奨すると方針を変更したそうです。

 

動的配信

 URLは1つですが、アクセスするデバイスごとに異なるHTMLを配信する方法です。

別々のURL

 PCはxxx.www.jp、モバイルはxxx.www.jp/SP 等、URLが異なるものです。

レスポンシブ

 この後説明するので、ここでは詳細は割愛します。

 

Googleがレスポンシブを強く推奨する理由は上で述べられてますが、将来の事を考えたら、レスポンシブデザインの選択がベストだと思います。

 

例えば、常時SSL化する為には、httpコンテンツが混在しないよう管理する必要がありますが、異なるHTML、異なるURLだと、二重に管理しなければならなくなります。

 

バイスごとにページにリダイレクトする必要がありますが、管理が不十分だとエラーの原因になります。

 

更に、同じコンテンツが複数あると、複数回クロールしなければ取得できませんが、レスポンシブだと1回のクロールで終わります。

 

従って、動的配信と別々のURLはレスポンシブを超えるメリットはない、と言えます。

 

なお、誤解がないように補足しますが、MFI対応は検索順位を上げる対応ではなく、検索順位を下げない為の対応です。

 

検索順位を上げるには、高品質なコンテンツと被リンクの両方が最重要とされてます

 

RWDとは

「RWD」はResponsive Web Design:レスポンシブ・ウェブ・デザインの略です。

 

 レスポンシブ・ウェブ・デザインとは一つのHTMLファイルをCSSを用いて、画面サイズが異なるデバイス(PC、タブレットスマホ等)にデザインを最適化させるものです。

developers.google.com

レスポンシブ・ウェブ・デザインは、meta viewport タグとCSSメディアクエリを使用することで対応できますが、記述に手間がかかるのが難点です。

 

しかし、レスポンシブ対応のテーマはどんどん増えてますので、早い段階で乗り換えておくのが良いと思います。

 

但し1つ注意点があります。

 

SSL化も視野に入れているのであれば、https対応済のテーマを選択して下さい。そうでない場合は、SSL化後にhttpコンテンツの個別修正が必要になります。

 

以上でWeb用語の説明は終了です。それでは本題の説明に移ります。

 

レスポンシブ・ウェブ・デザインの確認方法

レスポンシブ・ウェブ・デザインが正しく適用されているか、どうやって確認すれば良いのでしょうか。

 

"あトん"のスマホはiPhone6sPlusなので、自分のスマホでの見え方は確認できますが、ディスプレイが小さいiPhone5iPhone6は所有してないので分かりません。

 

すべてを実機確認するのは無理なので、シミュレーションを利用するのが現実的です。

 

現在レスポンシブデザインを簡単に確認できるツールがたくさん提供されており、どんどん使いやすくなってます。

 

これから8つ紹介しますので、皆様も気に入ったサイトで遊んでみて下さい。

 

それでは、”あトん”がFC2ブログでひっそりと公開しているサイトでテストしてみます。(お暇でしたら、きれいなお姉さんのスライドショーを見に来て下さい)

100pv.blog.fc2.com

 

前半の4つは画面フレーム付きで、後半の4つは画面フレームなしです。

deviceponsive

deviceponsive.com

トップ画面はこんな感じです。
チェックしたいサイトのアドレスを入力し、Goを押します。

iPhoneの表示画面です。機種は不明です。

 

Macbookでの画面です。機種は不明です。はめ込み画像ですが、リアルに動きます。

Responsive Checker

responsivechecker.net

 

トップ画面はこんな感じです。Check Responsiveをクリックします。 

 

チェックしたいサイトのアドレスを入力し、SUBMITを押します。

 

もし、対象機種が表示されなかったら、下までスクロールして下さい。

 

Apple,Samsung,Sony,LG,Google,Nvidia,Toshiba,Amazonの8メーカの製品が表示されるので、チェックしたい機種を選びなおして下さい。

 

iPhone 6S Plusでの表示画面です。フレームはアニメなので少しプアーですね。

 

画面の方向を90°回転する場合は、ブルダウンから選択して下さい。

 

なお、国内にResponsive Checkerと全く同名のテストサイトがありますが、チェックできる製品が古いので、こちらのサイトをお勧めします。

Responsive View
responsiv.eu

入口はこんな感じです。このサイトでテスト出来るのはApple製品のみです。
チェックしたいサイトのアドレスを入力し、Let's Go!を押します。

 

iPhone 6S Plusでの表示画面です。
Responsive Checkeryよりスマホのフレームが本物っぽいですね。

 

iPad Air2での表示画面です。

Am I Responsive

ami.responsivedesign.is

 

入口はこんな感じです。ここでテスト出来るのはApple製品4種類のみです。
チェックしたいサイトのアドレスを入力し、GO!を押します。

 

このサイトの凄いところは、表示されているデバイスの位置をマウスで上下左右にずらすことができるところです。

 

自作テーマを作ったら、この画面を利用して、カッコよくアピールできますね。

Media Genesis

responsivedesignchecker.com

 

入口はこんな感じです。
チェックしたいサイトのアドレスを入力し、GOを押します。

 

iPhone 6S Plusでの表示画面です。

 

iPad Retinaでの表示画面です。

 

このサイトではApple以外にAmzon,Asus,Nexus,Samsung,Sony,Googleをチェックできます。

 

残念ながらスマホタブレットの画面のローテーションボタンはありません。
縦横比を変える場合は、右上のセルに画素数を入力し修正して下さい。

Screenfly

quirktools.com

 

入口はこんな感じです。
チェックしたいサイトのアドレスを入力し、Goを押します。

 

iPhone 6 Plusでの表示画面です。
Apple以外にNetbook.Desktop,Kindle,Asus,Samsung,Surface,LGの製品がテストできます。

 

iPadでの表示画面です。

XRESPOND

app.xrespond.com

 

入口はこんな感じです。
チェックしたいサイトのアドレスを入力し、LOAD URLを押します。

 

画面横方向に選択したデバイスの画面が並んで表示されます。


Apple以外にGoogle,Nokia,Amazon,Surface,Samsungの製品を表示できます。
画面の縦横変更もクリック1発でできます。

Sizzy

sizzy.co

 

入口はこんな感じです。
チェックしたいサイトのアドレスを入力します。

 

テストできるのはApple以外にNexus,Galaxyのタブレットスマホです。

 

左下のZoomを変えると、計8種類のデバイスを同時表示できます。
今年リリースされた最新のものなので余裕で動きます。

 

全部いっぺんに見たい時、便利ですね。

 

以上でレスポンシブデザインをテストできるサイトの紹介を終わります。

 

次に普段使用しているブラウザでレスポンシブデザインを確認する方法を紹介します。

Firefoxでのレスポンシブデザイン表示

右上のハンバーガメニュより開発ツールを選択します。 

 

次にレスポンシブデザインモードを選択します。

 

画面上のメニュより端末を選択します。

 

画面を90°回転させる場合は右上のアイコンをクリックします。

 

もっと詳しい使い方は下記サイトを見て下さい。

developer.mozilla.org

Chromeでのレスポンシブデザイン表示

右クリックし、検証を選択します。 

 

モバイル端末のアイコンをクリックしデバイスモードを起動します。

 

画面上のメニュより端末を選択します。下の画像はフレーム在りとなってます。

 

画面を90°回転する場合は、右上のノブのアイコンをクリックします。

 

バイスモードの詳しい使い方は、サルワカさんの説明を見て下さい。

saruwakakun.com

 

まとめ

テストで使用した"あトん"の新しいサイトは問題ゼロの「RWD」か確認します。

 

最終テストはGoogleのツールを使用しました。

 

モバイルフレンドリーテスト

https://search.google.com/test/mobile-friendly?hl=ja

テストするサイトのアドレスを入力し、テストを実行をクリックします。

 

モバイル対応であれば、このページはモバイルフレンドリーです、と表示されます。

OKなのですが、一番重要なのは読み込みに関する問題がないことです。

 

すべてのページが正常に読み込まれたことが確認できました。

Test My Site

モバイルサイトの読み込み速度とパフォーマンスをテストする - Google

最後は過去記事でお馴染みの速度テストを行います。

atn.hateblo.jp

 

テストするサイトのアドレスを入力し実行します。

 

何と4秒を叩き出しました。まぐれかと思い5回程繰り返しましたが、全部4秒でした。

 

このスピードが出せた理由は、迷惑なアドセンス広告が出なかったからだと思います。(広告の抑制方法は検証途中ですが、まとまったら記事にするかもしれません。)

 

4秒は業界トップクラスのサイトと同程度だそうです。

 

更に5秒短縮が可能だそうです。5秒短縮するとマイナス1秒になるけど、Googleさん、小学生でも分かる嘘はダメですよ。(笑)

 

以上の結果より、”あトん”の新しいサイトの「RWD」はページ読み込みとスピードにおいて問題がないことが確認できました。

 

唯一の問題はPVが低いことでしょう。サイトのURLの先頭文字が100pvとなってますが、これは1日100PV以上を目指そうと願いを込めたものです。

 

しかし、2週間経過しても200PV行ってません。(笑)

 

さて最後は恒例の余談です。

 

余談

今までの説明は実は前置きです。少し問題になりそうなことを見つけたので、バズらないように、こっそり説明します。

 

問題になるのは「はてなブログ」ユーザ様です。

 

何が問題かと言うと、はてなブログユーザはブラウザのデベロッパーツールでレスポンシブデザインを確認できますが、今回紹介したテストサイト8つはすべて使えないのです。


使えない理由はページを完全に読み込めないからです。

 

嘘だと思ったら、各自お試し下さい。画面が真っ白のままで変わりません。

 

下記はhatenablogのトップページをモバイルフレンドリーでテストした結果です。

 

モバイルフレンドリーです、という結果を見てOKと思うかも知れませんが、注目して欲しいのは左上に表示されている警告表示です。

 

ページの読み込みに問題がある、と警告してます。 

 

警告の詳細を見ると6個のページリソースを読み込めなかった、と診断されてます。


読み込めなかった原因は、Googlebotがrobots.txtによってブロックされたからです。

 

そんなこと大した問題じゃないの、と思うかもしれませんが、Googleが今後確実に実施するMFIのことを思いだして下さい。

 

はてなブログのモバイルサイトのデータが正常に読み込めないということは、はてなブログは検索ランキングが下がる上がらない、ということなのです。

 

なぜなら、GoogleモバイルSEOの概要で、このことを明確に述べているからです。(重要なところは"あトん"が赤字にしました)

モバイル SEO の概要  |  Search  |  Google Developers

モバイルサイトの設定での重要な点

 

後で説明するように、モバイル フレンドリーのサイトにするために選択できる設定方法は複数あります。ただし、選択した設定方法によらず、留意してほしい重要な点があります。

 

1.モバイル用にページを設定したことを Google に知らせる(または対応するモバイル用のページがあることを Google に知らせてください)。このようにすると、モバイル端末から Google 検索を行ったユーザーに適切な検索結果としてコンテンツを提供できます。


2.リソースをクロール可能な状態にしておく。検索エンジンがページのレンダリングに不可欠なファイル(広告を含む)にアクセスできなくなるような robots.txt は避けてください。リソース(CSSJavaScript、画像など)に Googlebot がアクセスできないページは、モバイル ブラウザでの表示や動作向けに作成されたページとして認識されない場合があります。つまり、ページが「モバイル フレンドリー」と認識されず、モバイル ユーザーの検索結果に正しく表示されなくなります


3.モバイル ユーザーが不便を感じるようなよくある誤りを避ける。たとえば、再生できない動画(Flash など)を、ページの重要なコンテンツとして掲載する誤りなどです。ユーザーが快適に利用できないモバイルページは、モバイル検索結果のランキングが下がったり警告が表示されたりします。詳しくは、「よくある誤り」のページをご覧ください。

 

今はまだPCのページが検索ランキングの基準になっているので影響はありませんが、現状のままMFIに移行したら「はてなブログ」は全部検索ランキングが下がる上がらない恐れがあるのです。

 

最近、良質なコンテンツを持ったはてなブロガーが、SSL対応を理由にWordPressに多数流れて行ってますが、SSL化よりもMFI未対応の方がはるかに影響大と思います。

 

Proの流失が更に加速しないことを願います。

 

最後に誤解がないように補足しますが「はてなブログ」ユーザは全部がダメと言いましたが、はてなブログでも例外はあります。

 

はてなブックマーク」と「はてな匿名ダイアリー」「はてなフォトライフ」「はてなキーワード」「はてなダイアリー」の5つのサイトは、レスポンシブデザインのテストが出来ます。ページの読み込みに問題はあるのですが出来てます。

 

はてなブログ」は技術力があるので、たぶんrobots.txtを修正し何とか解決してくれると思いますが、対応が遅れないないよう早めに修正して欲しいですね。

おまけ

お口直しに、秀逸なレシポンシブWebデザインのサイトを紹介します。
お時間がある時に覗いてみると参考になるかと思います。

responsive-jp.com

追伸

重要なお知らせをうっかり忘れてました。

 

本日をもって、ブログ名を「Bumble-Bee」からafter work Laboに変更します

 

本当はこのブログをSSL化してから改名しようと思っていたのですが、先延ばししてもメリットはないので今変えます。

 

宜しければ、今後もお暇な時にお付き合い下さい。

 

それでは、再会(ザイチェン)。

SEO強化につながる、表示スピードが速いブログデザインとは

はじめに

 

今回の記事はブログの表示スピードに関する考察です。ご存知の内容でしたらスルーして頂き、他の面白いブログに遠慮なく飛んで行って下さいね。

 

はてなブログは移転前のF2Cブログに比べ表示が遅いと感じてましたが、割とサクサク表示されるはてなユーザさんのサイトが多数あります。

 

きっとSEOを重視しブログの表示スピードをアップする為、いろいろ工夫しているのではと思いました。

 

はてなブログに限った話ではありませんが、どんなブログデザインが表示スピードに対して有利なのかを少し探ってみました。

 

 

 

なぜ表示スピードが求められるのか

SEOに強いサイトは、内容の充実が第一条件ですが、訪問者が「面白かった≒美味しかった」と思い、また覗きに来ようと思うかどうかだと思います。

 

内容の面白さを支えるものが「読みやすさ」「見やすさ」「使いやすさ」の3つです。そして、これを効果的に増幅させる為には「速さ」が必要です。

 

「読みやすさ」「見やすさ」「使いやすさ」「速さ」を具現化するのが
Webデザイン」で、「テキスト」「フォント」「画像」等の材料を「HTML」「CSS」「jQuery」等で上手く料理できているかがポイントです。

しかし、何の対策もやってないサイトは情報がすぐ現れない為、せっかくの訪問者は別の場所に離れて行ってしまいます。

 

どれくらいで離れるかについて、Google

完全表示に3秒以上かかると53%のユーザが離れる
表示速度が7秒になると直帰率が113%上昇する

というデータを公開してます。

www.thinkwithgoogle.com

時間をかけ思いを込めて作ったブログも、表示が遅いと、訪問者は見るのをあきらめ、別のページに去って行きます。これは非常に残念ですね。

 

"あトん"もこのブログをもう少しマシにしたいと思ってますが、これ以上カスタマイズしてもやぶ蛇になると思い、先人達のブログを参考にしたく、表示スピードを測定してみることにしました。

 

表示スピードの測定・評価方法

 

サイトの計測ツールはいろいろとありますが、Googleが提供している3つのツールを少し紹介します。ご存知の方はここは読み飛ばして下さい。

1つ目「Lighthouse」

developers.google.com

 

「Lighthouse」は①~④の項目を評価するアプリです。

Progressive Web App:プログレッシブ ウェブ アプリ
②Performance:パフォーマンス
③Accessibility:アクセシビリティ
④Best Practices:ベスト プラクティス

 

使用方法

Chromeに「Lighthouse」の拡張機能を入れ、ツールバーの Lighthouse アイコンをクリックします。

設定を確認したら「Generete report」を実行し、評価スタートです。

1分若で測定が終り評価結果が表示されます。
下記はGoogleを測定した結果ですが、パフォーマンスは92ポイントと好成績です。

使用上の注意

「Lighthouse」は良くコケます。特に最初の実行でパフォーマンス0表示が多く、測定値のばらつきも大きいです。ひどいとエラーで止まる場合があります。

「Lighthouse」はプログレッシブ ウェブ アプリの評価に重点を置いている、とGoolgeは言ってますので、アプリ開発者向けのツールと考えた方がよいですね。

 

よって、一応一通り測定はしましたが、結果の公開は差し控えます。

2つ目「Test My Site」

testmysite.withgoogle.com

このアプリは割と有名ですね。皆さんも使ったことがあると思います。

使用方法

ブログカードをクリックすると「Test My Site」が開きます。
テストするサイトのアドレスを入力して実行します。

 

試しに「はてなブログ」トップページのスピードをチェックしてみましょう。

 

 

 

約1分で測定結果が表示されます。
はてなブログ」のトップページは要改善で良い結果ではありませんでした。

同じ業界内での比較でも、10秒は遅い方のようです。

少し修正すれば、何と5秒短縮できる見込みとのことです。 

Googleからのアドバイスは3つでした。

1.適切な形式と圧縮処理を採用すれば、データ量を大幅に削減し、サイトのパフォーマンスを向上させることができます。
2.JavaScript は、非同期化するか、最初のレンダリングが終わるまで保留しましょう。
3.キャッシュが有効になっていれば、2 回目以降はページを効率的に読み込むことができます。

使用上の注意

「Test My Site」のテスト結果もある程度ばらつくので注意が必要です。

 

同時間帯での実行では数秒の変化はありますが、日をまたいでテストした時は2倍くらい悪化した時があります。

 

ばらつく原因はいろいろ考えられますが、読み込む画像に大きく影響されるようです。

 

例えば、強制的に入る広告で、データ量が多いものがたまたま入ってしまうとスピードが悪化します。

 

下に表示しているのは、はてなブログの人気テーマをテストする為、テーマを呼び込んで実施した時の結果です。

 

特大の広告データが呼び込まれた為、読み込みに12秒もかかってます。(笑)

なお、「Test My Site」は連続テストの回数に制限があり、所定回数を超えると「自動車」「バス」「道路標識」「橋」「アパート」「お店の外観」をクリックし、ロボットでないことを証明しなければなりません。

 

100サイト以上を数回テストしたので、タイルパターンを覚えてしまいました。(笑)

 

3つ目「PageSpeed Insights」

「PageSpeed Insights」はお手軽なので一番使われているようです。

developers.google.com

使用方法

ブログカードをクリックしPageSpeed Toolsを開きます。テストするサイトのアドレスを入力し実行してください。


試しに「はてブニュース」のスピードをテストしてみます。

テスト結果

はてブニュース」はザーバ側が最適化されているのか、画像が無い為か、めちゃくちゃ良い結果が出てます。

  モバイル:89ポイント        パソコン:96ポイント

 

次に本家の「はてなブックマーク」のスピードを測定してみました。
「あれっ?」と思うくらい悪いですね。

  モバイル:36ポイント        パソコン:6ポイント

 

 テスト結果は3種類のアイコンで悪さ加減を教えてくれます。

はてなブックマーク」は最近リニューアルされたようですが、ユーザからは「改悪だ!」との声が多数上がっているようですね。スピードにも何か影響があるのでしょうか。

bookmark.hatenastaff.com

 

ブログの表示スピード比較

 

ではブログの表示スピードを「PageSpeed Insights」と「Test My Site」で測定した結果を順番に説明します。

 

 「PageSpeed Insights」の総合判定は、モバイルとパソコンの数値の加重平均を取りました。加重平均で計算した理由は、GoogleがRWD(レスポンシブ ウェブ デザイン)を強く推奨しているからです。

 

加重平均の計算方法は、モバイル:70%、PC:30%としました。

 

また、表示スピードの差を考察する為、失礼ながらHTMLとテーマ独自のCSSのデータ量も参考に調べました。(システムが読み込む共通のCSSは除いてます)

 

調査対象にしたブログテーマやブログサイトは、参考になるなー!と”あトん”が個人的に思ったものです。探し回るとキリがないので、はてなブログは90サイト程度に絞りました。

 

一見ブログの表示スピードランキングのように見えますが、表示画像(広告)、コンテンツ量がそれぞれ違うので、素の状態の比較ではないことをご了承下さい。

 

測定は複数回行い、良い方の結果を残しました。

 

まず大手サイトはどれくらいのスピードか遊んでみました。

 

大手サイトの表示スピード

予想はしてましたが、Googleはほぼ満点ですね。マイクロソフトが頑張っているのが少し意外でした。

 

次に、はてなブログのテーマを測定してみました。

 

はてなブログ デザインテーマの表示スピード

第1位は9月1日に「たにやん」さんがアップされた「SIMPLE CARD YAN」でした。
初心者で1ケ月で作ったとのことですが、凄いですね。

  モバイル:70ポイント        パソコン:85ポイント

 

但し「SIMPLE CARD YAN」がカスタマイズに強いかは未知数です。

 

次に、はてなブログ50サイトを比較した結果を表示しますが、表示スピードが速いブログのテーマは「こどみす」さんの「Minimalism」や「Codomisu Flat」をカスタマイズしたものが多いようです。

 

続いて、はてなユーザさんのブログを測定してみました。

 

はてなブログ表示スピード比較

それでは前半/後半に分けて結果を表示します。

前半25サイトの結果

測定前は「つばさ」さんの「つばさのーと」が最速だと予測してたのですが「カツヲ」さんの「晴れ時々晴天なり」が一歩抜きんでてました。

 

「カツヲ」さんのブログは、CSSが圧縮されHTMLに埋め込まれており、かなり作り込まれてました。「シロマ 」さんのブログ「NO TITLE」も同じ手法ですが「Test My Site 」では唯一3秒をたたき出しており最速でした。

 

後半25サイトの結果

 "あトん"のブログ「Bumble-Bee」は50番目です。最下位ではありません。50サイト以上テストしたのですが、たまたまキリ良く50番目だっただけです。(笑)

 

正直に言うと、最初http://atn.hateblo.jpでのテストはモバイル/パソコン共に0ポイントでした。次にURLをhttp://atn.hateblo.jp/archiveに修正したら、45.7ポイントでした。

 

無料ユーザが何も考えずにカスタマイズした結果ですね。

 

表示スピードの改善方法

表示が遅いブログはどこを直せば早くなるのでしょうか。改善方法は検索すると山のように出て来ますが、参考になる先人のサイトを紹介させて頂きます。
(解説もせず手抜きですみません)

fastcoding.jp

www.lifeport-gurigura.jp

www.notitle-weblog.com

www.aritai.net

www.weblog-life.net

www.aritai.net

まとめ

はてなブログの表示スピードを速くする為に先人がやった改善方法のポイントを、
難易度別に松竹梅にまとめてみました。

 

<梅> 難易度低

  ・画像圧縮、表示記事数削減
  ・はてなスター削除、読者ボタン削除、シェアボタン削除
  ・シェア数非表示、フォロアー数非表示
  ・Proのみ(広告削除、ヘッダー/フッタ非表示)

<竹> 難易度中

  ・未使用のCSS・JSの整理・削除
  ・圧縮したCSSとJSをHTML内に組込む

<松> 難易度高

  ・無駄な記述がないオリジナルテーマを書く

 

究極はデザインテーマをカスタマイズせず、自分でオリジナルテーマを作ることだと思います。

 

「たにやん」さんは1カ月で作ったとのことですが、Webの知識に乏しい”あトん”は半年頑張っても出来るかどうか自信がありません。

 

でもちょっと興味が湧いて来たので、勉強してみようかなと思います。

 

年内にこれに関する進捗ブログが出てこなかったら、挫折したと思って笑って下さい。

 

なお、このブログの表示スピードはブログを書くのに疲れてしまったので、ちっとも改善しておりません。(笑)

 

2017/9/3追記:モヒートが飲みたくなったので、ヘッダー画像を軽いものに変更しました。モヒート効果で、モバイルが43→46、パソコンが52→53にほんの少し良くなりました。(嘘です。単にモヒートが飲みたかっただけです。)

 

2017/9/4追記:サイドバーのAuthorの画像を圧縮し軽くしました。
変更後、モバイルが66、パソコンが76まで改善されました。
サイトのスピードアップは使用画像容量縮小が手っ取り早い対策だと分かりました。

 

2019/8/10追記 『晴れ時々晴天なり』を運営されているカツヲさんは2019/7/25にWordPressに移転されました。スピード1位の方は、かなり危機感を持たれていたようですね。

 

 

補足

はてなブログのデザインテーマについて表示スピードを測定した結果を示しましたが、申し送りがあります。

 

本当は同じ内容(コンテンツ)で測定したかったのですが、"あトん"は無料ユーザなので、広告が強制的に入ってしまいます。

 

この広告がくせもので、測定を大きくばらつかせてしまいます。

 

Proの方は広告を非表示に出来るので、もしProの方で表示スピードに興味がありお時間がある方は、測定結果を公開してもらえると嬉しいです。

おまけ

その他適当に測定したサイトを載せておきます。

はてな系のサイトは遅いですが、Webのデザインや製作を丁寧に解説している「サルワカ」さんは表示スピードもとっても速く、プロの方は凄いと思いました。

DMCA.com Protection Status