Github page(Jekyll) build speed up!

Github page(Jekyll) build speed up!


종종 제 Github page는 빌드가 실패합니다. 물론 대략적인 이유는 알고있었습니다. Github page는 약 최대 13분 전후 정도의 build time을 가질 수 있는데, 이를 넘어가게 되면 pending되거나 실패합니다.

이는 github 쪽에서 page를 운영하는 정책이다 보니 딱히 해결할 방법은 없던 상태였죠. (오죽하면 image repo를 분리할 생각도 했었습니다)

1413

Self check with --profile option in jekyll

우선 빌드에 어떤 부분이 가장 많이 소요되고 있는지 찾아야합니다. Jekyll은 build 시 --profile 이란 옵션을 통해 각 파일에 대한 빌드 소요시간을 알 수 있습니다.

$ bundle exec jekyll serve --profile
Filename                        | Count |      Bytes |    Time
--------------------------------+-------+------------+--------
_layouts/default.html           |   790 | 131322.55K | 405.412
_includes/navigation.html       |   790 |  61779.70K | 266.733
_includes/header.html           |   790 |  42560.48K | 179.197
_includes/head.html             |   790 |  52723.54K | 136.753
_includes/footer.html           |   790 |  22425.51K |  88.645
_layouts/post.html              |   649 |   8993.10K |   1.292
_includes/article-content.html  |   113 |   2383.00K |   0.637
sitemap.xml                     |     1 |     95.25K |   0.518
_layouts/tag_page.html          |    40 |   1630.02K |   0.453
_includes/social-links.html     |   790 |    729.82K |   0.187
_includes/javascripts.html      |   790 |    369.82K |   0.168
_layouts/redirect.html          |   633 |    380.09K |   0.080
_includes/google-analytics.html |   790 |    318.62K |   0.074
_pages/archive.html             |     1 |    133.15K |   0.066
search.json                     |     1 |    178.49K |   0.031
_includes/main.scss             |   790 |   2453.32K |   0.03
....

아니.. 시간이 많이 걸렸던걸 알고 있었으나, 큰거만 계산해도 1075초라뇨.. :hushed:

1414

Minimize liquid

Jekyll에 대해서 좀 더 찾아보고 했는데, 성능 관련 이슈에서 말이 많이 나왔던 부분이 liquid 문법들이였습니다. liquid는 jekyll 코드의 관리와 편리한 개발 때문에 많이 사용되는 부분인데, 저 처럼 게시글이 많아서 빌드해야할 페이지가 많은 경우 liquid 문법으로 인해 build time을 굉장히 많이 잡아먹을 수 있습니다. 그래서 되도록이면 최소한으로 쓰라고 권고하고 있구요.

자 이제 속도를 위해 손을 볼 시간입니다. default.html의 경우 _includes의 데이터들을 포함한 결과라 당연히 느리고, 나머지 _includes 하위 코드들을 다시 체크해보고, 정리해야하는데요. 여기서 눈에 띈 부분이 하나 있었습니다. 상단 메뉴를 위해서 for문과 if로 제가 노출하고 싶은 페이지들만 노출했었는데요, 모든 게시글과 페이지를 빌드할 때 마다 for문을 돌고 있어서 오래걸렸던 것으로 보였습니다. 그래서 어차피 고정된 메뉴만 노출하는 형태이기 때문에 Dynamic한 코드에서 Static한 코드로 변경했습니다. (그냥 정말 Raw HTML을 찍어주는거죠)

Before

<ul class="nav__list list-reset">
  {% for page in site.pages %}
    {% unless page.name == 'tags.html' or page.name == '404.html' %}
      {% if page.show != 'none' %}
      {% if page.title %}
      <li class="nav__item">
        <a href="{{ page.url | prepend: site.baseurl }}" class="nav__link">{{ page.title }}</a>
      </li>
      {% endif %}
      {% endif %}
    {% endunless %}
  {% endfor %}
</ul>

After

<ul class="nav__list list-reset">
<li class="nav__item"><a href="/about/" class="nav__link">About</a></li>
<li class="nav__item"><a href="/archive/" class="nav__link">Archive</a></li>
<li class="nav__item"><a href="/cullinan/" class="nav__link">Cullinan</a></li>
<li class="nav__item"><a href="/phoenix/" class="nav__link">Phoenix</a></li>
<li class="nav__item"><a href="/resources/" class="nav__link">Resources</a></li>
</ul>

Wow..

Filename                        | Count |     Bytes |    Time
--------------------------------+-------+-----------+--------
_layouts/default.html           |   791 | 70615.56K | 149.066
_includes/head.html             |   791 | 52790.21K | 147.258
_layouts/post.html              |   650 |  9000.80K |   1.366
_includes/article-content.html  |   113 |  2386.38K |   0.640
_includes/footer.html           |   791 |  2164.44K |   0.602
_layouts/tag_page.html          |    40 |  1632.33K |   0.452
sitemap.xml                     |     1 |    95.39K |   0.443
_includes/header.html           |   791 |  2035.43K |   0.389
_includes/javascripts.html      |   791 |   370.28K |   0.183

기존: 405+266+179+137+88 = 1075

현재: 149+147 = 296

결국 1075 - 296 으로 779 초의 시간이 절약됬습니다. 대략 10분이 넘는 시간이네요.

페이지 정상 노출되는지 테스트하고, github page에 반영해봤는데, 기존에 커트라인에 걸쳐있던 빌드타임이 5분 내로 끝나는 안정적인 모습이 되었습니다.

More?, Optimizing images

제 잡다한 리소스가 있는 assets-of-hahwul.com 저장소에는 ImgBot 이라는 git-action flow를 가지고 있습니다. 이는 push/merge 등으로 업로드된 데이터 중 이미지에 대해서 다시 한번 압축하여 경량화 하는 작업이고 약 99퍼의 감소율을 보인 생각보다 굉장히 효율적인 task입니다. 물론 제 github page repo는 private이라 사용할 수 없겠지만(저걸로 돈을 쓰느니..) public에서 구성해서 사용하시는 분들에겐 상당히 좋은 최적화 도구로 보이네요.

References