DOM(Document Object Model)과 Document.ready와 Window.onload의 차이에 대해서 알아보도록 하겠습니다.
DOM(Document Object Model)
DOM(Document Object Model) 즉, 돔이라고 일반적으로 말하며 돔(DOM)은 일반적으로 우리가 쉽게 접하는 인터넷 브라우저 안의 웹 페이지에 대한 인터페이스입니다.
기본적으로 여러 프로그램들이 페이지의 구조 및 이미지, 색상, 그리고 프로그램의 기본적은 틀의 구조를 구성하게 해주며 자신이 원하는 페이지의 구조와 이미지 등을 꾸며주는 CSS 즉, 스타일을 읽고 조작할 수 있도록 API를 제공하고 있습니다.
DOM(Document Object Model) 객체를 이용한 웹페이지 생성 과정
웹 브라우저가 원본 HTML 문서를 읽어들인다.
스타일을 입히고 대화형 페이지로 만든다.
뷰 포트라고하는 사용자에게 보여주는 브라우저에 표현되는 돔객체의 모습을 표시합니다.
여기까지 웹브라우저에 DOM(Document Object Model) 객체를 표현하는 과정을 “Critical Rendering Path”라고 한다.
Critical Rendering Path 란 무엇인가?
Critical Rendering Path 에서 다루듯이 이 과정은 여러 단계로 나누어져 있습니다.
[HTML] 서버에서 응답으로 받은 HTML 데이터를 파싱
[DOM Tree] HTML을 parsing한 결과로 돔트리(DOM Tree)를 생성
[CSS] 파싱(parsing)하는 중 CSS 파일링크를 만나면 CSS 파일을 요청하여 데이터를 요청
[CSSOM] CSS 파일 및 리소스를 해석하고 CSSOM(CSS Object Model) 객체를 생성
[Render Tree] DOM Tree와 CSSOM이 모두 생성되면 두가지를 이용하여 렌더트리(Render Tree)를 생성
[Layout (Reflow)] 렌더트리(Render Tree)에 존재하는 각각의 노드가 브라우저 화면상의 위치와 행동을 계산하는 Layout과정을 진행
[Paint] 브라우저 화면상에 실제 클라이언트가 볼 수 있도록 픽셀을 Paint하여 그려준다.
쉽게 표현하면, 첫번째 단계에서 브라우저는 읽어들인 문서를 파일, 문서, 태그 등 단위별로 해석(파싱)하여 DOM(Document Object Model)을 만들어내고 DOM Tree를 구성하여 DOM Tree를 만들어 최종적으로 어떤 내용을 페이지에 보통 사람들이 쉽게 말하는 렌더링(Rendering)할지 결정합니다.
다음으로 두번째 단계에서 CSS파일을 요청하여 CSSOM(CSS Object Model)을 만들어 낸다.
마지막으로 DOM Tree와 CSSOM(CSS Object Model) 이용해 렌더트리(Render Tree)를 만든다.
랜더트리까지 준비가 완료되면 현재까지 HTML 태그 및 구성요소들을 준비하고 CSS를 이용해 예쁘게 외형적 구조까지 완료되었다면 어디에 랜더트리를 윈도우 엣지, 크롬, 파이어폭스 등등 브라우저 화면상의 배치를 어디에 해줄지 결정해주는 과정을 Layout과정이라고 한다.
다음으로 브라우저 화면에 Paint 작업을 통해 픽셀에다 페인트작업을 완료한다.
마지막으로 브라우저는 해당 렌더링을 수행합니다.
즉, HTML -> DOM Tree -> CSS -> CSSOM -> Render Tree (DOM Tree + CSSOM) -> Layout(Position) -> Paint -> Rendering 세부과정을 통해 브라우저에서 우리가 마주치는 웹페이지를 볼 수 있습니다.
※ 지금 여기서의 문제는 글을 쓰는 이유라고 할 수 있는 DOM(Document Object Model)과 CSSOM(CSS Object Model)에 있는 Javscript 때문이다.
※ HTML 파일은 파싱을 할떄 맨위에 적혀있는 코드 순서대로 읽기 시작한다. 현재 자바스크립트가 맨위에 올라와 특정 태그 요소의 값을 불러오려고 할 때 DOM(Document Object Model)이 자바스크립트를 이해하지 못하고 오류를 발생시키거나 페이지를 렌더링하지 못하는 경우를 발생시키는 것이였다. 결론적으로 렌더트리를 구성하기 위해 DOM(Document Object Model)과 CSSOM(CSS Object Model)이 정확하게 파싱되어 렌더트리를 구성해야 브라우저에 레이아웃 및 페인트 과정을 거쳐 보여지는데 DOM(Document Object Model)에서 이미 자바스크립트가 이해할 수 없는 태그요소 id 값이 존재하였기 때문에 에러를 발생시킨 것이였다.
※ 결론적으로, 자바스크립트 위치만 바꿔도 해결되는 에러였다는 것이다... HTML 먼저 읽고 Javascript를 읽는다면 일어나지 않을 오류였다. 역시... 컴퓨터는 거짓말 하지 않는다...
Document.ready와 Window.onload의 차이
window.onload=function(){
// 외부 리소스와 파일 전부를 가져와야 window.onload()가 실행
// 리소스와 파일이 전부 불러올떄까지 새로고침이 돌아가는 흰색화면을 경험할 수 있음
// 한번에 짠~ 한고 나타남
}
$.function({
// 제이쿼리 방식
});
$(document).ready({
// 외부파일 또는 리소스가 전부 오지 않더라도 현재 생셩된 DOM(Document Object Model)만 생성되더라도
// Document.ready()실행
// 뭔가 형체는 보이는데 순차적으로 하나씩 뭔가 보여짐
});
Window.onload
전체 페이지의 외부 리소스와 이미지가 모두 브라우저(클라이언트)에서 불러들어졌을때 이후에 작동합니다.
외부 리소스와 이미지를 불러오는데 지연 및 딜레이가 발생할 경우 지연 및 딜레이 시간 만큼 늦게 브라우저가 동작을 하는 단점이 있습니다.
그리고, 외부 링크(Link)를 포함시켰을 경우 그 외부 링크에 관련된 DOM(Document Object Model)과 CSSOM(CSS Object Model), Javascript의 렌더트리(Render Tree)에 window.onload()가 존재한다면 여러 브라우저 창이 올라오더라도 단 하나만 존재하게 되어 페이지가 호출 되지 않을 수 있습니다.
쉽게 생각하면 window.onload()를 통해 브라우저 창에 만들어진 돔 객체를 불러달라 요청을 하였는데 불러들인 렌더트리에 2개의 window.onload()가 있다면 2개의 window.onload()중에 무엇이 우선순위가 있는지 판별하기 어려우며 경우에 따라 우선순위가 스크립트의 순서에 따라 생성될 가능성도 있지만 두가지가 동시에 엮인 경우 페이지가 렌더트리의 혼선으로 인해 호출되지 않을 가능성이 있습니다.
Document.ready
외부 리소스나 이미지와는 상관없이 요청한 DOM 객체만 Load만 완료되면 바로 $(doument).ready({ });의 안의 함수가 실행된다.
DOM(Document Object Model)만 호출해도 화면상에 구조가 나타나기 때문에 window.onload()보다 속도면에서 빠릅니다.
외부파일을 include하여 포현하더라도 모두 순서대로 실행이 되어 외부파일이 들어오는 순서에 따라 실행되기 때문에 혼선이 없다.
제이쿼리를 선호하지 않는 개발자들도 있으나 제이쿼리(JQuery)를 이용한다면 웹 개발의 생산성을 높여주는 부분도 있기 때문에 무엇이 좋고 나쁘고 판결하기는 힘들다.
-- 개인적 생각으로 개발은 회사에서 사용중인 방식을 따르되 사이드프로젝트는 개인이 선호하고 좋아하는 방법으로 만들면됩니다. 물론 회사의 방식과 개인의 선호 방식이 일치하다면 최고라고 생각합니다.
댓글 영역