Lei Hau'oli（レイハウオリエンジニアブログ）Engineer's Blog

開会の挨拶がてら、マネージャーの俊さんより、「高速化三原則」の講義が行われました。

５分の休憩をへて、4人のパネラーごとにグループを分け、セッションが開始されました。
内容は下記のとおりです。

セッション

高速化の自動処理(諸星)

• Compassはもう要らない、ついでにlibsassを入れてgem依存から脱却しよう
  
• CSSスプライトはSpritesmithに任せよう
  
• ベンダープレフィックスはautoprefixerに任せよう
  
• コンパイル、結合、圧縮、そんな機械的な作業はGruntに任せよう
  

JavaScriptのアンチパターン(田中)

表示速度や操作速度に影響するアンチパターンの実例紹介。
下記のサイトの内容を、個人的な見解を交えて解説。

javascript-patterns

比較的難易度の低いjQueryのアンチパターンをメインに、少しだけjavascriptのアンチパターンにも触れました。

アンチパターンは、当社のコーディング規約に乗っているような
メジャーなものから、ちょっと考えつかないようなマイナーなものまで。

セッションと言うよりも、解説の合間に、参加メンバーに対してちょこちょこ
質問するという形式で進めました。

ファイル軽量化テクニック(中根)

• HTMLの縮小化は必要か？(Googleが推奨するHTMLファイルの記法とか)

  • HTMLファイルの容量は減るが、Googleは規模が桁違いで比較するべきではなく、不都合もある可能性があるので真似なくていい。

• Gzip圧縮について(HTMLのタグ構成やCSSのプロパティの順番との絡み)

  • 文字列に関係するのでHTMLが全部divだったりすると圧縮率は高い、でもそれだとマークアップの意味ないからしなくいい。
  • CSSプロパティの順番も関係するけど手作業で行うにはコスパ悪いので、やるならCSScomb使うべき。

• なぜCSSは縮小しなければならないのか(CSSのレンダリングブロックとか)

  • レンダリングブロックがあるのでCSSは極力軽くしよう
  • レンダリングブロックの説明
    →3MBのCSSと、3MBの画像を読み込むCSSを用意しレンダリングブロックのデモを行いました。
    CSSが完全に読み込まれるまでHTMLは表示されないので、
    このケースでは体感として画像を読み込むCSSのほうが早いという結果を見せました。

• JavaScriptの縮小化(難読化)のメリット・デメリット

  • 難読化するならリファクタが済んでからやる(後々の検証のため)
  • あえてソースを読んでもらいたいときはしなくてもいい。
  • Gruntのuglifyで、制作環境は難読化せず、納品物(アップ用)だけにuglifyかければスムース

• 画像圧縮(レスポンシブでの絡みも話します。)

  • jpegmini,ImageAlpha,imageOptim,Compressor.io,SVGOなどのツールの紹介
  • gruntでimagemin、imageoptimの説明
  • Retina用のjpeg書き出しは30%程度で十分(見た目に差異なし)
    →80%と30%で書きだしたそれぞれの画像(写真)をiPhoneに表示して、見た目に差異がないことを確認してもらいました。

リクエスト最小化テクニック(山口俊)

• Base64エンコード画像の使いドコロ　★自動化
• ファイル結合はどこまでやる？どう分ける？　★自動化
• キャッシュ（Expiresなど）
• IconFontの使いドコロ
• 順序間違いによるブロッキング
• 遅延ロードテクニック（LAB.jsとかLazyloadとかSNSボタン遅延ロード化など）
• 実例紹介

日頃、現場が離れているフロントエンドエンジニア40人あまりが、一同に集い技術について語りあいました。

お菓子や飲み物もまじえ、楽しく交流ができ、お互いの技術力向上への刺激や、モチベーションにもつながったかなと思います。