HTML ? CSS ? JS ?
키워드로 정리하면 다음과 같다.
HTML = 구조
CSS = 시각적인 정적 표현 = 스타일
JS = 동적 처리
(웹 개발 전공수업 맨 첫 장 생각난다)
웹 동작원리
이제는 당연하지만 다시금 그려보기.
크로스 브라우징
웹 표준은 W3C 에서 정의하고, 각 브라우저 벤더사(제작사) 들은 해당 표준에 맞추어 브라우저를 개발한다.
그러나 벤더사가 다른 만큼 같은 웹일지라도 브라우저에 따라 사용자 경험에 차이가 발생하게 되는데, 이를 크로스 브라우징 이슈라고 한다.
따라서 웹개발 시 동일한 사용자 경험을 위해 크로스 브라우징을 고려하여 개발해야 한다.
Viewport
브라우저에 렌더링(출력)되는 전체 영역. 모바일(태블릿) 디바이스에만 적용된다.
defer
HTML은 위에서 아래의 순서로 read 되므로 헤더에서 외부 스크립트 로드 시 로드가 완료될 때까지 이후의 DOM 생성을 멈추게 된다. 때문에 해당 스크립트 내에서 아직 생성되지 못한 DOM 요소에 접근하는 등의 위험이 발생할 수 있다. (반환 값이 null 이라거나 ,,)
바디의 맨 마지막에서 로드하면 어떨까? 페이지가 모두 파싱된 후 마지막에 스크립트를 로드한다. 하지만 스크립트 파일이 크고 무거울수록 로드에 시간이 소요되기 때문에 사용자가 정상적인 페이지를 보기까지의 대기시간이 발생하게 된다.
이런 문제점들을 막기 위해서는 헤더에서 <script> 의 defer 속성을 사용하여 스크립트를 로드하면 된다. defer 는 HTML 파싱과 스크립트 로드를 병렬로 진행하면서도, HTML 파싱이 모두 끝난 후에 스크립트 파일을 실행하기 때문에 사용자의 많은 대기 시간도, 아직 생성되지 않은 DOM 요소에 접근하는 등의 위험도 발생하지 않는다.
defer 와 유사한 속성으로 async 가 있다. async 또한 HTML 파싱과 스크립트 로드를 병렬로 진행한다. 다만, 스크립트 로드가 완료되면 진행하던 HTML 파싱을 중단하고 로드된 스크립트 파일을 실행한다. 때문에 헤더에서의 로드와 마찬가지로 생성되지 않은 DOM 요소에 접근하는 위험이 발생할 수 있고, 대기시간 또한 발생할 수 있다.
더하여 async 는 로드된 순으로 스크립트를 실행하기 때문에 순서를 보장하기 어렵지만, defer 는 HTML 파싱 완료 후 작성한 순서대로 스크립트를 실행하기 때문에 순서가 보장된다.
결론 : 헤더에서 defer 를 쓰자 (?)
