始めはとても良いサーバーだと思っていたのですが、最近はサーバー障害が頻繁に起こっています。
信頼性が必要なサイトであればmixhostは避けたほうが無難でしょう。

それで今回は、サーバー障害の根拠となるデータをご紹介しようと思います。
また、当初は飛び抜けていて評判の良かったmixhostのサービスも、いまや他社サーバーと横並びになってしまったこともご紹介します。

mixhostのサポートが日本語できない疑惑についてはまた今度の機会に。

サーバー障害のデータ

まずはこちらをご覧ください。
これはmixhost公式サイトに示されているデータです。

「稼働率99.99%
高い稼働率をご提供。ビジネスにも安心してご利用いただけます。」

・・！？
どこからこの数字を出してきたのか・・
しかも根拠となるデータはどの期間のものなのか？？

では次に実際にmixhostでホストしているサイトのデータをご覧ください。

サイト監視サービスの2018年1月から3月までのデータです。
カレンダーで赤くなっているのが障害が発生した日です。

3月は障害が0ですが、この記事を書いている4月には既にサーバー障害が発生しています。

しかも恐ろしいのが、mixhost公式サイトの障害履歴のページにはそのほとんどが掲載されていません。
mixhost公式サイトの障害履歴には、大規模障害しか載せない決まりでもあるのだろうか？？それとも障害が多すぎて載せきれないのか？？

ですから、サイト監視サービスを入れていなければ障害が起こったことにすら気づかないのです。
全ての障害が公開されていないという事実に、サイトの信頼性だけでなく会社の信頼性にも疑問を感じます。

mixhostのメリットは今や無くなった

私がmixhostを使い始めた理由としては、契約当時はスペック的に抜きん出ていたからでした。
標準でSSD・無料のSSL・HTTP2・cPanelが使える・・などです。

しかし、今や他社サーバーでもこれらが標準になりました。
しかもmixhostよりも使い勝手が良い。

サーバーの速度についても、Chrome DevToolsなどで調べてみるとmixhostの遅さが分かります。
同じサイトのデータをmixhostと他社サーバーにアップロードしてみて、レスポンスを比べてみてください。

このように、mixhostを実際に使用しているユーザー体験をご紹介しました。
mixhostでもアフィリエイトプログラムが始まってからは、良い評判しか聞かなくなってしまいました。

ですから実際に使用している状態を参考にしてサーバーを選んでいただければ幸いです。

今後、サーバーの安定性が向上することで、また使いたいと思えるサーバーになってほしいと思います。

ですから何によってdns-prefetchが挿入されるのか見極めるために、最低限のプラグインを有効にしてコードを確認するのがオススメです。

WordPressによって挿入されるdns-prefetch

WordPress本体によって挿入されるdns-prefetchは、以下のものがあります。

<link rel=’dns-prefetch’ href=’//s.w.org’>

この挿入コードを消すにはfunctions.phpに以下のコードを追加します。

add_filter( ‘emoji_svg_url’, ‘__return_false’ );

https://wordpress.org/support/topic/remove-the-new-dns-prefetch-code/

Jetpackによって挿入されるdns-prefetch

なかなか消えないdns-prefetchはJetpackによるものでした。
Jetpackのモジュールを無効化することで挿入コードを消すことができます。

Jetpackモジュールによって挿入されるコードは以下のものがあります。

https://wordpress.org/support/topic/slow-slow-sites-so-much-additional-js-junk/

ショートコード埋め込み
<link rel=’dns-prefetch’ href=’//v0.wordpress.com’/>

いいね
<link rel=’dns-prefetch’ href=’//widgets.wp.com’/>
<link rel=’dns-prefetch’ href=’//s0.wp.com’/>
<link rel=’dns-prefetch’ href=’//0.gravatar.com’/>
<link rel=’dns-prefetch’ href=’//1.gravatar.com’/>
<link rel=’dns-prefetch’ href=’//2.gravatar.com’/>

Photon
<link rel=’dns-prefetch’ href=’//i0.wp.com’/>
<link rel=’dns-prefetch’ href=’//i1.wp.com’/>
<link rel=’dns-prefetch’ href=’//i2.wp.com’/>

それぞれのモジュールを無効にすることで、dns-prefetchを消すことができます。
モジュールを個別に無効化するには以下の手順で設定できます。

Jetpackモジュールを個別に無効化する方法

