2019년 10월 다섯째 주

Rendering on the Web

웹에서 렌더링하는 다양한 방법들의 특징 및 비교

관련 영상: Rendering on the Web: Performance Implications of Application Architecture (Google I/O ’19)

PRPL 패턴, Addy Osmani

점차 인터넷을 사용하는 디바이스 중 모바일이 차지하는 비율이 늘어감에 따라, 모바일 웹 앱의 경험을 향상시키기 위한 목적으로 탄생한 PWA를 구성하고 제공하기 위한 패턴.

• Push: 초기 URL 경로에서 중요한 리소스를 푸시합니다.
• Render: 초기 경로를 렌더링합니다.
• Pre-cache: 남은 경로를 사전 캐시합니다.
• Lazy-load: 필요 시 남은 경로를 지연 로드하고 생성합니다.

Caching in React

in memory 캐싱, redis를 사용한 캐싱, CDN을 사용한 캐싱에 대한 특징과 간단한 구현 방법을 서술한 글

번역

A comprehensive guide to HTTP/2 Server Push, Jeremy Wagner, 2017.4.10

HTTP/2가 지원하는 Server push에 대한 글

summary

HTTP/2 이전에는 브라우저가 어떤 페이지를 요청했을 때, index.html을 우선 받고, 이를 파싱하면서 css와 javascript 파일을 따로 요청해야 했다. 그러나 HTTP/2가 지원하는 Server push를 사용하면, 클라이언트가 index.html을 요청했을 때 서버가 알아서 index.html와 style.css 등 여타 파일을 함께 응답해줄 수 있다. 추가적인 요청을 줄여서 이는 브라우저가 더 빠르게 화면을 그릴 수 있게 된다는 뜻이다.

장점

• Round trip을 줄여준다.
• anti pattern인 inline css, javascript와 data URI scheme의 대안으로 적절하다. (inline css와 javascript 등은 모듈화가 되지 않아 다른 페이지에서 이 내용이 필요할 경우 캐시되지 않는다.)

성능

해당 기사에서는 CSS만 server push했을 때 성능이 제일 좋았다. javascript와 기타 등등의 파일을 같이 push했을 때 되려 화면이 그려지는 속도가 느렸다.

2017년 글임을 감안하여 최근엔 브라우저가 이를 어떻게 최적화했을지 모르므로, 좀 더 자료를 찾아보거나 직접 벤치마킹하여 서버푸쉬를 사용해야 할 것 같다.

server push와 cache

서버가 무조건 어떤 데이터를 보내준다면, 재방문 사용자이고 캐시를 가지고 있을 경우 캐시를 무시하는 결과를 낳게 된다. 이에 관하여, 클라이언트상의 쿠키로 캐시가 있으니 서버푸쉬를 보내지 않아도 되게끔 하는 기능을 가진 솔루션(cache-aware server push mechanism) 이 있으니 참고하는 것이 좋을 것 같다.

HTTP/2 소개

바이너리 프레이밍 계층

바이너리 프레이밍 계층은 HTTP 메시지를 캡슐화하여 클라이언트와 서버 사이에 전송되는 방식을 규정한다. 이 계층을 통해 동일한 연결에서 다중 동시 교환이 가능하다. 이렇게 한 연결에서 다중화된 요청과 응답이 가능하기 때문에 HOLB(Head of Line Blocking)¹이 발생하지 않는다.

스트림 우선순위 지정

각 스트림의 종속성, 우선순위를 지정할 수 있으나 실제로 이게 서버에 강제되지는 않는다. 즉, 안 지켜질 수 있다는 뜻.

출처당 하나의 연결

TCP 연결이 하나만 있으면 충분하다. 동일한 연결을 재사용하여 각 TCP 연결을 더 효율적으로 사용할 수 있다. 이는 전체 네트워크의 자원의 효율성도 높여준다. 또한 TLS 핸드셰이크도 줄고 세션의 재사용이 더 향상되어 클라이언트와 서버의 리소스도 감소한다.

서버 푸시

서버가 단일 클라이언트 요청에 대해 여러 응답을 보낼 수 있다. 서버는 어떤 리소스가 클라이언트에 필요한지 이미 알고 있다. 지연 시간을 줄이기 위해 서버가 리소스를 미리 푸시하는 것.

서버 푸시는 PUSHPROMISE 프레임을 통해 시작되며, 해당 프레임에 어떤 리소스가 푸시될 것인지 기술된다. 클라이언트는 이 프레임을 받고 어떤 리소스가 이미 캐시된 경우 RSTSTEAM 프레임을 통해 이를 거부할 수 있다.

클라이언트는 서버 푸시에 대한 완벽한 제어를 할 수 있어서, 서버 푸시 스트림의 수 제한, 푸시되는 데이터 크기를 제어하는 초기 흐름 제어 창 조정, 서버 푸시 비활성화를 할 수 있다.

Hastening React SSR with component memoization and templatization

리액트 서버 사이드 렌더링 시 메모이제이션 패턴을 어떻게 적용하는 것에 대한 발표 슬라이드 자료

How Typescript Can Power Design Systems | Isha Kasliwal | JSConf Korea 2019

Workflow by Design System

1. Ideation
2. Design
3. Code
4. Production

why typescript?

타입스크립트로 개발하는 것은 인터페이스 중심의 개발이다. 디자이너와 개발자 모두 이런 인터페이스에 쉽게 접근할 수 있고, 그로 인해 얻는 이점들이 많다.

이 동영상은 타입스크립트보다는 디자인시스템에 대한 내용인 것 같다.

Don’t block the event loop!JavaScript Async for Effortless UX|Jaeseok Kang|JSConf Korea 2019

자바스크립트는 기본적으로 단일 콜스택과 이벤트 루프로 동작한다. 그로 인해 고연산의 작업을 진행할 때 다른 작업을 아예 할 수 없게 된다. 이를 해결할 수 있는 몇 가지 방법을 소개하는 영상이다.

• worker thread
• scheduling (큰 작업을 쪼개서 짧게 짧게 동작하게)
• DOM 갱신 최적화 (이벤트가 여럿이 연속적으로 발생 시 마지막 작업만 실행)