Sketch3で軽量なスライドを作るポイント【実証実験データ付き】

このブログでは告知をしていませんでしたが（facebookページでのみ告知してました）、3/7にふくい産業支援センターで行われる「アップグレードふくい＋プラス ～Web制作者のための仕事の作り方・向き合い方～」というイベントで登壇する事になりました。
そこで発表に使うスライドをSketch3で作っていたのですが、内容が完成してからとある事に気付きました。

今回の問題点と仮説と解決策

スライドが出来て練習も一通り出来て、主催の方にファイルを送ろうとした時に気付いてしまいました。
「ファイルサイズが大きすぎる」
という事に。
何という事でしょう。
何か重いなくらいで特に気にせず作っていたら71枚のスライドで690MBにもなっていたんです（笑）

今回のスライドはしゃべるベースなので特に配布する予定はなかったんですが、参加いただいた方には特典としてスライドデータを差し上げようと思っていまして、その際に690MBもあるファイルとか嫌がらせのようです。
それは申し訳なさすぎるので、出来る限り軽くしようと思い、原因がどこにあるのかを考えてみました。
今回のスライドが重くなっている最大の理由は、背景に使っている画像のファイルサイズかなと思っています。
というのも、横が2580px〜4000px程度の高画質な画像を使っているので、明らかにそこに原因があるんですよね。
他には、埋め込んでいるテキストの問題とか色々考えられる問題点がありました。
そこで気になる点を一つづつ実際にどうなるのかを検証してみる事にしました。
各作業と実際の経過は以下で報告します。

検証1.テキストのアウトライン

まず実験した事は、「テキストのアウトライン化」です。
文字情報ではなく、ベクターデータになる事で内包するデータ量が減るんじゃないのかなという予想です。
作業効率を良くするために、まずは絶対に最大の原因だと思える画像を全て削除した状態にします。

この時点で73.8MBです。次に、スライドの中で一番文字量が多いページのみ文字をアウトライン化します。
全部してもいいんですが、71枚全部やるともとに戻すのもめんどくさいし作業量が多くなりすぎるので、どの程度変わるのかを検証する感じで1ページ分だけにしました。
その結果が以下の通りです。

72.3MBになりました。1ページ減らしただけで1.5MBも減ると思ってなかったので、けっこう大きなポイントなんだなと思います。
予想はある程度してましたがここまで効果的だとは…。
あとでslideshareとかに流す場合は文字情報を保持した方がいいですが、今回のようにそうではない場合はアウトライン化はかなり効果的な施策です。

検証2.画像のシンボル化

次の検証したのは、「画像のシンボル化」です。
Sketch3になってからできた機能のシンボル化を行う事で、共通の画像を呼び出す形になるので、そのまま配置している場合よりもファイルサイズを押さえる事が出来るのではないかという検証です。
まずは画面サイズに調整した画像を2枚そのままの形で配置します。

73.1MBになりました。これをシンボル化したらどう変化するのか。楽しみですね。

シンボル化すると結果は73.1MB。あれ？変わってない…。というかバイト単位でいうと微妙に増えてる。
これはシンボルで配置しているデータが少ないので、シンボルのデータ分だけ増えているという事なのかなと思ったので、再度枚数を増やしてチャレンジです。
２枚だと変化が少ないので、6枚に変更してみました。

画面サイズの画像を6枚そのまま配置すると、73.7MB。これを全てシンボルの配置に変えると…

74.3MB！駄目だ！増えてる！！
という事で、シンボル化ではデータが増えるという事が分かりました。
シンボル化する事で作業の効率化はできるので、作業の効率化を優先させる場合はシンボルで、そうでなければそのまま画像は配置した方がよさそうです。

検証3.背景色の有無

次に検証したのは背景色の設定によるファイルサイズの変動です。
おそらくそこまで変化はないだろうと思いますが、少しでも軽くするためにも実験してみます。
背景設定しているのが先ほど使用した画面サイズの画像を2枚そのまま配置のファイル（73.1MB）です。
そこから背景色の指定を削除して書き出すと…

73.1MB…。バイト単位だとなぜは指定しない方が増えています。
背景色は特に気にする必要はないようです。

検証4.画像のサイズ

そして最後に画像のサイズの検証です。
ここでも先ほど使用した「画面サイズの画像を2枚そのまま配置のファイル（73.1MB）」をベースにして、配置する画像を2倍／書き出しサイズを80％にした画像と比較します。
この検証を行う理由は、画面サイズに合わせた画像が汚かったから。
せっかく高画質の画像を配置しているのに、スライドを拡大すると画質が劣化するのでこれはよくないと思うんです。
写真はきれいな方がテンションが上がりますし、せっかくの高画質をいかせないというのも悔しいですしね。
そこで、RetinaDisplayの対応の時のように、画像の大きさは2倍にして書き出し時にファイズを80％に圧縮するパターンでの変化を見ました。
ファイルの解像度の差よりも縮められている画像の方がきれいになるという原則に則っての検証です。
ここでは単純にファイルサイズだけではなく、見た目のきれいさも検証します。
まずはファイルサイズ。

72.8MB。画像の大きさは倍なのに、圧縮率の影響でファイルサイズが押さえられる結果に。
では次の問題の「見た目」の部分を比較します。左が画面サイズで100％の画像、右が2倍サイズで80％の画像です。

こうやって並べて比べるとやっぱり分かりやすいです。
圧倒的に右の2倍サイズで80％の画像の方がきれいです。
拡大に耐えれるのがいいですね。

結論

これらが考えられる対応策でした。
結果としてみると一番効果があったのは実は文字のアウトライン化です。
次に画像の幅とかを倍にして書き出しサイズを80％くらいにするっていう感じの対応。
シンボルと背景画像は効果がないor逆効果という感じです。
以上の点をふまえてスライドを作り直した結果がこちら。

元が酷すぎたとはいえ、38.5MBまで減りました。
正直ここまでファイルサイズが小さくなるとは思ってなかったのでびっくりしています。
やはりきちんと検証を行って対応すると結果が違いますね。
これからSketchでスライドを作るという人はぜひご参考くださいませ。

おまけ

Sketchといえばこもりさんなので、こもりさんに質問してみたところ、「出来上がったPDFをAcrobatで最適化して保存したらいいよ」とアドバイスしていただいたので、出来上がったファイルをさらにAcrobatで保存し直しました。
その結果がこちら。

おどろきの3.8MB。さすがAcrobat。さすがのこもりさんのアドバイス。
ということで、Sketchだけじゃなく、最後の仕上げにはAcrobatも必須という事が分かりました。
ついでに気になったので、元あった690MBのファイルをAcrobatで最適化して保存してみました。
結果がこちら。

サイズは最も小さい3MBまでになりました。
これまでの苦労はいったい…。
変に小細工するより、Acrobatがあるなら何も考えずにつくってAcrobatで最適化するのが最もパフォーマンスがいいという結果になりました。
Acrobat持ってる場合はそのようにしましょう。

追記

こもりさんから追加で教えていただいた事があるので追記します。
追記する注意点は以下の2つです。

1. Acrobatがうまくいかない場合はPreview.appで開いて同じPDFで保存しなおす。
2. 保存の際に最適化ではなく縮小だと画質が劣化する。
3. 最適化の際に画像の圧縮形式が選べるので、ファイルに合わせて変更する。

Acrobatでの保存時は英語版は「Optimized PDF」、日本語版は「最適化されたPDF」になります。
それぞれ「Reduce Size PDF」、「サイズが縮小されたPDF」だと画質が劣化しますので注意しましょう。

英語版のスクリーンショット（画像提供こもりさん）

日本語版のスクリーンショット