A long time ago, a netizen raised Issue to my GitHub Pages blog template, saying that I hope to add CDN to speed up the loading of static resources, but due to laziness, I have not moved.

Recently, I had to wait a long time for my blog to check out the Wiki. I happened to see a post last night about the correct usage of GitHub Map bed with jsDelivr CDN global Speed, which felt like a perfect fit for my needs, so I decided to take a few days off to transform it.

Look at the effect

The following loads before and after the change were recorded after caching was disabled in the Edge browser. The recording time was close and the original response speed of the two GitHub Pages services should be similar from local access.

Pre-modification loading

Note: since the loading image was not retained before the modification, this is a screenshot of a friend using the same template.

As you can see, the two longest requests took around 12 seconds, and many resources took more than 1 second to load, and pages took more than 15 seconds to complete… I don’t think the average visitor has the patience to wait.

Retrofit loading

The contrast is striking. After the transformation, the longest time is the two requests that cannot go through the CDN, and the loading time of those resources that go through the CDN is basically less than 60 milliseconds, and the page loading time is shortened to less than 3 seconds.

Of course, because the page itself is still hosted on GitHub Pages, it sometimes takes a long time for the first request to return.

The effect of the transformation can be opened to experience mazhuang.org.

Solution to consider

There are a few different ways to optimize the loading speed of independent blogs, corresponding to different solutions:

  1. Optimize the blog code, simplify the need to load resources;
  2. Deploy your blog to a fast-access server in the country;
  3. Deployment to domestic code hosting platforms such as Gitee and Coding;
  4. CDN acceleration;
  5. And so on.

I do not want to consider 2 and 3 of them, and I still expect to manage blogs only on GitHub. Therefore, 1 and 4 are the optimization directions, and the corresponding part of this article is 4.

The CDN acceleration scheme can be considered

  • Change the public library to reference public CDN links directly;

  • Static resources written and modified by yourself are hosted on a CDN service.

    Some CDN service providers provide a certain amount of free, you can choose as you like, or choose paid service. I don’t have a problem with that. After reading the first article and reading the introduction to jsDelivr, I think it makes sense: It uses GitHub resources natively, requires no configuration, is free, has nodes in China, and has good speed (works in China is also a selling point on the official website), so I decided to use it directly.

JsDelivr supports GitHub resources in a way

JsDelivr support for making is as important to promote features, the introduction of website link: www.jsdelivr.com/features#gh, here are some think need to understand the knowledge of summary:

Here I blog hosting the lot of the warehouse, for example, https://github.com/mzlogin/mzlogin.github.io, The it resources can be directly to the file path to access the https://cdn.jsdelivr.net/gh/mzlogin/mzlogin.github.io/ + warehouse.

For example, if you have a js file in your repository assets/js/main.js, It can use the CDN links to access at https://cdn.jsdelivr.net/gh/mzlogin/mzlogin.github.io/assets/js/main.js.

Advanced usage is also supported, such as:

  1. Specify a release number/commit SHA1 / branch name, e.g. specify a release resource for the repository named 1.2.0 or v1.2.0:

    https://cdn.jsdelivr.net/gh/mzlogin/[email protected]/assets/js/main.js
    Copy the code

    If you specify a version of 1 or 1.2, it will automatically match the latest version number in that range.

    You can also not specify the version or specify the version as latest, so that resources of the latest version are always used.

  2. Compress resources by adding.min to the js/ CSS file suffix:

    https://cdn.jsdelivr.net/gh/mzlogin/[email protected]/assets/js/main.min.js
    Copy the code
  3. Merge multiple files, use combine/file1, file2, and file3 format link:

    https://cdn.jsdelivr.net/combine/gh/mzlogin/[email protected]/assets/js/main.min.js,gh/mzlogin/mzlogin.github.io@1 2.0 / assets/js/simple - jekyll - search. Min. JsCopy the code

CDN links that compress resources and merge files may be slow the first time someone accesses them, and then fast again.

Other facts:

  • Can be achieved byhttps://cdn.jsdelivr.net/combine/gh/mzlogin/mzlogin.github.io [@ < version number >] / [< > folder /]This path browses the list of cached files;
  • You can visithttps://purge.jsdelivr.net/gh/mzlogin/[email protected]/assets/js/main.jsTo clear the cache of the specified file; Will be referenced in the CDN linkcdntopurgeIs it)
  • You can visithttps://data.jsdelivr.com/v1/package/gh/mzlogin/mzlogin.github.ioTo view the tags and versions lists on the CDN, see for more data interface parametersGithub.com/jsdelivr/da….

Reform steps

Here are the steps to document specific changes to your blog template:

  1. Add a control switch to the _config.yml file:

    Accelerate the CDN configuration of CSS and JS resources
    cdn:
        jsdelivr:
            enabled: true
    Copy the code
  2. Modify the _layouts file to assign a variable named assets_base_URL to represent the root path from which static resources are loaded:

    {% assign assets_base_url = site.url %}
    {% if site.cdn.jsdelivr.enabled %}
        {% assign assets_base_url = "https://cdn.jsdelivr.net/gh/" | append: site.repository %}
    {% endif %}
    Copy the code
  3. {{assets_base_URL}}, such as _includes/header. HTML: {{site.url}} {assets_base_url}}

    - <link rel="stylesheet" href="{{ site.url }}/assets/css/posts/index.css">
    + <link rel="stylesheet" href="{{ assets_base_url }}/assets/css/posts/index.css">
    Copy the code

So in case of any CDN situation, we can also be very convenient through a switch to cut back to their own resource links to restore service.

Mainly is this kind of modification, of course, there are many places involved, the above is just an example of a record of the transformation process and the transformation of the code can refer to my blog warehouse github.com/mzlogin/mzl… .

Existing problems

  • If the project has been tagged before, a new tag is required if the CDN cache needs to be refreshed after adding/modifying static resources.

    This usually happens after changing the JS/CSS of the blog template. I’m still figuring out how to skip this step.

    Update: THE solution I adopted later was to delete all the tags, so that the previous releases became Draft and were not visible to the outside world. Because my warehouse does not need visible releases, this problem is solved and I do not need to worry about refreshing the CDN.

Refer to the link

  • Correct usage of GitHub map bed, global acceleration via jsDelivr CDN
  • JsDelivr offers a free public CDN acceleration service for developers
  • Features – jsDelivr

If you are interested in my article, you can follow my wechat public account “Dull Coders” to read more content at any time.