High performance web user interfaces 요약

2016.06.07 00:50

Google I/O 2016에서 웹쪽 주제로는 첫 번째 세션이었던 High performance web user interfaces 를 요악합니다.


- Progressive Web Apps

    - 여러 기능을 사용하기 위해서는 HTTPS가 필요

        - push messaging, offline 혹은 좋지 않은 접속 상태 (by service worker)

- 사용자는 native app처럼 생긴 앱은 native app 처럼 동작하기를 기대한다.

    - 동작(behaves)은 두 가지로 나뉜다. - performance, interaction

- Performance

    - RAIL

        - 퍼포먼스를 고려할 때 사용자를 중심에 두고 생각하는 모델

        - Response (0.1 sec), Animation (16ms), Idle (50ms), Load (1 sec)

        - 현실에서 중요도는 L > A > R > I 로 생각된다.

        - Add to homescreen에서 실행되거나 PWA에서는 중요도가 R = A > I > L 라고 생각.

            - add to homescreen에서 실행되는 경우에는 service worker가 기본으로 설정되어 있어야 하기 때문

            - SW에서 오프라인이거나 연결상태가 좋지 않을 경우 로딩을 컨트롤 할 수 있다.

            - 매일 실행하는 앱에서는 스크롤이 잘 되거나, 반응성이 좋거나 하는 것이 더 중요하다.

            - App이 아니라 site의 경우에도 user interface의 반응성이 좋은 것은 중요


- Three components의 성능을 높이는 사례를 볼 것임

    - sidenav, dismissable card, expanding and collapsing view

- sidenav

    - pointer-events: none;

        - 미리 준비되어 있어야 하고 언제든 동작 가능해야 하는데 사용자가 클릭하자마자 동작해야 하므로 렌더트리 내에 포함되어 있어야 한다. 그렇지 않다면 렌더트리에 포함될 때 layout, styles, painting 이 트리거 된 후에야 움직일 수 있다. 따라서 hidden 되어 있지 않고 렌더트리에 포함되어 있으려면 모든 엘리먼트의 최상단에 있어야 하는데 그렇게 되면 다른 엘리먼트를 클릭할 수 없다. 따라서 pointer-events를 none으로 설정하면 클릭이 아래에 깔린 엘리먼트로 넘어가게 된다. 화면에 노출될 때는 auto로 변경

    - sidenav가 자체의 composite layer를 갖도록 한다.

        - composite layer: 페이지의 특정한 부분을 페이지의 다른 부분과 분리하는 것

        - will-change: transform; 사용 (예전에는 translateZ(0) 사용)

        - 필요한 곳에만 쓸 것. 메모리 과다 사용 문제, compositing에 걸리는 시간 최소화.

    - 터치로 sidenav를 움직일 경우 document에 이벤트 처리를 위임한다.

        - requestAnimationFrame 사용

        - touchmove 이벤트 핸들러에서 event.preventDefault()를 사용한다.

            - 기본적으로 크롬에서는 touchmove 이벤트를 발생시키는 회수를 줄인다. 손가락으로 가리키는 모든 이벤트를 받고자 한다면 preventDefault()를 사용해야 함.

    - Supercharged 동영상 http://bit.ly/side-nav

- swipeable cards

    - this.onStart = this.onStart.bind(this);

        - prototype을 instance로 복사하면서 현재 instance와 바인딩한다.

        - 호출하면 항상 현재 instance를 참조하고 addEventLister에서 this.onStart으로 등록/제거가 가능

    - onStart에서 style.willChange를 지정해서 별도 레이어로 분리 (필요할 때만 분리한다는 점이 중요)

    - 손쉬운 easing 패턴

        - value += (target - value) / strength

    - Supercharged 동영상 http://bit.ly/swipeable-cards

