kyle: " @paul_irish 동의하지 않습니다. http://bit.ly/9IfMMN 캐시 가능성(외부 CDN), 병렬 다운로드, 스크립트 변경-휘발성..."

James burke: " @fearphage @getify RequireJS에는 스크립트 번들링/축소를 수행하는 빌드 도구가 있으므로 동적 및 사전 빌드 둘 다의 장점을 모두 가질 수 있습니다."

개발자가 스크립트 로딩을 시작하는 가장 쉬운 방법은 $Lab.js를 사용하는 것입니다. 왜냐하면 이미 많은 jQuery 사용자에게 익숙한 연결 구문을 사용하고 있기 때문입니다.

대규모 엔터프라이즈 앱을 구축하는 경우 필요한 경우 항상 require.js로 마이그레이션할 수 있습니다.

현재 세 가지 주요 스크립트 로딩 기술이 있습니다:

1. HeadJS
2. ControlJS
3. LABjs

사용 여부, 어느 것을 사용할지는 다소 논쟁의 여지가 있습니다. http://blog.getify.com/2010/12/on-script-loaders/

HeadJS ControlJS 및 LabJS에 대한 대안을 알려 주기 위한 requireJS 및 EnhanceJS도 있습니다. 심지어 야후와 구글도 비슷한 것을 제공한다.

jQuery 1.5 및 deferreds( http://www.erichynds.com/jquery/using-deferreds-in-jquery/ ) 의 릴리스와 함께 Boris Moore는 새로운 스크립트 로더 프로젝트인 DeferJS( https://github) 에서 이를 활용하고 있습니다

기본적으로 스크립트 로드는 다른 모든 다운로드를 중지하므로 헤더에서 modernizr을 다운로드하는 것은 좋지 않습니다. 인라인 로더는 로더가 차단 모드가 아닌 병렬로 스크립트를 다운로드할 수 있기 때문에 의미가 있습니다. 예를 들어 모든 modernizr 기능이 필요하지 않은 경우 6kb에 불과한 head.min.js 또는 modernizr의 사용자 정의 빌드(http://modernizr.github.com/Modernizr/2.0-beta/)를 인라인할 수 있습니다. CSS 인라인도 때때로 의미가 있습니다. Google은 인라인을 사용하며 CSS, js 및 datauri를 통해 빈 1x1 gif를 인라인합니다.

LabJS는 꽤 널리 사용되고 있으며 좋은 솔루션입니다. 또한 비동기식으로 포함될 수 있으므로 차단할 필요가 없습니다.

http://blog.getify.com/2010/12/on-script-loaders/ 는 작성자의 것입니다.

http://yepnopejs.com/은 막 1.0이 되었고 LAB 및 head.js와 달리 새로운 웹킷에서 깨지지 않습니다. 스크립트 로딩이 어렵습니다.

yepnope는 Modernizr.load 로 Modernizr에도 통합되었습니다. http://modernizr.github.com/Modernizr/2.0-beta/

따라서 곧 Modernizr.load를 통해 h5bp에 스크립트 로더를 갖게 될 것입니다.

나는 그것이 1.0을 만들 것이라고 생각하지 않지만 일단 Modernizr를 1.8까지 가져 가면 우리는 그것을 h5bp 1.1로 던질 것입니다. 응

안녕 폴

H5BP를 사용하기 위해 기존 사이트를 이식하고 있으며 yepnope.js 스크립트 로더를 사용하고 싶습니다. 당신이 한 것처럼 모든 비트와 봇이 함께 결합되는 것을 보는 것은 정말 좋습니다.

현재 어떤 것을 사용하는 것이 좋습니까?

1. 페이지 상단에 modernizer.js와 함께 yepnope.js를 포함합니다.
2. HTML 로드가 완료된 후 로드하려면 페이지 하단에 포함합니다.
3. Modernizer.js 베타 버전 사용
4. yepnope.js와 modernizer.js를 하나의 include로 연결할 수 있습니다.

그것을 포함하는 최선의 방법에 관계없이 yepnope,js로 스크립트를 로드하는 방법은 무엇입니까?

https://github.com/paulirish/html5-boilerplate/blob/master/index.html#L52 그리고 yepnope를 사용하여 jQuery 및 기타 스크립트의 CDN/로컬 복사본을 로드해야 합니다.

그러나 외부 스크립트를 사용하는 것이 가장 좋다고 생각하십니까? html 내에서 스크립트 블록을 포함하거나 렌더링한 다음 yepnope.js를 통해 스크립트를 로드합니까?

감사합니다.

앤디

아 그리고 또 하나.

yepnope는 css를 통해 로드할 수 있으므로 평소와 같이 기본 CSS를 포함하고 yepnope를 사용하여 특정 수정 사항에 대해서만 CSS를 포함하는 것이 가장 좋습니다.

예를 들어 이전 버전의 IE에만 ​​적용되는 일부 CSS를 포함합니다.

호카포카,

Modernizr의 베타 버전을 사용하십시오.. 필요한 것을 포함하고( Modernizr.load() ) 페이지 상단에 넣으십시오.

yepnope를 사용한 jquery 폴백의 실제 코드는 http://yepnopejs.com/에 있습니다.

그리고 네 저는 IE CSS의 조건부 로드에 대한 귀하의 아이디어를 좋아합니다.

스크립트 로더의 성능에 대한 맹신이 너무 많고 이것이 올바른 방법이라고 말할 준비가 되어 있지 않다고 생각합니다.

스크립트 로딩에 대한 현명한 권장 사항을 나타내는 파일 크기, 대역폭 및 네트워크 조건에 대해 더 많은 연구가 필요하지만 현재 이 분야는 초기 단계이며 스크립트 로딩에 대한 포괄적인 솔루션을 추천하는 것은 순진합니다.

그래서.

이 티켓을 닫고 개발자가 이에 대한 현명한 선택을 더 쉽게 하기 위해 필요한 포괄적인 연구 및 출판을 관심 있는 모든 사람에게 요청합니다.

나는 concat 대 병렬 로드에 대해 꽤 많은 연구를 했습니다. 나는 여전히 예약 없이 모든 js를 하나의 파일로 먼저 결합한 다음 2-3개의 동일한 크기의 청크로 청크하고 병렬로 로드하도록 권장합니다.

나는 내 연구를 가져와 널리 퍼뜨리고 확장하여 이 분야에서 "사실"로 실행 가능하게 만들고 싶습니다. 문제는 실제로 대규모 테스트를 실행하는 데 많은 비용이 들지 않는 호스팅 대역폭을 찾으려고 노력했지만 아직 해당 호스팅 제공을 찾지 못했다는 것입니다.

테스트를 위한 대역폭 문제를 해결할 수 있다면 병렬 로딩 이론이 실제로 실행 가능한지 알아보기 위해 실행할 수 있는 테스트가 있습니다.

@getify 테스트 장비까지 무엇이 필요합니까?

현재 사용 중인 것보다 개인 서버에서 약 1.5TB 더 많은 데이터를 처리할 수 있습니다. Nginx가 설치되어 있으며 마이크로초당 약 4조 조의 히트를 처리할 수 있습니다. 여기서 기술이 장벽이라고 생각하지 않습니다.

위치가 걱정되는 경우 대기 시간이 더 긴 것으로 위장하거나 상자에 약간의 여유 공간이 있는 다른 두 사람을 찾을 수 있습니다.

BTW, 나는 "맹목적인 믿음"에 대해 약간의 문제를 가지고 있습니다.

스크립트 태그가 있는 많은 스크립트를 로드하는 기존 사이트가 있는 경우 병렬 스크립트 로더(다른 변경 사항 없음)를 사용하면 성능이 향상된다는 것은 쉽고 입증 가능하며 거의 의심의 여지가 없는 사실입니다. 최신 브라우저라도 DOM 준비 차단에서 스크립트 로드를 고정 해제할 수 없기 때문에(그리고 그렇게 생각하지도 않습니다.) 이것은 사실입니다. 따라서 최상의 브라우저 로딩에서도 다른 이점이 없다면 사이트에서 DOM 준비 속도를 크게 높이는 것이 거의 항상 승리합니다(사용자와 UX의 경우).

귀하의 진술은 우리가 모든 사이트에 대해 스크립트 연결과 병렬 로드를 비교하려고 한다고 가정하기 때문에 약간 잘못된 전제입니다. 웹상의 대부분의 사이트는 실제로 script-concat을 사용하지 않습니다/사용할 수 없습니다. 따라서 실제로 비교(대부분의 경우)는 당신이 가정하는 것만큼 미묘하고 복잡하지 않습니다. 스크립트 연결을 사용하지 않거나 사용할 수 없는 경우(어떤 이유로든) 비교는 간단합니다. 병렬 로딩은 거의 항상 스크립트 태그보다 유리합니다.

그들이 script-concat에 열려 있다면(또는 이미 그것을 사용하고 있다면), 병렬 로딩이 도움이 될 수 있는지 여부를 결정하는 것이 조금 더 미묘하거나 복잡해집니다. 그러나 script-concat은 만능 솔루션이 아니므로 병렬 로딩이 선호되고 최상의 접근 방식으로 남아 있는 사이트가 많이 있습니다.

일부 사이트가 병렬 로딩과 스크립트 연결 사이를 결정하는 뉘앙스/복잡성을 다룬다고 해서 병렬 로딩 대 스크립트 태그에 대한 더 큰(더 영향력 있는) 논의가 믹스에서 손실되어야 함을 의미하지는 않습니다. 전자는 증명하기 어렵지만 후자는 이 시점에서 거의 주어진다.

이 모든 것은 모든 것을 고려할 때 IMHO 상용구가 긍정적인 방향으로 가장 큰 영향을 미치는 패턴을 장려해야 한다는 것입니다. 오늘날 인터넷에 있는 사이트의 80%가 스크립트 태그를 사용하고 대부분이 스크립트 태그에서 병렬 로딩으로 이동함으로써 이점을 얻는다면 병렬 로딩은 상용구의 시작점으로 제안하기에 매우 건전한 것입니다.

스크립트 연결 대 병렬 로드를 탐색하여 잠재적으로 더 많은 이점을 얻을 수 있는 사이트의 훨씬 작지만 중요한 하위 섹션입니다. 그러나 소수 사용 사례는 상용구에서 최적화되어야 하는 대상이 아닙니다.

내 몇 센트.

@paulirish @slexaxton --

대역폭이 필요한 한, 10,000명(정확한 샘플링이 필요하다고 느꼈음)이 테스트를 한 번 실행하게 하려면(많은 사람들이 여러 번 실행할 것이라고 확신합니다), 대략 200GB의 대역폭이 사용되었습니다. 어떤 사람들에게는 양동이에 한 방울입니다. 나를 위해, 며칠 만에 200GB의 대역폭은 내 서버 호스팅 비용에 압도적입니다. 그래서, 나는 그 이유만으로 테스트 확장을 추구하지 않았습니다.

게다가, 나는 우리가 탐구해야 한다고 생각하는 이 테스트의 12가지 이상의 변형이 있습니다. 따라서 100-200GB의 대역폭을 수십 번 사용하는 것은 비용을 부담하기에는 상당히 비용이 많이 듭니다. 작업을 완료하기에 충분한 대역폭이 있다고 확신하지 않는 한 그 길을 시작하고 싶지 않았습니다.

그것들은 단지 정적 파일이고 테스트에는 많은 동시 사용자가 필요하지 않으므로 CPU 등과 같은 기존 확장 문제에 대한 실질적인 우려가 없습니다. 대역폭만 있으면 됩니다.

테스트에 대한 나머지 논의를 오프라인으로 전환하고 이메일이나 IM을 통해 진행할 수 있습니다. 나는 마침내 테스트를 확장하고 이 문제를 "해결"하고 싶습니다. 그것은 지금 일년의 더 나은 부분을 위해 내 뇌의 뒤쪽에 매달려 있습니다.

내 dreamhost VPS에서 무제한 TB를 수행할 수 있으므로 문제가 되지 않습니다. 지금은 72GB/일을 사용하고 있으며 훨씬 더 많은 작업을 처리할 수 있습니다. :)

나는 paul의 말에 동의하며 스크립트 로더가 언제 어떻게 누군가에게 도움이 될 것인지에 대한 잘못된 정보가 꽤 있다고 생각합니다.

첫 번째 단락은 스크립트 로더가 성능을 향상시키는 것이 '쉽고', '증명 가능하고' '의심할 여지 없이'라고 말합니다.

나는 얼마 전에 @jashkenas 와 비슷한 가정을

https://github.com/SlexAxton/AssetRace

코드가 다 있습니다. 분명히 테스트 대상이 많지는 않았지만 결과는 기껏해야 이 스크립트 로더가 concat 메서드(유사한 크기의 3개 파일 병렬 로드 지침을 따름)와 거의 같은 속도였으며 최악의 경우 스크립트가 로더는 훨씬 더 다양했고 일반적으로 오차 범위 내에서 더 느렸습니다. 하나의 브라우저에서 귀하의 컴퓨터에 있더라도 자유롭게 분기하여 당사 또는 당사 모두를 능가하는 솔루션을 찾으십시오.

h5bp는 사람들이 js를 연결한다고 가정하기 때문에 "거짓 전제"에 관해서는. h5bp는 연결 및 축소가 포함된 스크립트 빌드 도구를 제공하기 때문에 이 인수는 완전히 유효하지 않습니다. 따라서 병렬 로딩이 거의 항상 여러 스크립트 태그보다 낫다는 주장은 사실일 수 있지만 현재 h5bp가 제공하는 것보다 좋지는 않습니다. 이것이 이 토론의 맥락입니다.

최악의 시나리오는 사람들이 yepnope 또는 lab.js와 같은 것을 가져와 스크립트 태그 폴리필로 사용하는 것입니다. 그것은 절대적으로 느린 로딩(19개의 JS 및 34개의 CSS 파일 중)을 초래할 뿐만 아니라 완전히 인식하지 못할 수많은 역방향 및 전방 호환성 문제를 도입합니다.

저는 사람들에게 _boilerplate_에 대해 가장 합리적이고 성능이 좋으며 호환 가능한 기본값을 제공한다는 정신으로 빌드 도구는 이 세 가지를 모두 보장하기 위해 훨씬 더 나아갑니다.

@slexaxton

... 결과는 이 스크립트 로더가 concat 방법과 거의 같은 속도임을 보여주었습니다(비슷한 크기의 3개 파일 병렬 로드 지침을 따랐습니다)...

나는 기꺼이 당신이 함께 만든 테스트를 살펴볼 시간을 가질 것입니다. 나는 당신들이 당신이하는 일을 알고 있다고 확신하므로 당신의 테스트가 유효하고 정확하다고 확신합니다.

OTOH, 나는 많은 모순된 증거를 가지고 있습니다. 병렬 스크립트 로딩이 대부분의 사이트에 낭비이거나 도움이 되지 않는다는 설득력 있는 내용을 본 적이 있다면 LABjs라는 미친 시간 싱크를 이미 오래 전에 포기했을 것입니다.

저는 2년 동안 사람들을 위해 LABjs를 공개하는 데 도움을 주면서 LABjs가 스크립트 태그 대안보다 느린 상황을 발견한 적이 없다고 100% 확신할 수 있습니다. _나에게_ 그런 일이 발생한 적이 한 번도 없습니다. 사람들이 많은 이점을 보지 못했다고 말한 적이 몇 번 있습니다. 사람들이 100개 이상의 파일을 로드하는 경우가 몇 번 있었고 많은 연결의 미친 오버헤드로 인해 다른 방법으로 볼 수 있었던 모든 이점이 사라졌습니다. 하지만 LABjs가 사이트를 느리게 만들었다는 말을 한 번도 들어본 적이 없습니다.

나는 말 그대로 50개 이상의 서로 다른 사이트가 스크립트 태그에서 LABjs로 이동하는 것을 도왔고 사이트는 실패 없이 즉시 성능 향상을 보았습니다. 노력 초기에 내가 도움을 준 7~8개 사이트에서 샘플링을 했고, 로드 속도가 평균적으로 약 15% 향상되었습니다. 제가 관리하는 4~5개 사이트의 경우 당연히 LABjs를 구현했고 로딩 속도가 3배나 빨라졌습니다.

물론 LABjs가 처음 나왔을 때 브라우저가 스크립트를 병렬로 로드하는 것은 최첨단이었습니다(몇몇만이 그렇게 하고 있었습니다). 그래서 그 이익은 거대하고 가시적이었습니다. 이제 거의 모든 브라우저가 병렬 로드를 수행하므로 이점이 더 이상 급격하지 않습니다.

그러나 부인할 수 없는 한 가지는 브라우저가 스크립트 태그 로드를 위해 DOM 준비 이벤트를 모두 차단한다는 것입니다. 그들은 document.write() 를 찾을 가능성 때문에 _해야 합니다_. 병렬 스크립트 로딩은 본질적으로 "브라우저, 나는 당신이 document.write를 다룰 필요가 없을 것이라고 약속합니다. 그러니 페이지를 계속 진행하십시오"라고 말합니다.

이 자료의 슬라이드 10에 있는 두 개의 다이어그램을 살펴보십시오.

http://www.slideshare.net/shadedecho/the-once-and-future-script-loader-v2

파란색 선의 위치를 ​​비교하십시오(DOM 준비됨). 이는 전체 페이지 로드 시간(또는 모든 자산 로드를 완료하는 시간)이 더 나아지지 않더라도 인지된 성능(UX)이 크게 개선되었습니다.

...h5bp는 스크립트 빌드 도구를 제공합니다...

여기서 잘못된 가정은 h5bp가 이 도구를 제공하기 때문에 h5bp의 모든(또는 대부분의) 사용자가 이 도구를 사용할 수 있다는 것입니다. h5bp 사용자의 100%가 그것을 사용한다고 해서 h5bp가 인터넷의 롱테일(long-tail)로 롤아웃된다면 모든 사람들이 그 concat 도구를 사용할 것이라는 의미는 아닙니다. 누군가가 그것을 사용하는 것을 쉽게 막을 수있는 많은 다른 요소가 있습니다. 누군가가 스크립트 태그 사용에서 병렬 스크립트 로더 사용으로 이동할 수 없는 이유는 _매우 적습니다_.

따라서 병렬 스크립트 로딩은 여전히 ​​인터넷의 롱테일에 더 광범위한 매력을 제공합니다. 스크립트 로딩 최적화를 사용하지 않는 대부분의 사이트는 아무것도 없는 상태에서 다른 상태로 이동하는 것이 여전히 더 쉽고 성능을 제공하는 것이 좋습니다. 이러한 롱테일 사이트 중 저렴한 월 6달러, 대량 공유 호스팅, CDN이 아닌 웹 호스팅 환경에서 자동화된 스크립트 빌드 도구에 노력을 들(또는 경험하는 기술이 있는) 사람은 거의 없습니다.

최악의 시나리오는 사람들이 yepnope 또는 lab.js와 같은 것을 가져와 스크립트 태그 폴리필로 사용하는 것입니다. 그 결과 로딩이 느려집니다...

나는 이 말에 더 동의할 수 없었다. LABjs는 스크립트 태그 폴리필로 특별히 설계되었습니다. 그리고 일반 스크립트 태그(당분간 스크립트 연결 무시)에 대한 LABjs의 개선 사항은 잘 확립되어 있으며 심각하게 반박된 적이 없습니다. LABjs를 사용하는 대부분의(또는 많은) 사이트가 스크립트 태그로 돌아가는 것이 더 낫다는 증거가 있다면 공유하십시오.

병렬 스크립트 로딩이 브라우저가 스크립트 태그로 달성할 수 있는 것보다 느린 로딩을 초래할 이유는 전혀 없습니다. 의미가 없습니다. 그리고 위에서 설정한 것처럼 스크립트 태그는 항상 DOM 준비를 차단하지만 병렬 스크립트 로딩은 그렇지 않습니다.

그들은 완전히 인식하지 못할 많은 역방향 및 순방향 호환성 문제를 도입합니다.

어떤 호환성 문제에 대해 이야기하고 있습니까? LABjs의 브라우저 지원 매트릭스에는 전 세계 모든 웹 브라우저의 절대 다수가 포함되어 있습니다. 그것이 침입하는 미친 작은 브라우저는 분명히 이점이 있는 많은 수의 브라우저보다 훨씬 중요합니다.

LABjs 1.x에는 캐시 사전 로드와 같은 미친 해킹이 많이 포함되어 있었는데, 이는 실제로 브라우저 손상에 대한 주요 우려 사항이었습니다. LABjs 2.x는 이를 완전히 뒤집었으며 이제 모든 경우에 병렬 로드에 대해 안정적이고 표준화된 접근 방식을 사용하고 이전 웹킷 브라우저에 대한 해킹만 사용합니다. 또한 LABjs 2.x에는 "실제 사전 로드"와 같은 곧 출시될 스크립트 로드 기술(곧 표준화될 예정)에 대한 기능 테스트가 이미 포함되어 있습니다.

다른 스크립트 로더에 대해 확실히 말할 수는 없습니다. 많은 스크립트 로더가 여전히 해킹을 사용한다는 것을 알고 있습니다. 하지만 LABjs의 경우 이것이 순방향 또는 역방향 호환성 문제를 야기한다는 주장에 당황합니다. 이는 명백히 오해의 소지가 있다고 생각하기 때문입니다. 주장하다.

LABjs가 실제로 스크립트 태그 폴리필이 되도록 의도한 이유에 대해 약간 설명하기 위해...

1. 이전 브라우저는 병렬 로딩이 처리할 수 있는 스크립트 태그 로딩을 처리하는 데 확실히 열등합니다. 2년 전 LABjs가 출시되었을 때 가장 최신의 브라우저였던 "이전 브라우저"에서 페이지 로드 시간이 3배 향상되었습니다. 거의 정의에 따르면 LABjs는 자체적으로 지원하지 않는 브라우저에 기능(즉, 병렬 로딩 성능)을 제공하기 때문에 더 나은 스크립트 태그 폴리필을 만듭니다.
2. 최신 브라우저는 분명히 훨씬 더 좋습니다. 그러나 스크립트 로더의 이점을 완전히 없애지는 못했습니다. 최근에 v12(v13에서 수정된 것 같습니다)의 크롬은 스크립트 태그 로드가 완료되는 동안 여전히 이미지 로드를 차단하고 있었습니다. IE, Firefox 및 Chrome의 최신 버전을 사용하더라도 스크립트가 동적으로 로드되는 동안 모두 여전히 DOM 준비를 차단합니다. 이는 모두 document.write() 가 숨어 있을 수 있다고 여전히 비관적으로 가정해야 하기 때문입니다.

따라서 최신 브라우저의 경우 LABjs는 스크립트 태그가 수행할 수 없는 방식으로 브라우저에 "비 DOM 준비 차단 스크립트 로드"를 가져온다는 의미에서 "폴리필"입니다. 병렬 스크립트 로더가 없는 최신 브라우저에서 접근할 수 있는 유일한 방법은 defer 와 함께 스크립트 태그를 사용하는 것입니다( async 는 순서를 유지하지 않기 때문에 분명히 작동하지 않습니다) . 그러나 defer 에는 여러 가지 단점이 있으며 지원이 실행 가능한 솔루션이 될 만큼 광범위하지 않습니다(비연기에 대한 대체는 나쁜 성능임). 따라서 가장 기본적인 경우에 LABjs는 스크립트 태그 defer (정확하지는 않지만)의 성능 특성에 대한 폴리필이라고 말할 수 있습니다.

솔직히, 나는 여전히 우리가 스크립트 로딩 객체에 대한 표준을 청원해야 한다고 생각합니다. 캐시를 트리거하기 위해 텍스트/자바스크립트가 아닌 다른 유형의 스크립트 태그를 생성해야 하는 경우(또는 더 나쁜 경우에는 개체 태그나 이미지 개체를 사용하거나 인기 있는 브라우저의 새 버전에 필요한 것이면 무엇이든 사용) 아무 것도 없이 많은 어려움을 겪을 수 있습니다. 성능은 너무 많은 변수에 따라 달라집니다. 우리가 여전히 dom 노드 삽입을 사용하여 스타일시트를 로드한다는 것을 이해할 수 있지만(순서 때문일 뿐입니다) 스크립트에 관해서는 더 이상 의미가 없다고 생각합니다(Google이 대부분의 경우 document.write 사용을 중단했으면 합니다. 그들의 대본이지만 그것은 완전히 다른 이야기입니다).

또한 여기에서 스크립트 로더에 관한 가장 큰 요점을 놓치고 있다고 생각합니다. 모든 것을 미리 로드하는 대신 js 코드를 온디맨드로 로드할 수 있다는 것 사소하지 않은 양의 연결된 스크립트로 추악함). UI 상호 작용 후 약간의 대기 시간이 있는 것은 시작 시 브라우저가 조금이라도 "멈추는" 것보다 문제가 훨씬 적습니다(DOM은 잘 준비될 수 있지만 페이지를 향상시키는 코드가 있으면 무슨 소용이 있습니까? 추가 반복 작업이 아직 실행되지 않았습니다. 일부 사이트가 즉시 로드된 다음 투박한 일이 발생하는 방법을 알아차린 적이 있습니까?).

