aratana Tech blog

ECテクノロジーで 世界をもっと楽しく もっと笑顔に

アラタナコーポレートサイトリニューアル - 技術まとめ

アラタナコーポレートサイトリニューアル技術まとめ

この記事は、aratana Advent Calendar 2017 最後の記事です。

qiita.com

皆さん聖なる夜をいかがお過ごしでしょうか?私は昨晩、サンタにパイを投げつけられる夢をみました。
こんにちは、株式会社アラタナでフロントエンドエンジニア兼人事を担当しています高見です。
12/24のクリスマス・イヴに「パフォーマンスを意識した要素監視について」の記事を書いた、空前絶後超絶怒涛のフロントエンドエンジニア、高速化を愛し高速化に愛された男、パフォーマンス向上の生みの親、菊地君(@kikuchi_hiroyuki)からバトンを受け取りアドベントカレンダー最後の記事を書かせていただきたいと思います。

11月20日に弊社のコーポレートサイトサイトをリニューアルしました。
リニューアルをするにあたってプログラムの担当をさせていただいたのですが、今回はそこで使用した技術の一部をお話したいと思います。

WordPress

Webサイトをリニューアルするにあたって、WordPressで制作することにしました。以下のような理由でこの選択にしました。

  • 社内でPHPを理解しているエンジニアが比較的多い(引継・メンテナンスを考慮)
  • 技術職でない広報チームでサイト更新がしやすいようにするため
  • 構造化マークアップの導入(プラグイン
  • AMP化の難易度の低さ(プラグイン
  • 問合せフォームの実装の容易さ(プラグイン
  • その他、サイト高速化技術を実装するにあたって便利なプラグインが多い
  • 高見がWordPressが好き

設計のしやすさも魅力の一つで、ABOUTページやRECRUITページなどのグローバルナビ・フッターナビから遷移するページは、固定ページで制作して管理画面から内容を変更できるように。 新着情報などの記事は、記事の投稿を使って更新をします。
エンジニアがソースコードを変更せずとも、なるべく管理画面から修正できるように構成しておけば、広報側で情報をサッと変更したり発信したりスピーディーにできますよね。

常時SSL

今さらですが、常時SSL化を採用しました。(正確にはTLSですが、一般的に伝わっているSSLという呼び方で話を進めます)
以前のサイトはフォーム以外はSSL化されていなかったので、今回からは常時SSLに。
国内主要企業サイトの常時SSL化は、1割程度と欧州や北米に比べるとまだまだ低いのですが、これから常時SSL化対応は必須になっていきます。

Googleが発表しているHTTPS経由で読み込まれたページの割合というのがあって、内容を見てみると右肩上がりに増えているのがわかります。

Percentage of pages loaded over HTTPS in Chrome by platform

また、Googleは公式ブログ(Webmaster Central Blog)で前々から常時SSL化におけるSEOへの影響について述べています。

SEOの話題といえば、つい先日Googleが7年ぶりに「SEOスターターガイド」を更新しました。

その中では常時SSL化がSEOに与える影響についてということは言及はされていませんが、公式で上記のような発信をしている点からも常時SSL化はSEO対策に効果があると考えたので取り入れました。
SEOに携わっている方は、このスターターガイドをしっかり見ておいたほうがよいです)

将来的には、ServiceWorkerを使ったPWA(Progressive Web Apps)の存在があります。
来るべきこの技術を組み込む際に常時SSL化は必要なので、現段階で常時SSL化しないという選択肢はなかったです。
(今だにフォームが存在するのにSSL導入していないWebサイトを見かけますが、恐怖しかない......)

HTTP/2

SEOの話が出てきたところでWebサイトの高速化の話をしようと思うのですが、Webページの表示速度はSEOに影響があるのかないのかという議論はよく巻き起こります。 個人の見解としては少なからず検索結果のランキングに影響を与えると思っています。
GooglePageSpeed Insignを準備しており、サイトの速度改善を促しているあたり影響を垣間見ます。
そもそも表示速度の遅いサイトはページの離脱に大きく影響しますので、速い方が優位であることは間違いないでしょう。

そこでHTTP/2の登場です。
Googleが2009年にSPDYを発表してから、早8年。HTTP/2として生まれかわった?プロトコルを日常的に使える時代になってきましたよ。
既にFacebookTwitter、大手サイトでは実装されている技術で、今までHTTP/1.1で必死に高速化していた苦労がHTTP/2の登場で改善されます。
地球に生まれてきて良かったです。

HTTP/2Webサイトの利用率
https://w3techs.com/technologies/details/ce-http2/all/all

HTTP/1.1はパイプライン方式

HTTP/1.1はパイプラインという仕組みでできており、1つのドメインからリクエストを送信する場合、クライアントからサーバにリクエストを送信してレスポンスが返ってこないと次のリクエストが送信できません。 そうなると画像やファイルへのリクエストが多ければ多いほど、サーバとのやり取りが増えるので、世のエンジニアたちは高速化を実現するためにリクエストを減らす努力をしてきました。(例えば、CSSスプライトや画像のインライン化など) また、逆にリクエストできる数を増やすために、ドメインシャーディングなども採用したこともありました。懐かしい。

※ものすごく読み込んだ本。今でも時々お世話になっています。オライリーさんはすてき。

ハイパフォーマンスWebサイト ―高速サイトを実現する14のルール

ハイパフォーマンスWebサイト ―高速サイトを実現する14のルール

HTTP/2はストリームの多重化

HTTP/1.1ではリクエスト/レスポンスがセットで、しかも終了を待たないといけないことがボトルネックになっていました。そこを解消したのがストリームと呼ばれるもので、1回のリクエスト(接続)をストリームと呼ばれる1つの仮想領域として扱い、その中で並列処理を行うことができる技術です。1回のストリームでの複数のリクエスト/レスポンスを送受信できるようになります。
実際に比較してみると以下のような差がでます。

HTTP/1.1の場合

HTTP/1.1 Network Download

HTTP/2の場合

HTTP/2 Network Download

速いぞ!HTTP/2!
とはいえ、どんなWebサイトでもHTTP/2である必要があるかと言われるとそうではありません。元々リクエストが少ない場合であったり、SSL化していないWebサイトでは意味がありません。Webサイトによって判断すべきところですね。

AMP

これまた高速化の話なのですが、リニューアルにあたってAMP(Accelerated Mobile Pages)を導入しました。 www.ampproject.org

今やパソコンよりスマートフォンでのWebサイト閲覧数が多いので、AMPのようにWebサイトを高速に表示する技術は取り入れたい。
ということで、WordPressには簡単にAMPを実装できるプラグインが存在します。 ja.wordpress.org

便利なことにプラグインをインストールして有効化するだけで実装は完了します。通常はHTMLをAMP HTMLに変換したり使用できるCSSに制限があったりと考慮すべき点が多いのですが、それを全部プラグインが変換してくれます。(対象は投稿ページです)

プラグインを有効化したあとAMP化されたかどうかは、Search Consoleで確認できます。

Search Console AMPGoogle Search Console」より

検索結果も変化します。AMP化されたページが検索結果に表示されると⚡マークがURLの横に表示されます。

AMP表示結果

このプラグインを使用する際に気をつけておかなければいけないのが、wp_headのフックポイントが存在しない点です。Google Analytics など計測用のタグをwp_headのフックポイントで出力している場合は、別途AMPのテンプレートのフックポイントを使って計測用のタグを出力するようにテーマのfunctions.phpに記述しましょう。 (2017/12/25現在のバージョン0.5.1では、管理画面からGoogle Analyticsのタグを設定できますが、現在の第5世代タグgtag.jsには対応していない模様)

また、Google Analyticsなどの計測タグ関連をGoogle Tag Managerで管理しようと思った場合、AMP用は通常のGoogle Tag Managerのタグと異なりますので、そちらの対応もお忘れなく。私は、他の広告関係や計測のタグが追加になってもすぐ対応できるようにGoogle Tag Managerで管理するようにしました。

ソースコードの最適化(圧縮・キャッシュ化)

これも高速化の技術。既によく使われている技術ですね。これもWordPressプラグインAutoptimize」で解決します。

ja.wordpress.org

このプラグインでは以下のようなことを設定しています。

  • HTML/CSS/JavaScriptソースコードの改行を消去・コメント削除
    Google botにはソースコードの美しさは必要ないため。できるだけ軽量化して速度を向上させる。)
  • CSS/JavaScriptの複数あるファイルを1つのファイルに結合
    (サーバに対してリクエストを減らすことで高速化。ファイル管理はページ毎にできるのでメンテナンス性も高くなる。)

稀に他のプラグインに影響を与えるケースがあるのでご利用はテストしてみてから。

ファイルの最適化(圧縮)

ソースコードの最適化もですが、ファイルそのものも最適化しておきたいところ。
サーバ側でHTML/CSS/JavaScriptなどのファイルをgzipで圧縮する設定をしておきます。以下はApache側(httpd.conf)での設定内容です。

<Location />
    SetOutputFilter DEFLATE
    SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png|ico)$ no-gzip dont-vary
    SetEnvIfNoCase Request_URI \.(?:exe|t?gz|zip|bz2|sit|rar|lzh|iso|7z)$ no-gzip dont-vary
    SetEnvIfNoCase Request_URI \.(?:avi|wma|wmv|mov|flv|mp3|mp4|rm)$ no-gzip dont-vary
    SetEnvIfNoCase Request_URI \.pdf$ no-gzip dont-vary
    Header append Vary User-Agent env=!dont-vary
