サイトの高速化に力を入れているWEB担当者の方ならご存じと思いますが、サイトの高速化にはパターンがあります。

サイトを高速化する王道3パターン

サイト高速化の教科書的パターンが、以下の3パターンです。

1. サーバーとの通信回数を減らす
2. サーバーからのダウンロードデータを減らす
3. サーバーからの読み込みタイミングをずらす

サーバーとの通信回数を減らす

これはファイル数が多いと、それだけ何度もサーバーにリクエストを送り、サーバーもそれに応えるように何度もファイルを送ります。
この『何度も行う通信』が無駄なんですね。

通信回数を減らすにはどうするか。
ファイルを一つにしてしまうんです。

サーバーからのダウンロードデータを減らす

サーバーからのダウンロードデータを減らすのは、皆さんご存じの画像ファイルを次世代フォーマット（WebPやSVG）に変更したり、画像サイズを適切なサイズまでリサイズした物を使用する、データ圧縮して軽量化するなどの方法があります。

他にもHTMLやCSS、javascriptのコメント分や改行を減らすことで、ファイルを1Byteでも軽量化してやろうという意気込みを感じます。

サーバーからの読み込みタイミングをずらす

こちらも画像の遅延読み込みなどが有名ですね。
Googleのスピード計測はホームページが表示されるまでの時間を計測しているので、遅延読み込みを駆使して、とりあえずページが開けばいいんです。

レンダリングブロックリソースといって、HTMLを解析してDOM生成中に、文中にjavascriptが出てくるとそこでDOMの生成が一旦止まり、javascriptの解析が始まります。
javascriptを解析中はDOMの生成が止まってしまうため、レンダリングをブロックしてしまうので、レンダリングブロックリソースと呼ばれます。
だからjQueryなどはフッターで読み込みなさいって言われるんです。

Javascriptの高速化とエラーの関連性

さて、それでは何がエラーの原因となるかですが、
javascriptって文末のセミコロンが無くても、改行されてあれば、そこを文末として認識してくれます。

しかし、そのようにセミコロンを省略して記述されたjavascriptを高速化するために改行を削除した場合、どうなるでしょうか？
文末位置がわからなくなり、エラーのオンパレードになってしまいます。

私の記憶ではギャラリーを手軽に作れるfotoramaのライブラリにはセミコロンが入っていなかったと思います。
特にWordPressでホームページ制作をしている方はfotoramaプラグインと高速化プラグインは相性が悪いので、お気を付けください。

高速化プラグインでは、先ほどの通信回数を減らすために、生成するHTML内にJavascriptを展開してくれる機能がついている可能性があり、尚且つHTML内に展開する際、ありがたいことにダウンロードデータの軽量化のために改行まで削除してくれるんです。
そのため、高速化を実施することで、エラーを吐くJavascriptライブラリが存在しています。

もし、原因不明のJavascriptエラーが発生する場合、高速化機能を疑ってみてもいいかもしれません。