브라우저 로딩, 렌더링, 파싱 프로세스의 블랙박스에 대한 간략한 분석_javascript 기술

Fiddler를 사용하여 IE6에서 리소스 다운로드 순서는 다음과 같습니다.

분명히 다운로드 순서는 위에서 아래로, 문서 스트림에 먼저 나타나는 리소스가 먼저 다운로드됩니다. IE8, Safari, Chrome 및 기타 브라우저에서도 유사합니다.

Firefox는 다운로드 순서를 최적화했습니다:

Firefox는 js, css를 미리 다운로드하고 이미지 및 기타 리소스의 다운로드를 나중에까지 연기합니다.

렌더링의 경우 Fiddler를 사용하여 네트워크 속도를 낮추면 다운로드 직후 CSS가 페이지에 렌더링되어 렌더링과 다운로드가 동시에 수행되는 것을 볼 수 있습니다. js의 구문 분석 및 실행도 비슷합니다.

js 실행 및 페이지 로딩 관련 이벤트 트리거에 대한 특별 테스트가 수행되었습니다. Firefox에서 테스트 페이지를 엽니다:

[22:13:32.947] HTML Start[22:13:32.947] normal inline script run time[22:13:34.904] normal external script run time[22:13:35.775] [body] normal external script run time[22:13:35.789] [body end] normal external script run time[22:13:35.789] HTML End[22:13:35.791] deferred inline script run time[22:13:35.791] deferred external script run time[22:13:35.793] DOMContentLoaded[22:13:38.144] images[0] onload[22:13:38.328] images[1] onload[22:13:39.105] images[2] onload[22:13:39.105] images[3] onload[22:13:39.106] window.onload

분명히 JS는 문서 흐름의 순서대로 엄격하게 실행됩니다. 지연된 스크립트는 마지막에 실행됩니다(참고: Firefox 3.5는 지연을 지원하기 시작하며 완벽하게 지원됩니다).

IE8을 다시 보면 결과는 다음과 같습니다.

[22:33:56.806] HTML Start[22:33:56.826] normal inline script run time[22:33:57.786] normal external script run time[22:33:57.812] deferred inline script run time[22:33:57.816] document.readyState = interactive[22:33:57.934] [body] normal external script run time[22:33:58.310] [body end] normal external script run time[22:33:58.310] HTML End[22:33:58.346] deferred external script run time[22:33:58.346] images[0].readyState = loading[22:33:58.346] images[0].readyState = complete[22:33:58.346] images[0] onload[22:33:58.361] doScroll[22:33:58.451] images[1].readyState = loading[22:33:58.479] images[1].readyState = complete[22:33:58.479] images[1] onload[22:33:58.794] images[2].readyState = loading[22:33:58.854] images[2].readyState = complete[22:33:58.854] images[2] onload[22:33:58.876] images[3].readyState = loading[22:33:58.876] images[3].readyState = complete[22:33:58.876] images[3] onload[22:33:58.887] document.readyState = complete[22:33:58.888] window.onload

IE8에서는 defer가 외부 스크립트에만 유효하고 인라인 스크립트에는 유효하지 않다는 것을 알 수 있습니다. 또한 DOMContentLoaded에 가장 가까운 것은 doScroll입니다. 이것이 doScroll이 DOMContentLoaded를 시뮬레이션하는 데 널리 사용되는 이유입니다. 주의: 이는 단지 시뮬레이션일 뿐이며 세부적으로 동일하지는 않습니다.

다소 예상치 못한 결과를 얻을 수도 있습니다. 본문 끝 앞에 배치된 스크립트는 실행 시 domready 이벤트에 배치하는 것이 가장 좋습니다. Firefox에서든 IE에서든 HTML End로 구문 분석한다고 해서 DOM이 안전하게 작동할 수 있다는 의미는 아닙니다. 특히 페이지가 복잡한 경우에는 더욱 그렇습니다.

위 데이터에서 스타일을 상단에 배치하고 스크립트를 하단에 배치하도록 권장하는 YSlow 성능 최적화 규칙의 기초도 확인할 수 있습니다.

관심 있는 분들은 스타일과 스크립트를 동적으로 추가하는 상황을 추가로 테스트해 볼 수 있지만, 특별히 놀랄 일은 아닙니다.

최종 요약:

페이지 리소스 다운로드 순서는 위에서 아래로 이루어지며, 문서 흐름에서 먼저 나타나는 리소스가 먼저 다운로드됩니다. (참고: 동시성이 있습니다. 자세한 내용은 UA 프로파일러를 참조하세요.) 특정 스타일을 다운로드하면 즉시 페이지에 렌더링됩니다(캐스케이딩 스타일 시트 렌더링에서 캐스케이딩의 의미 반영). 스크립트가 다운로드되면 즉시 구문 분석되어 실행됩니다. 스크립트는 문서 흐름의 순서대로 엄격하게 실행되고 지연된 스크립트는 일반 스크립트 이후에 실행됩니다(Firefox 및 IE에서).

특별한 주의가 필요합니다: 스크립트가 실행 중일 때 스크립트 아래의 모든 리소스 다운로드가 일시 중지됩니다(스크립트가 문서 흐름을 변경하거나 페이지로 이동할 수도 있기 때문에 브라우저의 일시 중지 정책은 합리적입니다). . 종종 후속 다운로드를 차단할 수 있는 인라인 스크립트에 주의하십시오.

알겠습니다. 더 이상 말도 안되는 소리는 하지 마세요. 위의 결과를 직접 테스트해보고, 반복적으로 테스트하고, 멍하고, 혼란스러우며, 갑자기 계속해서 혼란스럽다는 것을 깨달을 때까지 미친 듯이 테스트해보시길 권합니다...