</Location>

画像ファイルなど元々圧縮されているものは、圧縮することによりかえって容量が増えてしまうので圧縮しない設定にします。(no-gzip
この設定を実装して、HTMLのヘッダー情報を見てみると......

gzipで圧縮

圧縮されていることが確認できました。
HTTP/1.1でなくHTTP/2を採用していることで、ヘッダ部分も圧縮してくれます。ここでもHTTP/2の恩恵を受けます。ありがたや。
注意点としては、Apacheにmod_deflateモジュールがロードされている必要があるというところ。

ファイルの最適化(キャッシュ)

もう一つやっておきたいのが、ファイルのキャッシュ化。Webサイトを閲覧する度に毎回最新ファイルをダウンロードする必要はないので、ファイルに有効期限を設定しておいてブラウザにキャッシュさせます。
.htaccessに以下の記述をしました。

<Files ~ ".(gif|jpe?g|png|svg|ico|otf|ttf|eot|woff)$">
Header set Cache-Control "max-age=2592000, public"
</Files>

<Files ~ ".(css|js|html|gz)$">
Header set Cache-Control "max-age=604800, public"
</Files>

画像関連のファイルは、ほぼほぼ変更することがないので長めの2,592,000秒(30日)、HTML/CS/JavaScriptのファイルは、多少の変更があると考慮して604,800秒(7日間)に設定しています。
この有効期限の設定基準は、GoogleのPageSpeed Insightのブラウザのキャッシュを活用するというセクションに以下のような記述があったのでそれに従うようにしました。

Expires を 1 週間以上、できれば最大で 1 年間先に設定します(より広くサポートされているため、Cache-Control: max-age よりも Expires をおすすめします)。RFCガイドラインに違反するので、1 年以上先には設定しないでください。

GoogleはCache-ControlよりもExpiresでの設定を推奨しているようなのですが、ExpiresはIEの古いバージョンに対応できるためという意味だと思いました。そもそも古いIEに対応するWebサイトの作り方をしていないのでCache-Controlを採用。(Expiresを使う理由はこうだよというご意見があれば是非聞かせていただきたい。)
ヘッダー情報を確認すると有効期限が設定されていることが確認できました。

ヘッダーに有効期限を設定

構造化マークアップ

最後に構造化マークアップのお話。
SEOスターターガイドの中に「構造化データ マークアップを追加する」という項目が追加されました。
今までは構造化マークアップといえば直接SEOには関係なく、単に検索結果(SERP)ページのスニペットをリッチに表示(今はリッチ検索結果という言い方になったようです)し、CTRを向上させることが目的でした。しかし、SEOスターターガイドに記載されたことによって少なからずとも影響が出始めるという観測をしています(高見個人の見解です)。

これもWordPressプラグインで設定します。「Markup (JSON-LD) structured in schema.org」というプラグインをインストールします。

wordpress.org

構造化マークアップを設定すると検索結果の表示に変化を与えられます。
例えば、パンくずリストの構造化マークアップを有効にすると検索結果に以下のような変化が現れます。

パンくずリストの構造化マークアップ

パンくずリストの構造化マークアップをしていないWebサイトは、タイトルの下の表示がWebページのURLがそのまま表示されますが、パンくずリストの構造化マークアップを行っているWebサイトでは、タイトルの下にパンくずリスト(リンク付き)の状態で表示されます。当然、通常のパンくずリストと同じようにパンくずリストをクリックすると、該当の一覧ページであったり、トップページなどに遷移します。自分のWebサイトのCTR向上が見込めることになります。
(注:設定をしたことにより表示の変化が100%保証されるというものではありません。あくまでGoogle側が決定することで、その優位性を上げるものだと思ってください。)

Webサイトが構造化マークアップされているかどうか確認するには、AMP同様、Search Consoleで確認できます。

Search Console 構造化データGoogle Search Console」より

パンくずリスト以外にも記事・Webサイト・ローカルビジネスなどサイトの用途に応じて設定して、検索結果の情報量を増やすことが大事。
AMPも構造化マークアップができるようになっており、このプラグインと先ほど紹介したAMPのプラグインで連携できるように制作しています。(僕が作ったプラグインなので)

Google Speed Insight

では最後に、高速化など実装した結果を見てみたいと思います。GoogleのPageSpeed Insightでトップページをチェックしてみます。 https://developers.google.com/speed/pagespeed/insights/

PageSpeed InsightPageSpeed Insight」より

モバイルで88点いただきました!\(^o^)/ (パソコンは95点!)
減点要因は外部ドメインからWebフォントを使用している関係で、そのCSSJavaScriptファイルに有効期限が付与できなかったりする点なので、これはデザインを担保するためなので仕方ない。 とりあえずここまで。

まとめ

いかがだったでしょうか?
まだ紹介しきれていない技術内容も多々あるのですが、聖なる夜にこんな長い文章を最後まで読んでいただけたなんて、なんてさびしい なんて素敵なクリスマスなんでしょう!
今年もあと6日(こういうの数え日というらしいですね。俳句の季語だそうで。)ですね。これでaratana Advent Calendar 2017は終了です。最後までご覧いただきましてありがとうございました。
昨年に引き続き、アラタナアドベントカレンダーの発起人、永遠に少年の心を持ち続ける同い年の木目沢さんに敬意を表しつつ締めくくりたいと思います。

それではまた来年!良いお年を〜 (^-^)ノ

Aratana Advernt Calendar