博主是使用的Picgo+Jsdelivr+Github搭建博客图床，在typora里可以轻松上传图片到图床，国内访问也稳定迅速，很推荐。

起因

博主一开始的上传的都是原图，没有考虑到网站加载资源速度有限，导致了博客加载时间过长。原本以为是网络问题，在F12分析了各模块加载时间后，发现图片等静态资源加载时间较长（原背景图片2MB，加载用时1.92s）。故博主开始寻找静态资源压缩的方法，综合如下，

图片压缩
1. TinyPNG，优化幅度很高，损失很小
2. Imgbot，图片较多懒得手操可考虑，本文将记录其配置流程
css、js等资源压缩，博主使用的是gulp，感兴趣可以自行搜索教程，这里不加赘述。

Imgbot部署

简介

ImgBot 是一个为你节省时间优化图片的机器人。优化图片意味着不牺牲图片质量和更小的文件大小。安装后不久，你会收到一个优化图片的 pull request。合并这个 pull request 就行了！Imgbot 会伴随你的工作，保持图片的优化。 ImgBot 默认使用无损压缩。（翻自官方文档）

安装

首先来到 MarketPlace/Imgbot

如果未安装，右上方会显示set up a free trial

点击，选择Open Source，再点击Install it for free
检查一下，点击Complete order and begin installation
确认仓库以及设置权限，点击Install

随后会跳转到安装成功的页面，这说明Imgbot服务已经成功安装到你的Github账户

使用

Imgbot的优势在于与Github无缝集成，它会自动递归扫描你仓库里的图片文件，如果可压缩量达到设定阈值（默认10Kb），它会压缩所有图片并提交一个Pull Request并邮件通知你，你只需要检查并merge到main分支上就行。

在安装了Imgbot之后，它会开始压缩你仓库里的图片，如果图片较多，这一步可能需要几天的时间，博主是在四五天之后才收到压缩成功的邮件。提交的PR如下

看下Details，随后Merge即可。

设置

根据Imgbot官方文档，通过在根目录下放置.imgbotconfig文件来配置Imgbot

官方给的example

{
    "schedule": "daily", // daily|weekly|monthly
    "ignoredFiles": [
        "*.jpg",                   // ignore by extension
        "image1.png",              // ignore by filename
        "public/special_images/*", // ignore by folderpath
    ],
    "aggressiveCompression": "true", // true|false
    "compressWiki": "true", // true|false
    "minKBReduced": 500, // delay new prs until size reduction meets this threshold (default to 10)
    "prTitle" : "Your own pr title",        
    "prBody" : " Text before optimization ratio {optimization_ratio} Text after optimization ratio 
                 Text before optimization details {optimization_details} Text after optimization details",
}

schedule
频率，可选daily、weekly、monthly
ignorefiles
意如其名，官方的example里给了三种形式（某一后缀、某一文件、某一文件夹）
aggressiveCompression
无损压缩False，有损压缩True
compressWiki
是否优化Github Wiki
prTitle和prBody
PR的标题和内容

AutoMerge

有了Imgbot还是需要手动合并分支，偷懒得还不够彻底。这里使用Github Actions实现自动化Merge PR。

点进仓库Actions界面，new workflow -> set up a workflow yourself ,输入以下代码，文件将存储在.github/workflows中

name: Merge Imgbot  #workflow的名字

on:  				#定义workflow触发事件
  pull_request: 
    types:		
      - opened				#PR被创建
      - ready_for_review	#PR被标记为ready for review
  pull_request_review:
    types:					#PR审查通过
      - submitted			#这一部分看应用场景，这里可删去
  status: {}				#默认配置

jobs:				#定义具体任务
  automerge:
    runs-on: ubuntu-latest	#定义任务运行操作环境
    steps:
      - name: automerge
        uses: "pascalgn/automerge-action@v0.16.4" 
        env:
          GITHUB_TOKEN: "${{ secrets.GIT_MERGE_TOKEN }}"  #获取权限
          MERGE_LABELS: ""  #哪些标签的PR会被合并，空字符串表示不限
          MERGE_METHOD: "squash"  #合并方式
          MERGE_COMMIT_MESSAGE: "pull-request-description" #合并时的提交信息来源
          MERGE_FORKS: "false"  #是否允许自动合并来自 Fork 的 PR
          MERGE_RETRIES: "2"  #重试次数
          MERGE_RETRY_SLEEP: "10000" #重试间隔时间
          UPDATE_METHOD: "rebase"  #如何更新分支以使其与目标分支保持同步

有兴趣深入了解Github Actions的，参考官方文档。
配置中用到了 pascalgn/automerge-action，请注意版本，若版本过时可能会导致与ubuntu-latest间的依赖库不兼容。
此处场景PR无需审查，建议关闭Branch protection rules。

合并方式Squash：将多次commit整合为一次commit，提交记录更加简洁
源分支提交记录：
1
2
3
Commit 1: Add feature A
Commit 2: Fix bug in feature A
Commit 3: Refactor code for feature A
Squash 合并后目标分支记录：
1
Commit 4: Add feature A (包含所有变更)
Git操作rebase，将一个分支的提交历史“重新基于”另一个分支的最新状态，适用于合并分支之前同步最新的目标分支代码，git rebase 目标分支
初始状态
main分支：
1
Commit A -> Commit B -> Commit C
开发分支feature 基于B创建的，但main之后又新增了C
1
Commit X -> Commit Y
执行 rebase 后的 feature 分支：
feature 分支的提交会被摘下，并基于 main 的最新提交 C 重新应用：
1
Commit A -> Commit B -> Commit C -> Commit X -> Commit Y

这里用到了 secrets 保存 github access token，和配置 PicGo 用到的 token 一样，没用过的话可在账号设置Setting–>Developersettings–>Personal access tokens 生成
将这个token填到项目Settings –> Secrets and variables –> Actions –> secrets，名称为GIT_MERGE_TOKEN。