따라서 엄격한 성능 측정은 모두 훌륭하고 멋지지만 여전히 인지된 성능이 궁극적인 목표라고 생각합니다... 그리고 슬프게도 추정/최적화/계산하기가 훨씬 어렵습니다.

이것은 강렬하다.

@jaubourg--

솔직히, 나는 여전히 우리가 스크립트 로딩 객체에 대한 표준을 청원해야 한다고 생각합니다.

표준/사양 및 브라우저가 어떻게 더 나은 스크립트 로딩 기술을 제공할 수 있는지에 대해 많은 청원이 진행 중입니다. 몇 년 만에 이 카테고리의 첫 번째 큰 승리는 2월에 다시 채택되어 현재 모든 주요 최신 릴리스 브라우저에 있는 "ordered async"( async=false )입니다(예외: Opera는 곧 출시될 예정이며 IE10p2에는 이 기능이 있습니다. ).

현재 Ian Hickson과 계속 논의 중인 다음 토론은 제가 "실제 사전 로드"라고 부르는 것입니다. 제 생각에는 "실제 사전 로드"(IE가 v4, btw부터 이미 지원함)는 거의 모든 스크립트 로드 시나리오를 사소하게 해결할 수 있는 "은색 총알"에 가장 가까운 것입니다. 나는 우리가 이와 같은 표준화된 것을 보게 될 것이라고 여전히 매우 낙관적입니다.

자세한 정보는 이 위키를 참조하십시오: http://wiki.whatwg.org/wiki/Script_Execution_Control

캐시를 트리거하기 위해 텍스트/자바스크립트와 다른 유형의 스크립트 태그를 생성해야 하는 경우(또는 더 나쁘게는 개체 태그나 이미지 개체 또는 인기 있는 브라우저의 새 버전이 요구하는 모든 것을 사용)

이것을 "캐시 사전 로딩"이라고 하며, 인정되는 추악하고 끔찍한 해킹입니다. LABjs는 v2부터 이것을 강조하지 않습니다(이전 웹킷의 대체 수단으로만 사용). 다른 스크립트 로더는 불행히도 여전히 이를 기본 로딩 메커니즘으로 사용합니다. 그러나 "캐시 사전 로드"에 대한 필요성의 90%는 표준화되고 해킹이 아닌 "순서된 비동기식"으로 해결할 수 있으므로 올바르게 작동하는 스크립트 로더는 지금 "캐시 사전 로드"보다 이를 선호해야 합니다.

따라서 "캐시 사전 로드"가 형편없다는 점에는 동의하지만 이러한 해킹을 포함하지 않는 document.createElement("script") 를 사용하는 훨씬 더 좋은 방법이 있으므로 이것이 스크립트 로딩. "실제 사전 로딩"을 얻을 수 있다면 Script 요소는 우리가 필요한 모든 것이 될 것입니다. 나는 솔직히 그렇게 믿는다.

여기에서 스크립트 로더와 관련하여 가장 중요한 점을 놓치고 있다고 생각합니다. 요청 시 js 코드를 로드할 수 있다는 것

이것이 스크립트 로더가 가져오는 중요한 이점이라는 데 매우 동의합니다. 그러나 "script concat" 사람들은 스크립트 로딩 없이는 유스 케이스를 해결할 수 없기 때문에 둘을 "비교"하는 것은 의미가 없기 때문에 이것은 _this_ 스레드에서 일종의 무의미한 주장입니다. "스크립트 연결" 지지자로서 "좋아요, 우리는 그 사용 사례에 대해 신경 쓰지 않습니다"라고 말할 수 있지만 "XYZ를 사용하여 해당 사용 사례를 더 잘 제공할 수 있습니다"라고 말할 수는 없습니다.

인지된 성능은 _is_ 거대하고 중요합니다. 저도 동의합니다. 주문형 로딩은 이를 가능하게 하는 중요한 부분입니다. 온디맨드 로딩은 필요한 것만 다운로드하는 경우 실제 다운로드가 감소하는 경향이 있기 때문에 실제 실제 성능(단순한 인식이 아님)도 향상됩니다(작성한 코드의 100%가 필요한 페이지 방문이 거의 없음).

인지된 성능은 내가 위에서 DOM 지원 주장을 옹호하는 이유이기도 합니다. 사용자가 페이지와 상호 작용할 수 있는 것처럼 "느끼는" 속도가 페이지가 얼마나 빨리(실제로 로드되는 속도에 관계없이) 생각하는 _매우_ 중요하기 때문입니다. 그것은 많은 사용자 연구에 의해 확립된 사실입니다.

@getify의 열정적이고 긴 댓글을 사랑해야 합니다.
카일 ...

연구에 어떤 식으로든 기여할 수 있다면 _사랑_하고 싶습니다.
대역폭(비용)이 문제가 아닌 것 같아서 @getify 앞으로 나아가기 위해 무엇을 제안합니까?
주저하지 마시고 이메일(aaron [at] aaronpeters [dot] 또는 트위터(@aaronpeters)

@kyle

예, 사전 로드에 관한 스크립트 태그 "개선 사항" 토론을 따랐으며 실행 가능한 접근 방식으로 "스크립트 태그에 또 다른 속성 추가" 접근 방식을 구입하지 않았습니다. 나는 그것이 xhr 사양에 어떤 영향을 미치는지 보았습니다. 결국 우리가 얻는 작은 이점과 관련하여 많은 복잡성이 발생했습니다.

분명한 것은 동적 삽입을 수행할 때(즉, 자바스크립트에서 이미 수행하고 있는) 사전 로드 동작만 거의 필요하다는 것인데 도대체 왜 우리는 여전히 스크립트 태그 삽입을 사용해야 합니까? 태그를 거기에 두거나 DOM 노드로 사용하는 것과는 다릅니다. 문서 구조와 관련이 없는 목적을 위한 수단일 뿐입니다.

나는 그 라인에 따라 훨씬 더 편안 할 것입니다.

window.loadScript( url, function( scriptObject ) {
    if ( !scriptObject.error ) {
        scriptObject.run();
    }
});

이것은 놀라운 일이 될 것입니다. 여러 스크립트 로딩 이벤트를 "조인"한 다음 필요한 순서대로 해당 스크립트를 실행하는 것은 충분히 쉽습니다. 또한 DOM의 존재를 암시하지 않아 더욱 일반적입니다. 하루빨리 스크립트 태그 삽입에서 완전히 벗어나면 좋겠습니다. 게다가, 우리 모두가 알고 있는 트릭을 사용하여 이것을 폴리필하는 것은 충분히 쉽습니다. 또한 완전한 require 시스템보다 부담이 훨씬 적습니다(그러나 브라우저에 국한되지 않는 require 시스템을 위한 빌딩 브릭이 될 수 있음).

즉, 인지된 성능에 대해 100% 동의합니다. "모두 함께 압축하자"는 주문이 빠르게 내 취향에 맞지 않는 것을 너무 흐리게 하는 일종의 믿음이 되기 때문에 지적하고 싶었습니다. ;)

fwiw, defer 는 IE4+, Chrome, Safari 및 FF 3.5+에서 지원됩니다. Opera에서는 지원되지 않습니다.

즉.... 사용자의 98.5%가 이미 script@defer 지원을 받고 있습니다.

@getify

그러나 defer 에는 여러 가지 단점이 있습니다.

세부 사항 plz? 나는 이것에 대해 아무것도 본 적이 없다

defer가 있는 스크립트는 DOM 준비 이벤트가 발생하기 전이나 후에 실행됩니까?

모든 브라우저에서 실행 순서가 유지됩니까?

exec 순서와 인라인 스크립트와 외부 연결은 어떻습니까?

@paulirish--

...98.5%의 사용자가 이미 script@defer를 지원합니다.

많은 브라우저에서 지원이 있을 수 있지만 그렇다고 해서 많은 브라우저에서 신뢰할 수 있는 것은 아닙니다. 그게 내가 의미한거야. (아래 참조)

그러나 연기에는 여러 가지 단점이 있습니다.

세부 사항 plz? 나는 이것에 대해 아무것도 본 적이 없다

참조하세요... IIRC:

1. 동적 스크립트 요소에 대한 지연 지원은 어떤 브라우저에서도 정의되거나 지원되지 않습니다... 마크업의 스크립트 태그에서만 작동합니다. 이것은 "온디맨드" 또는 "지연 로딩" 기술 및 사용 사례에 대해 완전히 쓸모가 없다는 것을 의미합니다.
2. 일부 브라우저에서는 DOM 준비가 실행되기 직전에 지연된 스크립트가 실행되기 시작하고 다른 브라우저에서는 DOM 준비가 실행된 직후에 발생하는 경우가 있다고 생각합니다. 그것에 대한 자세한 내용은 더 파고들 필요가 있습니다.
3. 외부 리소스를 참조하는 스크립트 태그에 사용된 defer 가) 인라인 코드가 포함된 스크립트 태그에 지정된 defer 와 다르게 작동했습니다. 즉, 두 가지 유형의 스크립트를 모두 연기하고 올바른 순서로 실행되도록 보장할 수 없습니다.
4. defer document.write() 문으로 작성된 스크립트 태그의 defer 있는 마크업의 스크립트 태그와 다릅니다.

이 문제에 대한 내 손끝에 준비된 많은 세부 정보가 없습니다. 나는 약 2년 전(LABjs 이전)에 defer 를 사용하려고 시도했고 브라우저 간 테스트에서 충분히 마주쳤기 때문에 기본적으로 제쳐두고 실제로 다시 방문하지 않았습니다.

또한 defer 는 LABjs(및 기타 병렬 로더)가 제공하는 것과 실제로 동일하지 않다는 점을 지적해야 합니다. 나는 그것이 단지 그것과 비슷하다는 경고와 함께 위에서 말했다. 사실, 병렬 스크립트 로딩이 제공하는 것(적어도 LABjs의 부분에서는)은 "정렬된 비동기식"이며, 이는 마크업을 통해서만 달성할 수 있는 방법이 전혀 없습니다.