Jetpackの設定画面に移動します。
設定画面の一番下の、「Debug」リンクを選択します。

デバッグセンターが開くので、一番下にある「お使いのサイトで使用可能な Jetpack モジュールの全一覧にアクセスします。」をクリックします。

モジュールの一覧画面が開きます。
モジュールを無効にできます。

モジュールを無効にした後、目的のdns-prefetchが消えたことを確認します。

キャッシュプラグインを導入していれば、キャッシュをクリアして確認します。

表示されないNASを表示するには、QTSの設定を変更します。
QTSにログインしたら、「コントロールパネル」→「ネットワークとサービス」→「Win/Mac/NFS」→「Microsoftネットワーク」に進みます。

開いた「Microsoftネットワーク」タブの設定を見直していきます。
まず、「Microsoftネットワーク向けのファイルサービスを有効にする」をチェック。
「サーバーの説明（任意）」は、Windows側で表示したい名前を入力します。
「ワークグループ」にはWindows側で設定したワークグループ名を入力します。

Windows側のワークグループが不明な場合や、まだ作成していない場合には「コントロールパネル」→「システムとセキュリティ」→「システム」で確認・変更できます。

QNAP NAS側で設定を保存します。
Windowsに戻り、「ネットワーク」フォルダを「最新の情報に更新」します。

これで「ネットワーク」→「コンピュータ」にQNAP NASが表示されるはずです！

AMPページで画像が表示されるのに、AMPキャッシュで画像が表示されないというたぶんレアなケースを経験しました。
症状としては・・

AMPの文法チェックは合格している
サイトのAMPページで画像は正常に表示される
GoogleのAMPキャッシュ（https://cdn.ampproject.orgで始まるURL）では画像が表示されず真っ白
Google検索結果で返されるAMPページはAMPキャッシュですから、自サイトのURLで表示されていてもAMPキャッシュで表示されなければ意味がありません。
しかも、AMPページは確認しても、AMPキャッシュまではなかなか確認することはないケースが多いと思います。
自分では画像が見えているつもりでも、検索経由だと見えない！という恐ろしい状態もあり得るわけです・・

そんなわけでAMPキャッシュのみ画像が表示されない原因としては、「画像の先頭行が拡張子と合っていない」ということでした。

AMP画像が表示されない

とあるアフィリエイトサイトを作成し、AMPページも正常に動作していることを確認し安心していた時にそれは起こりました。

Google検索経由で自サイトのAMPページにアクセスしたところ、なんと画像が表示されない！
慌ててAMPページを確認したところ、画像は正常に表示されている・・

つまり、自サイトのURLで始まるAMPページで画像は表示されているのに、Googleの検索経由でアクセスすることになるAMPキャッシュページでは画像が表示おらず真っ白になっていたのです。
もちろんAMPのバリデーションは合格し、文法的にはOKなのです。

原因は画像そのものだった

いろいろと調べていた所、StackOverflowで気になる質問をみつけました。（URLは失念してしまって検索しても出てこない・・見つけたらURLを追加します）

その質問ではAMP画像が表示されない原因として、「画像のBOMつまりByteOrderMarkを確認する」という点が指摘されていました。
この確認方法をご紹介したいと思います。

AMP画像のチェック方法

バリデーションのためにhttps://ampbench.appspot.com/にアクセスし、確認したいAMPページをチェックします。

「Indexed in Google AMP Cache?」欄の、AMPキャッシュページにアクセスし、AMP画像が表示されるか確認します。
画像が表示されればOKです。

AMPキャッシュで画像が表示されない場合

https://cdn.ampproject.org/c/s/で始まるAMPキャッシュは、実際のGoogle検索結果で返されるページです。
AMPキャッシュで画像が評されない場合には、Googleデベロッパーツールで画像を確認していきます。

まず、AMPキャッシュで表示されない画像をChromeで開きます。
正常に表示されているAMPページなどから、画像を右クリックし「画像を新しいタブで開く」を選択します。

「F12」キーを押し、デベロッパーツールを起動します。
デベロッパーツールを起動後、「F5」キーでページを更新します。

「Network」タブを開き、「画像名」を選択します。
画像を選択すると、右側にタブが出るので「Preview」タブを選択します。

画像の詳細が表示されるので、先頭行をチェックします。
この画像の場合は先頭行が「PNG」になっています。

