블로그에서 추가되는 이미지를 자동으로 최적화하기 위해 https://imgbot.net/ 을 사용하고 있다. imgbot을 사용하면, 새롭게 추가되는 이미지들에 대해서 최적화를 해주는 PR을 만들어 준다. https://github.com/yceffort/yceffort-blog-v2/pull/298 (빌드가 실패한 것에 대해선 정말 긴 히스토리가 있다, imgbot 때문이 아니다)

그러나 기존에 추가되었던 이미지들에 대해서는 최적화가 안되기 때문에, 이를 위해서 방법을 찾아보다가 아래와 같은 라이브러리를 사용했다.

## PNG

```bash
brew install optipng
apt-get install optipng
```

```bash
find . -iname "*.png" -exec optipng -o7 {} \;
```

http://optipng.sourceforge.net/

PNG의 경우에는 굉장히 오래걸렸다.

## JPG, JPEG

```bash
brew install jpegoptim
sudo apt-get install jpegoptim
```

```bash
find . -iname "*.jpg" -exec jpegoptim -m80 -o -p {} \;
```

## GIF

```bash
brew install gifsicle
sudo apt-get install gifsicle
```

```bash
find . -iname "*.gif" -exec gifsicle --batch -V -O2 {} \;
```

## GUI application

일괄적으로 모든 파일을 수정하기 위해서는 위 명령어를 사용했지만, GUI application도 있어서 필요할 때 사용하면 좋을 것 같다.

https://imageoptim.com/mac


디렉토리에 있는 모든 이미지 최적화 하기

nodejs 10.5.0 버전 이후에서 부터는 `worker_threads`가 가능해졌고, 12 LTS 부터 stable로 자리잡았다. 이 `worker_threads`는 무엇이고 어떤 역할을 하는 것일까?

## 싱글스레드 세상

자바스크립트는 브라우저에서 실행되는 단일 스레드 프로그래밍 언어로 설계되었다. 단일 스레드 라는 것은, 하나의 프로세스 (브라우저 또는 모던 브라우저의 경우 하나의 탭)에서 하나의 명령어 집합만 실행된다는 것을 의미한다.

이러한 설계는 개발자들이 언어를 사용하는데 있어서 더 쉽게 할 수 있는 요소가 되었다. 자바스크립트는 처음에 웹 페이지, 폼 유효성 검사 등의 상호작용을 추가하는데만 사용되었었는데, 이 정도 작업으로는 멀티스레딩의 복잡함이 전혀 필요하지 않았다.

그러나 nodejs의 창시자(Ryan Dahl)는 이러한 한계를 기회로 보았다. 그는 비동기 IO 를 기반으로 서버측 플랫폼을 구현하고 싶어했다. 즉, 쓰레드가 필요하지 않았다. 동시성은 매우 풀기 어려운 문제가 될 수 있다. 동일한 메모리에 접근하려고 하는 스레드가 많아지면 재현 및 수정이 매우 어려운 race condition 문제가 발생할 수 있다.

## nodejs는 싱글스레드 인가?

그래서, nodejs 애플리케이션은 단일 스레드일까? 어느정도는 그렇다.

사실 우리는 병렬로 실행할 수 있지만, 우리는 쓰레드를 만들지도 않고 이를 동기화 하지도 않는다. 가상머신과 운영체재가 IO를 병렬로 실행하며, 자바스크립트 코드로 데이터를 다시 전송해야 할 때, 자바스크립트 부분은 단일 쓰레드로 실행된다.

즉, 자바스크립트 코드를 제외한 모든 것이 병결로 실행된다. 자바스크립트 코드의 동시식 블록은 항상 한번에 하나씩 실행된다.

```javascript
let flag = false
function doSomething() {
  flag = true
  // flag를 수정하지 않는 더 많은 코드...

  // 우리는 flag가 true라는 것은 확신할 수 있다.
  // 이 코드 블록이 동기로 실행되는 이상,
  // 이 코드블록이 flag 값을 바꿀일이 없다.
}
```

우리가 처리하는 것이 모두 비동기 IO로 이루어져있다면 이러한 방식은 매우 훌륭하다고 볼 수 있다. 코드는 빠르게 실행되고, 데이터를 파일과 스트림에 전달하는 동기 블록은 작은 부분으로 구성된다. 자바스크립트 코드는 너무 빨라서, 다른 자바스크립트의 실행을 막지 못한다. 자바스크립트 코드가 실행될 때 보다, IO 이벤트가 발생할 때 까지 기다리는 시간이 훨씬 더 많다. 아래 예를 살펴보자.

```javascript
// 2
db.findOne('SELECT ... LIMIT 1', function (err, result) {
  if (err) return console.error(err)
  console.log(result)
})

// 1
console.log('Running query')

// 3
setTimeout(function () {
  console.log('Hey there')
}, 1000)
```

데이터베이스로 실행한 이 쿼리는 몇 분 정도 걸릴 수 있지만, `Running query` 메시지는 쿼리를 호출한 후 즉시 표시된다. 그리고 잠시 후 쿼리가 여전히 실행중인지 아닌지를 확인 한후, 잠시후에 `Hey there` 메시지를 볼 수 있다.

nodejs 애플리케이션은 함수를 호출할 뿐, 다른 코드의 실행을 차단하지 않는다. 조회사 완료되면 콜백을 통해 알림을 받고, 결과를 받는다.

## CPU 집약적인 작업

만일 큰 데이터를 가지고 메모리에서 복잡한 계산을 수행하는 것 과 같이, 동기 집약적인 작업을 수행해야하는 경우엔 어떻게 될까? 그렇게 되면 많은 시간이 걸리게되고, 나머지 코드를 차단하는 동기 코드블록이 생길 수도 있다.

동기 코드 실행에 10초가 걸린다고 상상해보자. 웹서버를 실행중이면, 이 작업 때문에 다른 요청이 최소 10초동안 차단된다. 100ms이상 걸리는 작업은 문제를 유발할 수 있다.