- Expand and Collapse

    - 이건 좀 어려운데 width, height, top, left를 변경하면 매 프레임마다 layout 트리거 되고 paint도 트리거됨

        - layout은 dom size에 비례하여 시간이 증가

    - transform을 쓰면 layout만 트리거 할 수 있다. (그래서 발표자가 좋아함) (참고: 크롬에서만..)

    - FLIP 방법을 적용

        - First, Last, Invert, Play

        - First: 초기 상태의 position을 얻는다. (getBoundingClientRect)

        - Last: 애니메이션을 마지막 프레임으로 옮겨간다. 그리고 마지막 상태의 position을 얻는다. (getBoundingClientRect)

        - Last로 갈 때 layout, style이 강제로 트리거 된다. Layout은 나쁜데 이렇게 해도 괜찮은가?

            - 단 한 번만 layout함. RAIL의 도움을 얻을 수 있다. 

        - Invert: Last에서 First로 되돌리는 값을 얻어 transform 시킨다. 그리고 transform에 transition을 설정.

        - Play: transform = 'none' 으로 설정하면 카드가 늘어나게 된다.

        - FLIP 주의점

            - scales은 자식 엘리먼트를 변경시킨다. 형제 엘리먼트를 고려해야 할지도

            - first 에서 last로 가는 과정은 layout과 style을 발생시키므로 조심해야 함

        - 성능에 덜 민감하고 Responsive Web Design에도 유용

- 렌더링 퍼포먼스에 대해 알고 싶다면

    - http://bit.ly/render-perf

- 데모에 나온 UI를 더 자세히 살펴보고 싶다면

    - http://bit.ly/supercharged-ui



이 동영상에는 코드에 대한 설명이 많아 모든 내용을 요약하지는 않았습니다. 보다 상세한 내용이 궁금한 분은 동영상을 확인하기 바랍니다.

nundefined ETC expand and collapse, Flip, google io, google io 2016, https, progressive web app, pwa, Rail, requestAnimationFrame, side navigation, sidenav, supercharged ui, swipeable, swipeable cards, Transform, Transition

What's new in Chrome DevTools? by Addy Osmani 간단 정리

2015.10.06 01:31

지난 9월 16~17일간 토론토에서 열렸던 WEB UNLEASHED 2015에서 Addy Osmani가 발표한 What's new in Chrome DevTools?를 간단하게 요약했다. 발표자료동영상이 각각 제공되고 있으니 관심있는 분은 꼭 원본 자료를 살펴보기 바란다. 발표자료보다 동영상에서 확인할 수 있는 내용이 많으므로 자료를 살펴볼 결심을 했다면 동영상을 볼 것을 추천한다.


DevTools 공통

- DevTools 상단의 메뉴탭의 위치를 drag & drop으로 변경 가능

- Console에서 다양한 syntax highlighting 지원


Network Panel

> Filmstrip 지원

 - 시간별로 스크린샷을 기록.

 - 실제 화면에 렌더링되는 내용을 알 수 있음.

> Throttling

 - 브라우저에서 네트워크 속도를 조절할 수 있음.

 - 이미 정해져 있는 속도 중에서 선택하거나 임의로 조건을 지정할 수 있음.

> Block Request

 - 특정 요청을 보내지 않도록 막을 수 있음.

 - 특정한 요청으로 인해 속도가 느려지는 것으로 의심된다면 해당 요청만 막은 후 테스트 가능.


Timeline

> long frame times

 - 붉은 삼각형은 jank가 존재하는 것을 나타냄

 - Jank: 16ms(실제로는 10ms)내에 화면이 갱신되지 못해 프레임 속도가 떨어지는 현상

> Filmstrip

 - 메뉴의 Screenshots를 선택

 - 애니메이션과 같이 화면에 그려지는 내용을 확인할 수 있음

 - 타임라인의 특정 위치를 선택하면 해당 시간에서 화면에 그려지는 내용을 알 수 있음

> Aggregated Details

 - 실행 비용이 가장 높은 코드를 쉽게 볼 수 있음

 - URL을 기준으로 모아볼 수 있음

> Paint Profiler

 - 메뉴의 Paint 선택

 - 페인트된 내용, 그리는데 걸리는 시간, 페인트에 대한 상세한 내용을 알 수 있음.


Elements Panel

> Animation Inspection

 - about:flags에서 기능을 활성화해야 사용 가능

 - Elements > Styles > Toggle Animation controls

 - playback 속도, 실행 시간등을 간단히 변경하면서 테스트 가능

> Cubic Bezier Editor

 - transition이 적용된 엘리먼트에서 직접 값을 변경해가며 테스트 가능

> DOM Animation Changes

 - Class 변경으로 애니메이션이 이루어질 때 변경이 발생하는 dom에 대한 하이라이트 지원

> Colors & Pallettes

 - Eye Dropper로 페이지상의 색을 바로 선택 가능

 - 페이지에서 사용중인 Color pallettes 지원

 - Matirial Design palette 지원

 - Custom palette 지원

> Search selectors

 - ctrl+f 후 셀렉터를 입력해서 element를 찾을 수 있음