画像そのものの拡張子は「jpg」ですが、先頭行は「PNG」です。
この違いこそが、AMPキャッシュで画像が表示されない原因となっていました。

解決策

これを修正するには、画像を保存しなおせばOKです。
Photoshopやペイントなどの画像編集ソフトで画像を開き、改めて拡張子を決めて保存すれば画像の先頭行も拡張子に合わせて保存されるはずです。

ちなみに、広告の場合にはAMP-Adが使えればそちらを使ったほうが良いでしょう。
例として表示している画像も、AMP-Ad経由だと正常に表示できます。

まとめ

AMPページで画像が表示されていても油断しない！！
AMPキャッシュでは画像が表示されていない可能性がある・・・

アフィリエイト関係

固定広告の掲載のお話を新たにいただき、ありがたく掲載することに。

新たなサイトを作成するもあまりヒットせず・・
過去サイトのメンテナンスを行い、コンバージョンを向上させることを目指しました。

稼いでいた広告の単価が下げられたり、2016年後半のGoogle変動の波もあり、波乱のままに年を終える・・笑

サイト高速化

2016年も自作テンプレートの高速化を行いました。
2015年は初回アクセスで読み込みが500ms以内を目指していましたが、2016年は400ms以内を実現することができました。
400msは実験サーバPHP5系での数値なので、本番サーバPHP7系だとさらに体感的にも早く感じられます。

また、初めに表示される部分は優先的にCSSを適用し、CSSそのものも高速化を行いました。

投資関係

実は2015年末から投資を初めていました。
2016年はNISAを開始し、投資信託の購入を増やすことに。

年末のトランプ相場もあり、NISAの損益は+15.74%で終えることができました。
また、初めての優待や少額ながら配当金をもらえてちょっとうれしい気分に。

投資信託は「たわらノーロード」の「先進国株式」と「先進国リート」を買い増し。
「eMAXISバランス8資産均等型」と「ニッセイ4資産均等型」は引き続き積み立て。

利用サーバーのレビュー

・Mixhost
2016年は新たにMixhostを契約しました。
これは、レンタルサーバとVPSの中間くらいのサーバです。
細かく設定を変えたいけれど、VPSのようにセキュリティを気にするのは面倒だという場合にぴったりです。

Mixhostのメリット
最新のPHP7系バージョンが使える。SSLを無料で使える。SSL対応するとHTTP2に対応。LiteSpeedに対応（ApacheやNginxよりも高速という話）

Mixhostのデメリット
サポート専用のやりとりを保存できる専用ページがとても使いやすいが、肝心のサポートの内容が不満。
返ってくるのはヘルプページに書いてあることばかり。結局自己解決するしかなくなる。

PHPの高速化としてキャッシュ周りの設定を変更できるが、ドメインごとに変更することができない。
有効にすれば、ホストしている全てのドメインで有効になる。

・Xサーバー
2016年も引き続き活躍してくれました。
PHP7やSNI SSLにも早々と対応。サーバも高速で使いやすい。

ただ、パクリサイトがXサーバーでホスティングされている場合は最悪。
著作権関係で申し立てをした場合に冷たい対応をしてくださるのがXサーバー。

・その他サーバー
さくらレンタルサーバー・ムームードメイン・ロケットサーバー・ドメインキング・スタードメインは引き続き使用。

今年もよろしくお願いいたします

こんな感じで2016年も過ぎていきました。

今年も引き続き一歩一歩目標を達成していければと思います。
今年も良い年にしていきましょう！

HTTPS

今年のトレンドとして、ウェブサイトのセキュリティを高めるHTTPS化がブームになりました。

アフィリサイトも例外ではなく、やれることはやっておこうということで稼ぎ頭のサイトにSSLを導入しました。
リダイレクトの失敗などもありましたが、ウェブマスターコンソールの「クロールエラー」の解消法なども発見できたのは良かったと思います。

少し前まではSSLの導入にもかなりのコストがかかりました。
サーバーグローバルIPを購入したりSSL証明書の価格も高いものでしたが、最近ではグローバルIPが必要ない「SNI SSL」などもありますから、
低コストでSSLを導入できるようになりました。

ただし、導入よりもSSLをやめたくなった時の作業のほうが面倒なので、どのサイトをHTTPS化するかは見極めが必要になりそうな感じがします。

モバイル対応

