以前作ったサイドバーのランダムリスト がちょっと負担が大きかったので改良しました。
以前作ったもの
サイドバーにランダム記事リストを作る で作ったランダムな記事リストをサイドバーに表示するものですが、 ローカルでビルド時に決まったリストを作るか、 JavaScriptでクライアント側でリストを動的に作るか、の2つの方法がありました。
この後者の方が表示するたびに変更されるし シャッフルも出来る のでこちらをつかってますが、 このリストを作る際、別にリスト用のHTMLファイルを用意して、 そこから全記事リストを取得してその中からランダムに表示する、 的な事をやっていました。
この部分を余り気にしてなかったんですが、HTMLを取ってくる際、 そもそもファイルが大きいのと、 中でサムネイル用の画像へのリンクが沢山あるので それがかなり負担になっていました。
PageSpeed Insights で見るとどのページでも全ての画像がキャッシュされてない、みたいに出てて 最初なんでだろう、と思ってたんですが、このリストを取ってきてるのが見られてたみたいでした。
新しく作ったもの
ということで、軽くするにはリストを外に置かずに ページ内に書いてしまおう、と言うことをやってみました。
上に書いた前の物も含めてGitHubに置いてあります。
基本的にはREADMEに書いてある通り入れれば使えると思います。
octopress-となってますが、
_includesディレクトリーとかを気をつければJekyllなものなら使えるはずです。
source/_includes/custom/asides/random_posts.html を見ると分かりますが、 新しいもの(Active list with a inline list)を選ぶと、 この部分に全記事リストを書き出します。
それをJavaScriptの配列の中に入れてしまってそれを使って リストを作ります。
これをやることで、いちいち外部にコネクション張る必要がなくなるので、 読み込みもかなり早くなって、 また、全部の画像を最初から読み込むことはしないので キャッシュで文句を言われる率が一気に減ったので大分よくなりました。
ただ、1つ問題があって、このブログは今で450記事程ありますが、 それ全部書き出すと、ビルド時間が20分位かかる様になってしまいました。 (これやる前は大体5分位1)。
下手すると wercker での制限時間を超えてしまいます。
実際、これと ソーシャルボタンの数をビルド時に取ってくる でやったローカルなビルドでCPUを4つとかにしておくと こちらも5分位かかるので殆ど引っかかる様になってしまいます。
8つにするとソーシャルボタンの取得は1分程度に出来ますが、 これに他も合わせるとギリギリなので難しい所。 そもそも1回更新するのに20分以上かかるのは流石に辛い。
と、思ってたんですが、いつの間にか変わったらしく 今はwerkerでは最大60分まで使えるみたいです。
wercker - docs: http://devcenter.wercker.com/docs/faq/how-to-bypass-timeouts.html
前まではno-response-timeoutという、何も出力が無かった場合に
終了する時間をデフォルトの5分から最大25分まで伸ばせる、と言う
話だったと思うのですが、
いま見てみると、コレ以外に
command-timeoutという値があって、これが各ステップの実行時間の制限になる様です。
デフォルトが25分で最大60分まで設定できるとのこと。
前に書いたままno-response-timeoutを25分に設定しただけだったので、
実行時間が25分制限のままで引っかかってた様です。
読む限りでは各ステップ60分、ということなので、 ステップを分ければ1つのテストの中でもっと長い時間色々と出来るみたいです。
実際、25分設定の時に、上のgenerateのタスクと
OctopressでJavsScriptやHTMLを圧縮する
でやったminify_html(これも10分くらいかかる)と
を入れた時、
それらを別のタスクにして別々のステップとして実行したら
合わせて40分位の物でもそれぞれが25分以下なら成功してたので
大丈夫なのかな、と。(全部で60分を超える様な物はまた違うのかも知れませんが。。。試してません。)
ということで、command-timeoutを60にしておけば時間的にはまだ余裕がありそうではありますが、
ただ、やはり20分以上かかるのはちょっといただけないので
何とか速く出来ないか、と模索してなんとかなったのを次に書きます。