> Event Listeners

 - 임의의 Dom에 등록된 이벤트 리스너를 확인할 수 있음

 - Framework를 사용하여 등록된 이벤트 리스너도 확인 가능

> HTML in Console

 - console에서 html element를 바로 수정할 수 있으며 화면에도 반영됨


Console

> tips

 - $0: 마지막으로 선택한 dom node

 - $$('header'): query selector의 alias

 - copy(): clipboard로 복사

 - inspect(): 코드로 특정한 코드를 선택하여 inspect할 수 있음

 - console.timeStamp: timeline에 라벨을 붙일 수 있음


Sources

> inline variables

 - 디버깅 중에 변수의 값을 인라인으로 표시

> Proactive Compilation

 - 컴파일러처럼 오류가 있을 경우 바로 표시

> Blackboxing JS libraries

 - 특정한 파일을 블랙박스 처리하여 해당 파일은 디버깅 과정에서 건너뛸 수 있음

> ES2015 Promises Inspector

 - about:flags에서 기능을 활성화해야 사용 가능

 - promise의 다양한 정보를 제공하여 디버깅을 편리하게 만듬

 - Async모드: 비동기적으로 실행되는 경우에도 call stack을 정상적으로 보여줌


이 외에도 계속 기능을 추가하고 있음



여기에서는 요약하지 않았지만 발표자료 초반에 RAIL에 대한 언급이 있다. 크롬팀에서는 Performance에 대해 지속적으로 RAIL 모델을 사용하고 있으므로 성능 개선에 대한 이해를 높이기 위해서는 RAIL 모델에 대해 이해를 하고 있는 것이 큰 도움이 될 것이다.

Devtools에 대한 세션 말고도 IE6 sucks!를 외치던 더글러스 크록포드 아저씨가 발표한 Upgrading the Web을 비롯하여 다양한 세션의 동영상이 유튜브에 업로드되어 있으니 다른 주제들도 살펴보기 바란다.


nundefined HTML5_JS_CSS Chrome, devtools, Rail, 개발자도구, 크롬

  1. Blog Icon

    비밀댓글입니다

  2. 크롬팀에서 설명하는 내용들은 대체로 개발 버전인 크롬 카나리에서 실행되는 경우가 많습니다. 카나리 버전을 한 번 사용해보시면 어떨까요? https://www.google.co.kr/chrome/browser/canary.html 이 페이지에서 다운로드 하실 수 있습니다.

Performance and RAIL

2015.08.02 00:24

지난 7월 12일 열렸던 Google I/O Extended 2015 서울에서 발표한 자료를 여기에 공유한다. 이 행사는 Google I/O 2015를 기념하여 I/O 행사에서 발표된 내용을 다시 공유하는 행사로써 국내의 다양한 Google Developer Group이 연합하여 진행하는 행사이다. 휴일이었지만 하루 종일 비가 와서 다소 부담스러운 날이었는데도 불구하고 천여명에 가까운 분들이 참석한 행사였다.



정보를 전달하는 이런 발표는 매번 지루해지곤 했는데 이번에도 다를 바가 없었다. 게다가 3~40분 내에 끝내시는 다른 분들에 비해 50분에 가깝게 발표하는 민페까지... 이런 여러 불편함에도 불구하고 발표를 들어주신 분들에게 감사할 따름이다.






nundefined Presentations Google, google io extended 2015 seoul, Performance, Rail, 구글, 성능, 퍼포먼스

Performance Guide RAIL 요약

2015.07.15 00:48

지난 5월 초 라스베가스에서 열렸던 LoopConf의 세션 중 Performance Guide RAIL를 요약했다. 동영상은 여기서 볼 수 있다.



Performance

- Performance는 성공적으로 실행되는 방법의 관점에서 살펴보는 행동, 작업, 활동이다.

- 성공의 의미: 성공이란 인간 두뇌의 지각 반응이 기대하는 바를 충족시키는 것이며, 사용자에게 초점을 맞추면 다른 것들은 따라온다는 것


RAIL 성능 모델 - Response, Animation, Idle, Load


Response

- 목적: 즉각적이라고 느끼도록 100ms 내에 반응

- 반응 속도에 따른 느낌을 알 수 있는 비디오: https://www.youtube.com/watch?v=vOvQCPLkPt4 (Applied Sciences Group: High Performance Touch on YouTube)


Animation

- 목적: 16ms 마다 프레임을 갱신