今年はスマホでのアクセス割合がさらに上がりました。手持ちサイトでは約8割のアクセスがスマホになっています。
正直ここまでスマホアクセスが増えるとは思っていませんでした。

スマホでのアクセスが快適になるように、要点を分かりやすくしたり、サイトの高速化（詳しくは後述）などのチューニングを行いました。
データ上でもコンバージョン率の上昇を確認できたのはうれしい経験でした。

また、スマホとともにタブレットでのアクセスも増えてきています。
手持ちのテンプレートのタブレット対応なども行いました。

サイトの高速化

モバイル対応とも関連しますが、2015年後半はサイトの高速化に取り組んだ日々でした。
以前に特典としていた自作ウェブサイトテンプレート（人気が無くひっそりと公開していたものです 笑）をこまめに更新しているのですが、
今年は高速化のためにチューニングを行いました。

サイト表示にかかる時間として、初回アクセスで500ms(0.5秒)以内・JavaScriptやCSSをキャッシュした状態では100ms以内を実現しています。
また、GoogleのPageSpeed Insightsでサイト評価100点を達成しました。

スコアだけを目指すのではなく、サイトのデザインや利便性を損なうことなくバランスのとれた高速化が必要になってきます。
ウェブサイトの高速化のために施策した主なポイントは以下のとおりです。

・リクエスト数を減らす
モバイルの低速回線などは、ファイルサイズを減らすよりもリクエスト数を減らしたほうが、体感的に早く感じます。
例えば、10KBの画像を5つ表示するより、50KBの画像を1つ表示するほうが体感的に早く感じるということです。

LTEなどの高速回線では違いは感じませんが、応答時間の遅い低速回線だとリクエスト数を減らすほうが効果的でした。

・小さい画像はBase64エンコード
画像をそのまま表示するのではなく、Base64エンコードしhtmlに埋め込むと、その画像分のリクエスト数を減らせます。

PHPが使えれば、base64_encodeで画像のキャッシュも可能になります。

・JavaScriptの最適化
多くのサイトではjQueryが使用されています。
また、その他にもサイトに使うためのJavascriptファイルを読み込むのが一般的です。

しかし、PageSpeed Insightsでは「レンダリングブロックjavascript」を排除するよう警告が出る場合があります。
読み込み時に「sync」をつければ警告は消えますが、jQueryを最初に読み込む必要がある場合は他のJavascriptでエラーが出てしまいます。

そこで、サイトで使うjavascriptを一つにまとめてしまうのが効果的でした。
jQueryを先頭に、サイトで使うJavascriptを一つのファイルに記述します。そしてbody直前で読み込むようにします。

結果的にjavascriptを読み込む前にページの表示が可能になると思います。
ChromeのChrome DevToolsのnetworkタブで確認すると、DOMContentLoadedの後にもJavascriptの読み込みが続いているのが確認できます。

同じようにCSSも、ファーストビューに必要なものはインライン化し、その他の装飾に必要なCSSはbody直前に読み込みます。

・画像の最適化
画像はなるべくサイズを削ります。
作業が面倒な場合はPageSpeed Insightsの結果ページ下部の、「このページ向けに最適化された画像、JavaScript、CSS リソースをダウンロードできます」
から最適化された画像をダウンロードできます。

また、アイコンなどはWebフォントで代用できます。
拡大縮小しても綺麗なままなので色々と使える場面があると思います。

SEO

最近のSEOは、「いかにGoogleにサイトの内容を理解させるか」ということだと感じています。

Google日本はアルゴリズムもスタッフの技術も、本家のGoogle.comに追いついていないような気がします。
ですから、「Googleのアルゴリズムは理解してくれるだろう」という考えではなく、「細かいニュアンスまで指定して認識させる」ことが必要ではないかと思います。

構造化データの使用なども推奨されてきていますが、これはGoogleのアルゴリズムの限界があることの裏返しではないでしょうか。
個人的にここ数ヶ月は、JSON-LDとschema.orgを使用した構造化データ対策を進めてきました。

どれほど効果があるか分かりませんし、Googleの仕様変更によって無駄になる場合もあるかもしれませんが、できることはいろいろと実験していきたいと思います。

ということで、今年のアフィリエイト作業を忘れないように簡単にまとめてみました。

このブログは紅白を見ながら書いております。
みなさんもどうぞ良いお年をお迎えください！

スマホのアプリ開発に手を出してはや1年。

