[2019.11.23] DevFest WebTech 2019 컨퍼런스~!

 

오늘은 구글 캠퍼스에서 진행한 DevFest WebTech 2019 컨퍼런스에 다녀왔다. 

이번 컨퍼런스는 웹 성능 최적화를 주제로 한 다양한 발표가 진행되었다. 

 

# 컨퍼런스가 진행된 구글 캠퍼스 지하 2층

 

컨퍼런스를 듣기 위해 모인 사람들이 꽤 많았다.

역시나 구글캠퍼스라 그런지 내부 시설이 놀이문화 느낌(?)으로 가득했다.

 

 

이번 컨퍼런스에 참석한 사람들은 아래 두 세션 중 하나를 선택해서 들었어야 했다. 

#세션 1

• 오픈소스 기여한 내용
• ES6, ES7 맛보기 [코드랩]

#세션 2

• 코드의 메인스레드 위치에 대한 내용(?)
• ES8, ES9, ES10 [코드랩]

 

#세션 3

• HTTP/3의 웹 성능 최적화
• Rx.JS를 이용한 간단한 검색 기능 만들어보기 [코드랩]

 

사실 전부 듣고 싶은 욕심이 엄청났지만, 각 시간대마다 더 유익한 게 무엇일까 생각을 해보았을 때, 세션 1은 왠지 내가 오픈소스 기여할 시간이 나지 않는다는 것(절대 관심이 없는 것이 아님...), 세션 2는 내 동료와 각자 나뉘여서 듣고 서로 정보를 공유하기로 함.

세션 3은 왠지 내가 직접 웹 성능 최적화를 들어야겠다고 생각을 했다. 그래서 결국 세션 1,2는 코드랩을, 세션 3은 HTTP/3 내용을 들었다.

 

그러나 코드랩은 내가 새롭게 배울 것들이 많기를 바랐으나.... 그냥 상식적인 비구조화 할당, 리터럴 문자열, 프로미스, async await 등 내용들이었다..-.-

그러므로 아래 부분부터 유익했던 내용들 정리~!

 

[HTTP/3 웹 최적화 기술 이해하기]

웹 최적화란, 웹 사이트의 로딩 속도를 최대한 빠르게 만드는 기술.

# 웹 최적화를 시키는 방법 3가지

• 백엔드를 최적화 (DNS RTT 가속, DNS 캐싱, 로드밸런스, 웹 서버 프록시 서버 등)
• 프론트엔드를 최적화 (네트워크, 디바이스, 브라우저 등 실제 사용자 환경에 알맞게 최적화 시키는 작업이 중요)
• 프로토콜 최적화(이번 주제)

제일 적은 비용으로 큰 최적화 성능을 얻을 수 있는 것은 프론트엔드 최적화 작업이다.

 

# 프론트엔드 성능 최적화를 시킬 수 있는 여러 가지 방법 소개

코드 중복, 주석, CSS 스타일 등 코드를 조금이라도 짧게 줄여나가는 것부터 웹 성능 최적화에 엄청난 효과를 얻을 수 있다.

특히나 불필요한 CSS 코드에 성능을 많이 버릴 수 있으므로 신경을 많이 쓰면 효과적.

# gzip : 스크립트 압축 전달

# webP :이미지 형식 최적화 
*이미지 확장자, 사이즈 등 브라우저마다 선호하는 이미지 파일이 다르므로, 해당 브라우저마다 알맞은 이미지를 사용하도록 적용하는 것.

 

# 브라우저 cache 사용 cache-Control Header

로고 이미지와 같이 반영구적으로 변하지 않을 데이터는, 웹 접속마다 요청해서 가져오게 하는 것이 아닌, 사용자 로컬의 캐시에 저장하도록.

 

# DNS 조회 최소화 Domain Sharding

(이건 뭔지 알아봐야 함...)

자신의 네임서버가 충분한 퍼포먼스가 나올 때 이 Domain Sharding을 사용하면 좋음.

 

# CSS와 js의 위치

css코드보다 js코드가 더 상단에 위치해 있다면, 사용자가 페이지에 접속한 순간, 보이는 화면보다 내부에서 동작하는 기능이 먼저 세팅이 되므로, 흰 백지 페이지가 길어지게 됨.

# 페이지 읽어오기, 서드파티 최적화

(알아보기...)

 

[프로토콜 최적화]

클라이언트와 서버 상 주고받는 통신 부분을 최적화. 조금 더 웹 페이지 또는 데이터를 빠르게 요청, 응답을 할 수 있도록.

HTTP3!! 그러나 이 부분을 알기 위해서는 HTTP2의 개념을 알고 있어야 함.

