[Front-end] HTML5를 활용한 성능 개선

성능이란 무엇인가?

*The RAIL Performance Model

RAIL.png

오늘은 Loading에 대해서만 이야기 합니다.

*로딩 과정의 이해

loading.png

*Connect/Request/Response [자원 요청에 대한 과정]

rr.png

-Stalled : Browser waiting
-TTFB : Server Time

*Waterfall Chart

waterfall


 

*Front End 성능 개선이란?
== Waterfall Chart를 어떻게 개선할 것인가?

1.요청수 최소화 하기
== Waterfall Chart의 높이 줄이기

자원의 Merge
   1. JS, CSS의 Merge : Grunt, gulp와 같은 자동화 퉆을 이용한 자동 merge
2. IMAGE의 Merge[CSS Sprite]

sprite

불필요한 자원의 제거

자원의 재사용( Cache) < LocalStorage 이용 : 클라이언트의 Database를 이용하여 Request수를 줄인다.
_!브라우저 캐쉬를 사용하면 안되는가? : 안된다! 왜냐하면, 브라우저 캐시는 제한이 있다. 제한을 초과한 경우, 기존 캐싱 자원이 삭제된다. 또한 LocalStorage는 빠르다. 예를 들어, 스마트 폰의 경우 최대 5배까지 Native Cacher 보다 빠르다.

local.png

_ JS,CSS의 LocalStorage를 이용한 캐싱 : 자주 변경이 되지 않는 파일에 대해서는 LocalStorage를 이용해 확실하게 캐싱되도록 처리
_ LocalStorage Flow Chart

flowchart
_ LocalStorage 캐싱을 지원하는 오픈 소스 : basket.js

초기 로딩 속도에 필요 없는 자원 나중에 로딩

 

2. 요청 크기 최소화 하기
== Waterfall Chart의 폭 줄이기
== HTTP Request 양 줄이기

자원의 크기를 최소화
_1. Minify와 Obfuscation : 주석제거,공백제거 / 변수명 난독화 , Grunt, gulp와 같은 자동화 툴을 이용한 HTML, CSS minified와 JS minified, obfuscation
_2. 이미지 크기 줄이기 : 이미지의 크기를 결정하는 요인[포맷 / 사이즈] 줄이기
_2-1. 이미지 포맷 기준

imageformat
_2-2. 이미지 사이즈 산출 = Pixel 수(width * height) * 표현할 수 있는 컬러 수
_! 고해상도 (레티나) 대응을 위해, 실제 표현하는 사이즈보다 2배 이상으로 사이즈 조정
_3. HTML5를 이용한 반응형 이미지

srcsstpicture

HTTP Request Header 줄이기

Gzip compress

 

3. 렌더링 줄이기
== Waterfall Chart 간격 줄이기

-브라우저 렌더링 과정 : TTFB[Time To First Bytes] 이후, 병렬로 렌더링 한다.

rendering

-자원의 위치에 따른 렌더링
HTML.png_A : head 안의 모든 자원 로딩 후 body 파싱. First Paint Time을 결정한다.
_B : 병렬 렌더링 불가 : 스크립트는 다양한 작업을 수행하는 코드로 이루어져 있고, DOM을 변경하는 작업들이 포함되어 있을 수 있기 때문에, 블록 된다.
b1
_! HTML5를 이용한 스크립트 로딩
_B-1. defer를 이용 : HTML 파싱이 완료된 이후에, 스크립트를 실행
defer

_B-2. async를 이용 : 스크립트를 실행할 때만, HTML 파싱이 중단
async = false일 경우, 순서 보장 (기본값은 true)async
_B-3. defer와 async의 적절한 사용 : DOM 제어와 관련이 있는 스크립트는 defer / DOM 제어와 관련이 없고, 의존성이 없는 스크립트는 async
da
_C : body 렌더링이 완료된 이후

-적절한 자원의 위치 선정
_1. 시각적으로 빠른 화면을 제공하기 위해, head에는 레이아웃 구성에 꼭 필요한 CSS FILE만 넣는다.
_2. body 태그 안에는 CSS나 Script를 넣지 않는다.
_! 전체 렌더링이 잠시 중단된다.
_3. Script는 body 태그 닫기 전에 넣는다.

 

4. 결론
*Front End 성능 개선이란?
==Waterfall Chart를 어떻게 개선할 것인가?