いろいろな浮き沈みを経験しました（笑）

こんなこともあり、G○○gle（○は伏せ字です）に失望したこともあり、新たな端末で開発したくもなり、
現在ではiPhoneアプリを開発しています。
（これまでのAndroidアプリのアップデートは続けています）

実は2014年の今年こそiPhoneアプリを作りたいと思い、去年の年末に準備をしていたのです。

Macとモニターを購入し、iPadやiPadMiniを揃えました。
しかし、環境が整ったことに満足し、開発を始めたのが今年の4月からでした・・。

iPhoneアプリ開発を初めて半月ほど経過し、Androidとの違いについても気づくことがあったので記事にして残したいと思います。

この記事では、これからアプリ開発をしたいと感じておられる方に、
最初に気になる疑問についてご紹介したいと思います。

それは、「開発には何が必要か」「iPhoneとAndroidどちらが良いのか」の2点です。

開発には何が必要か

iPhoneの場合

・Mac
iPhoneアプリを開発するには、MacOSが必要です。

WindowsのバーチャルPCを使うことができますが、やはりMacのPCを購入したほうが良いと思われます。
デスクトップ型のMacや、ノート型のMacBookはかなりの値段がしますから、
おすすめなのはMac miniです。

とてもコンパクトな大きさで、場所も取りません。

アプリを開発するには十分なパワーがあります。

・モニター
Mac miniは、安い分モニターがありません。

モニターに加えて、キーボードとマウスを用意する必要があります。
HDMIに対応したテレビやモニターがあればそれを使えます。

キーボードとマウスもBluetooth対応のものや、USB対応していればそれが使えます。

すでにWindowsで使っているものがあれば、Mac miniでも使えるのでお得ですよ。

・iPhone（できれば）

シミュレータで動作確認もできますが、やはり実機でのチェックをしたいところです。

iPhoneであれば、MNPなどを利用すれば一括0円で購入できるチャンスがあります。
Wifi専用にすれば月々の通信費も安くできます。

また、iPadなどがあれば、アプリの幅が広がります。

・デベロッパー登録料

アプリを公開したり、実機チェックをするためにAppleにデベロッパー登録する必要があります。
（シミュレータ確認だけなら必要なし）

為替の変動がありますが、約1万円用意しておけばOKです。

Androidの場合

Androidの場合は、Windowsの環境でそのまま開発を始められます。

Androidのスマホがあれば、実機チェックも可能です。

Androidの場合もデベロッパー登録料が必要です。

iPhoneとAndroidどちらが良いのか

利益から考えた場合

私の主観になりますが、「とにかくアプリで稼ぎたい」という観点で考えると、どちらにも一長一短があるように感じます。

ヒット&アウェイ方式で、アプリが削除されてもいいので一発当てたいというのならAndroidです。

比較的審査が緩いので、良さそうなアプリをどんどん投入していくことができます。
新着ページにのせることができれば、どんどんダウンロードされていきます。

しかし、必ずアプリを精査されるタイミングがやってきます。

そこでアプリが削除されると、他のアプリも巻き添えになる可能性が高くなり、連鎖的に削除されていくこともめずらしくありません。

しかも、Googleのサポートはあってないようなものですので、
削除の理由も漠然としたものばかりです。

殿様商売のGoogleに耐え忍びながらアプリを延命させていくことになります。

もちろん、自分が使いたいと思えるようなアプリを作れば、
自然とダウンロードされていくものです。

しっかりとしたアプリであれば削除されるリスクも少なくなります。

丁寧にアプリを育て、息の長い収入を目指すのもよいでしょう。

一方、iPhoneアプリは審査が厳しいとされています。

ですから、オリジナリティのあるアプリを開発することが求められます。

しかし、iPhoneアプリの良い所は、iPhoneユーザーはアプリを有料で購入することに抵抗が少ないという点です。

iPhoneに特別なことをしなければ、アプリを購入するのはAppleのストアでしかできません。
そして、アプリを購入するという文化があるので、有料アプリを公開するならiPhoneの方が良いと言われているのです。

じっくりとアプリを育てていくなら、iPhoneアプリのほうが良いのではないでしょうか。

サポート面から考えた場合

サポート面は断然iPhoneアプリです。

サポートといってもいろいろな場面があります。
デベロッパー登録時の不明な点、アプリが審査に通らない理由を聞く場合など様々です。

