[枯れたシリーズ] 枯れたWeb技術をふりかえる (暫定版)

# はじめに
デベロッパーたちのバイブル
　　　↓↓↓↓
[こちらを参考にさせていただきました。](https://amzn.to/34li3Yb)

# Webサイト表示を高速化する(vol.59)

## Webサイトが表示されるまでの流れ
- 1. リクエストを受けてサーバサイドが処理する時間(サーバサイド)
- 2. レスポンスを返却する通信時間(通信時間)
- 3. レスポンス情報を解読し、表示するために必要な情報を構築する時間(フロントエンド)

- 1にかかる時間がパフォーマンスチューニングの対象になることが多い
- 2,3のフロントエンドの処理に８割もの時間を費やしていることが分かった(Yahoo!inc.の調査結果)

## Webサイトの高速化とは？
- 「８割」の時間を短縮する
- WebサイトのあるWebページの表示に５秒かかっている場合、その１秒がサーバサイトの処理、４秒がフロントエンドの処理ということになる

## フロントエンドの処理

### フロントエンドを構成する要素
![webサイトが表示されるまでの処理の流れ.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/282788/20cc3294-e18a-8059-0e80-0df05ec25c73.png)

![ビズリーチのトップページの例.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/282788/1713ebca-8563-593e-05be-01249d0d6e71.png)

#### ビズリーチのトップページ
- １つのHTMLレスポンス
- ３つの外出し JavaScript
- １つの外出し CSS
- ４つの背景画像(CSSでbacground-image指定した画像)
- ３つの画像(imgタグで指定された画像)
- １つのfavicon

- 少なくとも合計１３もの要素（レスポンス)で構成されていることが分かる
- 画像数が１００を超えるリッチなデザインの場合など、それだけのリスクエストをするということ
- たとえば１００の画像を使用したWEBページの画像を１つだけにしてしまい、残りの９９の画像を使わないHTMLに変えることが出来きれば、９９個ものリスクエスト、通信、レスポンス処理が不要になる

### ブラウザの処理時間
- 受け取ったレスポンスのHTMLに記述された内容を解析し、必要なCSS/JavaScript/画像などを取得するためのリクエストをサーバへ送る
- CSSのパースや、JavaScriptの実行などもブラウザが処理し、その他の要素と併せてレンダリング（画像の描画）を行うため、ここで行われるあらゆる処理を最適化することは、Webサイトの高速化に大きな意味を持つ
- ブラウザは内部でいくつかのスレッドを持っていて、処理の種類に応じてマルチスレッドでさまざまな処理を行っている
- JavaScriptの実行など、一部の処理ではシングルスレッドのものもあり（HTML５のケースを除く）、それによって処理が待たされるケースもある

## 通信時間
- 100Mbpsの光ネットワークでさえ、32Kバイト程度の画像をダウンロードするのに62msを費やす
- 同程度の画像が１００個Webページ内に存在していたら、通信時間だけで６秒以上の時間を要している計算になる
- 通信時間を短縮するためには、とくかくWebページを構成するすべての要素の総容量を小さくすることが先決
- Contents Deliverty Network(CDN)で、そもそもの通信速度を向上させる

## サーバサイドの処理
- サーバサイドの処理に１０秒かかっていては、Webページの表示までの時間を10秒以下にすることは不可能
- フロントエンドの高速化対策はサーバサイドが基礎として成り立つ

## Webサイト高速化基本１４のルール

### 1. HTTPリクエスト数を最小限に抑える
- 小さな画像を集めて１つにする技術(CSSスプライト)などを使ってリクエスト数を抑える

#### Webページを表示するために必要なコンポーネットの例
- JavaScript
- CSS
- 画像
- iframe/frameなどの内部HTML(埋め込みのやつ)
- リダイレクトによるリクエスト制御
- Ajaxによるリクエスト制御
- Favicon

#### HTTPリクエスト１つあたりに発生するコスト
- DNSルックアップ
- 接続            (TCPコネクションの確立)
- 送信            (HTTPリクエストの送信)
- ブロッキング    (サーバ処理時間)
- 受信            (ダウンロード)

### 2. CDNを利用する
- インターネット上でコンテンツを配信するために最適化されたネットワーク
- 画像など表示に時間のかかるものをCDNサーバに保存するなど

### 3. Expiresヘッダを使用する
- Expiresヘッダの値に該当するキャッシュ有効範囲を設定する
- この有効範囲に同一コンポーネット（同一URL）へアクセスを試みた場合、HTTPリクエストを発行することなくブラウザキャッシュを利用して画面を表示できる

### 4. コンテンツはgzip圧縮する
- テキスト系コンポーネント（HTML/CSS/JavaScript)のデータ量を削減できる
- gzip圧縮されたデータを解凍してレンダリング処理をする
- サーバサイドでレスポンスをgzip圧縮することで、Webサイト全体を飛躍的に高速化できる

### 5. CSSは上に配置する
- CSSないで「＠import」を利用したり、HTMLの後半で指定するようなケースではレンダリングの遅延を招くケースがある

### 6. JavaScriptは下に配置する
- JavaScriptをHTML丈夫に記述することは（外部リンクも含む）はダウンロードやレンダリングの中断を招く可能性がある

### 7. JavaScriptとCSSは外部ファイル化する
- 外部ファイル化することでExpiresなどを利用してキャッシュさせることができる
- 実際には運用的にも外部ファイル可したほうが便利で管理上も、メリットが大きい
- 動的にCSS/JavaScriptを作り出すケース以外では外部ファイル化したほうがいい

### 8. DNS参照を最小限に抑える
- Webページの」１ページに存在するコンポーネントがさまざまなドメインからダウンロードされる際、そのドメインの数だけDNSのルックアップ処理が発生する

### 9. CSSとJavaScriptを最小化する
- CSSについてはYSlowのToolsの機能で簡単に縮小化できる
- JQueryのJavaScirptファイルも、通常155kバイトもgzipで24Kバイトになる

### 10. リダイレクトは使用しない
- YSlowなどをつかって不慮のリダイレクトが発生していないか確認する

### 11. 重複したスクリプトは削除する
- JavaScriptの重複設置など

### 12. Etagの設定を変更する
- Etag = エンティティタグ　: キャッシュしたコンポーネットがサーバ上で変更されているかを検証するための情報
- 基本的にはEtagの設定はオフにして、サーバの負荷におうじてEtagが適用されるような設定を組み込んでいくのがよい

### 13. Ajax通信はキャッシュする
- Ajax通信を１つのコンポーネットと考えると、URLクエリで一意になるレスポンスに対してはキャッシュ対象にすることが可能となり、同一のURLへの２度目以降のアクセスに対してサーバ通信を発生させずにキャッシュを利用することで、高速に動作させることができる

### 各、高速化について
- vol.59のChapter3を読む

# 参考文献
<a target="_blank"  href="https://www.amazon.co.jp/gp/product/477419686X/ref=as_li_tl?ie=UTF8&camp=247&creative=1211&creativeASIN=477419686X&linkCode=as2&tag=hurryth30-22&linkId=a85ee31a347f9fae6d7772402cc1f7f5"><img border="0" src="//ws-fe.amazon-adsystem.com/widgets/q?_encoding=UTF8&MarketPlace=JP&ASIN=477419686X&ServiceVersion=20070822&ID=AsinImage&WS=1&Format=_SL250_&tag=hurryth30-22" ></a><img src="//ir-jp.amazon-adsystem.com/e/ir?t=hurryth30-22&l=am2&o=9&a=477419686X" width="1" height="1" border="0" alt="" style="border:none !important; margin:0px !important;" />