HTTP2에서 웹 성능을 최적화시킬 수 있는 요소들

#멀티플렉싱 

# 헤더 인덱싱과 압축 (사진, 영상 등 미디어 파일)

# Server push : 클라이언트가 요청하지 않은 콘텐츠를 서버가 알아서 내려줌. (요청을 안 했는데 어떻게..? )
* 주로 어떤 컨텐츠를 서버 푸시해야 하는지? 개발자 도구 - 네트워크 탭 'Priority - Highest'로 나오는 항목들이 서버에서 로딩 리소스가 많이 드는 항목들이라, 이러한 항목들을 서버 푸시를 해주면 효과적.

HTTP/2의 문제 => HTTP의 HOLB문제는 해결할 수 있으나, TCP의 HOLB문제가 해결되지 않음.

그래서 이러한 부분을 해결하기 위해 나온 것이 HTTP3~!

#QUIC(Quick UDP Internet Connections) : 요청 온 순서대로 응답을 보내는 것이 아닌, 요청 후 응답할 수 있는 상태가 되면 순서 상관없이 바로 응답.

#HTTP3을 UDP로 사용해보자.

# UDP란? udp/tcp 차이

#연결 최소화, Zero RTT 클라이언트, 서버와 유저가 서로 기억하고 있음. 한 번만 커넥트 하면 이후에는 신뢰성 있는 네트워킹이 가능.

# HTTP/3의 프로토콜 스택

#HTTP/3 - QUIC - UDP 

기존 HTTP 프로토콜 계층에서 신뢰성 레이어 계층이 추가. (패킷 재전송, 혼잡 제어, 손실 회복)

(네트워크 탭 - http/2+quic/46 이게 http3 사용하고 있는 것임)

 

[웹 어셈블리]

웹에서 동작하는 새로운 언어. 다른 언어로부터 컴파일을 돌려서 나온 웹 언어.

(무려 애플의 사파리도 이것을 받아들일 정도...)

자바스크립트 언어는 어떠한 기능, 어떠한 페이지 요청, 언제 요청인지 등에 따라 성능이 많이 좌우되지만, 이러한 부분에서의 웹 어셈블리는 최적화된 상태로 일관성 있는 성능을 보여줌.

(이미지 로테이트 또는 처리, 동영상 처리 등 계산 처리가 많이 들어가는 부분에 효과적. 자바스크립트와 웹 어셈블리 병행 사용 가능)

자바스크립트를 대체할 수 있는 언어는 아님.

# 자바스크립트와는 어떤 차이? 자바스크립트는 스택 베이스가 아니지만, 웹 어셈블리는 스택베이스이다. (스택베이스가 뭔지는 찾아보기)

# 웹 어셈블리를 다뤄볼 수 있는 툴 - WebAssembly Explorer

#웹 어셈블리 스튜디오란?

#WASM, WASM Thread, WASM Thread SIMD

#WASI interface types

와즘은 컴파일 언어인데 어느 환경에서 어느 언어든 상관없이 돌아가도록. (자바스크립트는 컴파일이 아니라 웹 환경이기 때문에 브라우저 환경에 종속임)

 

[웹 기술로 만드는 동영상 편집기]

Vrew: 인공지능 영상 편집기 

FFMPEG 라이브러리 : 최종 파일 만들기 

Electron : 프리뷰 기능 라이브러리

(프리뷰는 압축해 놓은 상태, 최종 파일이 압축 풀어놓은 거)

프리뷰에서 불확실한 영상 구간 처리를 어떻게 했느냐?

항상 압축을 해 놓은 상태에서 작업을 해야 하는데 어떻게?? 해당 문제를 해결하기 위해 압축을 풀면 엄청난 용량이..?!

스트리밍, 실행 중 스트리밍 안 좋으면 화질 줄이는 등 전부 IFrame 상태에서 작업?

오디오 버퍼 관리 Web Audio API  - W3c

 

# 영상 편집기 관점에서의 WEB 기술

• 풍부한 라이브러리 생태계 이용 가능.
• 웹 어셈블리로 외부 라이브러리 점점 더 사용 가능.
• MediaSource Extension으로 비디오 편집은 제약이 많이 있음.
• web audio로 오디오 제어는 거의 완벽.
• WebGL, glsl로 하드웨어 가속 받는 실시간 필터 구현 가능

 

헉...헉... 내용이 너무 많다...

정리를 한 번 했는데, 아직 더 정리해야겠네...

아직 더 알아볼 내용은 많지만, 우선 오늘은 여기까지~!!