その点で考えると、開発者を大切にしているのはAppleだと感じます。

問い合わせフォームからのレスポンスも早く、疑問をすぐに解決することができます。

Googleは・・問い合わせフォームなんてありましたっけ？（笑）

リンクをたどっていき、深い階層にあるフォームなど見つけられない人もいるのではないでしょうか。

AndroidとiPhoneのデベロッパー登録をして比べてみると、サポートは断然Apple陣営であると言わざるを得ません。

まとめ

このように、AndroidとiPhoneアプリに関してご紹介しました。

どちらが良いというわけではなく、人それぞれ自分にあったプラットフォームを選べば良いのではないかと思います。

投資額が少なくても開発を始めることができ、自由度が高いAndroid。

サポートが万全で、有料アプリ購入という文化が育っているAppleのiPhone。

どちらを選んでも、自分が欲しい・他の人が欲しいアプリを開発すれば、稼ぎは後からついてくるものだと思います。

そして、何よりも自作のアプリが自分のスマホで動くのはうれしいですよ。

ぜひアプリ開発に手を出してみませんか？(^^)

これまで愛用してきたASUSのK53TA。

2年ほど使ってきたのですが、最近CPUとGPUの温度が上がるようになってしまいました。
ETS2というトラックのゲームをすると、CPUが最大96℃（Core Temp計測）になりファンも全開で回るようになりました。

そこで、分解清掃とCPU・GPUのグリス塗りかえを試してみることにしました。

こんな結果に

結論から言うと、キーボードを外してファンを掃除するだけで劇的な変化を体感できます。

アイドル状態で60℃（冬場）ほどだったのが、40℃ほどに低下しました。
ファンも軽やかに回る音がします。

K53TAのキーボードは簡単に外せるので、まずはファン清掃がおすすめです。

私のK53TAは、清掃前こんな感じでした。
汚い・・

毎日拭きあげで手入れしているのに・・

ファン清掃の効果に味をしめて、CPUのグリス塗りかえもしてみました。

AS-05という銀グリスです。

その結果、アイドル温度にそれほど違いはないのですが、
負荷時に温度が上がりにくくなり、温度が上がった場合もすぐに下がるようになりました。

以前に96℃に達したETS2も、グリス塗り替え後には60℃ほどで抑えられるようになりました。

K53TAの分解

K53TAを分解するにあたって参考にするサイト一覧です。

Wikiを見れば分解の流れが分かります。
http://k53ta.wiki.fc2.com/wiki/%E5%88%86%E8%A7%A3

また、動画で分解の流れも確認できます。
https://www.youtube.com/watch?v=zOwJWdHbjVY

私の分解写真もこのページでご紹介しますが、グリス塗替えが初体験のため参考程度にみていただけると助かります(=ﾟωﾟ)ﾉ
いろいろと突っ込みどころがあると思います・・

まずはWikiを参考にしながら、裏面のビスを外します。

キーボードを外すだけなら、赤丸のビス（本体にKの刻印あり）を外すだけでOKです。

HDDを外します。
向かって左側にずらして端子を引き抜きます。

アンテナコネクタと電源コネクタを外します。
真上に引き抜きます。
ドライブネジを外すと、DVDドライブを引き抜けるようになります。

キーボードの爪をマイナスドライバなどで引っ込めながら、キーボードを外します。
裏側にコネクタがありますので、慎重に裏返します。

コネクタの黒い部分を上に引き上げます。基板側が支点となり、90度開きます。
すると配線シートの押さえがなくなり、引き抜けるようになります。

各種コネクタを外していきます。

青色の配線の部分は、基板側のクリーム色の部品を上に引き上げます。
基板側が支点となり、90度開きます。

この写真では勢い余って外れてしまいました・・

上部のコネクタ類も外していきます。
白・青・赤・黒配線のコネクタはそのまま引き抜きます。

「MB」と書かれている配線も外します。

ここまで外したら、表面カバーを外します。
爪で留めているだけなので、簡単に外せます。

いよいよ基板が見えてきました。

ホコリで汚い・・

このコネクタは横に引き抜くと外れます。

ヒンジ部分のコネクタは、上に引き上げると外れやすいかと思います。

モニターコネクタ横にあるネジを外すと、ボードが外れます。
裏返したボード表面。

ファンとヒートシンクのビスを外します。
まずはファンの分解清掃から。