자바스크립트와 nodejs는 CPU 바인딩 작업에 사용할 수 없었다. 자바스크립트는 단일 스레드이기 때문에, 브라우저의 UI는 멈추게되고, Nodejs의 IO 이벤트를 넣게 된다.

```javascript
db.findAll('SELECT ...', function (err, results) {
  if (err) return console.error(err)

  // 겁나 오래 걸리는 작업
  for (const encrypted of results) {
    const plainText = decrypt(encrypted)
    console.log(plainText)
  }
})
```

조회가 완료되면 콜백이 실행된다. 콜백이 실행 끝날 때 까지 자바스크립트 코드가 실행되지 않는다.

일반적으로, 앞서 이야기 한 것 처럼 코드는 일반적으로 매우 작고 빠르다. 그러나 위의 예제 코드에서는, 많은 결과가 나오고, 이에 따른 많은 계산이 필요하다. 이는 몇 초 정도 걸릴 수 있으며, 이 기간 동안은 다른 자바스크립트 실행이 대기 중이 기 때문에, 동일한 애플리케이션에서 서버를 실행하는 경우 해당 시간 동안 모든 사용자가 블로킹 될 수 있다.

## 자바스크립트에서 쓰레드가 없는 이유

그래서, 많은 사람들이 nodejs 코어에 새 모듈을 추가하여 스레드를 만들고 동기화 할 수 있어야 한다고 생각한다.

만약, nodejs에서 쓰레드가 추가된다면, 이는 언어의 본질을 바꿔버리는 것이다. 단순히 클래스 또는 함수 추가 만으로 쓰레드를 만들 수는 없다. 언어를 바꿀 필요가 있다. 멀티스레딩을 지원하는 언어에는 스레드간 협력이 가능하도록 `synchronized`와 같은 키워드가 있다.

예를 들어, 자바에서는 일부 숫자 유형의 경우 원자형이 아니다. 액세스를 동기화 하지 않는다면, 두개의 스레드가 변수의 값을 변경할 수 있다. 결과적으로 두개의 스레드가 변수에 액세스하고, 하나의 스레드에 의해 몇 바이트가 변경되고, 다른 스레드에 의해 몇 바이트가 변경되므로 유효한 값을 얻지 못할 것이다.

## 일단 간단한 해결책

nodejs는 이벤트 큐의 다음 코드블록을, 이전 코드블록의 실행이 완료될 때까지 평가하지 않는다. 그래서 할 수 있는 간단한 방법 중 하나는, 코드를 작은 동기식 코드로 나누고, nodejs에 이 작업이 끝났다고 전달한 이후에 큐에서 보류 중인 것들을 계속해서 실행할 수 있도록 하는 것이다.

```javascript
const arr = [
  /*겁나 큰 배열*/
]
for (const item of arr) {
  // 무거운 작업
}
// 저 포문이 끝날 때 까지 여기는 오지 못함
```

이를 작은 청크로 나눠서 실행해보자.

```javascript
const crypto = require('crypto')

const arr = new Array(200).fill('something')
function processChunk() {
  if (arr.length === 0) {
    // code that runs after the whole array is executed
    // 모든 배열이 실행이 끝난 뒤에 실행됨
  } else {
    console.log('processing chunk')
    /// 10개만 추출
    const subarr = arr.splice(0, 10)
    for (const item of subarr) {
      // 오래 걸리는 작업
      doHeavyStuff(item)
    }
    // 다음 큐로 작업을 밀어넣음
    setImmediate(processChunk)
  }
}

processChunk()

function doHeavyStuff(item) {
  crypto
    .createHmac('sha256', 'secret')
    .update(new Array(10000).fill(item).join('.'))
    .digest('hex')
}

// 다른 작업도 가능한지 확인하기 위한 함수
let interval = setInterval(() => {
  console.log('tick!')
  if (arr.length === 0) clearInterval(interval)
}, 0)
```

이제 `setImmediate(callback)`가 실행될 때마다 10개씩 작업을 처리하게 되며, 이외에 무언가 작업할게 생기게 되면 이 작업 사이에 처리하게 된다.

그러나 보다시피 코드가 더 복잡해졌다. 또한 알고리즘은 이보다 더 복잡하기 때문에 어디서 적절히 `setImmediate()`를 배치해야 할지 알 수 없다. 게다가 이제 코드는 비동기 식이며, 다른 외부 라이브러리에 의존하게 되면 실행을 더 작은 청크로 분할해서 실행하기 어려워 질 수도 있다.

## 백그라운드 프로세스

`setImmediate()`는 간단한 시나리오에서는 쓸만했지만, 아주 적당한 해결책이라 보기 어렵다.

쓰레드 없이 프로세스를 병렬로 처리하는 것이 가능할까? 그렇다. 우리에게 필요한 것은 충분한 CPU와 시간을 활용해서 결과를 애플리케이션으로 되돌 릴 수 있는 일종의 백그라운드 처리이다.

```javascript
// `script.js`를 별도의 환경에서 실행하여 메모리를 공유하지 않는다.
const service = createService('script.js')
// 여기에 데이터를 넘기고 결과를 받는다.
service.compute(data, function (err, result) {
  // 결과
})
```

사실 우리는 이미 nodejs에서 백그라운드 처리를 할 수 있다. 프로세스를 fork 하여 메시지를 전달하는 방식으로 구현이 가능하다. 메인 프로세스에서 하위 프로세스로 이벤트를 주고 받는 방식으로 통신이 가능하다.

메모리 공유는 없다. 서로 교환되는 데이터는 모두 복제된 데이터이며, 한쪽 데이터를 변경한다고 다른 쪽에 변경이 일어나지는 않는다.

그러나 이는 해결책이긴 하지만, 이상적인 해결책은 아니다. 프로세스를 만드는 것은 리소스 측면에서 많은 비용이 든다. 그리고 느리다. 프로세스가 메모리를 공유하지 않기 때문에, 많은 메모리를 사용하여 새 가상 시스템을 처음부터 실행해야 한다.