- 일정한 속도를 내는 쪽이 좋은 성능을 낸다고 받아들이게 된다.

- 따라서 0.5초 동안 아무것도 안하고 나머지 0.5초 동안 16ms마다 그리는 것보다 32ms마다 지속적으로 그리는 것이 사용자에게는 더 좋다.


Idle

- 목적: 가능한 긴 유휴시간을 확보

- 100ms 이내에 즉각적으로 반응하려면 100ms보다 짧은 시간마다 메인 쓰레드가 실행될 수 있도록 해야 한다. 따라서 유휴시간은 길 수록 좋다.


Load

- 목적: 사용자가 계속 집중할 수 있도록 1000ms 이내에 인터랙티브한 내용을 노출

- 1000ms (=1s) 내에 모든 내용을 보여줘야 한다는 의미는 아님. 일부라도 노출되어야 한다.


기타

서버와 통신하는 작업동안 긴 시간을 기다려야 하므로 이 시간에 트랜지션을 이용하여 사용자에게 즉각 반응하는 모습을 보여주는 것은 좋다. 그러나 트랜지션에는 수백 ms의 긴 시간이 걸리므로 주의해야 한다.


참고자료

- 슬라이드: bit.ly/perf-rails

- https://paulbakaus.com/tutorials/performance/the-illusion-of-motion/

- speed, performance and human perception

https://developers.google.com/web/fundamentals/performance/critical-rendering-path/

- Platform Success Model Explainer : chrome, blink가 performance에 대해 생각하는 내용을 알 수 있음




nundefined HTML5_JS_CSS Animation, Chrome, Google, IDLE, load, Performance, Rail, response, 구글, 성능, 크롬

Google I/O 2015 두 번째 날

2015.06.11 00:38

행사의 두 번째 날이 밝았으나... 이 날은 늦잠을 자고 말았다. 맞춰둔 알람은 제대로 듣지도 못하고 정신을 차리니 시간은 10시를 향해 가고 있었다. 이 때문에 9시 세션이었던 Polymer를 놓치는 불상사가 발생. 다행히 동영상으로도 제공되는 세션이라 최악의 상황은 면할 수 있었다.



오전부터 이번 IO의 기념품(?)인 넥서스9를 나눠주고 있었다. 집에서 이미 사용 중인 테블릿이 한 대 있고 그 활용도가 높지 않은 상태라 그런지 감동같은 감성적인 생각보다는 짬내서 안드로이드 M이나 올려봐야겠다는 생각이 들었다. 아직 올려보진 못했지만. 내심 테블릿 대신 핸드폰을 바랬는지도 모르겠다.



첫째 날 세션 중에 Notifications API가 구현되어 브라우저에 추가된 내용을 발표하는 자리가 있었는데 그 활용편이다. 웹사이트에서 알림을 사용하는 예제를 보여주는 세션이었다.



Notification을 구현하기 위해 위와 같이 세 가지 API를 같이 사용하게 된다.



Service worker에서 디버깅을 하려면 위 사진의 주소를 크롬브라우저에 입력하면 된다. 지금 사용 중인 브라우저에 입력해보니 구글 IO 사이트와 medium의 Service worker가 등록되어 있다.



성능 최적화 세션에 들어왔더니 이렇게 세 가지 숫자를 보여준다.



항상 느끼는 것이지만 이 동네 사람들은 경험을 정리하고 구조화하고 이름을 붙이는 것을 잘한다는 생각이 든다. 반면 우리나라 개발자들은 개발은 잘 하지만 이런 작업에는 약하다는 생각이 든다.



사용자의 각 동작을 RAIL에 맞게 분류한 화면이다. Animation은 16ms마다, 응답은 100ms보다 짧은 시간에, 로드는 1000ms 내에 화면이 갱신되어야 한다는 것이 RAIL의 개념이다. 시간표를 짤 때 처음 제목을 보고는 Ruby on Rails를 떠올렸다. 좀 노린 것일지도 모르겠다. 물론, 설명을 보고 금방 아닌 것을 알았지만.



왼쪽의 Paul Irish(@paul_irish)와 오른쪽의 Paul Lewis(@aerotwist). 위 사진의 RAIL 세션과 이어서 진행된 성능 최적화 세션은 두 명이 메인 스피커를 번갈아가며 진행했다. 개발자들을 대상으로 하는 직업탓인지 서로 이름이 Paul이라는 농담도 해가며 재미있게 진행했다. 위 사진에 보이는 슬라이드 첫 장에 Paul Irish의 이름밖에 없자 자기의 이름도 넣어달라며 장난을 치기도 했다. Paul Irish는 그에 응해 자기 이름보다 Paul Lewis의 이름을 더 크게 넣기도. 세션 내내 흥겨운 분위기였다. 



