a-blog cmsで使っているJavaScriptのファイルサイズを減量した話

a-blog cmsの主にフロントエンドを担当する堀です。今回はかなりニッチな話をします。a-blog cmsのJavaScriptのサイズを削減した話です。

経緯

a-blog cmsでは、Ver.2.8以降、モダンなフロントエンド開発環境にするべく、WebpackやBabel、Reactなどの整備をスタートしました。同時に独自のモジュールシステムでインポートしていたjsを一部、JavaScriptのimport文に切り替えたりしました。

Webpackに切り替えたことによってnpmのエコシステムに乗っかり以下のようにフロントエンドの力が試されるリッチな機能を比較的短期間で作れるようになりました。

  • 2.8の時は、LiteEditorやナビゲーションモジュール、SmartPhoto、クイックサーチ機能
  • 2.9の時にはプレビュー機能、管理メニューのカスタマイズ機能
  • 2.10ではメディア機能

ただ、2.10の時期になるとnpm、Webpackに頼りすぎたためその歪みもでてきました。

フロントで使うindex.jsのbundleサイズが52KB（非圧縮時95KB）、管理画面で使うadmin.jsが156KB（非圧縮時 269KB）なのに対し、フロントとindex.jsとadmin.jsが共通で使うvendor.chunk.jsも967KB（非圧縮時2.16MB）ありました。

そのため、CMSにログインしているユーザーの場合だと、画面が開いた時点でだいたい1MB近くのJavaScriptを読み込むことになってしまっていました。

これはパフォーマンス的にも非常によろしくないので、もう少しバンドルサイズを小さくしようという話になりました。

JavaScriptのファイルサイズ削減は画像などのファイルサイズ削減よりも重くパフォーマンスに影響します。ファイルサイズを減らすことによってページがロードされてから動作可能になるまでの時間が削減できます。

どのように削減したか

ではどのように削減したか紹介していきます。

  1. Webpack Bundle Analyzerの活用
  2. core-jsの見直し
  3. dynamic importの積極利用
  4. CacheGroupの利用

1. Webpack Bundle Analyzerの利用

まずはnpmから利用しているパッケージの何が大きな割合をしめているか把握したかったので WebpackBundleAnalyzerというWebpackのプラグインを利用しました。以下のような結果になりました。このようにvendor.chunk.jsが非圧縮時2MBという結果でした。これはa-blog cmsのフロント画面で、組み込みjsを利用する際、または管理者の場合は必ず読み込まれるJavaScriptなので、まずはこのvendor.chunk.jsで使わないであろうモジュールを削ぎ落として減量する作業が必要でした。

2. core-jsの見直し

まずはこの部分の対策からスタートしました。

core-jsというライブラリで、a-blog cmsはIE11まで対応しているのでこのライブラリの導入がマストでした。 core-jsは、モダンブラウザーでは実装されていて、古いブラウザーだと実装されていないJavaScriptの機能をpolyfillするためのJavaScriptです。

core-jsでは各機能ごとにpolyfillが提供されています。当初はどのpolyfillが使われるのか予想がつかなかったのでcore-jsのすべての機能を読み込んでいました。 ただそれだと必要のないpolyfillまで使われることになるので2.10でみなおしました。 具体的には以下のようにbabelの設定をみなおし、ソースコード内で使われていて、ターゲットのブラウザにない機能をpolyfillするようにしました。

['@babel/preset-env',
  {
    useBuiltIns: 'usage',
    corejs: 3,
    targets: {
      ie: 11,
      firefox: 30,
      chrome: 55
    },
  }
],

babelでは@babel/preset-envというプリセットを利用すると、useBuiltIns: 'usage'とオプションを指定することで自動で使われている機能だけをPolyfillしてくれます。 useBuiltin: 'usage'は@babel/preset-envを7.4以上で利用することができます。 その結果、core-jsが実際に必要なモジュール（js）に使用されるようになるので、vendor.chunk.jsからはcore-jsがほとんどなくなりました。 これで非圧縮時のバンドルサイズが1.96MBになりました。

3. dynamic-importの積極利用