既にキーボード外しのみで清掃済みのファンです。
掃除機での吸引で以外にキレイです。

しかし、細かい部分のホコリが残っています。

綿棒できれいにします。

外部につながるフィン部分もほこりが詰まっていました。
綿棒で清掃した後、裏側から息を吹き込むとほこりがきれいに取れました。

ヒートシンクのCPU接面です。
古いグリスが付いています。

無水アルコールと綿棒で洗浄します。

CPUの古いグリスです。

GPUの古いグリス。

CPUとGPUの古いグリスをきれいにします。

いよいよ新しいグリスの塗りつけです。
今回使うのは、AS-05という銀グリスです。

発売先から説明書がダウンロードできます。（PDF）
http://www.ainex.jp/data/as-05_mnl_web.pdf

CPUに米粒程度グリスをのせます。
（量に関しては個人差あり？？）

グリスを薄くのばします。
同じようにGPUにもグリスを塗りつけます。

ボディーのホコリもできるだけきれいにしました。

基板表面も軽くホコリを落とします。

これで分解清掃とグリスの塗替えが完了です。

後は逆の手順で組み上げて完成です！

AS-05は200時間ほど経過してから最大性能を発揮するようです。

これからどのように変化していくかが楽しみです！

確定申告の時期になると、忙しく書類を作る方も多いのではないでしょうか。

専業の方はもちろん、副業の場合も一定の条件を満たせば確定申告が必要です。
ある場合は税金が戻ってくる場合もありますので、じっくりと計算すると良いかもしれません。

今回は、アフィリエイターの確定申告ということで、
Amazonアソシエイトの源泉徴収についての情報をシェアできればと思います。

今年も、友人（といっても10歳以上年上の方です。でもとても親しくしていただいている。）のスゴ腕税理士さんに、一緒に書類の仕上げをお願いしました。

Amazonアソシエイトに関しても申請の仕方を教えていただきました。

おことわり：大まかには全国共通だと思いますが、詳細な点は地元の税務署にご確認ください。

Amazonの手続きが変わった

今回、確定申告で悩むのはAmazon側での変更があったからです。

それがこちら。

http://affiliate-blog.amazon.co.jp/2013/12/chosho.html

支払調書の送付停止のご案内

Amazonアソシエイト・プログラムでは参加者様へ年度ごとに支払調書の送付を行ってまいりましたが、事務処理の簡素化のため2013年分より支払調書の送付を停止させていただきます。確定申告書等の作成に必要な源泉徴収済の所得税額は「支払履歴の確認ページ」からご確認いただけます。

必要に応じ画面をプリントアウトしてご利用いただくなどご対応をお願い致します。
―弊社による源泉徴収済の所得税額について
Associate Central（アソシエイトセントラル）の「支払履歴の確認」ページ

―紹介料獲得者情報について
Associate Central（アソシエイトセントラル）の「支払い先情報の変更」ページ

これまでAmazonに源泉徴収されていた場合は、支払調書が送付されていました。

しかし、今年から支払調書がないので、源泉徴収の証拠は管理画面の履歴のみとなりました。

そこで、今年行った手続きは以下のとおりです。

源泉徴収額を確認する

まずは源泉徴収額を確認します。

Amazonアソシエイトセントラルにログインし、ページ上部のメニューから「アソシエイトアカウントの管理」を開きます。

管理メニューの「支払い履歴の確認」を開きます。

確定成果と支払いの履歴が表示されますので、その中から「Tax Withholding」を探します。
このTax Withholdingが源泉徴収額です。

一定の額以上の支払いが行われた時、Tax Withholding としてAmazonに源泉徴収されています。

一年間のTax Withholding の額を合計しておきます。

Amazonの画面をプリント

先ほどご紹介したAmazonの管理画面には、「画面をプリントアウトしてご利用いただくなど」と表示されています。

そこで、この文面と、Tax Withholdingの画面をプリントアウトします。

ブラウザの画面で、「Ctrl」と「P」を同時押しすると、プリントすることができます。

確定申告書Bに源泉徴収額を記載

確定申告書Bに、源泉徴収額を記載します。
（Amazon以外にもあればすべて合計する）

25年度の申告書Bであれば、44番の欄に金額を記入します。
（国税庁下記URLのPDF1ページ目・44番）
http://www.nta.go.jp/tetsuzuki/shinkoku/shotoku/yoshiki01/shinkokusho/pdf/h25/02.pdf