conclusion.png

 


 

출처: HTML5를 활용한 Front-End 성능 개선

회사의 홈페이지를 만들다가 고해상도의 이미지들 때문에 로딩하는 시간이 길어졌다. 앞으로를 위해서도 해결방법을 알아야 할 것 같아서 찾던 중에 이 자료를 공부하게 되었다. 이제 2개월.  공부에는 끝이 없다는 사실을 다시금 깨닫는다.

지금 당장 적용할 수 있는 건 Image를 sprite 형식으로 쪼개서 사용하는 방법.
규모가 큰 프로젝트 일 경우 css/js를 minimize 할 것.
적용하기 위해 더 공부가 필요한 부분은 LocalStorage,  캐싱, 파싱 …

[Front-end] CSS 실무 테크닉

2015.12 [Front-end 기술 세미나 발표자료]

    1. Del 태그의 취소선과 폰트 색이 다르게

Mark Up

<del><span>취소선</span></del>

CSS

del {color:#f00;}
del span{color:#333;}

결과

position_relative_2


 

  1. 이미지 마우스 오버시 안쪽으로 border 생성
  2. 둥근 투명 마스크
  3. 이미지 / 텍스트 형태의 레이아웃
  4. CSS 우선순위에 따른 계산방법
  5. CSS 호출 방법에 따른 속도

출처 : CSS 실무 테크닉

[번역]Why can’t we find Front End developers?

대부분의 사람들이 생각하는 프론트 엔드 엔지니어링

  1. 포토샵 파일, 이미지, 와이어 프레임 등을 가지고 웹 페이지를 만드는 일
  2. 때로는 앞서 나온 포토샵 파일, 이미지, 와이어프레임을 그리는 일
  3. 웹 페이지에 애니메이션을 만들고 트랜지션 효과를 주기 위해 자바스크립트를 작성하는 것
  4. 콘텐츠를 정의하고 이를 꾸미는 HTML과 CSS를 작성하는 것

프론트 엔드 개발자가 실제로 하는 일

  1. 디자이너와 엔지니어 간의 시각적 언어 확립
  2. 시각 디자인으로부터 콘텐츠, 브랜드, 기능 등을 표현한 컴포턴트 세트 정의
  3. 컨벤션, 프레임워크, 요구 사항, 시각적 언어, 스펙 면에서 웹 애플리케이션의 기준 확립
  4. 웹 애플리케이션의 범위를 기기, 브라우저, 화면, 애니메이션의 측면에서 정의
  5. 브랜드 충성도, 코드 품질, 관계자의 상품 리뷰를 위한 품질 보증 가이드라인 개발
  6. 적절한 간격, 타이포그래피, 헤딩, 글꼴, 아이콘, 여백, 그리드 등을 사용해 웹 애플리케이션 꾸미기
  7. 디자인 가이드라인을 따르며 다양한 해상도에 대응하는 이미지, 디바이스 별 목업 등을 사용해 웹 애플리케이션 꾸미기
  8. 시맨틱, 접근성, 검색엔진 최적화, 스키마, 마이크로포맷 등을 고려하여 웹 애플리케이션 마크업하기
  9. API에 접근하여 사용하기 편하고 배터리 소모가 없는 디바이스 및 클라이언트가 인지하는 방식으로 정보를 가져오기
  10. 부드러운 애니메이션, 트랜지션, 게으른 로딩[lazy loading], 인터랙션, 애플리케이션 워크플로우를 수행하는 클라이언트 사이드 코드 개발. 대부분 점진적 기능 향상 및 하위 표준 호환성까지 고려.
  11. CORS[Cross Origin Resource Sharing]을 고려하는 한편 XSS[Cross Site Scripting]와 CSRF[Cross Site Request Forgery] 공격을 막아낼 수 있도록 백엔드 접속에 대한 안정성 확보
  12. 엄격한 데드라인, 관계자들의 요구, 기기별 제한에도 불구하고 항상 사용자가 최우선이라는 점을 잊지 않는 것
  13. 다루는 도구
    시각 디자인 도구(포토샵, Adobe, Macaw, Sketch)
    프로그래밍 도구(IDE, Command Line, Source Version Control, Bash script, build task)
    마케팅(뉴스레터, 캠페인, 분석, 검색엔진 최적화, 소셜미디어)
    UX(애니메이션, 트랜지션, 피드백, 인터페이스, 시각적 언어)
    콘텐츠 수정(구획점, 단어가 뚝 떨어지지 않게 하는 일, 가독성, 색상)

 

나쁜 프론트 엔드 엔지니어 😦

  1. 자바스크립트 라이브러리를 남용하는 사람. 자바스크립트 내부를 제대로 알지 못하기 때문에 라이브러리를 남용한다.(예: 모든 작업에 jQuery 가져다 붙이기)
  2. 자바스크립트 플러그인을 남용하는 사람. 다른 사람의 코드를 읽을 능력도 없이 가져다 쓰는 경우(예: jQuery.doParallaxPls.js)
  3. 전체 CSS/JS 기능의 5%밖에 안쓰면서 요구사항이나 디자인도 안보고 성능 비교/평가도 안하고 웹 애플리케이션 CSS 프레임워크를 붙이는 사람
  4. CSS 프레임워크만 가져다 붙이면 “반응형” 웹 사이트가 된다고 생각하는 사람. 또는 이러한 방승성이 웹 애플리케이션에 언제든 뿌리기만 하면 되는 양념으로 생각하는 사람
  5. “반응형 웹 디자인”에 대해 말하면서 서버측 기법에 대해서는 알지 못하는 사람
  6. 컨벤션, 전처리 도구[preprocessor], 네이밍 표준, 모범 예시없이 CSS 코딩을 하면서 셀렉터, 아이디, 매직 넘버, !important를 과하게 사용하는 사람
  7. 성능, 메모리 누수(+메모리 누수가 무엇인지 잘 모르는 점)에 대해 무시하고 자신의 코드를 검사하거나 측정하지 못하는 사람
  8. 아무런 기준없이 제품을 보여주는 사람 또는 “제 컴퓨터/브라우저/디바이스 에서는 잘 됩니다” 따위를 기준으로 삼는 사람
  9. 30년 된 소프트웨어 엔지니어링을 무시하면서 소프트웨어를 작성하는 사람(?)

 

숙련된 프론트 엔드 엔지니어가 알아야 하거나 작업시 해야할 일(HINT: 고용하고 싶은 사람!)

  1. DNS Resolution, CDN[Content Delivery Networks]사용, 여러 호스트 이름을 통한 리소스 요청 성능 향상
  2. HTTP 헤더(Expires, Cache-Control, If-Modified-Since)
  3.  스티브 사우더스의 규칙 전부(고성능 웹사이트)
  4. PageSpeed, YSlow, 크롬 개발자 도구 Audit, 크롬 개발자 도구 Timeline에서 보여주는 문제를 해결하는 범
  5. 작업을 서버에서 해야할 때와 클라이언트에서 해야할 때 구분
  6. 캐시, 프리 페칭[pre-fetching]및 지연 로드 기법
  7. 네이티브 자바스크립트. 직접 바닥부터 코드를 작성해야 할 때 혹은 다른 사람의 코드를 가져다 써야 할 때를 아는 것. 그리고 두 작업의 장점과 단점을 평가할 수 있는 능력
  8. 최신 MVC 자바스크립트 라이브러리(예: AngularJS, EmberJS, ReactJS), 그래픽 라이브러리(예: D3, SnapSVG), DOM 관련 라이브러리(예: jQuery, Zepto), 게으른 로딩 또는 패키지 관리 라이브러리(예: RegularJS, CommonJS), 태스크 관리자(예. Grunt, Gulp), 패키지 관리자(예: Bower, ComponentJS), 테스팅(예: Protractor, Selenium)에 대한 지식과 사용
  9. 이미지 포맷과 장점. 언제 무엇을 어떻게 써야 하는가에 대한 지식. 이미지 최적화 기법과 사용 계획(스프라이트, 게으른 로딩 기법, 캐시 비움, 인터레이스드 PNG)
  10. CSS 표준, 최신 컨벤션과 기법(예: BEM, SMACSS, OOCSS)에 대한 지식과 사용
  11. 자바스크립트의 컴퓨터 과학(메모리 관리, 싱글 스레드 특성, 가비지 컬렉터 알고리즘, 타임아웃, 스코핑, 호이스팅, 패턴)

 

출처 : 프론트엔드 개발자는 왜 구하기 어렵나요?

원문 : Why can’t we find Front End developers?