dynamic-importとはJavaScriptを必要なタイミングでJavaScriptから読み込む仕組みです。dynamic-importを積極的に利用することによってBundleされるファイルにはロード時に本当に必要なモジュールしか読み込まれないためBundleサイズの削減が見込めます。

とくにa-blog cmsの場合は、vendor.chunk.jsに依存モジュールを大量に溜め込んでいたため特に効果がありました。これによりBundleサイズが一気に非圧縮時のバンドルサイズが581KBにまで削減されました。

4. Cache Groupの利用

最後に検討したのがWebpackのCache Groupの導入です。どのモジュールでも共通で使われているモジュールをグループ単位で別のモジュールとして吐き出しておく設定ができます。実際に以下のように、styled-componentprop-types, react react-dom`が共通で使われていたのでそれらを抜き出してCache Groupに設定しました。Webpack.config.jsでは以下のように記述しました。

optimization: {
  splitChunks: {
    name: 'vendor',
    chunks: 'initial',
    cacheGroups: {
      vendorAdmin: {
        test: /styled-component|prop-types|react|react-dom/,
        name: 'vendor-admin',
        chunks: 'initial',
        enforce: true
      }
    }
  }
},

これでvendor.chunk.jsの中から、reactやreact-dom、prop-typesなどのモジュールを追い出すことができたので最終的にバンドルサイズは213KB（非圧縮時 385KB）になりました。先ほどの画像と見比べてみると、reactやprop-typesなどのモジュールがなくなっているのが確認できると思います。

まとめ

今回は特に改善が必要だった vendor.chunk.js に焦点をあてて記事にしましたが、結果的にvendor.chunk.jsは213KBに、index.jsは58KBに、admin.jsも27KBになり、最初に最低限読み込まなければいけないjsが300KB以内に抑えられるようになりました。1MB超→から300kBということで今回の一連の改善はかなりの効果がありました。この改善は a-blog cmsのVer.2.10.18から適応されています。 新機能を開発するのも大事ですがパフォーマンスなどに目を配ることも大事ですね。

Ver.2.10をお使いの皆さんはJavaScriptの改善が見込めますのでぜひバージョンのアップデートをご検討いただけたらと思います。 最後までおつきあいいただきありがとうございました。

Google Chrome（バージョン: 79.0.3945.79） でセレクトメニューのスタイルが崩れる不具合について

最新版のGoogle Chrome（バージョン: 79.0.3945.79）にて、セレクトメニューのスタイルが崩れてしまう不具合を確認しています。

ご迷惑おかけしてしまい大変申し訳ございませんが、お早めにご確認いただきますようよろしくお願いいたします。

影響している箇所

  • 管理画面のセレクトメニュー
  • acms.cssを使用したセレクトメニュー

この不具合はVer.2.0以上のバージョンで確認されています。

対応方法

以下のようにCSSを上書きすると解決されます。

/* acms.css に対応した記述 */
.acms-form select,
.acms-form select:hover,
.acms-form .acms-form-select
.acms-form .acms-form-select:hover  {
  -webkit-appearance: none;
}

/* 管理画面・閲覧側の編集画面のUI に対応した記述 */
.acms-admin-form select,
.acms-admin-form select:hover,
.acms-admin-form .acms-form-select
.acms-admin-form .acms-form-select:hover {
  -webkit-appearance: none;
}

管理画面側の対応

管理画面の修正方法ですが、上記のコードを themes/system/include/head/admin-css.html に追記します。

<link href="/css/normalize.css" rel="stylesheet">
<link href="/css/acms-admin.min.css" rel="stylesheet">
<link href="/css/acms-system.css" rel="stylesheet">
<style>
.acms-admin-form select,
.acms-admin-form select:hover,
.acms-admin-form .acms-form-select
.acms-admin-form .acms-form-select:hover {
  -webkit-appearance: none;
}
</style>

@include("/include/head/blog-color.html")

この現象は次期バージョンで修正予定です。

使われているGoogle Chromeで発生していなくても、Google Chromeのバージョンアップは自動で行われますのでお早めに対応いただくことをお勧めいたします。

実装がわからなくてもa-blog cmsで制作するサイトのデザインを考えるための4つのポイント

こんにちは。
普段はあまり表に出ないアップルップルの中の人のデザイナーです。
3年ぐらいのブランクのあるアップルップル出戻り社員なのですが、出戻る前はデザインとa-blog cmsの簡単な実装も行なっていたものの、出戻ってからは一切実装を行なっておらず、バージョンアップして様々な機能追加や仕様の変更があり、今のa-blog cmsの実装については正直よくわかっていません_(:3 」∠)_。ですがa-blog cmsで実装するWebサイトのデザインを担当しています。

a-blog cmsのこと
コードの書き方とか細かいことはいいから
ざっくり分かるように教えて！

新しいCMSを導入するのにあたってハードルになるのは学習コストかなと思います。エンジニアはそのCMSのことを勉強して実装方法を習得しますが、実際に実装するわけではないデザイナーも、そのCMSのことをある程度学習しなくては、デザインができません。

しかし、デザイナー向けのドキュメントなんてありませんし、エンジニアと同じドキュメントを見て学習するには、ややこしい用語やらなんやらでてきて時間がかかりすぎるし、どこまでそのCMSのことを勉強するべきなのか悩むところではないかなと思います。

そこで本記事では、デザイナーのために、「a-blog cmsのこの部分だけ把握しておけばデザインができるポイント」を解説したいと思います。

とりあえず抑える4つのポイント

  1. 基本的なテンプレート／top index entry × ブログ・カテゴリー
  2. HTMLがわからなくてもリッチな見た目のWebページが作れる／エントリーユニット
  3. Webサイトを動的にするためのパーツ／モジュール
  4. 固定の入力枠を任意で作れる／カスタムフィールド

1. 基本的なテンプレート／top index entry × ブログ・カテゴリー

※1ページのみのランディングページのようなサイトを作る場合には、この項目は読み飛ばしてOKです！

テンプレートファイルについて

Webサイトは大抵階層構造になっていますが、a-blog cmsのテンプレートもその考え方が適応されます。

top … トップページ
index … 一覧ページ
entry … 詳細ページ（だいたい記事というかコンテンツが置かれるページ）

この3パターンを基準にテンプレートファイルが置かれるため、この3パターンを基準にデザインを作成すればOKです。

ブログとカテゴリーについて

「ブログ」というのは、サイトのコンテンツを分類するための言わばカテゴリーのようなものですが、a-blog cmsには「ブログ」の他に「カテゴリー」も存在します。
この「ブログ」と「カテゴリー」は、実装上ではできることが異なるため、使い分けされますが、デザインをする上ではこの2つは特に区別しなくて大丈夫です。実装する上でブログを使ったりカテゴリーを使ったりするので、「ブログ」と言われても「カテゴリー」と言われても、「コンテンツの区分けなんだな」ぐらいに思っておきましょう。

ブログ内にはブログ・カテゴリーが作成できます。
カテゴリー内にブログを作成することはできません。

この「ブログ」や「カテゴリー」ごとに、先ほどの top index entry を設置することができます。

ブログやカテゴリーに、3種類のテンプレートが適用できます。

サイトの階層構造としては、こんな形でデザインを作っていけます。

2. HTMLがわからなくてもリッチな見た目のWebページが作れる
／エントリーユニット

「ユニット」はa-blog cmsの特徴とも言えるブロック型のエントリー更新システム。
「ユニットグループ」は「ユニット」をグループ化し、例えば特定のユニット群を2カラムにレイアウトしたり、背景色をつけたりするなどができる機能です。こちらについては必要があればスタイルを用意する程度でOKです。

ここについてはエンドユーザーの方が利用する部分であり、難しい操作はないので、どのような動作になるのかは、ablogcms.ioなどで実際に触ってもらうのが早いかなとは思いますが、デザインを作るべき項目をリストアップしておきます。

ユニットのデザインのパターン例

エントリーユニット

テキストユニット

  • 見出し（大／中／小）
  • 本文（フォントサイズと行間の設定）
  • リスト（ul／ol）
  • 引用（blockquote）

画像ユニット・地図ユニット

  • 全幅(1/1)、半幅(1/2)、(1/3)…

その他のユニット

  • テーブルユニット
  • 動画ユニット（必要であれば。特にデザインを用意する必要はあまりないかもです。）
  • ボタンユニット（必要があれば。ボタンのスタイルを用意します。）

またこの他にも、コンテンツによって必要なユニットの種類があれば、追加することもあります。 弊社では、コンテンツの内容に合わせて以下のパターンをよく追加しています。

見出しのパターン違い同じレベルの見出しを複数、装飾などのパターン
キャッチコピーp要素にクラスを当てて、本文用のp要素より大きいフォントを当てる
補足説明p要素にクラスを当てて色をグレーなど薄く、本文のp要素よりひと回りフォントサイズを小さくする
リンク用のリストul要素にクラスを当ててマーカーを矢印などにする
テーブルユニットのパターン違い枠有無、スマホの時に折り返すのか、スクロールするのかなど

3. Webサイトを動的にするためのパーツ／モジュール

「モジュール」とは、a-blog cmsでサイトを動的にするためのパーツのようなものです。
a-blog cmsは基本的にhtmlで実装されるため、HTMLのテーマファイルに、この「モジュール」と呼ばれるパーツのソースコードを設置して、動的サイトとして動作させます。
「モジュール」には様々な種類があり、一般的なWebサイトで使いたくなるような機能のものはだいたい揃っています。動的な部分はだいたい「モジュール」が設置されていると考えておけばOKです。

デザインする上で知っておきたい存在のモジュール

この他にもたくさんありますが、まずはこの3つを覚えておけば大丈夫です。
この他に使用するモジュールがあるようであれば、実装を担当する方やディレクターの方に詳細を聞いてください。

Entry_Body（エントリー本文）モジュール

上記でも散々話題に上がっていたエントリーです。実はモジュールですので任意の場所に設置することができます。でも大抵はentryのテンプレートファイルに設置されます。

Entry_Summary（サマリー）モジュール

エントリーの一覧を表示するためのモジュール。主にindexのテンプレートに設置されます。
一覧のためのモジュールですので、adobe XDをお使いの方はリピートグリッドを使うとこのサマリーモジュールのデザインをさっと作れます。

Topicpath（トピックパス）モジュール

現在地を表示するためのモジュール。こちらもモジュールが用意されているため、動的にできます。1ページずつ書く必要はありません。

4. 固定の入力枠を任意で作れる／カスタムフィールド

カスタムフィールドは特定の箇所に、固定の入力枠を用意できます。

用途としては、例えばパターンが決まった情報がある場合に、カスタムフィールドを作成してそこに入力することで、一覧ページで意図した情報に意図したスタイルを当てることができます。
入力できる内容は、フォームで設定できるものならなんでも。テキストはもちろん、チェックボックス、ラジオボタン、プルダウン、画像のアップロードも可能です。
カスタムフィールドが設置可能な場所は、ブログ、カテゴリー、エントリー、モジュール、ユーザーです。

おまけ

a-blog cmsでは、インストールした時点で同梱されているテンプレートファイルがあり、基本的にはそのファイルをカスタマイズしていき、サイト制作を行います。この基本のテンプレートファイルに合わせたadobe XDファイルを配布していますので、よりスムーズにデザインを行えるかなと思います。よろしければ是非ご活用ください。

まとめ

少し長くなってしまいましたが、デザインをする上では、この辺りを把握しておけば基本的には大丈夫なはずです。もしここに書いていないことが制作の際に登場したら、チームのエンジニアさんやディレクターさんに確認お願いします。
かなり端折って書いてしまっている部分もあり、分かりづらい部分もあるかと思います。ablogcms.ioを利用するなどして少し触ったりすることもオススメです。

制作の際、チームのエンジニアさんやディレクターさんと情報共有する際の一助になれば幸いです。

追伸：文字ばかりで分かりづらいですので、後日図などを追加するかもしれません。期待しない程度にお待ちください。