paranitips

Never stop learning! がモットーのゆるふわエンジニアブログ

CSS削除の前後でレイアウト崩れがないかどうかチェックするスクリプトを書いた

はじめに

「よっしゃあ、サイト高速化するぞ!」

「むむ、CSSサイズが大きいなぁ。軽量化しよう!」

「このCSS使われてないやん、、削除ー!」

・・・・・

他のページのレイアウト崩れてるやん 😇

CSSの構造が複雑になっていたので、削除の影響範囲わかんない。どうしよう。

ってことで、対応の前後でレイアウト崩れがないかどうかをチェックできるスクリプトをつくりました。

あんましnode使ったことなかったんですが、puppeteerでさくっと作れました。

流れとしては、

  1. 対応の前後でサイトのスクショを撮る
  2. スクショ画像の差分をチェックする

っていう手順です。

サイトのスクショを撮る

PATHSにスクショ撮影対象のパスを入れてます。
スマホサイトにするためにUserAgentも設定。
ディレクトリつくってそこに一括で画像保存してます。

// main.js

// iPhone X に合わせた
const DEFAULT_VIEWPORT = {
  width: 375,
  height: 812,
  deviceScaleFactor: 1,
};

const puppeteer = require('puppeteer');
const fs = require('fs');

const DEFAULT_HOST = 'https://qiita.com';

const PATHS = [
  '/',
  '/paranishian',
  '/tags/aws',
  '/tags/ruby'
]

const date = new Date();
const timestamp = date.getTime().toString();

