📈 Noise-Effector 개발기 -성능 개선-

thumb_hyeok·2023년 2월 14일

⚡ Noise-Effector

목록 보기

2/3

🏃🏻 들어가며

혹시 "노이즈 이펙터"에 대해서 모른다면 이전 포스팅을 참고하는 것을 추천한다. 이번 글에서는 노이즈 이펙터를 개발하면서 꽤 애를 많이 먹었던 부분인 성능 개선에 대해 내가 겪은 시간 순으로 트러블 슈팅 과정을 적어보려한다. 그럼, 시작해보자!

🤔 아무리 프로토타입이라지만…

노이즈 이펙터의 핵심 기능인 사진에 노이즈를 적용하는 기능이 최초로 완성된 시점이다. 성능 점수 20점.. 사실 이것도 실제 성능보다 훨씬 높게 나온 것이다. 왜냐하면 “LCP”가 된 시점이 실제 이미지가 완성되어 다운로드 받을 수 있는 시점과는 괴리가 꽤 컸기 때문이다.

무려 네트워크 무제한, 개발모드가 아닌 배포된 환경, 데스크탑 기준으로 측정한 점수이다. 심지어 개발모드에서는 너무 오래 걸려서 응답없음으로 크롬이 꺼지는 경우가 대부분이라 측정 자체도 불가능했다.

이렇게… 매우 자주 가버리곤 했다.

이렇게 성능이 처참한 이유는 “이렇게 성능이 많이 저하되는 작업일 거라 생각 못하고” 점묘화를 이루고 있는 삼각형 요소들을 div 를 이용해서 하나 하나 다 그렸기 때문이다. (아래 사진의 삼각형이 모두 div다..)

조금만 노이즈 강도를 약하게 해도 div 태그 수십, 수백만개가 생성되곤했다. 그리고 당연히 이렇게 동작하니 노이즈 정도에 따라 그리는 div 의 갯수 차이로 성능 차이가 어마어마했다.

그래서 “Canvas API”를 이용해 div 대체해 점묘화를 그리는 것으로 했다. Canvas API는 GPU 가속을 사용하여, 브라우저가 그래픽 연산을 처리하는 과정에서 CPU와 GPU를 모두 사용한다. 이를 통해 빠른 그래픽 렌더링을 할 수 있다는 장점이 있다.

이 뿐만 아니라, Canvas API는 HTML 태그와 비교해서 상대적으로 가볍고 빠르게 로딩된다. 이것은 브라우저의 메모리를 적게 사용하고, 렌더링 속도 또한 빠르게 만들어준다.

💡 이렇게 장점이 많은 Canvas API를 이용하지 않을 이유가 없다!

🤔 정말 이게 맞는 방법이 맞을까?

위에서 말은 Canvas API가 좋다, 좋다했지만 다른 방법은 없었을까? 내가 원하는 점묘화 썸네일을 만들어 낼 수 있는 기능들은 무엇이 있는지 살펴보고 비교해보자. 그 이후에 가장 알맞은 기술을 사용하는 게 맞을 것이다!

1️⃣ DOM

웹 프론트엔드 개발자라면 가장 친숙한 방법일 것이다. 그래서 내가 제일 먼저 시도해본 방법이기도 하다. 이벤트 핸들러를 이용하거나, 사용하기에 편한 점들이 있긴하지만, 메모리와 성능을 고려해봤을 때 지금은 적합만 방법이 아니라는 답이 나온다.

2️⃣ SVG

SVG는 세밀한 제어(Canvas API, WebGL)와 편의성(DOM)의 중간에 위치하는 방법이다. 나는 고퀄리티의 점묘화를 만들어야하니 벡터기반의 SVG는 나름 좋은 선택지일 수도 있지만 다만 SVG는 도형의 속성을 수정할 때마다 리렌더링이 발생하지만, Canvas API는 한 번에 모든 것을 그리기 때문에 일반적인 경우라면 SVG는 요소가 많아질 수록 성능이 감소한다.

3️⃣ Canvas API

Canvas API는 위에서 설명했던 것처럼 다른 방식에서 생길 수 있는 문제점 “요소가 많아지면 성능이 감소한다” 가 발생하지 않는 조건에 있는 것은 물론, 하드웨어와 운영체제에 따라 다르지만 일반적인 최신 브라우저에서는 GPU 가속을 사용해 성능상의 장점을 가져갈 수 있다는 장점이 있다.

다만, DOM 문서 상에 canvas 안에 그린 것들은 인식되지 않아 텅 빈 canvas 태그 하나 뿐이라는 단점이 있다. 하지만 Canvas API 자체가 많은 요소들을 하나 하나 제어하기에 편해 큰 문제가 되지는 않았다.

그 외 WebGL이나 다른 방법들도 존재할 수 있겠지만, 목적과 조금 동떨어졌다거나 진입장벽이 있어보이는 기술을 고려하지 않았다.

이렇게 결론은 “Canvan API”가 되었다.

🎨 Canvas API로 성능 개선하기

