アクトインディ開発者ブログ

子供とお出かけ情報「いこーよ」を運営する、アクトインディ株式会社の開発者ブログです

Charlesでレンダリングブロックを調査してみた

ohata tool

こんにちは ohataです。

2018/3/1に入社して、早3ヶ月経ちました。

わずか3ヶ月ですが、オフィス移転、15周年記念など会社として インパクトの大きい行事に参加させてもらいました。
(オフィスめちゃ広くなった！)

さてオフィス移転と同時にホームページがリニューアルされたのですが 表示に時間がかかっていたので、ちょっと調べて見ました。

遅い原因

サイトが重い場合はリソースの容量が関係するパターンが多いですが、 開発ツールのTimelineを見た感じ容量による影響ではなく、どこかの処理で レンダリングブロックが発生しているようでした。

しかも本番でしか発生していない、WEBあるある状態です。

調査1

大抵はjs絡みが多いのですが、念のため切り分けを行ってみます。

  1. Safari - [開発ツール]-[javascriptを無効にする]
  2. Safari - [開発ツール]-[スタイルを無効にする]

今回はCSSが原因のようでした

調査2

対象css全部をwebコンソールで調べていくのも、ちょっと辛かったので、 前にネイティブアプリ開発をやっていた際に利用していた [Charles]を使って調べて見ました。

Charlesとは

CharlesはDebugging Proxyツールです。
※ WindowsにはFreeで、Fiddlerという素敵なツールがありますね

Proxy設定

Charles をProxyとして動作させます

  1. Charlesを立ち上げる
  2. [help] - [local Ip address] を開く
  3. en0 に表示されているIP Addressを　macのproxyに設定する
  4. [Proxy]-[Record setting]-[include]に調査したいURLを設定する

ここまでがProxy設定です

cssのレスポンスを書き換える

今回はレンダリングブロックしているCSSを特定するのが目的なので、cssの処理を一度全部無効化して、 1個ずつ有効化していく事にしました。

  1. レンダリング対象を特定するために処理を無効化するように、
    空のファイルを作成します 
    touch empty.css
  2. [Tools]-[Map local]に対象のリソースと書き換え先のファイル[empty.css]を指定します ※ XMLでimportできるので今回はimportして見ました
<?xml version='1.0' encoding='UTF-8' ?>
<?charles serialisation-version='2.0' ?>
<mapLocal>
  <toolEnabled>true</toolEnabled>
  <mappings>
    <mapLocalMapping>
      <sourceLocation>
        <path>/wp-content/themes/agent_tcd033/style.css?ver=4.9.6</path>
      </sourceLocation>
      <dest>/Users/ohata.kenji/empty.css</dest>
      <enabled>false</enabled>
      <caseSensitive>true</caseSensitive>
    </mapLocalMapping>
    略

map_local_settings
スクリーンショットのように

  • [location] に書き換えたいリソース
  • [local path]に書き換え後のリソース
    が反映されます

  1. この状態でサイトにアクセスすると cssのレスポンスを empty.cssの内容をブラウザに返してくれます
  2. チェックボックスで書き換えする/しないがすぐ適用できるので、1つづつ有効にして 重くなっているcssを特定していきます。
  3. 重くなっている cssを特定できたら、そのcssをダウンロードしてきて、書き換え先のファイルに適用します
    (スクリーンショットの[update.css])
  4. あとは[update.css]をコメントアウトしたり、書き換えたりすれば、原因と改修方法が本番で確認できます

    最終的には css内で呼び出しているリソースが重くレンダリングが ブロックされていたという事がわかりました。
    css内の呼び出しリソースが開発ツールのTimelineに表示されなかったので、 現状が把握できなかった場合は一つの手だと思います。
    特にデバッグする際に開発環境を作らなくてもいいのが楽です

思った事

今回いろいろな調査をしていく中で、デザイナーさんと一緒にガガッと勧められたのがよかったです。 会社が大きくないというのもあるかもしれませんが、職種の責任範囲ではなくプロダクト目線で一緒に 動けるのは改めてやりやすいと思いました。