앞 세션에서 했던 RAIL를 다시 설명하고 있다. 이번 행사에서 모바일 웹 성능 최적화에 대한 세션은 다 RAIL 키워드를 중심으로 진행됐다. 당분간은 계속 이 키워드를 사용할 듯 싶다.



이 세션은 실제로 모바일 웹 성능 최적화를 진행했던 ESPN 사이트에 대한 설명이었는데 세션의 막바지에 청중들로부터 최적화를 하기를 원하는 사이트를 받아 분석하는 과정을 간단히 보여줬다. 슬라이드에 박혀 있는 고정된 그림으로 보다가 개발자 도구를 사용하여 문제가 되는 부분을 찾아가는 것을 보니 상대적으로 잘 와닿는 느낌이랄까.



시간표에 잡아뒀던 세션을 모두 마치고 행사장을 찍어봤다. 이틀동안 진행된 행사이긴 했지만 작은 세션들의 경우 두 번씩 하는 경우가 대부분이어서 실제로 느끼는 세션의 수는 더 적었다. IO에 다년간 참석했던 다른 사람들의 이야기를 모아보면 1. 작년보다 볼만한 것이 줄어든 것 같다. 2. 웹은 이제 두 번째 기술로 삼아야 하는 듯. 3. 작년에는 강의실 형태로 구성됐었는데 이번에는 이렇게 열린 형태로 구성되며서 강의 스타일보다는 구글 개발자와 직접 이야기하며 궁금한 점을 해결하는 형태로 바뀌는 것 같다. 4. 디자인 세션이 늘어난 듯. 아마 내년에는 더 늘어나지 않을까? 5. 시작은 개발자 행사였는데 점점 개발자 행사같이 생각되지 않는다. 등등이 있었다.


개인적으로는 안드로이드(모바일)이 50%, 사물인터넷이 20%, VR/AR이 20% 나머지가 10% 이하의 비중으로 느껴졌다. 특히나 웹의 경우에는 발전 혹은 혁신이라고 생각할만한 내용이 전혀 없었다. Service worker나 Notifications같은 경우에는 이미 한참 전부터 언급되던 것이 이번에 Stable 버전에 들어간 정도라 별로 와닿지 않았다. 이미 몇 달 전 국내에서 Service worker에 대한 이야기를 들었기에 신선함이 떨어졌을 수도 있다. 안드로이드 M에서 크롬이 웹뷰 대신 들어간다는 것도 있었지만 딱히 와닿지는 않고. 이는 개발 부담을 줄이려는 시도가 아닐까 싶기도 하다. 당분간은 Specification상에 존재하는 웹은 점점 발전하겠지만 사용자가 느끼는 웹은 상당히 정체되어 있을 것 같다. 물론 여기서 말하는 웹이란 브라우저에서 동작하는 것을 의미한다.


이런 행사에 참여하면 웹페이지를 통해 보는 것보다 더 생생하게 세상의 흐름을 느낄 수 있게 되는 것 같다. 무엇보다도 같은 경험을 공유한 사람들의 생각을 들을 수 있고 웹페이지에 나올 만큼의 뉴스꺼리는 아니지만 중요한 사실들을 알 수 있게 된다. (가령, 예전에는 웹쪽 일을 했던 구글러가 이제는 사물인터넷쪽 일을 한다던가 하는...) 이런 사실들이 모여 가리키고 있는 한 방향을 몸으로 느끼게 되는 것이 아닐까. 이런 행사에 참여하는 것이 여러 모로 쉬운 일은 아니지만 기회가 올 때마다 잡을만한 가치는 있다고 본다.



그리고 구글 IO의 세션 비디오가 공개됐다. 전체 세션은 아니고 강의실같은 장소에서 진행됐던 세션의 동영상이다. 한글 자막은 없지만 영어 자막이 포함되어 있으니 [cc] 메뉴를 눌러 켜놓고 보면 도움이 될 것이다. 한글로 기계 번역하는 메뉴가 있긴 한데 추천할만한 번역은 아니므로 영어로 보는 것을 추천한다.



nundefined ETC Android, Google, google io, Polymer, Rail, 구글, 구글IO, 안드로이드, 폴리머