이게 Canvas API를 어떻게 사용하는지 알려주는 포스팅이 아니기 때문에, “어떻게 구현했냐” 하는 부분은 생략하도록 하겠다. 바로 넘어가서 div로 떡칠한 점묘화를 Canvas API로 대체하고 어떻게 성능이 향상되었는지 살펴보도록 하자! (잘 보면 이상한 점이 있을 것이다)

성능 점수상으로는 69점이지만, 잘보면 LCP가 0.3초인 것을 확인해볼 수 있다. 아무리 봐도 한 2초는 걸리는 것 같은데 0.3초라니.. 말이 안 되는 리포트였다. 그래서 퍼포먼스 탭을 확인해봤다.

모나리자 점묘화가 로딩이 되는 시점은 저 뒤 1998ms 지점에 있는데, LCP는 42.9ms로 찍혀있는 것을 확인할 수 있다. 이건 아마도 Canvas API의 내부 요소는 DOM에 찍히지 않기 때문에 Canvas가 로딩되면 바로 LCP로 기록이 되는 것으로 보인다. (하지만 정확하지는 않다)

측정환경은 아까와 동일하게 측정했다. 아마 이대로면 실제 LCP는 1.5s~1.9s 사이의 값일 것 같았다. 아주 만족스러운 성능은 아니지만 개발모드에서 웹사이트가 터진다거나, 하루 종일 기다려야 하는 사태가 일어나지는 않았다.

그러나 장치 종류나 브라우저에 따라 성능이 차이가 꽤 나는 것 같았다. 프로젝트를 테스트 해주던 내 친구의 컴퓨터에서는 거의 10초 가까이 기다려야 화면이 로딩이 완료된다고 했다.

그래도 일정상 개발해야하는 기능들이 많아 성능에 목숨걸지 않고 일단 넘어가기로 했다.

💣 끝판왕을 만나다

저번 글을 보신 분이라면 노이즈 이펙터에는 노이즈 강도를 조절하도록 도와주는 “3D 캐러셀”이 존재한다는 사실을 알 것이다. 그렇다. 노이즈는 6단계로 이루어져 있고, 나는 캐러셀을 렌더링하기 위해서 저 오래걸리는 작업을 6번이나 해야함을 깨달았다.

📈 다시 한 번 성능 분석

잘 보면 캐러셀 요소마다 다른 노이즈 정도를 가지고 있기때문에, 하나 하나 다 따로 렌더링을 해야하는 상황이었다. 오… 이런 나는 UX가 뛰어난 3D캐러셀을 포기하고 싶지 않아서 결국 다시 성능 개선 문제로 되돌아갈 수 밖에 없었다. 먼저 구현이 끝나고 측정한 성능을 분석해보자

이전처럼 LCP가 정상적으로 기록되지 않아서 퍼포먼스 탭을 참고해 LCP를 대충 계산해봤더니 약 “4s” 정도 될 것 같았다. 그 외 성능도 권장사항과는 매우 멀어보인다. 이정도면 다행이다라고 생각했을 정도였다.

여기서 나는 점묘화를 그리는 기능을 A-Z까지 담당하고 있는 usePointillism 훅을 중심으로 어떤 부분이 성능적으로 문제가 생기는 지 찾아봤다. 찾아보니 유독 두가지 함수가 오래 걸림을 확인했다.

자, 아래에서 해당 문제를 상세히 살펴보고 고쳐보도록 하자.

🤖 성능을 위한 코드 리팩터링

createImageData 함수는 source로 제공된 이미지를 캔버스에 그리고, 해당 이미지의 각 픽셀 마다의 RGBA값 정보를 배열을 반환하는 함수이다. 이건 보자마자 이름과 달리 역할이 두개라 분리해야겠다는 생각부터 들었다.

추가로 createRgbaValues 함수는 그렇게 만들어진 RGBA 값 배열을 받아서 내가 사용하기 편한 형태로 바꿔서 이차원배열 형태로 반환해주는 함수이다. 나중에 알고 봤더니 이게 성능 문제의 주범이었다.

분석 결과, 점묘화를 그리는 게 주목적인 usePointillism 훅에서 굳이 이미지를 그리고, RGBA 값을 추출하는 로직까지 들고 있을 필요가 없어 보여 useRgba 라는 훅으로 따로 분리했다.

그리고 이미지의 RGBA 값은 한 번 이미지를 첨부하고 나면 바뀌지 않으니, 성능상의 문제가 없을 거라는 생각을 하고 “Context API”를 이용해서 컨텍스트에 저장해서 useRgba 에서 한 번 계산한 RGBA 값을 컨텍스트를 통해 usePointillism 에서 받아 쓰는 것으로 했다.

이렇게 하면 가장 오래걸리는 작업인 RGBA 값 계산을 점묘화를 그려야할 캔버스 갯수만큼 할 필요 없이 단 한번만 하면 된다는 아주 큰 이득을 얻을 수 있었다.

추가로 굳이 필요없는 작업인 RGBA 값을 이차원배열에 옮겨담는 작업을 하면서 작업 시간을 늘리고 있어 해당 함수를 제거 했다.