添付書類の糊付け

添付書類台紙に先ほど印刷したAmazonのプリント画面を添付します。

25年度の申告書Bであれば、上記URLのPDF2ページ目

第二表詳細の記入

上記URLのPDF3ページ目（第二表）を開きます。

「所得の内訳（所得税及び復興特別所得税の源泉徴収税額）」を記入します。

それぞれの情報を記入します。

所得の種類：
営業等

種目・所得の生ずる場所又は給与などの支払者の氏名・名称：
〒153-0064東京都目黒区下目黒1-8-1 ARCO TOWER ANNEX
Amazonジャパン

http://www.amazon.co.jp/gp/help/customer/display.html?ie=UTF8&nodeId=643004

収入金額：
一年間のAmazon報酬の合計

所得税及び復興特別所得税の源泉徴収税額：
Tax Withholdingの合計

まとめ

これでAmazon関係の書類作成は完了です。

友人の税理士さんはこれでいいと言っていました。

面倒な手続きや計算が必要ですが、会計ソフトを使うと計算や印刷が簡単で便利です。

最近の会計ソフトは、一度購入すれば安価で最新版にアップデートしてくれます。

やよいの青色申告などを使い印刷したものを税務署に郵送で提出するだけでOK。
混みあう確定申告会場に行かなくても良いのでとても楽ですよ！

同じアクセス数でも成約率を上げることによって、売り上げも上げることができます。

なるべく効率のよいサイトにチューニングすることで、
不労所得のサイトを増やしていくことができます。

今回は思いがけなくチューニングで良い結果が出ましたので、情報をシェアできればと思います。

15日時点での成果

2月1日頃サイトをチューニングし、15日時点での成果は以下のようになりました。

しかし、発生ですので確定成果はこれより少なくなります。

チューニングの内容

サイトのコンテンツは美容外科系で、クリニック来院での成果確定となります。

このサイトは、アクセス端末によって表示デザインを変えるように作成した（CSSの切り替え）自作テンプレートを使用しています。

先月のアクセスを解析していると、スマホでのアクセスが全体の8割ほどを占めるようになりました。

そこで、テンプレート自体はスマホ対応なのですが、コンテンツの配置もスマホに最適化することにしました。

最適化した後のコンテンツ配置図です。

パソコン・タブレットでアクセスした時の表示

スマホでアクセスした時の表示

チューニング前の問題点

このサイトでは、トップページにしっかりとコンテンツを入れています。
文字数にすると約3000文字ほどです。

個人的な感覚ですが、トップにしっかりとコンテンツがあると検索順位が安定する傾向にあるように感じていました。

しかし、スマホでアクセスした場合には、どうしてもスクロール量が多くなってしまいます。

上記のコンテンツ配置図でも分かるように、スマホの場合は「サイトメニュー」が最下部に表示されます。
そこまで表示するにはかなりのスクロールが必要です。

成果につながる広告は、サイトメニューからページ移動する必要があったので、
サイトの離脱率も高かったのだろうと思います。

実際、ユニークユーザー数とページビュー数にあまり開きがありませんでした。

そこで、まず新たにキラーページを用意しました。

キラーページには各クリニックを一覧で表示しています。

さらに、サイトのトップからキラーページへ簡単に移動できるようリンクを設置しました。

それが、上記のコンテンツ配置図（スマホ）で表示されている「キラーページへのリンク」です。

サイトを開いてすぐにユーザーが求めている情報へのボタンを表示するようにしました。

このボタンを設置したことで、ユニークユーザー数に対してページビュー数がかなり多くなりました。
サイトを回遊する時間が伸びたということになります。

そして、成果の成約率も上がるという結果になりました。

ユーザーの利便性とSEOを両立するのが難しく感じることがありますが、
今回のチューニングではそれがバランスよくできたように感じています。

今回の経験を他の手持ちサイトのチューニングにも生かしていきたいと思います。

サイト診断はじめました

サイトチューニングと関連してですが、
いいねプレミアムの特典として「サイトの診断」をお付けしております(=ﾟωﾟ)ﾉ

自分以外の第三者の目で客観的にサイトを診断することで、
これまで見えてこなかった部分が見えてくることもあると思います。

ご不明な点がありましたら、ご遠慮なくいつでもお問い合わせください！

いいねプレミアムの特典はコチラから～