"ordered async"와 "defer"의 차이점은 "ordered async"는 첫 번째 요청된 스크립트 로드가 완료되는 즉시 실행을 시작하는 반면, "defer"는 실행을 시작하기 전에 `DOM 준비가 될 때까지 대기합니다. 마크업이 거의 없고 다른 차단 마크업 호출(예: 다른 스크립트 태그)이 없는 간단한 페이지의 경우 이 차이는 작습니다. 그러나 리소스가 많은 페이지의 경우 스크립트 실행이 허용되는 시점은 크게 다를 수 있습니다.

그래서 솔직히 defer 의 접선에서 너무 많이 벗어나지 않았으면 합니다. 왜냐하면 실제로는 병렬 스크립트 로딩이 제공하는 것과 크게 비교되지 않기 때문입니다. 내가 얻고 있는 실행 순서 동작을 설명하는 데 사용할 수 있는 것은 마크업 전용에서 가장 가까운 예일 뿐입니다. defer 올리지 말았어야 했는데 토론이 흐려졌을 뿐입니다.

위에서부터 다시 말하겠습니다. "최신 브라우저의 경우 LABjs는 '순서화된 비동기' 동작에 대한 일종의 '폴리필'이며, 이는 모든 브라우저에서 마크업 전용을 선택할 수 없습니다."

나는 "ordered async"를 좋아하는데, 좋은 표현입니다.

Kyle > afaik, defer가 있는 스크립트는 domready 전에도 _before_ onload를 실행합니다.
async 속성이 있는 스크립트는 최대한 빨리 실행하고 _always_ _before_ onload하지만 반드시 domready 이전에 실행해야 하는 것은 아닙니다.

@aaronpeters--
나는 당신이 약간 궤도에서 벗어날 수 있다고 생각합니다. 내가 이해하는 방법은 다음과 같습니다.

async 스크립트(마크업에서 또는 동적으로 생성됨)는 DOM 준비 이전 또는 이후를 의미하는 ASAP를 실행합니다. 즉, async 스크립트는 아무 것도 기다리지 않아야 합니다(JS 엔진 가용성 자체 제외). 그러나 window.onload 전에 요청되면 거의 모든 브라우저에서 로드 및 실행될 때까지 window.onload 이벤트를 "유지"합니다. async 스크립트가 window.onload 유지하지 않고 정확한 세부 사항을 기억하지 못하는 문서화된 사례가 있다고 생각합니다.

반면에 defer 는 구체적으로 다음을 의미합니다. DOM이 준비될 때까지 기다리십시오. 게다가, defer 설정된 모든 스크립트의 "대기열"이 있어 대기열이 DOM 준비가 될 때까지 처리되지 않습니다. 즉, DOM 준비 이후(또는 오히려 DOM이 준비되고 구문 분석이 완료되었습니다. 그러나 더 지연될 수 있습니다(로딩이 느리게 진행되는 경우). 그들은 window.onload 유지해야 합니다. IE의 일부 버전에서 이 이론의 실제 실행이 약간 모호했다는 막연한 과거의 기억이 떠오릅니다.

@getify

이 스레드를 더 이상 탈선시키고 싶지 않았기 때문에 스크립트 사전 로드에 대한 내 생각과 WHATWG 페이지에 귀하의 제안을 게시했습니다. http://jaubourg.net/ driving-a-nail-with-a-screwdriver-the-way

async 스크립트(마크업에서 또는 동적으로 생성됨)는 DOM 준비 이전 또는 이후를 의미하는 ASAP를 실행합니다. 즉, async 스크립트는 아무 것도 기다리지 않아야 합니다(JS 엔진 가용성 자체 제외). 그러나 window.onload 전에 요청되면 거의 모든 브라우저에서 로드 및 실행될 때까지 window.onload 이벤트를 "유지"합니다.

JavaScript가 단일 스레드라는 것을 알게 되면 이해가 더 쉬울 것입니다. (시간이 좀 걸렸다는 걸 알지만...)

마찬가지로 setTimeout(fn, 0) 를 사용하여 리소스를 다운로드하고 onload 가 실행되기 전에 다운로드 대기열에 들어가면 이러한 리소스를 로드하면 (여전히) onload 지연됩니다.

async 스크립트가 window.onload 유지하지 못한 문서화된 사례가 있었던 것 같습니다. 다만 정확한 세부 사항을 기억하지 못할 뿐입니다.

이에 대해 더 많은 정보를 얻고 싶습니다. 기억해주세요! :)

야 스크립트 로더!

AOL의 사이트 네트워크를 통해 구현한 문제는 경쟁 조건을 처리하는 것입니다. 예를 들어 헤드에서 jQuery를 비동기식으로 로드한 다음 블로그 게시물 내부에서 비동기식으로 전달되는 문서의 중간에 jQuery 플러그인을 말합니다.

따라서 이를 처리하기 위해 나만의 스크립트 로더 과학 프로젝트(Boot.getJS)를 시작했습니다. 아이디어는 모든 스크립트를 병렬로 다운로드하고 가능한 한 빨리 순서에 관계없이 실행하는 것입니다. 또한 준비 또는 로드 지연 및 스크립트 캐싱을 지원합니다. 이 스레드의 사람들이 대부분의 아이디어를 빌렸습니다(도난). 감사합니다. :)

벤치마크에 대해 논의하고 있었기 때문에 다양한 스크립트 로더의 성능, 구문 및 동작의 차이점을 이해하기 위해 만든 테스트 페이지를 공유하려고 합니다. 여기에서 확인하세요.

http://artzstudio.com/files/Boot/test/benchmarks/script.html

다양한 로더가 어떻게 작동하는지 보려면 캐시를 지우고 네트워크 요청과 마지막 시간 및 스크립트가 실행되는 순서를 확인하십시오.

Dave(@artzstudio), 생각과 테스트 페이지 링크를 공유해 주셔서 감사합니다.

질문: '<script> tag in head' 페이지에 LABjs를 로드하는 이유는 무엇입니까? 잘못된 것 같습니다.

@artzstudio 도 이전 버전의 LABjs를 사용하고 있습니다. 의도적인가요? 그렇다면 왜?

@aaronpeters AOL에는 헤드에 들어가야 하는 Omniture Ad 코드(및 그 이상)와 같은 스크립트가 있으므로 사용 사례에서 로더 라이브러리가 있는 곳으로 이동합니다. 또한 스크립트가 맨 아래에 있을 때 일부 위젯에 FOUC 문제가 있으므로 종속 항목(예: jQuery)이 빨리 로드될수록 좋습니다.

고의가 아니었습니다. 이 테스트는 몇 달 전입니다. 기회가 되면 라이브러리를 업데이트하겠습니다.

참고로(이 내용이 다소 흥미롭거나 관련이 있기를 바랍니다.) Webpagetest.org에서 몇 가지 테스트를 실행하여 @artzstudio 테스트 페이지 중 일부를 로드할 때 IE8에서 어떤 일이 발생하는지 확인했습니다.
스크립트 태그: http://www.webpagetest.org/result/110810_C7_752b756180e132f50a3ef065e9e059ca/
예프노프: http://www.webpagetest.org/result/110810_8S_a53f4ed2e16179c328fc57c572e71076/
LABjs: http://www.webpagetest.org/result/110810_ZV_1ece92044799e52ed5199aed6b407133/
RequireJS: http://www.webpagetest.org/result/110810_Z3_a1537e41a0b0570286151859973d0cfa/

Yepnope와 LABjs 비교 동영상: http://www.webpagetest.org/video/view.php?id=110810_074cb94c1b04a7ac9bd6538ec3fdd8d3c07f842d

몇 가지 참고 사항:

• 서버에서 Gzip이 꺼져 있으므로 RequireJS의 더 큰 파일 크기가 영향을 미치는 방식
• 이전에 언급했듯이 스크립트 태그 페이지는 HEAD에 LABjs를 로드하며(이치에 맞지 않음) 물론 영향을 미칩니다.

이 두 가지 이유로 저는 Yepnope와 LABjs만 보여주는 비디오를 만들었습니다.

내가 흥미로운 점은 Start Render 시간이 LABjs에 훨씬 더 좋다는 것입니다. 왜 그런 겁니까? 더 잘 이해하고 싶습니다.

끝맺는 말: 나는 Yepnope나 그와 비슷한 것보다 LABjs를 선호할 목적으로 이 글을 게시하지 않습니다. 그냥 데이터 공유...

아 죄송합니다. <script> 테스트에서 LABjs에 대해 말씀하신 내용을 확인했습니다. LABjs로의 업그레이드와 함께 지금 수정되었습니다.

@artzstudio--

따라서 이를 처리하기 위해 나만의 스크립트 로더 과학 프로젝트(Boot.getJS)를 시작했습니다. 아이디어는 모든 스크립트를 병렬로 다운로드하고 가능한 한 빨리 순서에 관계없이 실행하는 것입니다.

그래서, 이것이 LABjs가 _정확히_ 무엇을 위해 설계되었고 매우 잘 작동한다는 사실을 알고 계셨습니까? (내가 그렇게 말한다면)? 내 말은, 다른 API를 원했습니까, 아니면 병렬 스크립트 로딩 기능이 충분하지 않았습니까?

어쨌든 LABjs에 대해 자랑하고 싶은 만큼 이 스레드를 "봐라, 내 스크립트 로더가 X에서 더 낫다"는 형식의 토론으로 수렁에 빠지는 것은 효과적이지 않다고 생각합니다. 이러한 토론은 유용하지만 다른 곳에 있습니다.

결국 모든 스크립트 로더 기술은 몇 가지 간단한 아이디어로 요약됩니다. 어떤 종류의 멋진 API를 그 위에 레이어링하든, 또는 어떤 사용 사례를 충족하든 기술은 동일합니다. 요즘에는 50개의 다른 스크립트 로더가 있어야 하며 실제로 그들 중 어느 것도 기술 측면에서 다른 것을 제공하지 않으며 단지 다른 API를 제공합니다. 따라서 API를 비교하는 것은 실제로는 다소 관련이 없는 토론입니다.

우리가 집중해야 할 것은 현재 브라우저에서 사용할 수 있는 기본 스크립트 로딩 기술을 사용하여 마크업에서 스크립트 태그를 사용하는 것과 비교하여 페이지 로드 성능을 향상시킬 수 있습니까? 이것은 그것이 절대적으로 사실이라는 나의 오랜 전제이지만, 그 전제는 이 스레드에서 의문을 제기했습니다. 따라서 작업 #1은 그 질문에 답하는 것입니다.

스크립트 태그가 단순히 스크립트 로딩보다 낫다는 것을 알게 된다면, 우리는 이 모든 미친 짓을 멈추고 모든 프로젝트를 종료할 수 있습니다. 나는 그렇지 않을 것이라고 생각합니다. ;-)

작업 #2는 스크립트 연결이 항상 병렬 로드보다 나은지 확인하는 것입니다. 다시 말하지만, 내 전제(및 내 테스트)에 따르면 모든 파일을 하나로 연결하는 것이 좋지만 큰 파일을 2-3개의 대략 동일한 조각으로 청크하고 해당 청크를 병렬로 로드해야 합니다. 따라서 우리는 그 이론도 테스트해야 합니다.

script-concat이 항상 최고라는 것을 알게 된다면 대부분의 사이트가 둘 이상의 위치에서 스크립트를 로드한다는 점을 고려할 때 스크립트 로더가 여전히 유용합니다(Google CDN의 jquery, google의 google analytics, facebook/twitter/g+ 버튼 , 등). 따라서 우리는 작업 #3으로 concat이 훨씬 더 나은지 결정하여 모든 파일의 자체 복사본을 호스팅하고 자신의 코드와 함께 연결해야 합니다.

Kyle, 제 예제의 소스를 보고 어떻게 LabJS를 계측하여 페이지의 모든 스크립트를 순서대로(체인 외부에서도) 실행하는지 알려주실 수 있습니까? API를 잘못 읽었을 수도 있습니다(Paul이 말했듯이 스크립트 로더는 어렵습니다, %-).

2011년 8월 10일 오전 9시 9분에 [email protected]이 다음과 같이 썼습니다.

@artzstudio--

따라서 이를 처리하기 위해 나만의 스크립트 로더 과학 프로젝트(Boot.getJS)를 시작했습니다. 아이디어는 모든 스크립트를 병렬로 다운로드하고 가능한 한 빨리 순서에 관계없이 실행하는 것입니다.

그래서, 이것이 LABjs가 _정확히_ 무엇을 위해 설계되었고 매우 잘 작동한다는 사실을 알고 계셨습니까? (내가 그렇게 말한다면)? 내 말은, 다른 API를 원했습니까, 아니면 병렬 스크립트 로딩 기능이 충분하지 않았습니까?

---

어쨌든 LABjs에 대해 자랑하고 싶은 만큼 이 스레드를 "봐라, 내 스크립트 로더가 X에서 더 낫다"는 형식의 토론으로 수렁에 빠지는 것은 효과적이지 않다고 생각합니다. 이러한 토론은 유용하지만 다른 곳에 있습니다.

결국 모든 스크립트 로더 기술은 몇 가지 간단한 아이디어로 요약됩니다. 어떤 종류의 멋진 API를 그 위에 레이어링하든, 또는 어떤 사용 사례를 충족하든 기술은 동일합니다. 요즘에는 50개의 다른 스크립트 로더가 있어야 하며 실제로 그들 중 어느 것도 기술 측면에서 다른 것을 제공하지 않으며 단지 다른 API를 제공합니다. 따라서 API를 비교하는 것은 실제로는 다소 관련이 없는 토론입니다.

우리가 집중해야 할 것은 현재 브라우저에서 사용할 수 있는 기본 스크립트 로딩 기술을 사용하여 마크업에서 스크립트 태그를 사용하는 것과 비교하여 페이지 로드 성능을 향상시킬 수 있습니까? 이것은 그것이 절대적으로 사실이라는 나의 오랜 전제이지만, 그 전제는 이 스레드에서 의문을 제기했습니다. 따라서 작업 #1은 그 질문에 답하는 것입니다.

스크립트 태그가 단순히 스크립트 로딩보다 낫다는 것을 알게 된다면, 우리는 이 모든 미친 짓을 멈추고 모든 프로젝트를 종료할 수 있습니다. 나는 그렇지 않을 것이라고 생각합니다. ;-)

작업 #2는 스크립트 연결이 항상 병렬 로드보다 나은지 확인하는 것입니다. 다시 말하지만, 내 전제(및 내 테스트)에 따르면 모든 파일을 하나로 연결하는 것이 좋지만 큰 파일을 2-3개의 대략 동일한 조각으로 청크하고 해당 청크를 병렬로 로드해야 합니다. 따라서 우리는 그 이론도 테스트해야 합니다.

script-concat이 항상 최고라는 것을 알게 된다면 대부분의 사이트가 둘 이상의 위치에서 스크립트를 로드한다는 점을 고려할 때 스크립트 로더가 여전히 유용합니다(Google CDN의 jquery, google의 google analytics, facebook/twitter/g+ 버튼 , 등). 따라서 우리는 작업 #3으로 concat이 훨씬 더 나은지 결정하여 모든 파일의 자체 복사본을 호스팅하고 자신의 코드와 함께 연결해야 합니다.

이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/paulirish/html5-boilerplate/issues/28#issuecomment -1772315

물리학에서는 concat이 최고라고 생각할 것입니다. 모든 새로운 HTTP 연결은 CDN의 더 나쁜 시나리오에서 또 다른 느린 시작 + 100ms 세금입니다.

그러나 문서의 진실은 문서가 매우 길 수 있다는 것입니다. 따라서 헤드에 하나의 BFJS 파일을 로드하면 모듈 초기화가 불필요하게 느려질 수 있습니다. 마지막에 로드하면 성가신 FOUC가 발생할 수 있습니다. 대용량 파일에 모바일 영향이 있을 수 있습니다. http://www.yuiblog.com/blog/2010/06/28/mobile-browser-cache-limits/

이것이 Souders의 "페이로드 분할" 규칙(http://oreilly.com/server-administration/excerpts/9780596522315/splitting-the-initial-payload.html) 뒤에 있는 동기라고 생각합니다. 우리는 감지할 수 있는 속도도 더 빨라야 합니다.

그리고 불행하게도 이것이 요약되는 것은 "그것에 달려있다"는 대답으로, 우리 모두를 즐겁게 하기에 충분히 이 문제를 흥미롭게 만듭니다.

getJS 호출이 큐에 대기되고 정해진 시간 간격으로 주기적으로 연결되는 하이브리드 접근 방식을 가지고 놀고 있습니다. 또한 모듈 종속성 수준에서 연결합니다(예: 한 번에 하나씩 로드하는 대신 RequireJS 종속성 연결). 모든 것이 프론트 엔드에서 즉석에서 진행됩니다.

그것은 당신이 지적한 것처럼 곧 무의미해질 것이지만 그럼에도 불구하고 흥미로운 과학 실험입니다.

@getify : 이 시점에서 퍼레이드에 대해 거의 오줌을 그렇습니다 .

스크립트 태그가 단순히 스크립트 로딩보다 낫다는 것을 알게 된다면,
그러면 우리는 이 모든 광기를 멈추고 모든 프로젝트를 종료할 수 있습니다.
나는 그렇지 않을 것이라고 생각합니다. ;-)

나는 뱀 기름에 대해 많은 것을 말할 수 있지만 데모도 잘 작동합니다.

http://jashkenas.s3.amazonaws.com/misc/snake-oil/labjs.html

http://jashkenas.s3.amazonaws.com/misc/snake-oil/vanilla.html

100k의 텍스트, 10개의 이미지, 171k의 JavaScript가 있는 페이지입니다. 바닐라 버전은 jQuery, jQuery-UI, Underscore, Backbone이 포함된 단일 축소 파일과 로드 시간 결과를 작성하는 timer.js 파일을 사용합니다. LABjs 버전은 LABjs를 사용하여 5개의 개별적으로 축소된 JavaScript 파일을 각각 로드합니다.

LAB 버전에는 이점이 없을 뿐만 아니라 추가 HTTP 요청이 로드 성능을 저하시키고 이미지와 같은 페이지의 다른 자산과 경쟁해야 한다는 것을 알게 될 것입니다. 그러나 이 모든 것은 이전에 여러 번 언급되었습니다...

나는 당신의 스크립트를 조금씩 로딩하는 것에 대한 반론을 예상할 수 있습니다 ... 그러나 그것은 스크립트 로딩 기술과 완전히 직교하므로 논의에서 제외하십시오.

부디, 광기를 멈추십시오.

@jashkenas 전체, 100% 승인. 스크립트 로더는 오버헤드, 복잡성 및 실패 지점을 추가할 뿐입니다. 단일 서버 연결 파일은 순수한 전송 시간과 JavaScript 인터프리터의 효율성 면에서 모두 빠르게 로드되며, 보너스로 파일이 하나뿐인 경우 gzipping이 더 잘 작동합니다.

LABjs 버전은 _때때로_ 내 브라우저에서 더 빠르게 로드되지만(바닐라 페이지와 비교하여) 일관되지는 않습니다. 또한 onload 가 항상 실행되는 것은 아니므로... 이상하게 보입니다.

예, gzipping은 더 적은 HTTP 요청으로 더 많은 전체 승리를 제공합니다.

그리고 이것은 독단에 관한 것이 아니며 전체 앱에 대해 _단일_ JS 파일일 필요는 없습니다. defer 가 포함된 두 개 또는 세 개는 나중에 로드할 때와 같이 세분화된 캐싱에 적합합니다.

Google Page Speed ​​팀의 일부 연구:

http://pagespeed-velocity2011.appspot.com/#8 슬라이드 8-14 참조

나는 여전히 스크립트 @defer 속성에 열광하며 자신의 변형에 대한 성능 테스트에 많은 시간/일을 할애할 계획이 없다면 이것이 현명한 기본 기본값이라고 생각합니다.

@miketaylr : 예, 전체 느낌을 얻으려면 각 페이지를 여러 번 shift-refresh하십시오. S3 대기 시간과 이미지 로드는 실제 앱처럼 작동하여 상황을 약간 예측할 수 없게 만듭니다.

음 labjs _always_는 shift-refresh를 사용하거나 요소가 캐시된 경우에도 내 브라우저(Safari 5.1)에서 가장 빠르게 로드됩니다.

물론 연결하지 않고 스크립트 로더를 사용하는 것은 연결된 스크립트 태그보다 느릴 것입니다. 그렇기 때문에 사람들(YUI, requireJS)은 연결된 파일을 로드하는 스크립트 로더와 요청 시 연결하는 서비스를 만들었습니다(https://github.com/rgrove/combohandler).

이 토론은 의미가 없습니다. 스크립트 로더는 특히 사용자 상호 작용 후 요청 시 스크립트를 로드하기 위한 것입니다. 예를 들어 "로그인" 버튼을 클릭할 때 대화 상자 및 양식 유효성 검사 뒤의 논리를 로드합니다.

@jashkenas 와 @madrobby 가 일을 지나치게 단순화하고 있다는 교활한 의심이 있습니다.
Steve 는 병렬 다운로드가 다양한 차단 문제와 브라우저에 대해 몇 가지 이점이

내 원래 게시물에 명확하지 않은 경우. 나는 (jdalton과 함께) 고도로 테스트되고 특별한 주의가 필요한 특정 환경에서 스크립트 로더의 이점이 꽤 있다는 데 동의하는 경향이 있습니다. 적절한 기본값이 아니라고 생각합니다.

@jdalton에 동의합니다. 크기에 맞는 로더가 없습니다. 저는 개인적으로 실제 필요와 프로젝트에 따라 다른 스크립트 로더를 사용합니다. 때로는 yepnope 또는 LabJS와 같은 간단한 것이 괜찮고 다른 경우에는 RequireJS가 신의 선물입니다. 보일러플레이트가 강제로 들어가야 하는지 잘 모르겠습니다. 보일러플레이트가 스크립트 로더로 쉽게 전환할 수 있도록 하는 아이디어이기 때문에 까다롭습니다... 그래서 목욕물과 함께 아기를 그냥 버리지는 않을 것입니다. 그래도.

또한 @getify 모든 스크립트 로더가 실제로 동일한 기술을 사용하는 척하는 것은 정보가 없는 진술입니다.

가치 있는 일을 위해...
이것

var script = document.createElement('script')
script.src = 'foo.js'
document.getElementsByTagName('head')[0].appendChild(script)

이것보다 낫다

<script src="foo.js"></script>

차단되지 않는 주된 이유 중 하나입니다. 따라서 후속 이미지 및 CSS 파일은 해당 파일이 최신 버전으로 다운로드될 때까지 기다려야 합니다. 전자는 비동기식 — 이것은 스크립트 로더를 사용하기로 결정했는지 여부에 관계없이 모든 사람이 알아야 합니다.

re: "모든 스크립트 로더가 실제로 동일한 기술을 사용하는 척하는 것은 정보가 없는 진술입니다."

위의 방법으로 하지 않으면 잘못하고 있는 것입니다.

완벽하게 공정하기 위해 appendChild 를 사용하는 것은 바람직하지 않습니다... :D

그러나 나는 그 테스트 케이스를 AssetRace에 추가했습니다.

https://github.com/SlexAxton/AssetRace/blob/master/asyncconcat.html

그것은 onload 발사를 더 빠르게 하므로 약간의 인지된 이점이 _가능_합니다. 하지만 종료 시간은 거의 동일합니다 ...

@ded : 여기서 <head> 무능한 대규모 차단 <script> 에 대해 이야기하는 것이 아닙니다 ... 우리는 defer 또는 async 가 있는 스크립트 태그에 대해 이야기하고 있습니다. <body> 끝에 로드되며 차단할 항목이 없습니다.

@jaubourg--

또한 @getify 모든 스크립트 로더가 실제로 동일한 기술을 사용하는 척하는 것은 정보가 없는 진술입니다.

이것은 내가 얻고자 하는 것에 대한 완전한 잘못된 표현입니다. 사실, 대부분의 스크립트 로더는 최고의 기술을 사용하는 측면에서 내가 해야 한다고 생각하는(그리고 LABjs가 현재 하고 있는) 일을 하지 않습니다. 제 요점은 그들 모두가 최고의 기술을 사용하더라도 기술적으로 우리가 할 수 있는 일에는 여전히 유한한 한계가 있다는 것입니다. 나는 LABjs가 인식하지 못하거나 사용하지 않는 마법의 은색 총알을 사용하는 로더가 없다고 확신합니다. 당신이 무엇을 하든, 어떻게 숫자를 만지작거리든, 빛을 빛의 속도보다 빠르게 갈 수는 없습니다.

아래에 있는 기술에 대해 논쟁하는 것("이봐, 내 멋지고 더 나은 API를 봐"라고 말하는 방식으로)은 무의미합니다. 스크립트 로딩의 최고의 기술은 알려진 유한 수량입니다(많은 로더가 무책임하고 사용하지 않더라도). 우리는 더 나은 기술을 추진할 수 있지만(저도 마찬가지입니다), 누가 로더에 더 나은 API를 가지고 있는지 토론하는 것은 그 목표를 위해 아무 소용이 없습니다.

이 스레드는 스크립트 태그가 자체적으로 충분히 좋은지(지연 여부에 관계없이) 또는 스크립트 로더가 더 나은 성능을 얻는 데 도움이 되는지 여부를 결정하는 데 가장 중요한 역할을 하는 것 같습니다. 두 번째로, 우리는 concat이 실제로 스크립트 로딩의 만능인지 알아내야 합니다.

(이 스레드의 경우) 스크립트 로더가 할 수 있는 다른 모든 사용 사례를 가지고 있다는 것 또한 논쟁의 여지가 있습니다. (온디맨드/지연 로딩과 같은) 마크업 스크립트 태그는 할 수 없습니다. 다시 말하지만, 그것은 기본적으로 이 시점에서 주어진 것이므로 그 사실을 다시 확립하려는 시도는 무의미합니다.

NO U

로드 레이지!

여기에서 원본 게시물을 봅니다.

또한, 만화 페니스에 기분이 상한 모든 사람/사람: 인터넷에 오신 것을 환영합니다! 여기에서 여행 을

좋습니다. 몇 가지 요점을 설명하기 위해 3개의 테스트를 만들었습니다. 먼저 수동 스크립트 태그(기준선으로):

http://labjs.com/dev/test_suite/test-script-tags.php

DOMContentLoaded(일명 "DOM 준비")는 스크립트가 완료된 후 늦게 나타납니다. 이것은 나쁜 것입니다. 페이지의 실제 로드 시간은 이후 테스트와 같을 수 있지만 DOM 준비가 차단되면 페이지의 인식 로드 시간은 항상 훨씬 더 느려집니다(많은 사이트에서 클릭 동작을 첨부하기 위해 DOM 준비가 될 때까지 기다립니다. 콘텐츠에 JS 기반 개선 사항 적용 등).

이제 스크립트 태그에 defer 를 사용합니다.

http://labjs.com/dev/test_suite/test-script-defer-tags.php

좋습니다. DOMContentLoaded 지연 문제를 수정했지만 이제 다른 문제가 있습니다. 인라인 스크립트 블록은 defer 작동하지 않습니다. 즉시 실행됩니다. 죄송합니다. BTW, 이것은 버그가 아니며 사양에 구체적으로 명시되어 있습니다.

http://labjs.com/dev/test_suite/test-LABjs.php

LABjs 테스트는 기본적으로 defer 테스트와 비교하여 동일한(또는 더 나은) 성능 수치를 얻지만 스크립트가 완료된 후 인라인 코드를 실행하는 데 실패하지 않습니다.

최신 브라우저(Chrome 13, FF5 등)에서 이러한 테스트를 여러 번 시도하십시오. 저에게 LABjs는 항상 defer 테스트와 거의 같거나 더 나은 성능을 보였습니다. 내 모든 시도에서 LABjs가 defer 테스트보다 성능이 떨어지는 것을 본 적이 없습니다. 이전 브라우저(예: FF3.5 또는 IE7)에서 해당 테스트를 시도하면 스크립트 로더가 다른 테스트보다 눈에 띄게 성능이 향상되기 시작하는 것을 볼 수 있습니다.

LABjs 테스트는 최신 브라우저의 defer 테스트와 유사한 숫자를 가지고 있지만 defer 를 defer ALL 코드에 사용할 수 없으면 거래 차단기입니다. 외부 파일을 통해 로드된 코드의 경우). 많은 사이트가 스크립트를 로드한 다음 방금 로드한 코드를 활성화/초기화하는 인라인 코드를 가지고 있습니다. defer 는 이에 대한 솔루션을 제공하지 않습니다.

따라서 defer 는 "일반 스크립트 로딩" 기술로 적합하지 않습니다. 차선책은 스크립트 로더입니다.

@getify

마이크로 최적화가 전부는 아닙니다... 예, API는 중요하며 일반적으로 기본 기술이 가지고 있는 제한의 종류를 잘 나타냅니다. 주로 마이크로(또는 매크로) 최적화 때문입니다. 항상 스크립트를 로드하는 것만 이 전부는 아닙니다. 복잡한 종속성 관리, 적절한 샌드박싱 및 실제적이고 실제적인 모듈성은 관심이 없다고 해서 씻어낼 수 있는 것이 아닙니다. 뭔지 맞춰봐? 이것은 실제로 사람들이 필요로 하는 것이며 페이지 로드 성능은 정적 스크립트 태그를 사용하여 상당히 좋은 수준에서 달성할 수 있습니다.

결국 스크립트 태그 삽입이 작업에 적합한 도구가 아니라는 결론이 나옵니다. 실제로는 그렇지 않았습니다. 아주 못생긴 해킹입니다. 그런 의미에서 당신은 실제로 더 나은 기술을 요구하는 아닙니다 . 우리 중 누구도 아직 추론할 수 없는 새로운 종류의 경고 와 함께

정말 화나는 것은 스크립트 로딩을 위한 적절한 네이티브 자바스크립트 API가 아닌 스크립트 태그 삽입을 위해 단일 인수를 배치하는 것을 거부한다는 것입니다. 당신은 모든 것을 무시합니다. 하지만 문제를 해결해 드리겠습니다. 거기 에는 논쟁의 여지가

마침내 내가 지적인 대답을 할 만큼 충분히 가치가 있다고 판단되면(또 다른 LabJS 광고와 대조적으로) 내 블로그에서 그렇게 하고 이 스레드는 그대로 두도록 합시다. 감사합니다.

@jaubourg --
지난 밤에 귀하의 게시물을 자세히 읽었습니다. 나는 당신이 거기에서 제시한 좋은 생각에 대해 대체로 당신을 칭찬하고 칭찬하는 응답으로 블로그 게시물을 작성할 계획이었습니다. 불행히도, 당신이 제안하는 것은 이미 W3C 및 WHATWG에 대한 토론 스레드의 구성원에 의해 AT LENGTH로 해시되었습니다. 당신은 그 파티에 꽤 늦었어요.

완전히 새로운 로더 API를 지원하는 사람들이 몇 명 있었고 왜 그것이 최선의 방법이 아닐 수 있는지에 대한 몇 가지 중요한 반론이 있었습니다. 다시 말하지만, 나는 그 모든 것을 설명하는 데 도움이 되도록 신중하고 합리적인 블로그 게시물에 답변을 작성할 계획이었습니다.

유감스럽게도 당신은 여기에 가서 그런 놈이 되어야 합니다. 이제 그 합리적인 블로그 게시물이 시간 낭비가 될 것 같은 느낌이 듭니다. 당신은 분명히 내가 바보라고 생각하고 당신이 제기하려는 것들을 고려한 적이 없습니다. 스크립트 로더 기술과 이를 개선하기 위해 사양 및 브라우저를 얻는 방법에 대해 절대적으로 집착하는 작년의 더 좋은 부분을 보내지 않았기 때문입니다. 그래, 난 바보야 나는 분명히 이전에 스크립트 태그 이외의 다른 것에 대해 생각한 적이 없습니다.

당신은 분명히 내가 _this_ 스레드가 Paul Irish와 Alex Sexton이 제기한 특정 질문에 초점을 맞추는 더 나은 목표가 있다고 말한 15번을 듣지 않은 것 같습니다. defer 충분히 좋은가요? 스크립트 연결이 병렬 로딩보다 낫습니까?

더 중요한 질문들입니다.

기본 "로더" 기술이 사용되는 것이 아닙니다. 기본 로더 기술이 무엇인지 논의하기 위한 다른 더 나은 포럼이 있습니다. 이해합니다. 스크립트 태그가 마음에 들지 않습니다. 괜찮은. Ian과 다른 사람들이 당신의 말을 듣도록 하기 위해 W3C/WHATWG 목록에서 수십 시간을 보내십시오. 그들은 아마 모두 하품을 하고 "이미 해명했으니 가세요."라고 말할 것입니다.

@getify : 어리석은 스트로우맨 테스트를 만드는 것은 점수를 얻지 못할 것입니다. 순차 스크립트 태그가 페이지를 차단한다는 것은 모두 알고 있습니다. 우리는 또한 "지연된" 스크립트 전에 인라인 스크립트 블록을 실행하는 것이 실제 사이트에서 어떤 식으로든 문제가 되지 않는다는 것을 알고 있습니다.

사전 오해를 확인하기 위해 테스트하는 경우 ... 테스트는 항상 그 오해를 확인합니다. 20개의 스크립트 태그 대 20개의 LABjs 스크립트 로드에 대한 논쟁은 없었습니다. 가능한 한 적은 수의 HTTP 요청으로 JavaScript를 지능적으로 트리밍, 연결, 축소, gzipping 및 로드한 다음 캐싱하는 것입니다.

한편으로 우리는 실제 페이지에서 훨씬 더 나은 성능을 보이는 신뢰할 수 있는 브라우저 지원, 오랜 시간 테스트를 거친 접근 방식을 가지고 있습니다. 다른 한편으로는 과거에 브라우저 업데이트 후 이를 사용했던 모든 사이트를 실제로 망가뜨렸던 함께 해킹된 "기술"이 있습니다. 이 기술은 평균적으로 훨씬 더 나쁜 성능을 내고 훨씬 더 큰 속도 차이를 보입니다.

당연한 선택입니다.

@jashkenas--

우리는 또한 "지연된" 스크립트 전에 인라인 스크립트 블록을 실행하는 것이 실제 사이트에서 어떤 식으로든 문제가 되지 않는다는 것을 알고 있습니다.

어... 인터넷에 있는 모든 사이트의 약 98%에서 소스 보기를 수행하지 않은 것 같습니다. 이 사이트는 실제로 마크업에서 인라인 스크립트 블록을 사용하여 이전(차단)에서 로드한 코드를 실행/초기화합니다. 스크립트 태그 호출.

@paulirish가 제안하는 경우 defer 충분한이며 해당 스크립트 로더가 필요하지 않습니다 나는 그것이 사실, 이유를 지적하는 것이 중요합니다 기분이 defer 충분이 아닙니다.

당신은 당신이 제어하는 ​​몇 가지 틈새 사이트에만 관심을 가질 수 있습니다. 이 사이트는 빌드 프로세스 등에 대해 고도로 최적화할 수 있는 완전한 능력을 가지고 있습니다. 반면에 저는 인터넷의 롱테일 사이트에서 성능 향상을 돕는 데 관심이 있습니다. 6개의 스크립트 태그(일부는 인라인 스크립트 블록!)가 포함되어 있습니다. 여기서 6개의 $LAB.script() 호출을 사용하면 실제로 성능이 향상될 수 있습니다. 그것이 LABjs가 항상 추구했던 것입니다. 관심이 없다고 해서 관련이 없는 것은 아닙니다.

20개의 스크립트 태그 대 20개의 LABjs 스크립트 로드에 대한 논쟁은 없었습니다.

이 스레드의 논쟁은 3-4개의 스크립트 태그( defer 또는 포함하지 않음)가 병렬 스크립트 로더를 사용하여 동적으로 로드된 3-4개의 스크립트보다 성능이 더 나쁘거나 같거나 더 나은지에 대한 것입니다. 내 "어리석은 스트로우맨 테스트"는 사실 정확히 그것을 테스트하기 위한 것입니다.

내 경험에 따르면 스크립트 로더는 페이지 로드 시간을 밀리초 단위로 단축합니다. 하지만 우리 모두는 여기서 요점을 놓치고 있다고 생각합니다. JavaScript에는 몇 가지 더 큰 문제가 있습니다.

• import 문이 부족하면 코드를 모듈식으로 구성하기가 어렵습니다.
• 모든 것의 신중한 네임스페이스에 많은 주의를 기울이지 않는 한 전역 변수가 충돌합니다.
• 스크립트의 종속성이 무엇인지 명확하게 볼 수 있는 방법이 없습니다.

좋은 부작용이긴 하지만 로드 속도가 더 빠르기 때문에 RequireJS를 사용하지 않습니다. NodeJS에서 하는 것처럼 JS 앱을 작은 모듈로 구성할 수 있도록 사용합니다. 각 모듈은 종속성을 명확하게 나열하고 샌드박스 패턴을 사용하여 전역 네임스페이스를 깨끗하게 유지합니다. 모듈(및 해당 종속성)은 미리 로드하거나 요청 시(예: 사용자 클릭 시) 로드하거나 지연 로드할 수 있습니다. 이러한 기술을 사용하여 성능을 실제로 미세 조정할 수 있습니다. 또한 RequireJS는 배포를 위해 모든 종속성을 단일(또는 소수의) gzip 준비 파일로 결합하고 축소하는 빌드 도구와 함께 제공됩니다. 이 세 가지 문제를 해결하는 것은 저에게 큰 승리입니다.

사람들이 이러한 문제를 해결하지 못하는 스크립트 로더를 사용하는 것에 대해 토론하는 이유를 알 수 있습니다. 성능이 유일한 요점이고 논쟁의 여지가 있다면 확실합니다. 그러나 RequireJS와 같은 AMD 모듈 로더를 사용하면 논쟁이 무의미해집니다. 모듈은 JavaScript의 미래입니다. Mozilla의 Dave Herman은 Apple 및 Google의 이사회 구성원과 협력 하여 언어 자체에 기본 모듈을 추가

@getify

사람들이 당신을 다른 사람들과 다르게 대할 것이라고 기대할 수는 없습니다. 후원하는 것은 적절한 반응을 얻는 영리한 방법이 아니며(그리고 신이 당신을 후원하고 있습니다) 제 블로그 게시물에서 말했듯이 당신이 바보가 아니라고 생각합니다. 다만 당신이 집착하고 있다고 생각합니다. 당신 자신 btw) 그리고 그것은 당신의 판단을 심각하게 손상시킵니다. 내 블로그 게시물에서 말했듯이 이 문제를 처리하는 것은 W3C나 WHATWG가 아니라 EcmaScript 자체입니다. 이것은 브라우저 문제가 아니라 언어 문제입니다. 이제, 원하지 않으면 이 대답을 하지 마십시오. 그것은 당신의 특권입니다.

내가 가혹하게 왔을 수도 있지만 나는 단지 내가 믿는 것을 옹호합니다.

이 스레드에서 구독을 취소하고 더 ​​이상 댓글을 달겠습니다. @paulirish 와 @SlexAxton이 탈선해서 죄송합니다.

@getify

당신은 당신이 통제하는 소수의 틈새 사이트에만 관심을 가질 수 있습니다.
빌드 프로세스 등에 대해 고도로 최적화할 수 있는 완전한 능력
다른 한편으로는 롱테일 사이트의 성능 향상을 돕는 데 관심이 있습니다.
인터넷, 6개의 스크립트 태그가 있는 태그(일부는 인라인 스크립트
블록!), 여기서 6개의 $LAB.script() 호출을 사용하면 실제로
성능을 향상시킵니다. 그것이 LABjs가 항상 추구했던 것입니다. 으니까
당신이 신경쓰는 것이 중요하지 않다는 것은 그것이 관련이 없다는 것을 의미하지 않습니다.

LABjs가 평범한 사이트가 로드 불량률을 약간 낮추도록 돕는 것이라면 ... 그것은 고귀한 목표라고 생각합니다. 그러나 느리게 로드되는 웹사이트를 진지하게 생각하고 가능한 한 빨리 로드하도록 하는 경우(LABjs가 허용하는 것보다 문자 그대로 몇 초 더 빠를 수 있음) 열린 마음을 유지하고 더 쉽고 덜 취약하다는 것을 인정해야 합니다. 기술도 더 효율적입니다.

이 스레드의 논쟁은 3-4개의 스크립트 태그(지연 여부)에 관한 것입니다.
다음을 사용하여 동적으로 로드된 3-4개의 스크립트보다 더 나쁘거나 동일하거나 더 나은 성능을 보입니다.
병렬 스크립트 로더. 나의 "어리석은 스트로우맨 테스트"는 사실
정확히 그것을 테스트하십시오.

이 스레드의 논쟁은 가능한 한 빨리 JavaScript를 로드하고 실행하기 위해 웹 사이트를 구축하는 방법에 대한 것입니다. 고객에게 뱀 기름을 판매하고 웹 개발자에게 홍보하는 것은 두 사람 모두에게 해가 됩니다.

인터넷에 대기 시간이 있습니다. JS를 연결, 축소 및 압축하고 가능한 한 적은 수의 HTTP 요청으로 페이지 하단에 로드합니다. 그런가 말했다.

@jashkenas--

LABjs가 평범한 사이트가 로드 불량을 약간 덜 수 있도록 돕는 것이라면 ... 그것이 고귀한 목표라고 생각합니다.

지난 2년 동안 스크립트 태그를 $LAB.script() 호출로 바꾸는 것 외에는 아무것도 하지 않은 수백 개의 사이트가 있으며 전반적으로 모두 더 나은 성능을 보았습니다(일부는 크게, 일부는 약간만).

다양한 산업(예: 전자 상거래, 부동산 등)의 사이트가 더 나은 성능을 얻도록 돕는 데 초점을 맞춘(완전히 독립적이고 나와 관련되지 않은) 작성된 기사가 있습니다. 그들은 스크립트 태그를 $LAB 호출로 대체하고 해당 댓글 스레드의 많은 사람들이 도움이 되었다고 긍정적으로 응답했습니다.

기사에서 "좋아요, 더 많은 성능을 얻으려면 gzip을 이해하고 ruby ​​또는 node.js를 설치할 수 있는 서버 관리자를 고용하여 자동화된 빌드 프로세스를 수행할 수 있습니다......."라고 말했습니다. 그 기사를 읽는 것은 그것에 대해 다른 생각을 하지 않고 그냥 지나쳤을 것입니다. 하지만 저는 "이봐, <script>를 script()로 대체"가 그들이 이해하고 공감할 수 있는 매우 쉬운 메시지라고 믿고 싶습니다.

LABjs에 대해 내가 원했던 것은 너무 많은 생각 없이 누군가가 쉽게 방문하여 스크립트 태그를 교체할 수 있는 간단한 솔루션입니다. 사이트와 개인적으로 상담하고 최상의 최적화를 찾을 수 있다면 많은 사이트에서 훨씬 더 많은 성능을 끌어낼 수 있다는 것을 알고 있습니다. 그러나 나는 또한 이것이 인터넷의 긴 꼬리를 위해 할 수 있는 한 사람의 능력을 훨씬 뛰어 넘는다는 것을 인식하고 유사하게 모든 엄마&팝 사이트에 "이봐, 자동 빌드 시스템을 가져와서 gzip을 사용하는지 확인하십시오"라고 말하는 것은 다음과 같습니다. 그들에게 낯선 언어를 말하는 것. OTOH, "이봐, 저 3개의 스크립트 태그를 가져와서 3개의 script() 호출을 만드세요. 얼마나 쉬웠나요?"라고 말하는 것은 꽤 성공적이었습니다.

결론적으로, LABjs에 대한 나의 접근 방식은 낮은 성과를 내는 것이었습니다.

그 어느 것도 최적화에 대한 보다 정교한 접근 방식이 불가능하다는 것을 암시하는 것은 아닙니다. 그것들은 분명히 가능하며, 제가 상담할 기회가 있을 때, 저는 확실히 그것들을 탐구합니다. 그것은 많은 웹에서 그들이 기꺼이 또는 얻을 수 있는 것보다 더 복잡하거나 복잡하다는 것을 말하는 것입니다. 그리고 저는 단지 _그_ 사이트가 이해하기 쉬운 방식으로 개선되도록 도우려고 노력하고 있습니다.

@jashkenas--

잠재적으로 말 그대로 LABjs가 허용하는 것보다 몇 초 더 빠릅니다. 그런 다음 열린 마음을 유지하고 더 쉽고 덜 깨지기 쉬운 기술도 더 성능이 좋다는 것을 인정해야 합니다.

LABjs가 사이트 속도를 크게 늦추고 있다는 확실한 증거는 없습니다. 많은 사이트에 도움이 된다는 확고한 증거가 많이 있습니다. 그래서 나는 이것을 사지 않습니다. 당신이 말하는 것은 증거가 아닌 사실을 가정하는 잘못된 전제입니다.

@paulirish 는 defer 속성의 문제를 지적하는 게시물을 찾았습니다.
http://hacks.mozilla.org/2009/06/defer/

@jashkenas가 말했듯이 모바일 성능 관점에서 볼 때 3g 네트워크 연결로 인해 발생하는 대기 시간으로 인해 여러 http 요청이 있는 것보다 라인을 통해 하나의 패키지로 연결, gzip 및 전송하는 것이 항상 가장 좋습니다.

이미지를 base64로 문자열로 인코딩한 다음 http 요청을 줄이고 '캐싱'을 활용하기 위해 localStorage에 키:값 쌍으로 저장하는 인라인 기술을 활용하는 데 많은 연구가 진행되고 있습니다. http://channel9.msdn.com/Events /MIX/MIX11/RES04 는 Microsoft Research의 James Mickens의 훌륭한 프레젠테이션입니다.

http://davidbcalhoun.com/present/mobile-performance/ http 요청이 있는 모바일 성능과 사용자 경험에 미치는 영향에 대한 좋은 자료입니다.

저는 RequireJS 에서 일하고 있으며

1) JS가 실행되는 모든 곳에서 잘 작동하는 JS의 모듈식 코드에 대한 방법을 보여줍니다.
2) 스크립트를 로드합니다.

"스크립트 로드" 부분은 첫 번째 목표를 달성하는 데 필요한 부분입니다. dev에서는 디버깅을 더 어렵게 만들고 줄 번호가 일치하지 않기 때문에 모든 스크립트를 연결하는 것은 좋은 생각이 아닙니다. 또한 스크립트 로더를 사용하면 JS API를 사용하여 요청 시 코드를 쉽게 로드할 수 있습니다. 웹메일 크기 앱의 경우 이것은 성능 스토리의 필수 부분입니다. 그러나 스크립트를 하나 또는 적은 수의 요청으로 연결하는 것이 일반적으로 최상의 배포 옵션입니다.

그러나 requirejs의 목표는 전역을 억제하고 명시적 종속성을 장려하는 방식으로 다른 사람들과 공유할 수 있는 모듈식 코드 단위를 만들고 참조하는 방법을 보여주는 shim/polyfill/무엇이든 되는 것입니다.

JS의 모듈 형식에 대한 논의를 알리는 데 도움이 되는 것을 목표로 모듈식 스크립트 로더( 준수 테스트 포함)를 만드는 다른 사람들과 함께 작업 한 AMD API 를 사용합니다. 이 접근 방식은 실제 구현을 하고 API에 대해 다른 사람들과 합의에 도달함으로써 진행되는 방식입니다.

특히 JS의 네트워크 특성과 ​​웹 문서/응용 프로그램과의 관계를 고려할 때 로더 플러그인 API 는 ES Harmony 모듈과 함께 어떤 방식으로든 지원되어야 하는 것이며 , requirejs 로더 플러그인을 사용 하여 하모니 제안을 더 잘 이해하고 피드백을 제공할 수 있습니다.

성능 사용자를 위해 :

• AMD( curl , Dojo 1.7 , loadrunner , requirejs)를 지원하는 로더를 위한 몇 가지 선택 사항이 있으며, 배포를 위해 수행되는 "하나의 JS 파일에 있는 모든 스크립트" 최적화에 사용할 수 있는 아주 작은 것 까지도 있습니다. 따라서 최상의 코딩 방법을 권장하면서 뛰어난 성능을 얻을 수 있습니다. 즉, 명시적 종속성을 사용하여 전역을 피함으로써 코드를 더 쉽게 공유할 수 있습니다.
• requirejs 옵티마이저는 Node에서 매우 빠르게 실행되며 Rhino에서도 실행할 수 있습니다. 커맨드 라인 툴이지만 최신 마스터 브랜치 코드는 이를 Node에서 사용할 수 있는 모듈로 내 보낸다 . 따라서 원하는 경우 "항상 하나의 스크립트 다운로드" 모드에서 개발할 수 있지만 최적화된 파일에서 하나 또는 두 개의 모듈을 제외하도록 선택하면 쉽게 디버그할 수 있습니다.

이 티켓의 맥락에서 : AMD 호환 로더(requirejs일 필요는 없음)를 선택하는 것은 HTML 상용구의 목표에 부합합니다. 즉, 코드와 성능 모두에서 모범 사례로 가는 길을 가리킵니다. 그러나 HTML 상용구를 만드는 것은 매우 어려운 일이고 이해 관계가 상충되고 약간의 문체도 있으므로 현재로서는 이 분야에서 추천하고 싶지 않다는 점에 감사드립니다.

AMD API를 구현하는 requirejs 및 로더의 목표는 전역을 덤프하고 개발자가 전체, 때로는 암시적인 종속성 트리를 해결하도록 강제하는 일부 스크립트를 로드하는 것보다 더 큰 이점을 제공한다는 점을 분명히 하고 싶습니다. 이러한 목표는 견고한 성능 프로필을 가진 솔루션으로 달성됩니다.

이전부터 다시 초점을 맞추려면... defer 테스트를 LABjs 테스트와 비교...( defer 가 인라인 스크립트 블록에서 작동하지 않는다는 사실을 무시하고) LABjs 테스트가 defer 테스트보다 성능이 좋지 않습니까? 여러 브라우저에서, 심지어 모바일 기기에서도 시도해 보았지만 여전히 거의 같은 숫자를 보고 있습니다.

http://labjs.com/dev/test_suite/test-script-defer-tags.php

http://labjs.com/dev/test_suite/test-LABjs.php

@getify

왜 또는 어떻게 이것을 최적화할 수 있는지 모르지만 3년 이상 된 MacBook 컴퓨터에는 두 제품 사이에 일관된 3000의 차이가 있으며 이는 @defer 합니다.

그러나 Firefox에서만 테스트했습니다.

@espadrine-- 꽤 이상합니다. 그 바닥에 도달하고 싶습니다. 어떤 버전의 Firefox로 테스트하고 있습니까? 결과 스크린샷을 보내주실 수 있습니까?

모든 JS와 CSS를 연결 및 축소하고 HTML 페이지에 바로 인라인 처리하면 됩니다. 단일 HTTP 요청 FTW! :NS

진지하게 말하지만 이 커뮤니티에는 앱이 로드되는 방식보다 더 큰 문제가 너무 많아서 집중해야 합니다. 아마도 가장 간단한 방법(하단의 스크립트 태그)이 충분히 빠를 것입니다. 훌륭한 앱을 작성하고 마지막에 로딩 성능을 처리하십시오. 다른 일을 하는 것은 성급하게 최적화하는 것입니다.

이 스레드의 사람들은 AMD가 JS 코드 구성의 황금 표준이 되어야 한다는 일반적인 합의가 있습니까? 다른 옵션을 실제로 본 적은 없지만 Boilerplate는 사람들이 코드를 구성하는 데 좋은 출발점이 될 것이라는 데 동의합니다.

Firefox UX 8.0a1(2011-08-07) 업데이트 채널.

다시 말하지만, 이유는 알 수 없으며 아마도 매우 구체적일 것입니다. LABjs는 아마도 레거시 브라우저에서 매우 유용할 것입니다.

@getify 의 테스트 페이지를 웃음 이상의 목적으로 사용하지 마세요. 인용하려면:

<스크립트 연기 src="http://labjs.xhr.me/dev/test_suite/testscript1.php?_=4911710&delay=5"> <스크립트 연기 src="http://labjs.xhr.me/dev/test_suite /testscript2.php?_=6146431&delay=3"> <스크립트 연기 src="http://labjs.xhr.me/dev/test_suite/testscript3.php?_=9499116&delay=1">

@getify , 실제 테스트를 하고 싶다면 자유롭게 @SlexAxton 의 AssetRace repo를 포크하고 LABjs 버전을 추가하거나 _real_의 JavaScript 파일을 사용하는 테스트 페이지를 실제 대기 시간으로 만드십시오.

또한 단일 스크립트 태그( defer 여부)에 대해 JS를 실제로 연결했는지 확인하십시오. 요점은 1개의 HTTP 요청을 통해 제공되는 동일한 콘텐츠가 10개의 HTTP 요청에서 제공되는 동일한 콘텐츠를 능가한다는 것입니다.

LABjs가 상당히 중요하다는 것을 시사하는 어떤 확립된 증거도 없습니다.
모든 사이트의 속도를 늦춥니다. 많은 도움이 된다는 입증된 증거가 많이 있습니다.
사이트의. 그래서 나는 이것을 사지 않습니다 -- 당신이 말하는 것은 가정이 잘못된 전제입니다
증거에 없는 사실.

위에서 설명한 것은 LABjs가 이미지, CSS 및 기타 자산을 사용하여 많은 HTTP 요청에서 JS가 경쟁하게 하여 실제로 사이트 속도를 크게 늦추고 있다는 것입니다. @getify :

기록을 위해 AssetRace repo 테스트 페이지에서 더 많은 이미지를 얻는 것이 현명할 것이라고 생각합니다. 하지만 지금은 확실히 좋은 기준이 됩니다.

@artzstudio AMD 로더로 JS를 구성하는 것은 최소한 Harmony의 모듈이 완성되고 널리 지원될 때까지는 실제로 최고의 표준입니다. 그러면 AMD 모듈에서 기본 모듈로의 명확한 마이그레이션 경로가 생깁니다.

AMD 모듈이 표준이 되는 것은 확실히 의견입니다(나도 공유할 수 있음). 그러나 그것을 좋아하지 않고 다른 솔루션을 제공하는 똑똑한 사람들(Yehuda Katz와 Dan Webb가 떠오름)이 많이 있습니다.

@danwrong 의 loadrunner는 당신의 가방이라면 둘 다 할 수 있습니다: https://github.com/danwrong/loadrunner

꽤 좋은 것들이 있습니다. JS가 아닌 사람들에게도 잠재적으로 조금 더 실용적입니다. 나는 내 물건에 대한 AMD 모듈을 좋아하지만 모든 사람이 사용하는 라이브러리의 각 버전을 모듈로 변환하는 데 시간을 보내고 싶어하는 것은 아닙니다.

@strobecorp 가 AMD 모듈에 필요한 추가 코드를 많이 필요로 하지 않는 자체 솔루션을 개발하고 있다는 것을 알고 있습니다.

AMD가 기본값이 되었으면 좋겠지만 다중 라이브러리/newb 관점에서 내가 원하는 만큼 현명하지 않을 수 있습니다.

@jashkenas--

@getify 의 테스트 페이지를 웃음 이상의 목적으로 사용하지 마세요.

당신이 예의 바르게 행동할 수 없다면 나는 당신과 더 이상 논의할 생각이 없습니다. 성실하게 행동하고 있습니다. 나는 약간의 일반적인 품위를 높이 평가할 것입니다.

@getify , 실제 테스트를 하고 싶다면

내가 하는 일이 왜 그렇게 미쳤고, 웃기고, 무의미한지 설명해주셨으면 합니다. 나는 (그의 훌륭한 경험과 지혜로) 모든 테스트에서 서버 타이밍을 사용하여 스크립트를 제어하고 테스트의 변동을 줄인다고 제안한 Steve Souders로부터 직접 접근 방식을 취했습니다. 그게 바로 내가 하는 일이다.

보다 통제된 테스트는 유효한 기준 테스트입니다. 그것은 확립된 과학적 관행입니다. 그렇다고 해서 실제 테스트가 유용하지 않다는 의미는 아니지만, 저를 저격하면서 "그를 비웃어라, 그가 내가 생각하는 것과 다르게 테스트를 하기 때문에 이 바보야. 해야 한다."

@SlexAxton 의 AssetRace 저장소를 자유롭게 분기하고 LABjs 버전을 추가하십시오.

기꺼이 그렇게 하겠습니다. 하지만 내 다른 테스트가 유효하지 않다는 데 동의하기 때문이 아닙니다. 내 테스트 설정이 유효하지 않은 이유에 대해 합리적이고 수준 높은 주장이 있는 경우 공유하십시오. 그러나 그것에 대해 그런 바보가되는 것은 그만 두십시오.

@jashkenas--

요점은 1개의 HTTP 요청을 통해 제공되는 동일한 콘텐츠가 10개의 HTTP 요청에서 제공되는 동일한 콘텐츠를 능가한다는 것입니다.

나는 당신(그리고 다른 사람들)이 이 토론이 concat과 not-concat에 관한 모든 것에 대해 어떻게 여기에서 계속해서 소리를 질렀다는 것을 알고 있습니다. 스레드의 훨씬 더 앞부분을 읽었다면 해결해야 할 두 가지 질문이 있음을 인정했습니다. 내가 아는 한 두 가지 문제는 직교합니다. 첫 번째는 마크업의 스크립트 태그가 병렬 스크립트 로더에서 사용되는 동적 스크립트 요소와 같거나 더 좋을 수 있는지 여부입니다. 그 질문은 내가 여전히 테스트를 통해 해결하려고 하는 것입니다.

우리가 아직 얻지 못한 두 번째 질문은 script-concat이 항상 더 나은지에 관한 것입니다. 나는 당신이 이미 그것을 확신하고 있다는 것을 알고 있지만 그것이 그렇게 간단하지 않다는 것을 시사하는 반대 증거가 있습니다. 그 질문도 철저히 검증해야 합니다. 하지만 지금 이 스레드에서 해결하려고 하는 것은 아닙니다.

당신의 방법이 더 나은 방법이라고 계속 주장함으로써, 당신은 전체 토론을 덜 유쾌하게 만들 뿐입니다. 제가 하려고 하는 일은 이 두 가지 주요 질문 각각에 대한 몇 가지 증거를 체계적으로 설정하는 것이므로 추측을 멈추고 더 많은 정보를 얻을 수 있습니다. 당신이 나와 동의하지 않는다는 이유로 나에게 바보짓을 하려고 하는 대신에 당신이 도울 수 있는 일이 아닌 이유는 무엇입니까?

defer 테스트 대 LABjs 테스트와 관련하여 IE9, FF8(야간) 및 Chrome15(카나리아)에서 두 가지 일대일 테스트의 빠른 스크린캐스트 캡처를 수행했습니다.

http://www.screenr.com/icxs

defer 단점에 대한 @paulirish 의 이전 질문(https://github.com/paulirish/html5-boilerplate/issues/28#issuecomment-1765361)에 대답하려면 IE에서 "DOMContentLoaded"가 어떻게 작동하는지 살펴보세요. defer 테스트의 Chrome 및 Firefox.

IE9 및 Chrome15에서 DOMContentLoaded 이벤트는 보류(차단)되고 스크립트가 실행될 때까지 실행되지 않습니다. 그러나 FF에서는 DOMContentLoaded 이벤트가 유지되지 않고 즉시 실행되고 스크립트가 그 이후에 실행되기 시작합니다. 이는 최신 브라우저 전반에 걸쳐 엄청난 불일치이며 defer 가 충분하지 않다고 생각하는 이유 중 하나입니다.

사양을 읽고 알 수 있는 한 어떤 동작이 올바른지 잘 모르겠습니다. 그러나 브라우저 간에는 분명히 기발하고 일관성이 없다는 것을 알고 있습니다.

@getify 저는 바보가 되려고 하는 것이 아닙니다. 마음에 상처를 드린 점 진심으로 사과드립니다.

당연히, 당신이 욕하는 것으로 보는 것은 토론의 요점으로 ... 그리고 내가 뱀 기름으로 보는 것을 당신은 도움이 되는 한 걸음으로 봅니다.

두 가지 문제는 실제로 직교합니다(원래 게시물에서 사용한 언어).

첫 번째는 마크업의 스크립트 태그가
병렬 스크립트 로더에서 사용되는 동적 스크립트 요소.

우리는 이 문제에 대해 전적으로 동의합니다. 그것은 중요하지 않습니다. 물론 병렬 로딩은 하나 이상의 스크립트에 대한 순차 로딩보다 빠를 것입니다. 그리고 물론, 말하거나, 비 블로킹 방식으로 그 일을 <body> 또는과 태그 defer , 또는 스크립트 로더의 블로킹보다 더 좋을 것이다 <head> .

그러나 이것은 요점을 놓치고 있습니다. 순차 스크립트 태그를 넣는 것은 비교하기 힘든 일입니다. JavaScript의 성능에 관심이 있는 사람은 아무도 그 접근 방식을 사용하지 않을 것이기 때문입니다. 순차 스크립트 태그보다 더 빠른 것은 무엇입니까? _아무것_.

우리가 아직 얻지 못한 두 번째 질문은
script-concat은 항상 더 좋습니다.

우리는 이 질문을 "얻었다". 사실, 이 페이지 상단에 @paulirish 의 질문입니다. 이 스레드에서 해결하려고 하지 않는다면 그렇게 해야 합니다. 이것은 이 스레드에서 뿐만 아니라 수년에 걸쳐 LABjs가 하는 일에 대한 모든 주장의 핵심을 찌릅니다.

그 질문도 철저히 검증해야 합니다.

반복하기 위해, 여기에 (공정한) 테스트 케이스가 있습니다. 동일한 5개의 실제 스크립트, 다른 자산이 있는 중간 크기 페이지에 로드합니다. 하나는 로드 순서를 보장하기 위해 LABjs 모범 사례를 사용하고 다른 하나는 연결된 단일 스크립트를 사용합니다.

http://jashkenas.s3.amazonaws.com/misc/snake-oil/labjs.html

http://jashkenas.s3.amazonaws.com/misc/snake-oil/vanilla.html

조사하고 싶은 다른 테스트 사례나 실험해보고 싶은 실제 LABjs 사용 웹사이트가 있다면 공유해 주세요.

@SlexAxton 감사합니다. 이에 대한 Yehuda의 견해와 다른 강력한 의견(리팩토링하기가 너무 어렵다는 점 제외)을 듣고 싶습니다. 내가 발견 이 이야기를하지만.

@geddesign 의 의견을 명확히 오늘 현재 AMD 모듈은 하모니 모듈로 상당히 쉽게 변환될 수 있지만 내가 생각하는 하모니 모듈 제안은 여전히 ​​유동적이며 나중에 변경될 수 있습니다. 아직 엄격한 구현 테스트를 거치지 않았지만 어느 정도 다리를 놓기 시작했습니다. 플러스 측면에서 AMD 로더 + 로더 플러그인은 일부 조화 아이디어를 시도하는 데 확실한 피드백을 제공할 수 있습니다.

@SlexAxton 의 의견:

loadrunner의 경우: 구문이 더 나은지, 단지 다른지 명확하지 않습니다. AMD를 지원하므로 여전히 작동합니다.

strobe의 경우: 아직 그들로부터 코드를 보지 못했습니다. 나는 Yehuda가 그 발전을 열기 위해 한 일에 감사하지만 그들은 상당히 내면에 초점을 맞춘 것 같습니다. Alex, 그들이 생각하는 것에 대한 포인터가 있다면 알려주시면 감사하겠습니다.

접근 방식이 중첩된 종속성을 허용하려면(광범위한 코드 공유에 필요함) 다음과 같은 구문이 필요합니다.

• 코드 단위에 이름을 부여합니다.
• 의존성을 지정하는 방법
• 종속성이 준비될 때까지 실행되지 않도록 해당 코드 주위에 함수 래퍼를 추가합니다. 또는 항상 JS 개발 범위에서 확장할 수 없는 빌드 또는 XHR 액세스를 요구합니다.

이것이 AMD가 제공하는 것이며 구문은 가능한 한 슬림합니다. 다른 것은 이름과 일부 유형의 구두점을 놓고 싸우는 것뿐입니다. 어떤 시점에서 무언가를 선택해야 하고, 지금까지 Dan Webb 또는 Yehuda로부터 AMD를 지지할 수 없는 구조적 약점에 대해 들어본 적이 없습니다. requirejs와 같은 일부 AMD 로더는 일반 스크립트만 로드할 수 있으며 모듈일 필요는 없습니다.

특히 모듈에 대한 코드 구문을 생각하는 것은 매우 쉽고 모든 사람이 자신의 개인적인 선호도를 가지고 있다는 점을 이해할 수 있습니다. 그러나 AMD는 어떤 종류의 동의를 얻기 위해 열심히 노력했으며 더 중요하게는 이를 백업하기 위한 실제 코드 및 배포를 수행한 꽤 깊은 역사를 가지고 있습니다. AMD가 적합하지 않은 이유에 대해 매우 명확하고 명확하게 설명해야 하는 책임은 이제 다른 사람들에게 있다고 생각합니다(이 티켓은 이를 위한 장소가 아닙니다. 언제든지 저에게 연락하지 않거나 amd-implement list를 사용하십시오) .

그러나 @SlexAxton 의 견해에 감사드립니다. HTML 상용구에 대한 AMD 접근 방식을 표준화하는 것은 시기상조일 수 있으며 저는 그것에 대해 완전히 괜찮습니다. 상용구 프로젝트가 하나를 선택하기로 결정했다면 AMD는 광범위한 JS 개발에 적합한 강력한 선택입니다.

@SlexAxton 당신과 함께 해요. 내 자신의 코드는 AMD입니다. 모두가 스크립트 대신 모듈을 작성했으면 좋겠지만 운 좋게도 RequireJS는 일반 스크립트와 모듈을 로드할 수 있습니다.

Yehuda의 handlebars.js 템플릿을 언급하는 경우 RequireJS와 매우 잘 작동합니다. 특히 템플릿을 컴파일/캐싱하고 템플릿 기능을 반환하는 플러그인을 작성하는 경우.

define(['tmpl!navigation.html'], function(nav){
   $('body').append(nav(data));
});

그러나 나는 이 진술에 동의하지 않습니다.

AMD가 기본값이 되었으면 좋겠지만 다중 라이브러리/newb 관점에서 내가 원하는 만큼 현명하지 않을 수 있습니다.

Newbs는 전역 변수 충돌에 더 취약하기 때문에 AMD가 노련한 개발자보다 훨씬 더 많은 깨끗한 구조를 제공해야 합니다. 등. 라이브러리는 모듈로부터 막대한 이점을 얻습니다. 이것이 곧 출시될 Dojo 1.7 및 Mootools 2.0이 AMD로 이동하는 이유입니다. jQuery가 탑재되기를 바랍니다. 가장 큰 불만 중 하나는 "전부 아니면 전무"입니다. 애니메이션, ajax, 이벤트 등도 페이지에 로드하지 않고는 뛰어난 DOM 조작을 사용할 수 없습니다. 네, AMD는 윈윈입니다. HTML5 Boilerplate가 사람들에게 모범 사례를 알려주고 싶다면 AMD를 제외하는 것은 부끄러운 일이 될 것입니다. JavaScript의 많은 문제를 우아하게 해결합니다.

확실하게. 나는 동의한다. 나는 그들이 모든 방법을 필요로 사용하기를 바랍니다.

나는 그들이 할 것이라고 생각하지 않습니다.

나는 사람들이 아직 AMD가 모든 진지한 개발자가 알아야 할 유행어라는 것을 깨닫지 못한다고 생각합니다. 일단 그렇게 하면 상사와 향후 인터뷰에서 자신이 알고 있는 내용을 말하고 사용하기를 원할 것입니다.

우리 모두가 우리의 몫을 다하고 "쉽고 더 좋고 중요합니다"라고 말하고 유행어로 만든다면 무리는 자신의 경력을 위해 따라갈 것입니다.

@jashkenas--

첫 번째는 마크업의 스크립트 태그가 병렬 스크립트 로더에서 사용되는 동적 스크립트 요소와 같거나 더 좋을 수 있는지 여부입니다.

우리는 이 문제에 대해 전적으로 동의합니다. 그것은 중요하지 않습니다.

사실, 나는 동적 스크립트 요소 로딩이 스크립트 태그보다 더 나은 성능을 이끌어낼 것이라는 데 모두가 동의한다는 가정하에 이 스레드에 참여하기 시작했습니다. 그러나 @paulirish 와 @slexaxton 은 모두 _this_ 스레드에서 이러한 가정에 의문을 제기했습니다.

@paulirish 는 defer 가 일반 ol' 스크립트 태그를 동적 스크립트 요소 로딩 대안보다 좋게(또는 더 좋게) 만드는 충분한 방법이라고 제안했습니다. 나는 defer 가 충분하다는 데 동의하지 않으며, 이제 그 이유를 몇 가지 설정했습니다.

따라서 첫 번째 질문을 검토하고 defer 가 스크립트 로더보다 나은지 살펴보는 것이 타당하다고 생각합니다. defer 벗어날 수 있는 몇 가지 제한된 경우가 있을 수 있지만 일반화된 경우 스크립트 로더는 모든 단점을 처리/정규화하는 반면 defer 는 이러한 문제에 노출됩니다.

나는 여전히 모든 사람들이 defer 가 충분하지 않은 이유를 보거나 동의하는지 확신하지 못합니다.

반복하기 위해, 여기에 (공정한) 테스트 케이스가 있습니다. 동일한 5개의 실제 스크립트, 다른 자산이 있는 중간 크기 페이지에 로드합니다. 하나는 로드 순서를 보장하기 위해 LABjs 모범 사례를 사용하고 다른 하나는 연결된 단일 스크립트를 사용합니다.

이것은 당신과 다른 사람들의 잘못된 테스트 전제입니다. 저는 1개 대신 5개의 스크립트를 로드하는 것이 더 빠를 것이라고 주장한 적이 없습니다. 절대. 항상. 더 명확해질 수 있습니까? 전제는 5 대 1이 아니었습니다.

첫 번째 테스트는 3개의 스크립트 태그와 3개의 script() 호출을 테스트하는 것이었습니다. 왜냐하면 그것이 공정한 테스트이기 때문입니다. 그리고 비디오와 테스트는 그 시나리오에서 스크립트 로딩이 유익하다는 것을 보여주고 있다고 생각합니다.

두 번째, 그리고 훨씬 더 복잡한 테스트 질문은 이미 모든 JS를 하나의 파일에 로드하고 있는 사이트의 성능을 향상시킬 수 있는 방법이 있는지 여부입니다. 대부분의 사람들은 그것을 개선하는 것이 불가능하다고 말합니다. 나는 동의하지 않는다.

참고: 이 질문이 직교하는 이유는 스크립트 태그를 사용하거나 document.createElement("script") 유형 동적 로드를 사용하여 이 단일 연결 파일을 로드할 수 있기 때문입니다. 어느 쪽이든 단일 concat 파일에 대한 질문은 유효한 질문이지만 스크립트 태그 또는 동적 스크립트 로딩이 더 나은지 여부와는 별개입니다.

이 스레드와 다른 많은 컨텍스트(주제에 대한 모든 회의, 블로그 게시물 등 포함)에서 제가 여러 번 말하는 것을 들었을 때 단일 JS 파일 연결을 개선할 수 있다고 생각합니다. "청크"(큰 연결 파일을 분할하는 것)를 2개 또는 3개의 청크로(최대) 쪼개는 방식으로 접근합니다. 청크가 ~같은 크기이고 병렬로 로드되는 경우 "Keep-Alive" 연결, 병렬 로드 효과 등으로 인해 추가 HTTP 오버헤드가 있더라도 페이지가 더 빨리 로드될 수 있습니다.

사실 저는 LABjs의 첫 번째 릴리스 직후인 2009년 11월에 이 주제에 대해 글을 쓰고 있었습니다. http://blog.getify.com/2009/11/labjs-why-not-just-concat/

그 블로그 게시물에서, 그리고 그 이후로 저는 여러분이 빌드 프로세스를 사용하여 연결하는 위치에 있다면(모든 사람이... 사실, 대부분의 웹이 그렇지 않은 경우) 다음을 수행해야 한다고 말했습니다. 그래서. 기간. 언제나. 항상 10-20개의 로컬 파일에서 훨씬 적은 수로 파일을 연결합니다.

그러나 단일 연결 파일이 있으면 단일 파일을 2-3개의 청크로 병렬로 로드하고(스크립트 로더 사용) 로드하는 것이 도움이 될 수도 있습니다.

이것이 더 나은 이유는 무엇입니까? 나는 그 블로그 게시물에 그것을 나열했지만 간단히 말해서 :

1. 병렬 로딩 효과는 실제입니다. 이에 대해 bit-torrent 사용자에게 문의하십시오. HTTP 오버헤드도 실제적이며 이에 대응하여 그 이점을 제거하는 역할을 합니다. 그러나 그것이 이익을 얻는 것이 불가능하다는 것을 의미하지는 않습니다. 연결 Keep-Alive를 사용하면 2-3개의 동시 연결을 얻을 수 있고(2-3개의 전체 연결 오버헤드 패널티 없이) 더 짧은 시간에 코드를 로드할 수 있습니다. 3개의 청크로 로드하면 1/3(60-70% 더 빠름)이 될까요? 아닙니다. 절대 아닙니다. 그러나 20-30% 더 빠를 수 있습니다.
2. 단일 파일에서 모든 코드를 제공하면 다른 수명 코드에 대해 다른 캐시 헤더를 수행하는 것을 방지할 수 있습니다. 예를 들어, jquery는 매우 안정적이며 다시 다운로드할 필요가 없습니다. 그러나 사이트의 UX 중심 코드는 매우 변동적일 수 있습니다(일주일에 한 번 이상 조정할 수 있음). 단일 concat 파일에서 짧은 캐싱 헤더를 수행하는 것은 불필요한 안정적인 코드를 더 자주 다시 다운로드해야 하기 때문에 어리석은 일입니다. 단일 concat 파일에서 긴 캐싱 헤더를 수행하는 것도 어리석은 일입니다. 왜냐하면 캐시된 파일(cache bust param 등)을 무효화하고 전체 파일을 강제로 다시 다운로드해야 하기 때문입니다. 더 휘발성 코드. 따라서 큰 concat 파일을 2개의 청크로 청크하면 하나는 안정적인 코드용이고 다른 하나는 휘발성 코드용으로 각 청크에 대해 다른 캐싱 헤더를 가질 수 있습니다. 이렇게 하면 캐시를 보다 효율적으로 사용하고 사용자가 사이트를 반복적으로 방문할 때 시간이 지남에 따라 잠재적으로 성능이 향상될 수 있습니다.
3. 연구에 따르면 평균적으로 단일 페이지 조회는 페이지에 로드되는 JS의 100% 미만을 사용하는 것으로 나타났습니다(일부 추산에 따르면 코드의 약 20-30%). 페이지 로드가 시작될 때 모든 코드를 한 번에 모두 로드하면 필요하지 않은 파일의 70-80%를 푸시하기 위해 불필요하게 줄을 혼잡하게 만듭니다. 코드가 2개의 청크로 되어 있고(하나는 더 중요한 코드이고 다른 하나는 덜 중요한 코드) 첫 번째 청크를 즉시 로드하고 페이지 로드 후 몇 초 후에 두 번째 청크를 로드하면 훨씬 더 중요한 이미지/css 및 콘텐츠를 위한 파이프입니다. 본질적으로 청크를 사용하면 코드의 우선 순위를 지정할 수 있습니다.

결론은... concat 대 병렬의 주제에 대해... 나는 _항상_ 사람들에게 말합니다. 둘 다.

@getify 잘 말했다.

Kyle의 LABjs가 제 지원을 받고 있습니다.
사이트의 성능 향상을 돕는 컨설턴트로서 저는 LABjs가 잘 작동하는 것을 여러 번 보았습니다.
성능이 크게 향상되었을 뿐만 아니라(100ms가 아니라 1초 이상) 개발자들도 좋아했습니다.
이해하기 쉽고 구현하기 쉽습니다.

그리고 저는 이 기회를 통해 "Kyle에게 LABjs에 대한 큰 지원에 감사드립니다. 제 기대치를 몇 번이나 초과했습니다."라고 공개적으로 말할 것입니다.

연결 Keep-Alive를 사용하면 2-3개의 동시 연결을 얻을 수 있습니다(2-3개의 전체 연결 오버헤드 패널티 없이).

HTTP는 응답을 mux/interleave하지 않으므로 먼저 여러 연결을 열지 않고 병렬 다운로드를 할 수 없습니다. 영구 및 파이프라인 연결의 이상적인 경우는 단일 파일(+ 소수의 헤더)을 연속적으로 다운로드하는 것과 같습니다.

@포르넬--

저는 브라우저가 단일 서버에 대해 병렬로 여러 연결을 열 수 있다는 것을 직접 보았고 확인했습니다. 연결 유지가 작동하면 두 번째 및 세 번째 연결에 대한 오버헤드가 첫 번째 연결보다 훨씬 적습니다. 그것이 내가 말하는 효과입니다.

@getify Fantastic, 저는 우리가 일종의 합의에 도달했다고 생각합니다. 기억을 새로 고치려면:

나는 당신의 스크립트를 조금씩 로드하는 것에 대한 반론을 예상할 수 있습니다 ...
그러나 그것은 스크립트 로딩 기술과 완전히 직교하므로 생략하십시오.
토론의.

예, 영구 스크립트와 다른 JS 파일에서 휘발성 스크립트를 로드하는 것이 좋다는 데 동의합니다. 특정 페이지에만 필요한 스크립트를 해당 페이지에만 로드하는 것도 마찬가지로 훌륭합니다.

내가 웹 개발자이고 많은 JavaScript가 포함된 페이지가 있는 경우 어떻게 해야 합니까? LABjs를 사용하거나 영구 스크립트를 하나의 파일에 연결하고 휘발성 스크립트를 다른 파일에 연결하고 <script defer="true"> body 태그의 맨 아래에 둘 다 로드합니까?

왜 내 앱이 캐싱 문제, 브라우저 비호환성, 페이지 상의 이미지 경쟁, 그리고 스크립트 로더가 가져오는 나머지 문제에 노출되어야 합니까?

성능을 위해 스크립트 로더를 사용하는 전체 전제가 두 개의 스크립트 태그를 사용하는 것보다 더 쉽고 간단하다는 것이라면 ... 브루클린에서 판매할 다리가 있습니다.

@getify 는 웹 서버를 두 번 이상 구현했습니다. 연결 유지는 어떤 방식으로든 동시 요청에 영향을 주지 않으며 후속 요청의 비용만 절감합니다. 연결 유지가 있는 두 개의 후속 요청이 있는 분할 본문은 단일 요청보다 여전히 비쌉니다. 두 개의 본문 부분에 대해 두 개의 동시 요청이 있으면 더 나은 성능을 보일 수 있지만 브라우저는 제한된 수의 동시 요청(브라우저 및 구성에 따라 약 5개 정도)만 열 수 있다는 점을 염두에 두십시오. 세 개의 js 파일을 로드하는 것이지만 @jashkenas 가 두 번 이상 지적했듯이 이미지 또는 CSS 파일과 같은 다른 자산이 있는 경우 문제입니다.

@jashkenas-

내가 웹 개발자이고 많은 JavaScript가 포함된 페이지가 있는 경우 어떻게 해야 합니까? LABjs를 사용하거나 영구 스크립트를 하나의 파일에 연결하고 휘발성 스크립트를 다른 파일에 연결하고 <script defer="true">를 사용하여 body 태그 맨 아래에 둘 다 로드하시겠습니까?

TL;DR: 둘 다

첫째, 웹의 많은 사이트가 CMS로 조합됩니다. 즉, 인라인 스크립트 블록이 페이지 전체에 흩어져 있는 것이 일반적이며 "모든 코드를 하나의 파일로 이동"이라고 말하는 것만으로는 유지 관리 측면에서 해결하기가 매우 어렵습니다. 따라서 _대부분의_ 사이트가 다른 외부 스크립트가 로드 및 실행된 후 실행할 "인라인 코드" 없이도 벗어날 수 있다는 전제는 기껏해야 거의 불가능하다고 생각합니다.

둘째, 다양한 브라우저에서 defer 가 DOMContentLoaded 에 대해 다르게 작동한다는 것을 증명했습니다. 일부 브라우저에서는 스크립트가 DOM 준비보다 먼저 실행되고 다른 브라우저에서는 DOM 준비 이후에 실행됩니다. DOM 준비 전후에 발생하는 스크립트에 코드가 있는 경우 defer 를 사용하는 것이 문제가 될 수 있습니다. 특히나 오해와 혼란이 많은 민감한 부분이라 금세 "단순한 해법이 아니다"라는 말이 나오는 게 사실이다. 훨씬 더 많은 생각이 필요합니다.

셋째, 내가 사용하는 자신의 마크 업을 변경, 사이트의 많은에 대한 생각 $LAB.script() 대신 <script> 에 일부 자동 (또는 수동) bulid 과정을 설치하는 방법을 그들에게 설명하는 것보다 더 쉽게 많은 그들의 섬기는 사람. 특히 해당 사이트가 공유 호스팅(대부분의 웹이 있음)에 있고 서버의 많은 부분을 실제로 제어하지 않는 경우 코드 유지 관리 가능성이 손실되지 않도록 빌드 프로세스를 파악하도록 요청하는 것은... 글쎄요. .. 사소하지 않은.

이러한 것들을 극복할 수 있을까요? 네. 물론 그들은 할 수 있습니다. 그러나 그들은 많은 노력을 기울입니다. 어떤 경우에는(DOM 준비가 된 것과 같은) 실제로 코드를 힘들게 조정해야 할 수도 있습니다. 이 모든 것을 정리하려면 이 분야에서 헌신적인 노력과 많은 전문 지식과 열정을 가진 사람이 필요합니다.

대조적으로 <script> 태그 대신 LABjs에서 "빠른 승리"를 얻을 수 있습니다. 생각해야 할 것이 거의 없습니다( document.write() 제외). 대부분의 경우 "그냥 작동합니다". 그리고 대부분의 경우 페이지 로드 속도가 즉시 증가합니다. 대부분의 사이트에서 이는 큰 승리입니다.

그래서, 귀하의 질문에 답하기 위해, 제가 전에 말했듯이, 두 가지 모두 를 하라고 말하고 싶습니다. 먼저 LABjs에 드롭하고, 즉각적인 속도 증가를 보십시오. 이제 빌드 프로세스를 사용하여 15개 파일에서 2개 파일(1개 파일은 반로 쪼개짐)로 이동하는 이점을 강력하게 고려하십시오. 그렇게 할 때(내가 말했듯이 대부분은 그렇게 하지 않을 것입니다) 그렇게 하면 정말 원하면 LABjs를 버릴 수 있습니다. 그러나 실제 해는 없습니다(모바일에서도 작고 캐시가 잘 됨). 두 파일 청크를 계속 잘 로드하고 defer 인해 발생할 수 있는 문제 없이 로드됩니다.

또한 LABjs가 이미 있으면 나중에 "게으른/주문형 로드"할 수 있는 코드를 파악하기 시작하는 3단계를 수행하는 것이 어리석게 간단합니다. 스크립트 로더 없이는 할 수 없습니다. LABjs가 이미 있고 친숙하다는 것은 해당 주문형 스크립트를 로드하는 방법에 대해 전혀 걱정할 필요가 없다는 것을 의미합니다.

@rkh--

(특히 Apache에서 Keep-Alive 설정을 토글하여) 여러 병렬 요청이 어떻게 영향을 받았는지 보여주었습니다(Keep-Alive가 있을 때 긍정적으로). 저는 이 분야의 전문가가 아니므로 작동 방식에 대한 정확한 세부 사항을 논하는 것은 제 몫입니다. Keep-Alive가 있을 때 요청 #2의 타이밍이 요청 #1의 타이밍보다 적었다고 말할 수 있습니다. 브라우저와 서버가 그렇게 한 방법은 부분적으로만 추측할 수 있을 뿐입니다.

연결 유지가 있는 두 개의 후속 요청이 있는 분할 본문은 단일 요청보다 여전히 비쌉니다.

나는 두 번째 요청이 무료라고 주장한 적이 없습니다. 나는 두 번째 요청이 첫 번째 요청만큼 비싸지 않다고 주장했다. 따라서 적어도 하나의 요청이 이루어져야 한다고 가정할 때 두 번째 요청을 병렬로 갖는 것은 오버헤드 또는 시간 비용 측면에서 동일한 서버에 대해 완전히 독립적인 두 연결을 갖는 것과 동일하지 않습니다.

예상대로 요청 #1은 서비스에 대한 X이고 #2는 Keep-Alive와 병행하여 0.7X인 것 같았습니다. 서버가 두 번째 요청을 처리할 때 기존 연결 오버헤드 중 일부를 활용할 수 있어 비용이 조금 더 저렴해진다고 설명했습니다. 연결 유지가 해제된 상태에서 두 번째 요청에는 측정 가능한 감소가 없었습니다.

이 모든 토론은 심각하게 깊은 토끼 구멍입니다. 저는 서버 전문가가 아닙니다. 그럴 필요 없어 나는 이 정확한 주제에 대해 실제로 보았고 테스트를 만들었다는 것만 설명할 수 있습니다... 단일 100k 파일 로드 시간과 동일한 파일의 두 절반을 병렬로 로드하는 것을 테스트할 수 있습니까? 두 번째 테스트는 측정할 수 있습니까? 금액이 더 빠릅니다. 내가 말했듯이, 나는 청크 인 병렬 테스트에서 15-25% 더 빠른 것을 보았습니다. 어떻게 그렇게 했고 끔찍한 "OMG HTTP RESPONSE OVERHEAD IS TERRIBLE" 효과를 어떻게든 따라잡았고 여전히 두 개의 병렬 로딩의 이점을 얻었습니다. 저는 과학적으로 증명할 자격이 없다고 생각합니다. 그러나 그것은 관찰에 의해 확실히 이루어졌습니다.

맙소사, 빨리 타자. 읽기를 마치고 페이지를 새로고침하면 댓글이 9개 더 있습니다.

도움이 필요해 나는 이 스레드에서 _보일러플레이트 HTML 파일에 가장 적합한 것_에 대해 논의하는 것부터 _스크립트 로더가 모든 경우에 스네이크 오일_인지 여부에 대해 논의하는 방향으로 이동한 정확한 위치를 찾으려고 노력했습니다.

@getify , 당신은 확실히 LABjs를 방어하고 스레드에서 다른 사람들이 한 특정 비판에 응답해야 하지만 (@jashkenas 제외) LABjs를 비판하는 사람들은 그것이 상용구에 대한 최상의 솔루션이 아니라는 것을 보여주기 위해 그렇게 하는 것이라고 생각합니다. script[defer] 보다는 레거시 페이지를 LABjs로 변환하는 것이 더 쉽다고 주장하는데 그것이 사실일 수도 있습니다. 그러나 이것이 어떻게 상용구 HTML 파일(정의상 처음부터 시작)에 적용됩니까?

당신은 그것이 멋진 빌드 프로세스가 없는 사람들을 위해 설계되었다고 말하지만, 당신은 또한 연결, 동일한 크기의 청크로 분할 및 병렬 로딩을 옹호하는 것 같습니다. 빌드 스크립트의 작업이 아닌가요? 다시 말하지만, 사용자에게 지능형 기본값을 제공하도록 설계된 상용구에 대한 잘못된 선택인 것 같습니다. 사용자가 20-30% 속도 증가를 원하면 상용구가 제공하는 것보다 나중에 업그레이드하도록 선택할 수 있지만 이는 사소한 작업이 아닙니다.

이 모든 것을 말했지만 여러분이 일반적인 주제("스크립트 로더: 귀중한 도구 또는 뱀 기름?")로 계속 진행하고 싶다면 기꺼이 팝콘을 만들겠습니다.

@getify : 두 번째 및 세 번째 연결이 첫 번째 연결보다 더 빨리 열릴 수 있다는 데 동의할 수 있습니다. 첫 번째 연결은 DNS를 기다리고 아마도 첫 번째 패킷을 서버로 라우팅하는 것이 나머지를 동일한 경로로 라우팅하는 것보다 약간 느립니다. HTTPS에서 SSL 세션 캐시는 후속 연결에 많은 도움이 됩니다.

그러나 나는 이 상황에서 Keep-Alive의 관련성을 보지 못합니다. 동일한 연결에 대한 후속 _requests_는 Keep-Alive를 사용하여 더 빠르게 시작되지만 이러한 요청은 연결 내에서 직렬입니다.

이제 거의 끝났습니다. 이제 막 스크립트 로더와 관련하여 "미쳤고 더 이상 참지 않을 것"이라는 순간에 도달했습니다.

그렇긴 하지만, 화염 축제를 위한 이 스레드는 실제로 상당히 생산적이었습니다. LABjs가 불운하고 무능한 웹 사이트에 대한 주장을 펼치고 실제로 사이트를 빠르게 로드하려는 사람들을 홀로 내버려 두면 큰 진전입니다.

친구, 진정

@savetheclocktower--

공정한 질문.

나는 LABjs(또는 모든 스크립트 로더)가 h5bp에 포함될 것을 강력하게 옹호하는 이 스레드에 참여하기 시작하지 않았습니다. 나는 그것이 유용하다고 생각하지만(아래 참조), 잠이 덜 깬 것은 내 주요 관심사가 아니었습니다. 분명히 이 스레드는 "스크립트 로딩"인 모든 것에 대한 전면적인 공격으로 변했습니다. 그것은 분명히 내가 조금 더 신경 쓰는 것입니다.

당신은 그것이 멋진 빌드 프로세스가 없는 사람들을 위해 설계되었다고 말하지만, 당신은 또한 연결, 동일한 크기의 청크로 분할 및 병렬 로딩을 옹호하는 것 같습니다. 빌드 스크립트의 작업이 아닌가요?

저는 먼저 수십 개의 스크립트 태그를 모두 LABjs와 같은 병렬 스크립트 로더로 이동하는 것을 지지합니다. 이것은 마크업을 조정하는 능력 이상을 필요로 하지 않습니다. 예를 들어, 이것은 mom&pop 사이트에 자동화된 node.js 기반 빌드 시스템을 사용하도록 지시하는 것보다 훨씬 쉽고 덜 위협적인 단계입니다.

그리고 파일 빌드를 할 수 있는 사람들을 위해 LABjs가 이러한 청크를 병렬로 로드하는 데 도움이 될 수 있기 때문에 여전히 이점이 있다고 주장합니다. 청크가 어떤 식으로든 유용하다는 데 동의하지 않는다면 defer 보다 LABjs를 사용할 이유가 없습니다. 그러나 청크가 _유용한_ 이유를 알 수 있다면 스크립트 로더가 해당 프로세스에서 _도움을 줄 수 있습니다_ 따라야 합니다.

다시 말하지만, 사용자에게 지능형 기본값을 제공하도록 설계된 상용구에 대한 잘못된 선택인 것 같습니다.

스크립트 로더(특히 LABjs와 같이 스크립트 태그와 script() 호출 간에 일대일 매핑을 갖도록 설계된)가 상용구에서 이점이 있다고 생각하는 유일한 이유는 상용구에서 , 태그와 같은 것의 하나의 인스턴스를 자주 볼 수 있으며 페이지를 구축하는 경향은 필요한 만큼 복사하여 붙여넣는 것입니다. 따라서 상용구에 성능이 좋지 않은 패턴(스크립트 태그)이 있으면 사람들은 스크립트 태그를 수십 번 복제하는 경향이 있습니다. 평균적으로 $LAB.script() 호출을 여러 번 복제하면 성능이 예전만큼 나쁘지 않을 가능성이 높습니다.

그것이 내가 이 스레드에 참여하기 시작한 유일한 이유입니다. 내가 @paulirish 의 "맹목적인 믿음" 댓글을 여기 스레드에서 문제로

그렇군요.

나는 이 논의가 스크립트 로더가 h5bp 프로젝트에 적합한지 여부를 지나쳐 갔다는 것이 분명하다고 생각합니다. 그러나 이 주제는 탐색할 가치가 있으므로 좋습니다.

어쨌든 저는 테스트 결과와 함께 재현 가능한 테스트 케이스에 매우 관심이 있습니다.

또한 @defer 에 대한 사양은 브라우저가 함께 제공하는 일부 불규칙한 동작을 보호하기 위해 작성된 것 같습니다. 그 행동은 문서화되어야 합니다. 준비가 되면 MDC로 마이그레이션하는 것을 도와드릴 수 있습니다.

우리는 모든 브라우저, 다양한 연결 유형 및 네트워크 효과를 캡처하는 이러한 동작에 대한 직접적인 문서가 필요합니다. 테스트 장비가 cuzillion 또는 assetrace를 사용해야 하는지 확실하지 않지만 결정할 수 있습니다.

https://github.com/paulirish/lazyweb-requests/issues/42에 대한 관심을 모으기 위해 티켓을 설정했습니다.

webperf 연구 및 증거 문서화라는 _superfun_ 작업에 관심이 있다면 저와 함께 하십시오.

여러분, 이 스레드를 닫았다고 생각합시다.

@jrburke 가 그의 의견에서 설명한 것처럼 지연 로딩은 AMD 모듈의 핵심 이점이 아닙니다. 내가 AMD 모듈을 최대한 사용하기로 선택한 주된 이유는 코드 구조를 개선하기 때문입니다. 소스 파일을 작고 간결하게 유지합니다. 개발 및 유지 관리가 더 쉽습니다. 개발 중에 CSS @import 사용하고 스타일시트를 결합하기 위해 자동화된 빌드를 실행하는 것도 대규모 프로젝트에 권장되는 것과 같은 방식입니다...

작년에 쓴 이 게시물이 다음 주제에 적합하다고 생각합니다 . 성능 도그마 -

그리고 저는 @SlexAxton 과 함께 RequireJS 옵티마이저 Ant 작업 ) 대신 RequireJS 옵티마이저를 실행하는 새 설정을 추가하는 것일 수 있습니다. 이는 꽤 멋지고 구현하기 어렵지 않을 것입니다.

여러분, 이 스레드를 닫았다고 생각합시다.

@paulirish AMD 지원을 포함하는 것은 어떻습니까? 어디에서 논의해야 할까요?

@benatkin 새 티켓을 엽니다 형.

@paulirish 알겠습니다. 감사합니다. @jrburke 시작한 토론을 계속하려면 새 티켓을 열어 주시겠습니까? 의견을 추가할 수 있을 것 같지만 AMD 지원 사례를 여러분만큼 잘 정리할 수는 없을 것 같습니다.

재미있고 유익한 정보. 고마워 얘들아.

누군가 새로운 스크립트 로더 프로젝트를 시작하고 "Issue28"이라고 이름을 지어야 한다고 생각합니다. :)

가장 광범위한 호환성을 위해 스크립트를 맨 아래에 놓고, 축소하고, gzip하면 빠른 성능을 얻을 수 있지만 연기하지 마십시오. 적어도 몇 년 동안 브라우저 호환성이 일관될 때까지는 그렇지 않습니다.

병목 현상은 광고, 너무 많은 자바스크립트, 부풀려진 HTML, 너무 많은 CSS, 너무 많은 iframe, 너무 많은 요청, 서버 대기 시간, 비효율적인 자바스크립트에서 발생할 수 있습니다. 타사 라이브러리를 많이 사용하는 응용 프로그램은 너무 많은 자바 스크립트로 인해 문제가 발생하지만 그 이상으로 대부분 부풀려진 HTML, 잘못된 HTML, 너무 많은 CSS 및 비효율적인 자바 스크립트와 같은 다른 많은 문제도 있는 경향이 있습니다. Twitter는 두 가지 버전의 jQuery와 두 개의 onscroll 핸들러를 사용하여 오른쪽 열 onscroll이 튀는 현상을 유발합니다.

중요한 것은 자신이 무엇을 하고 있는지 알면 이러한 문제를 피할 수 있다는 것입니다. jQuery 또는 밑줄과 같은 것이 필요하지 않으므로 스크립트가 훨씬 작습니다. 깨끗하고 간단하며 유효한 HTML 및 CSS를 작성합니다. 결과적으로 페이지가 더 빨리 로드되고 앱이 변경 측면에서 더 유연해지며 SEO가 향상됩니다. 그런 다음 스크립트 로더를 사용하면 부당한 복잡성과 오버헤드가 추가됩니다.

https://github.com/BroDotJS/AssetRage

팔! 나는 클럽을 닫고 실을 닫습니다.

무슨 스레드 ... 와우.

Imo, 토론은 웹 개발자를 위한 출발점으로 의도된 h5bp의 맥락에서 시작되었습니다.
따라서 h5bp를 사용하는 webdev는 실제로 깨끗한 HTML, 깨끗한 CSS, 좋은 .htaccess 등을 갖게 될 것이며 너무 많은 이미지, 비효율적인 JS, 많은 형편없는 제3자 JS 등으로 인해 _어쩌면_ _그렇지 않을 수도 있습니다. 웹 개발자가 고성능 h5bp를 사용하기로 선택하고 그에 따라 성능에 관심이 있기 때문에 페이지로 이동하는 비 h5bp 항목에 주의를 기울일 것입니다.

스레드에서, 그리고 이러한 맥락에서 불행히도 최종 결론을 내리기에 충분한 증거가 없다고 생각합니다.
저는 Paul과 함께 연구를 진행하고 문서화해야 할 사항을 문서화합니다.
나를 바울로 세어 보십시오.

사이드노트. 저는 AMD에 대해 잘 알지 못하며, 언뜻 보기에 저에게 위협적이거나 적어도 제가 쉽게 집어들 수 있는 것은 아닌 것 같았습니다. 나는 대부분의 '일반' 웹 개발자가 동의할 것이라고 생각합니다.
h5bp에서 볼 수 있는 항목은 진입 장벽이 낮아야 합니다. 그렇지 않으면 사용되지 않고 h5bp의 흡수가 없는 경우보다 느릴 수 있습니다.
AMD와 같은 것이 h5bp에 속하는지 의심스럽습니다.
간단하게 유지하세요.

그리고 또하나의 댓글....
'최하단에 스크립트 넣기' 및 'JS 파일을 단일 파일로 연결'은 수년 동안 Web Perf 모범 사례 목록에서 상위에 있었습니다. 그렇다면 사내 개발자와 최고의 브랜드 에이전시가 구축한 평균 사이트의 90% 이상에 여전히 HEAD에 여러 스크립트 태그가 있는 이유는 무엇입니까? 정말, 왜 그래?

그리고 나머지 9%는 HEAD에 하나의 연결된 JS 파일을 가지고 있습니다.
일부 최고의 웹 성능 개발자가 맨 아래에 하나의 스크립트로 구축한 _not_ '보통' 사이트를 거의 볼 수 없습니다.

개발자는 몇 년 동안 계속해서 사이트를 구축합니다.
사이트 소유자는 디자인과 기능을 가장 중요하게 생각하므로 개발자가 시간을 투자하는 것입니다.

작업 방식, 빌드 시스템, 코드를 변경하는 ... 그것은 쉽고, 아주 쉬워야 합니다. 그렇지 않으면 일어나지 않을 것입니다.

HEAD의 JS를 단일 파일로 결합하고 BODY의 맨 아래에 로드하면 사이트의 페이지가 손상되는 많은 사이트에서 작업했습니다. 그 다음엔? 대부분의 경우 문제를 해결하는 데 한 시간이 소요되지 않습니다. 심각한 리팩토링이 필요합니다... 그리고 이것은 지식 부족, 특히 시간 부족으로 인해 발생하지 않습니다.

(아 맞다, 쓰레드가 닫혔다...)

jQuery와 Modernizr을 기반으로 한 라이브러리 빌드에 대해 이야기하고 있습니다. 모든 것을 말해줍니다. 누가 그것을 사용합니까? 오, 젠장, 두 개의 jQuery를 사용하고 소스 코드에도 다음이 포함된 Twitter.com을 잊어버렸습니다.

 352행, 6열: 끝 태그 div가 표시되지만 열린 요소가 있습니다.
 오류 라인 350, 열 6: 닫히지 않은 요소 ul.
 오류 줄 330, 열 6: 닫히지 않은 요소 ul.

그리고 브라우저가 오류를 수정하기를 기대하는 것의 문제는 HTML4가 오류 수정 메커니즘을 정의하지 않았기 때문에 누가 어디서 무엇을 알고 있는지를 알게 된다는 것입니다. 물론 HTML5는 오류 처리를 정의하지만 소급 적용되지는 않습니다. 여전히 "오래된" 브라우저가 많이 있습니다.

그리고 젠장, 여기 누군가 jQuery ES5 shim을 본 적이 있습니까?

BTW, "h5bp를 사용하는 webdev가 실제로 깨끗한 HTML을 가질 것"이라고 aaronpeters의 진술에 추가할 것이 있습니까?

@GarrettS ok, ok, "아마도 _ 깨끗한 HTML을 가질 것"이라고 썼어야 했습니다.

:-D 우리는 항상 희망할 수 있습니다!

나는 죽은 말을 이기고 있다는 것을 압니다 ... 하지만 우리가 이 흥미로운 토론을 하고 있는 동시에 현재 버전의 LABjs에는 실제로 일부 브라우저에서 JavaScript가 잘못된 순서로 실행되도록 하는 버그가 있었습니다: https: //github.com/getify/LABjs/issues/36

오, 아이러니.

해야하다. 저항하다. 전기. 완전히. [부적절]. 영상. 을위한. 이전. 성명.... 어이쿠! 고뇌!

내가 가장 좋아하는 부분은 dhtmlkitchen.com (현재 완전히 엉망진창) 을 만든 친구가 마크업 오류에 대해 이야기하기 시작했을 습니다 .

해당 사이트는 Paulo Fragomeni에게 이전되었습니다. 예, 나는 그것을 만들었고 여기에서 내가 쓴 것을 자랑스럽게 생각합니다. 약한 아바타의 스크린샷을 찍으세요.

...이 작업을 마친 후에는 고개를 갸웃거리며 내 오래된 개인 웹사이트(이는 더 이상 내가 유지 관리하지 않음)와 팀에서 개발하고 재정 지원을 받는 웹사이트 간의 차이점을 이해하려고 수익을 내는 수백만 달러의 회사(트위터의 가치는 AFAIK 수십억 달러일 수 있음).

우리가 이것을 고급스럽게 유지하고 _주제에 대해_ 다행입니다.

jashkenas는 이 토론의 초기에 관련 정보를 얻었습니다.

하지만 반발이 거셌다. 아니요! 그것은 안된다! Souders는 그것을 할 말했다! 그리고 실패했을 때 어떻게 실패하는지 신경 쓰지 않고 defer를 사용하라는 나쁜 조언이 있었습니다.

그리고 아이러니하게도, 어디선가 h5bp 사용자들이 제대로 일을 할 것이라는 주장이 나왔습니다. 그리고 이 의견은 분명히 잘못된 마크업을 생성하고 많은 제3자 추상화 계층(및 끔찍한 계층)을 사용하는 지지자들의 의견이 _후에_ 나왔기 때문에 매우 아이러니합니다. 그리고 defer 사용에 대한 주석 후.

그렇다면 이 중 dhtmlkitchen.com이 다운되는 것과 어떤 관련이 있습니까? 전혀, 분명히. 그것은 비판을 참을 수 없는 h5bp 포크의 약한 잽이었습니다.

브라더스
녀석.
브라더스

이 스레드는 닫혀 있습니다. 기억하다? 집에 갈 필요는 없지만 여기에서 불을 붙일 수는 없습니다.

이봐, 우리가 여러 토론, 개인적인 불꽃 전쟁, 사방에서 사람들이 화를내는 사람들, 외설적 인 이미지 한두 개, 그리고 모든 주위에 좋은 시간이 있었던 장대한 스레드를 만들었던 것을 기억하십니까? 무료였다는게 믿기지 않습니다. 우리는 언젠가 그것을 다시 해야 합니다.