async function run(){
  // ブラウザを起動する
  const browser = await puppeteer.launch({
    // headless: false,
    defaultViewport: DEFAULT_VIEWPORT,
  });

  // ページつくる
  const context = await browser.createIncognitoBrowserContext();
  const page = await context.newPage();

  // スマホのUserAgentにする
  await page.setUserAgent('Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.96 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)')

  // ディレクトリ作成
  fs.mkdirSync(timestamp);

  for(const path of PATHS) {
    const url = DEFAULT_HOST + path;
    await page.goto(url, {waitUntil: 'networkidle2'});

    console.log(`Done! : ${url}`);

    const filename = path.replace(/\//g, '_') + '.png';
    // スクリーンショットを保存
    await page.screenshot({path: timestamp + '/' + filename, fullPage: true})
  }

  // 終了
  await browser.close()
}

run()

さっそく実行。

❯ node main
Done! : https://qiita.com/
Done! : https://qiita.com/paranishian
Done! : https://qiita.com/tags/aws
Done! : https://qiita.com/tags/ruby

❯ ls -l 1542803191786
total 12144
-rw-r--r--  1 paranishian  www   657027 11 21 21:26 _.png
-rw-r--r--  1 paranishian  www   749702 11 21 21:26 _paranishian.png
-rw-r--r--  1 paranishian  www  2202719 11 21 21:26 _tags_aws.png
-rw-r--r--  1 paranishian  www  2599285 11 21 21:26 _tags_ruby.png

こんな感じで画像保存してます。

差分をチェックする

pixel-diffで差分をチェックします。

// diff.js

const DIFF_DIRECTORY = 'diff';

const fs = require('fs');
const PixelDiff = require('pixel-diff');
const PNG = require('pngjs').PNG;
const path = require('path');

const argv = require('yargs')
  .options({
    'a': {
      describe: '比較対象画像のディレクトリA',
      type: 'string',
      demandOption: true
    },
    'b': {
      describe: '比較対象画像のディレクトリB',
      type: 'string',
      demandOption: true
    },
  })
  .help()
  .argv;

async function checkDiff(filename) {

  // NOTE: 同じファイル名の画像がある前提なのでファイルの存在チェックはしていない
  const imageA = `${argv.a}/${filename}`;
  const imageB = `${argv.b}/${filename}`;
  const pngA = await PNG.sync.read(fs.readFileSync(imageA));
  
  const diff = new PixelDiff({
    imageAPath: imageA,
    imageBPath: imageB,
    thresholdType: PixelDiff.THRESHOLD_PERCENT, // thresholdType: PixelDiff.RESULT_DIFFERENT,
    threshold: 0.01, // 1% threshold
    imageOutputPath: `${DIFF_DIRECTORY}/${filename}`,
    cropImageB: {
      x: 0,
      y: 0,
      width: pngA.width,
      height: pngA.height,
    },
  });

  const result = await diff.runWithPromise();
  console.log(`Found ${result.differences} pixels differences in ${filename}.`);

}


async function run(){
  // diff保存用ディレクトリ作成
  if (!fs.existsSync(DIFF_DIRECTORY)){
    fs.mkdirSync(DIFF_DIRECTORY);
  }

  if (!fs.existsSync(argv.a) || !fs.existsSync(argv.b)){
    throw new Error('ディレクトリが見つかりません!');
  }

  fs.readdir(argv.a, (err, files) => {
    files.forEach(file => {
      // pngファイル以外は無視する
      if(path.extname(file) != '.png') {
        return;
      }

      checkDiff(file)
    });
  })
}

run()

引数に対象ディレクトリ名を指定して実行すると、diffディレクトリが作成されて差分画像が保存されます。

❯ node diff -a 12345 -b 67890
...

最終的にはCIに導入してmasterとの差分チェックを自動化するのが目標です。

それにしてもpuppeteerは簡単で最高ですね 🤤

どなたかの参考になれば幸いです 🤗

参考

アセットの変更がない場合、assets:precompileをスキップすることでCIの速度を改善した

f:id:paranishian:20181120150741p:plain

assets:precompileに毎回1分ほどかかっていたので嬉しい速度改善 😋

以下の記事を参考にさせていただきました 🙏
CircleCI 2.0に移行して新機能を活用したらCIの実行時間が半分になった話 - クラウドワークス エンジニアブログ

仕組みとしては、precompile対象のアセットの変更をgitのrevisionを使ってチェックして、変更があればprecompile、なければスキップする、という流れです。

自分のプロジェクトではwebpacker + react-railsを使ってるので以下を考慮しました。

  • compile対象のディレクトリ(app/javascript)の変更もチェックする
  • compile後のassets(public/packs-test)もキャッシュする

.circleci/config.yml

...
    steps:

      ...

      # precompile対象のassetsのgitのrevisionをkeyにする
      - run:
          name: create key for cashing assets
          command: |
            git rev-parse $(git log --oneline -n 1 app/assets lib/assets vendor/assets Gemfile.lock app/javascript | awk '{{print $1}}') > VERSION

      - restore_cache:
          keys:
            - asset-cache-{{ arch }}-{{ .Branch }}-{{ checksum "VERSION" }}
            - asset-cache-{{ arch }}-{{ .Branch }}
            - asset-cache

      # assetsのrevisionが変わってなければキャッシュから使う。変わっていればprecompile
      - run:
          name: assets:precompile
          command: |
            current_revision=VERSION
            previous_revision=public/assets/VERSION

            if [ ! -e $previous_revision ] || ! diff $previous_revision $current_revision; then
              bundle exec rake assets:precompile
              cp -f $current_revision $previous_revision
            else
              echo "Skipped."
            fi

      - save_cache:
          key: asset-cache-{{ arch }}-{{ .Branch }}-{{ checksum "VERSION" }}
          paths:
            - public/assets
            - public/packs-test
            - tmp/cache/assets/sprockets

どんどん改善していくでー 💪

参考

Amazon CloudFront & Lambda@Edge でリクエストに応じて自動で画像リサイズする仕組みを試してみた

Webページをすばやく表示するにはページ内画像のlazyloadや圧縮は不可欠。
けど、毎回画像を圧縮するのは手間だし自動化したい。
そして、なんかモダンな方法でやってみたい。

ってことで、調べていたらこの記事を見つけました。
Amazon CloudFront & Lambda@Edge で画像をリサイズする | Amazon Web Services ブログ

参照記事によると、

  1. リクエストのクエリパラメータに応じて画像をリサイズしてレスポンスを返す
  2. webp対応のブラウザには画像をwebpに変換してレスポンスを返す

が実現できるとのこと。

お、これ使えば画像の圧縮も簡単にできそう!!
しかもS3にオリジナルファイルを残した上で実現できるやーん 😆
さらに動的にリサイズできるからサイズ変更とか追加も簡単そう 💪

ひとまず動作検証したかったので、カスタマイズせずに記事通りにやってみました。
(画像の圧縮はOrigin-Response関数に手を加えればできるはず)

Lambda@EdgeやCloudFrontの細かい説明は参照記事におまかせするとして、参照記事では詳細な実装手順がわからなかったりつまづくポイントがあったので流れをまとめます。

Dockerで環境構築

まずはDockerでLambda@Edge関数をコンパイルするための環境を構築します。

Dockerfileを作成する

参照記事のままのDockerfileだとさっそくコケるので注意 😂
tar, gzipがなくてbuildが通らないので追加しています。

FROM amazonlinux

WORKDIR /tmp
#install the dependencies
RUN yum -y install gcc-c++ findutils tar gzip

RUN touch ~/.bashrc && chmod +x ~/.bashrc

RUN curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.5/install.sh | bash

RUN source ~/.bashrc && nvm install 6.10

WORKDIR /build

docker buildする

docker build --tag amazonlinux:nodejs .

Lambda@Edge関数の作成

View-Request関数をつくる

これは参照記事のままでOK。
lambda/viewer-request-function/index.jsに保存しました。

Origin-Request関数を作る

これも参照記事のままでOK。
lambda/origin-response-function/index.jsに保存しました。

関数のコンパイル&パッケージング

Origin-Response 関数

$ docker run --rm --volume ${PWD}/lambda/origin-response-function:/build amazonlinux:nodejs /bin/bash -c "source ~/.bashrc; npm init -f -y; npm install sharp --save; npm install querystring --save; npm install --only=prod"
$ mkdir -p dist && cd lambda/origin-response-function && zip -FS -q -r ../../dist/origin-response-function.zip * && cd ../..

Viewer-Request 関数

$ docker run --rm --volume ${PWD}/lambda/viewer-request-function:/build amazonlinux:nodejs /bin/bash -c "source ~/.bashrc; npm init -f -y; npm install querystring --save; npm install --only=prod"
$ mkdir -p dist && cd lambda/viewer-request-function && zip -FS -q -r ../../dist/viewer-request-function.zip * && cd ../..

CloudFormationの実行

zipファイルのUPLOAD

まずはS3バケットを作成し、先ほど作成したzipファイルをUPLOADします。

Lambda 関数の要件と制限 - Amazon CloudFront

トリガーを追加できるのは、米国東部(バージニア北部) リージョンの関数のみです。

とあるので、このバケットのRegionもus-east-1を使います。

f:id:paranishian:20181115180417p:plain

yamlファイルの作成

これも参照記事のままです。
cloudformation.yamlとして保存しました。
テンプレート内の<code-bucket>は上記で作成したS3バケット名を設定してください。

スタックの作成

リージョンをus-east-1に切り替えて、CloudFormationを実行します。

スタックの作成 > テンプレートを Amazon S3にアップロード で、先ほどのyamlファイルを指定します。

f:id:paranishian:20181115180451p:plain

スタックがじゃんじゃん作成されて、完了。

f:id:paranishian:20181115180511p:plain

あとは、作成されたS3バケットimage-resize-${AWS::AccountId}-${AWS::Region})に画像をUPLOADして、CloudFront経由でアクセスすればOKです。

https://{cloudfront-domain}/images/image.jpg?d=100x100

アクセスすると、画像が表示されるのと、S3にフォルダが作成されて、リサイズ後の画像が保存されています。

f:id:paranishian:20181115182206p:plain

・・・

なんか急に説明が雑になってしまった 😇

考えないといけないこと

ステキな仕組みやけど考えないといけないこと。

初回アクセスが遅い

まあわかってはいたけど。。画像処理してるわけですし 🍣 クローラーつくってクロールさせるとか、なんかシステムで自動化したいところ。

S3への画像UPLOADが遅い

バケットus-east-1になっているのでしゃあないけど実際運用するとなるとひと手間必要かなぁ。
UPLOAD用のバケットは東京Regionに作成して、us-east-1バケットにsyncするとかかなぁ 🤔

ってことで、いろいろやるべきことが多そうだし今回は見送りました。

はじめてLambda@EdgeやCloudFormationを使ったので良い勉強になりました。
実際運用できる仕組みを作ったらまた記事にします 😋

おしまい。