TOAST UI

Firefox Quantum 릴리즈가 가까워지고 있다. 이번 릴리즈에서는 Servo에서 가져온 초고속 CSS 엔진을 포함하여 많은 성능 개선이 있다.

Binary AST는 자바스크립트를 더욱 빠르게 파싱하기 위한 표준이며 최근에 ECMA TC-39에 채택되었다. 텍스트 형태의 자바스크립트를 바이너리 형태로 변환하여 전송 속도를 높이고 자바스크립트 파싱 자체를 빠르게 하는 것이 목표이다.

자바스크립트 세계에서는 JIT(Just-In-Time) 컴파일러가 등장하면서 성능의 비약적인 발전을 이루었고 웹 어플리케이션의 규모가 점점 더 커질 수 있는 초석이 되었다. 그럼에도 불구하고 여전히 성능에 대한 목마름은 해소가 되지 않았고 WebAssembly라는 것이 등장하였다. WebAssembly는 Weekly Pick에서도 여러 번 다루어 왔던 주제이다.

React는 간단하면서도 충분히 빠르다. 하지만 착각하지 말자. 대충 만들어도 빠르다는 것은 아니다. React 애플리케이션은 잘 만들어야 빠르다. React의 동작 원리를 이해하고 애플리케이션이 느려질 수 있는 상황들을 찾아 해결하는 것이 중요하다. 다행히 React는 간단하고 이해하기 쉬운 라이브러리다.

몇 주 전에 나는 일 때문에 공항을 이용했는데 여기서 GitHub의 성능에 이상한 점을 발견했다. 링크를 클릭하는 것 보다 새 창으로 접속하는 것이 더 빨랐던 것이다. 아래는 영상으로 그 현상을 캡쳐한 것이다. 영상에서 나는 링크를 클릭하고 바로 주소를 새 탭에 붙여넣었다. 링크를 더 일찍 클릭했지만 새 탭으로 연 페이지의 내용이 더 빨리 보였다.

타임라인은 웹페이지를 로드할때나 혹은 유저 인터렉션 등으로 인해 브라우저에서 발생하는 동작들을 레코딩하고 타임라인 형태로 시각화해주는 도구다. 시간의 흐름에 따라 브라우저의 이벤트(여기서의 이벤트는 DOM상의 이벤트가 아닌 브라우저 내부의 동작, 물론 DOM이벤트를 발생시키는 이벤트도 있다)뿐 아니라 CPU, 메모리, 네트워크 사용량과 FPS까지 확인 가능하다. 이벤트에 스택 트레이스 형태로 자바스크립트의 함수 콜 스택도 확인이 가능해 어떤 자바스크립트 코드가 성능에 영향을 주고 있는지도 쉽게 확인할 수 있다. 두가지의 성능 측정 예를 통해 타임라인의 기능을 살펴본다.

과거 웹오피스의 워드를 개발했던 때에, 각주 기능을 개발했던 적이 있다. 문서의 특정 부분에 커서를 두고 "각주"를 추가하면 해당 부분에 대한 코멘트를 문서의 우측 영역에 작성할 수 있는 기능이었다. 며칠 만에 기능을 완성하고 개별적으로 성능을 측정했다. 각주의 수를 늘려가면서 추가 삭제를 반복하는 일이었다. (IE6가 지원 대상이었고 마땅한 성능 측정 도구가 없어 CPU, 메모리 증가 여부와 사용감 정도로 체크했었다.)

리액트의 성능 향상을 위한 가이드. 보통의 웹 어플리케이션에서는 한 페이지에 다수의 엘리먼트들을 렌더링한다. 이번 포스트에서 다수 엘리먼트들을 렌더링할 때 어떤 방식으로 성능 향상을 하는지 보여주고자 한다.

그렇다. 신년 초부터 한해의 일에 대해 이야기한다는 것은 가벼운 일은 아니다. 그러나 웹 스트림 API의 잠재력은 나를 매우 흥분 시켰기에 그런 일을 가능하게 했다. 요약하면, 스트림은 "cloud"라는 단어를 "butt"로 변경하거나 MPEG를 GIF로 변환하는 작업과 같이 익숙한 일들을 할 수 있다. 그러나 가장 중요한 것은 제공 내용을 가장 빠르게 서비스 워커로 결합시킬 수 있다는 것이다.

지난 몇 달 동안 에디터의 성능 최적화 작업을 진행했다. 진행 도중 '마커' 기능 개선하는 약간은 어려운 이슈를 해결하는 작업이 계획되었다. '마커'는 논리적 영역을 지정하여 수정과 상관 없이 계속 추적하는 기능이다. 예를 들어 아래 gif 에서 녹색 영역이 '마커' 인데 텍스트가 변경되어도 계속 녹색으로 지정되어 있다.