물론 동일한 포크 프로세스를 재사용할 수 있다. 그러나 포킹된 프로세스 내에서 동시에 실행되는 서로 다른 과중한 워크로드를 전송하면 두가지 문제가 발생한다.

먼저, 메인 애플리케이션은 차단하지 않을 수 도 있지만, 포크된 프로세스는 한번에 하나의 작업만 처리할 수 있다. 10초가 걸리는 작업과 1초가 걸리는 작업이 순서대로 대기하는 경우, 두번쨰 작업을 실행하기 위해 10초를 기다리는 것은 이상적이지 않다.

또 다른 문제로, 한작업이 프로세스가 중단되면 동일하나 프로세스에 전송되는 모든 작업이 완료되지 않은 채로 남아있게 된다. 이러한 문제를 해결하기 위해서는 포크가 한 개가 아니고 여러개가 있어야 한다. 그러나 각 프로세스마다 모든 가상 시스템 코드가 메모리에 중복되므로, 프로세스당 몇 MBs의 처리시간과 부팅시간을 계산해서 포크되는 프로세스의 개수를 제한해야 한다.

따라서 데이터베이스 연결과 마찬가지로, 사용할 수 있는 일종의 프로세스 풀이 필요하고, 각 프로세스마다 한번에 작업을 실행하고, 작업이 완료된 후 프로세스를 다시 사용해야 한다. 구현이 매우 복잡해보인다. [worker-farm](https://github.com/rvagg/node-worker-farm)이라는 것을 사용해보자.

```javascript
// main app
const workerFarm = require('worker-farm')
const service = workerFarm(require.resolve('./script'))

service('hello', function (err, output) {
  console.log(output)
})

// script.js
// 여기는 포크 프로세스에서 실행됨
module.exports = (input, callback) => {
  callback(null, input + ' ' + world)
}
```

## 문제 해결?

뭐, 문제는 해결되었지만 멀티스레드 솔루션보다 훨씬 더 많은 메모리를 쓰고 있다. 스레드들은 포크 프로세스에 비해 리소스 측면에서 매우 가볍다. 이러한 이유 때문에 Worker Thread가 탄생하게 되었다.

Worker Thread에는 분리된 컨텍스트가 있다. 메시지 패싱을 활용하여 메인 프로세스와 정보를 교환하기 때문에 레이스 컨디션 문제를 해결할 수 있다. 또한 이들은 같은 프로세스에 존재하기 때문에 더 적은 메모리를 쓴다.

Worker Thread와 메모리도 공유할 수 있다. 이러한 용도로 많이 사용되는 객체 `SharedArrayBuffer`를 활용하여 객체를 전달할 수 있다. 많은 양의 데이터를 활용하여 CPU 집약적인 작업을 수행할 때만 이 기능을 사용해야 한다.

## Worker Thread 예제

노드 10버전 이상을 사용하고 있다면 `worker_threads`를 쓸 수 있다. 그러나 11.7버전 이하에서는 `--experimental-worker`를 추가해야 사용이 가능하다.

한가지 명심해야할 것은, 아무리 프로세스 포킹보다 저렴하다 하더라도 너무 많이 워커를 생성하면 리소스를 많이 사용할 수도 있다는 것이다. 이 경우에는, 워커 풀응ㄹ 만들기를 권장한다. 이 워커 풀도 마찬가지로 직접 구현하는대신, 워커 풀을 구현한 다른 패키지를 npm에서 찾을 수 있다.

간단한 예제에서 시작해보자. 먼저 Worker thread를 만드는 메인 파일을 구현하고, 데이터를 넘긴다. API는 이벤트 드리븐이지만 Promise로 감싸서 워커로부터 첫번째 메시지를 받는다면 `resolve`하도록 한다.

```javascript
// index.js
const { Worker } = require('worker_threads')

function runService(workerData) {
  return new Promise((resolve, reject) => {
    const worker = new Worker('./service.js', { workerData })
    worker.on('message', resolve)
    worker.on('error', reject)
    worker.on('exit', (code) => {
      if (code !== 0) reject(new Error(`Worker stopped with exit code ${code}`))
    })
  })
}

async function run() {
  const result = await runService('world')
  console.log(result)
}

run().catch((err) => console.error(err))
```

보시다시피, 파일 이름과 데이터를 argument로 넘기는 것 만으로도 쉽게 구현이 가능하다. 이 데이터는 복제되었다. 그런 다음 메시지 이벤트를 리슨하여 Worker Thread가 메시지를 보낼 때 까지 기다린다.

```javascript
const { workerData, parentPort } = require('worker_threads')

// 여기에서 무거운 작업을 동기로 메인 스레드를 방해하지 않으면서 처리할 수 있다.
parentPort.postMessage({ hello: workerData })
```

여기서는 메인 애플리케이션이 보낸 `workerData`와 메인 애플리케이션으로 정보를 돌려보내는 방법 이 두가지가 필요하다. 작업이 끝나면 `parentPort.postMessage`를 통해서 결과를 보낼 수 있다.

이게 접누다. 이는 간단한 예제지만, 우리는 더 복잡한 것들을 할 수 있다. 예를 들어 피드백을 보내야 하는 경우, Worker thread에서 실행 상태를 나타내는 메시지를 여러개 보낼 수도 있다. 아니면 일부 결과만 보낼 수 있다. 수천개의 이미지를 처리한다고 가정해보자. 처리된 이미지별로 보낼 수 있지만, 이 모든작업이 처리될 때 까지 기다리는 것은 좋지 않다.

https://nodejs.org/docs/latest-v10.x/api/worker_threads.html

## 웹 워커?

아마도 Web Worker API에 대해 들어본 적이 있을 것이다.

- https://developer.mozilla.org/ko/docs/Web/API/Web_Workers_API
- https://caniuse.com/webworkers

이는 웹에서 지원하는 api고, 모던 브라우저에서 잘 지원되고 있다. (심지어 IE11에서도?!) API는 요구사항과 기술조건들이 제각각이지만, 브라우저 런타임에서 유사한 문제를 충분히 해결할 수 있다. 웹 애플리케이션에서 암호화, 압축/압축해제, 이미지조작, 컴퓨터 비전(얼굴인식) 등을 수행하는 하는 경우 유용하다.

## 결론

Web Worker는 Nodejs 애플리케이션에서 CPU 집약적인 작업을 할 때 유용하다. 이는 마치 공유메모리가 없는 쓰레드로, 레이스 컨디션과 같은 문제를 피할 수 있다. `worker_threads`는 nodejs 12 LTS에서 부터 정식 지원하므로, 한번 사용해봄직하다.


nodejs의 멀티쓰레딩과 worker threads

블로그를 또 개편했다. 개편한지 1년도 안된거 같은데 화끈하게 바꿨다.

## Table of Contents

## 1. 계기

1. 관리 능력 부재로 박살난 라이트 하우스 점수
   - 그냥 가끔씩 생각날 때 마다 보던 점수였는데, 지난 번 포스팅에서 점수가 박살난 것을 보고 매우 반성. 원인은 이런저런 실험을 하다가 삽질을 한 것.
2. 보다 보니 질리는 디자인
   - 단순함이 최고라고는 하지만, 지나치게 단순했던 것 같다. 특히 태그 목록페이지는 눈뜨고 보기 어려울 정도. 그리고 다크 모드 지원도 해보고 싶었다.
3. 코드 리팩토링
   - 그 때는 나름 최선이었던 것 같지만(?) 더 이상 최선이 아닌 코드들을 리팩토링
4. styled component 를 활용한 구성의 한계
   - 디자인 고자라서 내가 아무리 css로 춤춰도 한계가 있었다. 그래서 그냥 tailwindcss를 도입하기로 했다.

## 2. 바꾼점

### tailwindcss

외국 친구들 프론트엔드 이야기를 볼 때마다 가끔씩 눈에 밟히던게 있었는데 바로 [tailwindcss](https://tailwindcss.com/) 다. 클래스를 활용해서 css를 편하게 잡아줄 수 있도록 도와주는 라이브러리인데, 나 같은 디자인 고자에게 꼭 필요한 라이브러리였다. 다만 className이 장황해진다는 점, 그리고 더더욱 css를 공부할 의지가 사라진다는 점에서 좋지 않았다. (css공부를 위해 완벽 가이드를 구매했다. 이번에는 반드시)

### mdx

이것도 외국 블로그들을 돌아다니면서 알게 된 것인데, 마크다운 문서를 파싱하는 툴로 [mdx](https://mdxjs.com/)를 많이 사용한다는 것을 알게 됐다. 기존에 내 블로그는 `remark`와 `rehype`를 unify 하여 string으로 강제로 떨궈주는 방식이 었는데, 이 때문에 부득이하게 `dangerouslysetinnerhtml`를 사용했다. 물론 나밖에 안쓰는 곳이라 보안 위험 따윈 없겠지만,,, mdx를 사용하면 string이 아닌 jsx로 바꿔주기 때문에 리액트에서 사용하기엔 안성맞춤이다.

nextjs에서 사용을 위해서 mdx를 직접 사용하지는 않고, [next-mdx-remote](https://github.com/hashicorp/next-mdx-remote)를 사용했다. 간단하게 원리를 설명하면 `getStaticProps`에서 `renderToString`를 활용하여 해당 주소별 내용을 string으로 들고 있다가 요청이 오면 이를 `hydrate`를 활용하여 jsx로 렌더링하는 방식이다. 덕분에 깔끔하게 처리할 수 있었고, 나아가 단순히 img 태그로 변환하던 이미지들도 `next/image`를 활용할 수 있도록 커스터마이징을 거쳤다.

https://github.com/yceffort/yceffort-blog-v2/blob/c19b26d17671baa4e0a7987402c9a5bfa0d6a85c/src/utils/Markdown.ts#L47-L131

`next/image` 덕분에 이미지 최적화와 lazy loading도 쉽게 가능해졌다. (next 도덕책,,,,)

이런 커스터마이징 덕분에 빌드 타임시에 잘못된 내부 이미지 링크도 수정이 가능해졌다. 추가로 내가 디자인을 바꾸고 싶은 마크다운 요소가 있다면 컴포넌트를 집어넣어서 디자인 변경도 가능하다. string으로 변환해서 꽂을 때와 비교하면 많은 것이 달라졌다.

### next-seo, next-themes

SEO 지원을 위해 [next-seo](https://github.com/garmeeh/next-seo)를, 다크모드 지원을 위해 [next-themes](https://github.com/pacocoursey/next-themes)를 사용했다.

### 그 외 리팩토링

현재 블로그 포스트에 두가지 주소 체계가 존재한다.

- (과거) `/:year/:month/:day/:title`
- (현재) `/:year/:month/:title`

현재 설정 건드리기 귀찮아서 nextjs에서 제공하는 디렉토리 라우팅을 사용하고 있는데, 이 두 주소 지원을 위해서 미련하게도 거의 비슷한 비즈니스 로직이 들어 있는 두가지 파일을 별개로 관리하고 있었다. 이를 `/:year/[...slug].tsx`로 바꿔서 하나의 라우팅에서 모두 처리가 가능하도록 변경했다.

그리고 그 외에 미뤄뒀던 코드 리팩토링도 거쳤는데, 사실 다 한 것 같진 않다. 여전히 귀찮아서 생략한 타이핑도 존재하기 때문에,, 아,, 언제 하지?

## 3. 결과

디자인도 바꼈고, 라이트 하우스느님의 심기를 거슬리는 부분도 많이 줄였다. 아쉬운 점은 디자인과 파서 외에는 급진적인 변화를 거치지 못했다는 것이다. rescript를 써보고 싶었지만(?) 그걸 갖다 쓸 만큼 실력이 되지 못했고, 그 외에 크게 이목을 끌 만한 기술도 접하지 못했다.

과연 이 객기의 끝은 어디일까. 또 무엇을 만족하지 못하고 바꿀 것인가,, 내년 이맘 때를 지켜보자.


아무도 보지 않는 블로그를 갈아 엎는 사람이 있다?

블로그 4.0 업데이트!

Lighthouse는 웹사이트의 성능을 측정하는 유명한 도구중 하나다. 이 Lighthouse를 CI와 연동하여 수시로 웹사이트의 성능을 점검할 수 있도록 해보자.

일단 lighthouse-ci는 [여기](https://github.com/GoogleChrome/lighthouse-ci)에서 확인할 수 있다.

## Local에서 사용하기

1. 설치
   ```bash
   npm install -g @lhci/cli
   ```
2. 루트 디렉토리에서 `lighthouserc.js`를 만들자. 여기가 [설정](https://github.com/GoogleChrome/lighthouse-ci/blob/v0.4.1/docs/configuration.md#configuration-file)이 들어가는 곳이다.
   ```javascript
   module.exports = {
     ci: {
       collect: {
         /* Add configuration here */
       },
       upload: {
         /* Add configuration here */
       },
     },
   }
   ```
3. Lighthouse CI가 실행 될때마다, 서버가 구동되어 사이트가 시작되어야 한다. 이 서버가 작동하게되면, Lighthouse CI가 해당 서버를 토대로 웹사이트 성능을 추적할 것이다. 작업이 끝나면, 알아서 종료된다. 제대로 작동하기 위해서는 둘 중에 하나를 설정해둬야 한다.
   1. `staticDir`: `ci.collect`에 해당 속성과 함께 static 파일이 위치한 곳을 설정해 두면된다. 그러면 Lighthouse CI는 알아서 그 파일을 기준으로 서버를 실행해서 테스트를 하게 된다.
   2. `startServerCommand`: static한 사이트가 아니라면, `ci.collect`에 서버를 키는 명령어를 적어두면 된다. (`npm run start`) 그러면 Lighthouse CI는 알아서 해당 명령어를 실행해서 서버를 키고, 끝난 후에는 종료 시킬 것이다.
4. `ci.collect.url`에 Lighthouse CI가 조사해야 할 주소를 적어두면 된다. 값은 배열로 설정해야 하며, 이말인 즉슨 여러개의 사이트를 적어둘 수 있다는 뜻이다. 기본값으로 해당 주소를 각 3번씩 조사한다.
5. `ci.upload.target`에 `temporary-public-storage`로 설정해두자. Lighthouse CI가 조사한 결과 레포트를 해당 위치에 업로드 할 것이다. 이 결과는 최대 7일까지 유지되며 이후에는 자동으로 삭제된다. 자세한 내용은 [여기](https://github.com/GoogleChrome/lighthouse-ci/blob/main/docs/configuration.md#target)를 확인하자.
6. `ci.collect.numberOfRuns`에 숫자를 넣어두면, 몇번을 실행할지 설정할 수 있다.
7. 설정이 끝났다면 실행하자. `lhci autorun` 정상적으로 설정해두었다면, 아래와 같이 결과가 나타날 것이다.

```javascript
module.exports = {
  ci: {
    collect: {
      url: ['http://localhost:3000'],
      collect: {
        numberOfRuns: 5,
      },
    },
    upload: {
      startServerCommand: 'npm run start',
      target: 'temporary-public-storage',
    },
  },
}
```

```bash
yceffort@yceffort yceffort-blog-v2 % lhci autorun
✅  .lighthouseci/ directory writable
✅  Configuration file found
✅  Chrome installation found
⚠️   GitHub token not set
Healthcheck passed!

Started a web server with "npm run start"...
Running Lighthouse 5 time(s) on http://localhost:3000
Run #1...done.
Run #2...done.
Run #3...done.
Run #4...done.
Run #5...done.
Done running Lighthouse!

Uploading median LHR of http://localhost:3000/...success!
Open the report at https://storage.googleapis.com/lighthouse-infrastructure.appspot.com/reports/1617202753232-29187.report.html
No GitHub token set, skipping GitHub status check.

Done running autorun.
```

## CI와 연계하기

Lighthouse CI는 다양한 CI 툴과 연계할 수 있다. [여기](https://github.com/GoogleChrome/lighthouse-ci/blob/main/docs/getting-started.md#configure-your-ci-provider)를 참고하면 관련된 가이드를 참조할 수 있다.

또한 성능 모니터링에서 한 걸음 더 나아가서 사전에 정의된 기준을 충족하지 못하는 경우 빌드에 실패하게 만들 수 있다. 이는 [assert](https://github.com/GoogleChrome/lighthouse-ci/blob/master/docs/configuration.md#assert)를 이용해서 작업할 수 있다.

Lighthouse CI 에서는 세가지 단계로 검사할 수 있다.

- `off`: 무시
- `warn`:
- `error`: 이 경우 0가 아닌 값으로 종료된다.

```javascript
module.exports = {
  ci: {
    collect: {
      // ...
    },
    assert: {
      assertions: {
        'categories:performance': ['warn', { minScore: 1 }],
        'categories:accessibility': ['error', { minScore: 1 }],
      },
    },
    upload: {
      // ...
    },
  },
}
```

## github action과 연동하기

나의 최애이자 유일신(?) 은 github action이기 때문에, 여기에 연동을 해보려고 한다. (oss님 제발...)

1. `.github/workflows`에 원하는 이름으로 파일을 만든다. 나는 `lightouse-ci.yaml`로 했다.
2. 해당 파일 내용을 다음과 같이 꾸몄다.
   ```yaml
   name: Build project and run Lighthouse CI
   on: [push]
   jobs:
     lhci:
       name: Lighthouse CI
       runs-on: ubuntu-latest
       steps:
         - uses: actions/checkout@v1
         - name: Use Node.js 12.x
           uses: actions/setup-node@v1
           with:
             node-version: 12.x
         - name: npm ci
           run: |
             npm ci
         - name: run build
           run: npm run build-nextjs
         - name: run Lighthouse CI
           run: |
             npm install -g @lhci/cli@0.3.x
             lhci autorun --upload.target=temporary-public-storage || echo "LHCI failed!"
   ```
   1. nodejs 설치
   2. npm ci
   3. 프로젝트 빌드
   4. lhci 설치 및 실행
3. assert 를 추가
   ```javascript
   module.exports = {
     ci: {
       collect: {
         url: ['http://localhost:3000'],
         collect: {
           numberOfRuns: 5,
         },
       },
       upload: {
         startServerCommand: 'npm run start',
         target: 'temporary-public-storage',
       },
       assert: {
         preset: 'lighthouse:recommended',
       },
     },
   }
   ```

이제 코드를 푸쉬하면 아래와 같이 작동하는 것을 볼 수 있다.

https://github.com/yceffort/yceffort-blog-v2/pull/278

![image1](./images/lighthouse-ci-github-action1.png)

![image2](./images/lighthouse-ci-github-action2.png)

추가로 [여기](https://github.com/apps/lighthouse-ci)를 방문해서 app을 설치하고 레파지토리에 `LHCI_GITHUB_APP_TOKEN`를 키값으로 값을 추가해준다면, PR에 메시지도 남겨준다. 물론, secret 추가 이후에는 아까 만들었던 github action yaml 도 변경해주어야 한다.

```yaml
- name: run Lighthouse CI
  env:
    LHCI_GITHUB_APP_TOKEN: ${{ secrets.LHCI_GITHUB_APP_TOKEN }}
  run: |
    npm install -g @lhci/cli@0.3.x
    lhci autorun --upload.target=temporary-public-storage || echo "LHCI failed!"
```

## 후기

나름 블로그 최초 개설 시엔 신경을 썼었는데 시간이 지나고 이것저것 덕지덕지 붙으면서 점수가 점점 바닥으로 가고 있는 중이라는 것을 이제 알게 되었다. 🤪

여기서 개선은 모르겠고,,, 블로그 v3.0을 계획하고 있습니다. 블로그 v3.0 작업시에 lighthouse 점수를 수시로 확인하면서 작업을 해야겠다. 그리고 지금 내가 몸담고 있는 프로젝트에도 Lighthouse CI를 들이밀어 봐야겠다. 라이트하우스 함무바라 (점수보고) 디진다 퍼뜩 무봐라

![try lighthouse](https://mgall.app/api/file/9477923)


github workflow로 lighthouse ci 추가하기

모던 웹사이트의 복잡성과 더불어 브라우저가 CSS를 처리하는 방식 까지 얹혀진다면, 일부 구식장치, 네트워크 지연, 제한된 데이터를 경험하는 사람들에게는 그리 많지 않은 CSS도 병목현상을 겪을 수 있다. 성능은 사용자 경험에서 필수적인 부분이기 때문에, 다양한 디바이스에서 일관된 고품질의 환경을 제공해야하며 이를 위해선 CSS 최적화가 필수다.

이 포스트에서는 CSS의 성능 이슈와, CSS의 성능을 향상 시키기 위해서는 어떤 작업들이 필요한지 다뤄보려고 한다.

## Table of Contents

## CSS는 어떻게 동작하는가

### CSS는 렌더링을 막는다

CSS의 존재 자체 만으로도, CSS가 파싱되기 전까지 브라우저는 렌더링이 지연된다. 대부분의 모던 웹사이트에서 CSS가 존재하지 않는다면 정상적으로 페이지를 이용할 수 없을 것이다. 만약 브라우저가 CSS가 없는 페이지를 그대로 노출된다면, 잠깐 동안 CSS가 파싱되면서 스타일이 적용되는 페이지가 나타나기 전까지 의 시간이 생기고 말 것이다. 이러한 것을 [FOUC(Flash of Unstyled Content)](https://en.wikipedia.org/wiki/Flash_of_unstyled_content)라고 한다.

### CSS는 HTML 파싱도 막을 수 있다.

브라우저가 CSS가 파싱되기 전까지 콘텐츠를 보여주지 않더라도, HTML의 로딩된 부분만을 일단 보여줄 수도 있다. 그러나 스크립트의 경우 `async` `defer` 이 없다면 파싱을 막게 된다. 스크립트는 잠재적으로 페이지를 조작할 여지가 있으므로, 브라우저는 스크립트 실행에 매우 주의를 기울일 필요가 있다.

![js-blocking-html-parsing](https://web-now-rbviiass9-calibreapp.vercel.app/_next/image?url=%2Fimages%2Fblog%2Fcss-performance%2Fparser-blocking-script.png&w=1920&q=75)

스크릡트가 페이지의 스타일에 영향을 줄 수 있기 때문에, 만약 브라우저가 CSS 관련 작업을 진행중이라면, 이 작업이 완료될 때 까지 기다렸다가 스크립트를 실행할 것이다. 스크립트가 실행되기 전까지 문서 파싱을 할 수 없기 때문에, CSS는 더이상 렌더링을 차단하는 요소로 작용하지 않는다. (하단 그림 참조) 문서의 외부 스타일시트 및 스크립트 순서에 따라서 때로는 HTML 파싱도 중지할 수 있다.

![css-can-block-html-parsing](https://web-now-rbviiass9-calibreapp.vercel.app/_next/image?url=%2Fimages%2Fblog%2Fcss-performance%2Fparser-blocking-css.png&w=1920&q=75)

파싱을 차단하는 상황을 피하기 위해서는, CSS를 최대한 빨리 불러와야 하고, 리소스를 최적의 순서로 불러와야 한다.

## CSS 사이즈 지켜보기

### CSS 압축하고 최소화 하기

외부 스타일 시트를 다운로드 하는 작업은 필연적으로 네트워크 지연이 발생지만, 네트워크에 전송되는 바이트의 양을 줄임으로써 이 과정을 최소화 할 수 있다.

파일을 압축하는 것은 속도 향상에 지대한 영향을 미치며, 많은 호스팅 플랫폼과 CDN에서는 기본적으로 애셋을 압축해준다. 가장 널리알려져 있는 압축 솔루션은 GZip이고, Brotil 또한 존재하지만, [Brotli는 일부 브라우저에서 지원을 하지 않는다.](https://caniuse.com/brotli)

Minification (최소화) 과정은 코드에서 필요없는 공백을 지우는 과정이다. 결과물은 이전 코드에 비해서 작아지지만, 브라우저는 충분히 코드를 파싱할 수 있으며 이를 통해 몇 바이트라도 더 절약할 수 있다. 가장 유명한 자바스크립트 압축 툴로 [terser](https://github.com/terser/terser)가 있고, [웹팩 v4 버전 이상 부터는 빌드 파일을 작게하는 도구가 내장되어 있다.](https://webpack.js.org/plugins/css-minimizer-webpack-plugin/)

### 사용하지 않는 CSS 제거

CSS 프레임워크를 사용하게 될 경우, 필요한 컴포넌트만 번들링 하지 않는 이상 사용되지 않는 CSS가 포함되는 것은 일반적인 문제다. 이와 비슷하게, 오랜시간에 걸쳐서 쌓이는 큰 코드 베이스에도 안쓰는 CSS가 남는 경우가 더러 있다.

사용하지 않는 CSS를 제거하는 것은 수동 작업이다. 따라서 코드가 얼마나 복잡하느냐에 따라서 난이도가 증가하게 된다. 이 작업은 웹사이트 전체에서, 가능한 모든 디바이스에서, 가능한 모든 상황에서, 가능한 모든 자바스크립트 실행 결과에 따라서 결정해야 한다. [UnusedCSS](https://unused-css.com/)나 [PurifyCSS](https://purifycss.online/) 와 같은 유명한 툴이 있지만, 항상 visual regression 테스트도 병행해서 이뤄져야 한다.

**바로 이것이 CSS-in-JS를 쓸 때 얻을 수 있는 가장 큰 이점이다. 각 컴포넌트가 렌더링에 필요한 CSS가 js내에 포함되어 있다. (따라서 컴포넌트 레벨로 관리하기 때문에 편하다는 것)** CSS-in-JS는 페이지 내부에 CSS를 인라인 처리하거나, 외부 CSS파일로 따로 번들링 해버린다. CSS를 자바스크립트 내부에 포함시켜 버리면 CSS 파싱과 평가가 느려진다.

## CSS의 우선순위 정하기

Critical CSS란 화면에 보이는 컨텐츠 (above-the-fold content)의 CSS 에 대해서만 inline 처리하는 것을 의미한다. HTML 문서의 `<head/>`에 있는 스타일을 따로 추출해서 인라이닝 하면 스타일을 가여오는 추가 요청을 할 필요가 없어져 렌더링이 빨라진다.

첫 렌더링 시의 라운드트립을 최소화 하기 위해서는, above-the-fold content의 크기를 14kb내로 유지해야 한다. (압축시)

Critical CSS를 정확히 정의하는 것은 어렵다. 디바이스의 크기에 따라서 사용자가 보이는 영역이 달라지기 때문이다. 이는 특히 매우 유동적인 사이트의 인 경우에는 더욱 어려워 진다. 그러나 이는 여전히 성능 향상에 중요한 부분 이므로, [Critical](https://github.com/addyosmani/critical) [CriticalCSS](https://github.com/filamentgroup/criticalCSS) [Penthouse](https://github.com/pocketjoso/penthouse) 등의 도구를 활용해서 자동화 할 필요가 있다.

### CSS 비동기로 불러오기

위 above-the-fold content를 최대한 빠르게 불러오는데 집중했다면, 나머지 영역은 비동기로 로딩하는 것이 최선이다.

```html
<link
  rel="stylesheet"
  href="non-critical.css"
  media="print"
  onload="this.media='all'"
/>
```

`"Print"` 미디어 타입이란, 사용자가 페이지를 프린트를 하려고 하는 경우에만, 브라우저가 해당 스타일 시트를 불러오는 것으로 렌더링에는 영향을 미치지 않는다. 그리고 여기에 `onload` 이벤트로 `this.media='all'`를 추가한다면, 스타일 시트가 로드가 완료되면 미디어 속성을 다시 `all`로 바꾸면서 스타일 시트가 적용된다.

또 다른 방법은 `<link rel="preload">`를 사용하는 것이다. 그러나 이 방법은 아래와 같은 단점이 있다.

- [브라우저 지원이 여전히 시원치 않으므로](https://caniuse.com/?search=preload), [loadCSS](https://github.com/filamentgroup/loadCSS/)와 같은 폴리필이 필요하다.
- `preload`는 생각보다 매우 이른 타이밍에, 높은 우선순위로 다운로드 되므로 다른 중요한 애셋의 다운로드 우선순위를 밀어 버릴 수 있다.
  - https://developer.mozilla.org/ko/docs/Web/HTML/Preloading_content

```html
<link rel="preload" href="/path/to/my.css" as="style" />
<link
  rel="stylesheet"
  href="/path/to/my.css"
  media="print"
  onload="this.media='all'"
/>
```

> https://www.filamentgroup.com/lab/load-css-simpler/

### @import 사용 자제하기

`@import`는 CSS파일의 렌더링 속도를 느리게 한다. 특히 `@import url(imported.css)`와 같은 코드는 네트워크 흐름을 아래와 같이 바꿔버린다.

![@import](https://web-now-rbviiass9-calibreapp.vercel.app/_next/image?url=%2Fimages%2Fblog%2Fcss-performance%2Fcss-import-blocking.png&w=1920&q=75)

그러나 두 파일을 별개로 분리하면 이런식으로 동시에 다운로드 하게 된다.

![parallel](https://web-now-rbviiass9-calibreapp.vercel.app/_next/image?url=%2Fimages%2Fblog%2Fcss-performance%2Fcss-parallel-download.png&w=1920&q=75)

## 효과적인 CSS 애니메이션 사용하기

페이지에 애니메이션이 있는 요소가 있는 경우, [브라우저는 종종 문서 내 요소의 위치와 크기를 재 계산한다.](https://calibreapp.com/blog/investigate-animation-performance-with-devtools#animation-performance) (레이아웃 발생) 예를 들어, 어떤 요소의 너비를 바꾸게 되면, 그 자식 요소들 까지 영향을 미치면서 페이지 내부에서 큰 레이아웃이 발생할 수 있다. 그리고 이 레이아웃의 크기가 커질 수록, 성능에 안좋은 영향을 미칠 것이다.

요소에 애니베이션을 넣을 때는, 레이아웃과 리페인트가 최소한으로 이뤄지도록 해야 한다. 모든 CSS 애니메이션 기술이 동일하지 않으며, 모던 브라우저에서는 위치, 크기, 회전, 불투명도 등을 가진 고성능 애니메이션을 만들 수 있다.

- `height` `width` 대신 `transform: scale()`을 쓰자
- 요소를 움직이게 하기 위해서는, `top` `right` `bottom` `left` 대신 `transform: translate()`를 쓰자.
- 배경에 blur를 먹이고 싶다면, opacity를 바꾸는 것보다 그냥 blur 된 이미지를 불러오는게 낫다.

### `contain` 속성

[contain](https://developer.mozilla.org/en-US/docs/Web/CSS/contain)은 브라우저에 요소와 하위 요소가 그 문서 트리와 무관한 것으로 간주된다는 것을 알려주는 속성이다. 페이지의 하위 트리와 나머지 페이를 분리한다. 그런 다음, 브라우저는 페이지에서 독립된 부분의 렌더링을 최적화하여 성능을 향상 시킬 수 있다.

`contain`는 페이지 내부에서 독립적으로 작동하는 위젯 등에서 매우 효과적이다. 이 속성을 활용하여 위젯의 내부에서의 변경사항이 바깥으로 전파되는 것을 막을 수 있다.

## CSS로 폰트 로딩 최적화 하기

### 폰트 로딩 중에는 보이지 않는 텍스트를 두지 않기

폰트는 로딩하는데 시간이 걸리는 큰 파일인 경우가 많다. 일부 브라우저는 폰트가 로딩되기 전까지 텍스트를 숨긴다. (FOIT, flash of invisible text) 속도를 최적화 하기 위해서는 보이지 않는 텍스트가 갑자기 나타나는 현상(FOIT)을 피하고, 시스템 폰트를 기본으로 사용하여 즉시 사용자에게 콘텐츠를 보여주는 것이 좋다. 폰트가 로딩 되면, 시스템 기본 글꼴로 로딩된 폰트를 대체 하는 FOUT(flash of unstyled text) 현상이 일어날 것이다.

이를 위한 방법 중 하나가 [font-display api](https://developer.mozilla.org/ko/docs/Web/CSS/@font-face/font-display)를 사용하는 것이다. `swap`을 사용하면, 브라우저가 폰트가 다운로드 되기 전에는 즉시 시스템 글꼴로 보여줘야 한다는 것을 알려줄 수 있다.

### variable font를 사용하여 파일 크기 줄이기

[Variable Font](https://variablefonts.io/)는 모든 너비, weight,style에 대해서 별도의 폰트 파일이 아니라 하나의 파일에 여러가지 다양한 폰트를 통합해줄 수 있도록 한다. CSS와 단일 `@font-face` 참조로 지정된 글꼴의 다양한 변형에 액세스 할 수 있다.

이는 글꼴의 여러 변형이 필요한 파일 크기를 획기적으로 줄일 수 있다. 일반, 볼드, 기울임꼴 폰트 버전을 각각 로딩 하는 대신 모든 정보가 포함된 하나의 단일 파일을 로딩할 수 있다.

[Monotype](https://www.monotype.com/resources/expertise/truetype-gx-variable-fonts) 에서는 12개의 폰트를 결합하여 이탤릭과 로만 모두에 3개의 다른 너비, 8개의 다른 weight를 생성하는 실험을 한 바 있다. 하나의 variable font에 48개의 개별글꼴을 모두 저장함으로써 파일의 크기가 88% 감소했다.

## CSS 선택자의 속도에 대해서 걱정할 필요는 없다.

CSS 셀렉터를 구조화하는 방법에 따라서 브라우저가 CSS를 매칭하는데 필요한 속도가 달라진다. 브라우저는 셀렉터를 오른쪽에서 왼쪽으로 읽기 때문에 자식에서 부모로 거쳐서 올라가게 된다.. 예를 들어, `nav a {}`가 있다면, 모든 `<a/>`를 찾고, 그 다음에 `nav` 하위에 있는 `<a/>`를 찾는다. 따라서 만약 선택자를 `<nav/>` 내부에 있는 `<a/>`에 대해서 `.nav-link`로 지정하 찾는다면, 전체 페이지에서 `<a/>`를 찾는 수고로움을 덜할 것이다. 따라서 `.container ul li a { }`와 같은 선택자는 따라서 비용이 많이 발생하게 된다.

선택자를 매칭 시키는 속도는 굉장히 빠르므로 굳이 걱정할 필요는 없다. CSS 선언은 압축 알고리즘에 매우 유연하게 동작하기 때문에, CSS 선택자를 최적화하는데 필요한 노력은 투자대비 더 큰 수익으로 다가올 것이다.

## 결론

CSS는 페이지 로딩과 유익한 사용자 경험을 주기 위한 필수적인 요소다. js나 image와 같은 요소에 최적화 하다보면, css에도 관심이 필요하다는 것을 잊을 수 있다. 위의 전략들을 활용하다보면, 사용자에게 더 빠르고 최적화된 웹사이트를 제공할 수 있을 것이다.


CSS의 황제가 출간한 CSS 완벽가이드를 장식용으로 구매...

Latest

디렉토리에 있는 모든 이미지 최적화 하기

nodejs의 멀티쓰레딩과 worker threads

블로그 4.0 업데이트!

github workflow로 lighthouse ci 추가하기

CSS 성능 향상 시키기