Html5-boilerplate: スクリプト読み込みソリューション

作成日 2010年08月10日  ·  132コメント  ·  ソース: h5bp/html5-boilerplate




この問題のスレッドは現在閉じられています。

楽しかったですが、会話は今のところ他の場所に移動しています。 ありがとう

私たちが楽しんだことを感謝して、

楽しみ。





labjsまたはrequireを介して。

私の「ボイラープレート」load.jsファイルにはLABjsがインライン化されており、それを使用してjquery、GA、および1つのサイトjsファイルをロードします。 それが役立つ場合は、1つのファイルに統合されたRequireJS + jQueryがあります:http://bit.ly/dAiqEG;)

また、これは、すべてのスクリプトを連結して最小化するビルドスクリプトの期待にどのように影響しますか? スクリプトの読み込みはオプションである必要がありますか?

javascript

全てのコメント132件

カイル:「私は同意しない@paul_irish。 http://bit.ly/9IfMMN 、キャッシュ可能(外部CDNの)並列ダウンロード、スクリプトの変更-ボラティリティ...」

james burke : " @fearphage @getify RequireJSには、スクリプトのバンドル/縮小を行うためのビルドツールがあるため、動的とビルド済みの両方の長所を活用できます。"

開発者がスクリプトの読み込みを開始する最も簡単な方法は、おそらく$ Lab.jsを使用することです。これは、多くのjQueryユーザーが精通している連鎖構文をすでに使用しているためです。

大規模なエンタープライズアプリを構築している場合は、必要に応じていつでもrequire.jsに移行できます。

現在、3つの主要なスクリプト読み込み手法があります。

  1. HeadJS
  2. ControlJS
  3. LABjs

使用するかどうか、どちらを使用するかは議論の余地があります: http

HeadJSControlJSLabJSの代替案を知らせるためrequireJSEnhanceJSもあります。 ヤフーとグーグルでさえ似たようなものを提供します。

jQuery 1.5とdeferredsのリリース( http://www.erichynds.com/jquery/using-deferreds-in-jquery/)により、Boris Mooreは新しいスクリプトローダープロジェクトであるDeferJSでそれらを利用しています:https:// github。 com / BorisMoore / DeferJS

デフォルトでは、スクリプトのロードにより他のすべてのダウンロードが停止するため、ヘッダーにmodernizrをダウンロードするのは適切ではありません。 ローダーはスクリプトを並行してブロックモードではダウンロードできないため、ローダーのインライン化は理にかなっています。 たとえば、すべてのmodernizr機能が必要ない場合は、わずか6kbのhead.min.jsまたはmodernizrのカスタムビルド(http://modernizr.github.com/Modernizr/2.0-beta/)をインライン化できます。 CSSのインライン化も意味がある場合があります。 Googleはインライン化を使用しており、datauriを介してcss、js、および空の1x1gifをインライン化します。

LabJSはかなり広く使用されるようになり、優れたソリューションです。非同期で含めることもできるため、ブロックする必要はありません。

http://blog.getify.com/2010/12/on-script-loaders/は作者によるものです

http://yepnopejs.com/は1.0に移行したばかりで、LABやhead.jsとは異なり、新しいWebkitに割り込むことはありません。 スクリプトの読み込みは難しいです。

yepnopeはまた、Modernizrに統合されているModernizr.load .. http://modernizr.github.com/Modernizr/2.0-beta/

したがって、Modernizr.loadを介してh5bpにスクリプトローダーがまもなく登場するでしょう。

1.0になるとは思いませんが、Modernizrを1.8まで上げたら、それをh5bp1.1に入れます。 うん

こんにちはポール

H5BPを使用するために既存のサイトを移植しましたが、yepnope.jsスクリプトローダーを使用したいと思います。 これまでのように、すべてのビットとボットが組み合わされているのを見るのは本当に素晴らしいことです。

現時点で何を使用することをお勧めしますか?

  1. ページの上部にmodernizer.jsと一緒にyepnope.jsを含めます
  2. HTMLの読み込みが完了した後に読み込むには、ページの下部に含めます。
  3. modernizer.jsのベータ版を使用する
  4. yepnope.jsとmodernizer.jsを1つのインクルードに連結できます。

それを含めるのに最適な方法に関係なく、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/にあります

そして、はい、私はIEcssの条件付き負荷についてのあなたの考えが好きです。

スクリプトローダーとパフォーマンスについてはあまりにも多くの盲信があり、これが正しい方法であると言う準備ができているとは思いません。

スクリプトの読み込みに関する賢明な推奨事項を示すファイルサイズ、帯域幅、ネットワークの状態についてさらに調査する必要がありますが、現時点ではこの分野はまだ始まったばかりであり、スクリプトの読み込みの包括的なソリューションを推奨することはできません。

それで。

このチケットを閉じて、開発者がこのチケットについて賢明な選択をしやすくするために必要な包括的な調査と公開を行うことを気にかけている人に尋ねます

私は連結負荷と並列負荷についてかなりの研究をしました。 それでも、予約なしで、最初にすべてのjsを1つのファイルに結合してから、2〜3個の同じサイズのチャンクにチャンクし、それらを並行してロードすることをお勧めします。

私は自分の研究を取り入れて、それを広く普及させ、規模を拡大して、この分野で「事実」として実行できるようにしたいと思っています。 問題は、実際に大規模なテストを実行するのに多くの$$の費用がかからないホスティング帯域幅を見つけようとしましたが、そのホスティングプロビジョニングをまだ見つけられなかったことです。

テストの帯域幅の問題を解決できれば、並列ロードの理論が実際に実行可能かどうかを確認するために実行できるテストがあります(私が信じているように)。

@getifyテストリグに関して何が必要ですか?

パーソナルサーバーから、現在使用しているよりも約1.5TB多くのデータを処理できます。 Nginxをインストールしましたが、マイクロ秒あたり約4兆兆ヒットを処理できます。 ここではテクノロジーが障壁になっているとは思いません。

場所が心配な場合は、待ち時間が長くなることを偽装したり、ボックスに少し余裕のある他の2人の人を見つけたりすることができます。

ところで、私は「ブラインドフェイス」について少し問題を抱えています。

簡単で証明可能であり、スクリプトタグを使用して多くのスクリプトをロードする既存のサイトがある場合、並列スクリプトローダー(他の変更なし)を使用するとパフォーマンスが向上することはほぼ間違いありません。 これは、最新のブラウザーでさえ、スクリプトの読み込みをDOM対応のブロックから解除できないためです(そして、そうなることはないと思います)。 したがって、最良の場合のブラウザの読み込みでも、他にメリットがない場合は、サイトでDOM対応を大幅に高速化することがほとんどの場合(ユーザーとUXにとって)メリットになります。

あなたのステートメントは、すべてのサイトについて、script-concatとの並列ロードを比較しようとしていることを前提としているため、少し誤った前提になっています。 Web上のほとんどのサイトは、実際にはscript-concatを使用していない/使用できないため、実際の比較(それらのサイトの大多数)は、想定しているほど微妙で複雑ではありません。 スクリプト連結を使用しない/使用できない場合(何らかの理由で)、比較は簡単です。並列読み込みは、ほとんどの場合、スクリプトタグよりも優先されます。

彼らがscript-concatにオープンである(またはすでにそれを使用している)場合、そうです、並列ロードが役立つかどうかを判断するために、少し微妙な/複雑になります。 しかし、script-concatも万能の解決策ではないため、並列読み込みが引き続き推奨される最善のアプローチであるサイトはたくさんあります。

一部のサイトが並列読み込みとscript-concatのどちらを使用するかを決定する際の微妙な違いや複雑さを扱っているからといって、並列読み込みとスクリプトタグのより大きな(より影響力のある)議論が混ざり合って失われるべきだという意味ではありません。 前者を証明するのは難しいですが、後者は現時点ではほとんど与えられています。


これはすべて、考えられるすべてのことを考えると、IMHOの定型文は、前向きな方向に最大の影響を与えるパターンを奨励する必要があるということです。 今日のインターネット上のサイトの80%がスクリプトタグを使用しており、そのほとんどがスクリプトタグから並列読み込みに移行することでメリットが得られる場合、並列読み込みは定型文の出発点として提案する非常に健全な方法です。

これは、これらのサイトのはるかに小さい(ただし重要な)サブセクションであり、スクリプト連結と並列読み込みの比較からさらに多くの利益を得る可能性があります。 しかし、少数派のユースケースは、定型文で最適化する必要があるものではありません。

ほんの数セント。

@ paulirish @ slexaxton-

帯域幅のニーズに関しては、10,000人(正確なサンプリングである必要があると感じた)がテストを1回実行する(そして多くの人が数回実行するだろう)と推定しました。 200GBの帯域幅が消費されました。 一部の人々にとって、それはバケツの低下です。 私にとって、数日で200GBの帯域幅は、サーバーホスティングのコストに圧倒されます。 したがって、私はその理由だけでテストのスケーリングを追求していません。

さらに、このテストには12を超えるバリエーションがあり、調査する必要があると思います。 したがって、それぞれ100〜200 GBの帯域幅を数十回使用することは、私が費用を負担するのに非常に高額な費用がかかります。 タスクを完了するのに十分な帯域幅があることが確実でない限り、私はその道を歩み始めたくありませんでした。

これらは単なる静的ファイルであり、テストでは多数の同時ユーザーを必要としないため、CPUなどの従来のスケーリングの問題について実際の懸念はありません。帯域幅だけです。

テストの残りの議論をオフラインにして、電子メールまたはIMで追跡することができます。 最終的にテストをスケーリングし、この問題を「解決」したいと思います。 それは今一年の大部分の間私の脳の後ろにぶら下がっています。

Dreamhost VPSで無制限のTBを実行できるので、これは問題になりません。 現在、私は72GB /日を実行しており、さらに多くの処理を実行できます。 :)

私はポールに同意します。スクリプトローダーがいつどのように誰にとっても有益になるかについては、かなりの誤った情報があると思います。

最初の段落では、スクリプトローダーがパフォーマンスを向上させるのは「簡単」、「証明可能」、「間違いなく」と述べています。

私はしばらく前に@jashkenasと同様の仮定をし

https://github.com/SlexAxton/AssetRace

コードはすべてそこにあります。 明らかに、テスト対象者はそれほど多くありませんでしたが、結果は、このスクリプトローダーがconcatメソッドとほぼ同じ速度であり(同様のサイズの3ファイル並列ロードガイドラインに従っている)、最悪の場合、そのスクリプトを示しました-ローダーのバリエーションははるかに多く、エラーの範囲内で一般的に低速でした。 1つのブラウザのマシン上にある場合でも、自由にフォークして、私たちまたはその両方に勝るソリューションを見つけてください。

「誤った前提」については、h5bpは人々が自分のjsを連結することを前提としているためです。 h5bpは、連結と縮小を備えたスクリプトビルドツールを提供するため、この引数は完全に無効です。 したがって、並列読み込みはほとんどの場合、複数のスクリプトタグに勝るという議論は正しいかもしれませんが、h5bpが現在提供しているものよりも優れているわけではありません。 それがこの議論の文脈です。

最悪のシナリオは、yepnopeやlab.jsのようなものを取得し、それをスクリプトタグのポリフィルとして使用することだと思います。 その結果、(19個のJSファイルと34個のCSSファイルの)読み込みが遅くなるだけでなく、完全に気付かないような多数の下位互換性と上位互換性の問題が発生します。

_ボイラープレート_の最も賢明でパフォーマンスが高く互換性のあるデフォルトを人々に提供するという精神で、ビルドツールは3つすべてを確実にするためにさらに進んでいると思います。

@slexaxton

...結果は、このスクリプトローダーがconcatメソッドとほぼ同じ速度であることを示しています(同様のサイズの3ファイル並列ロードガイドラインに従います)...

私はあなたがまとめたテストを見てみる時間を喜んで見つけます。 皆さんはあなたが何をしているのか知っていると確信しているので、あなたのテストは有効で正しいと確信しています。

OTOH、私には矛盾した証拠がたくさんあります。 並列スクリプトの読み込みが無駄であるか、ほとんどのサイトにとって役に立たないことを示唆する説得力のあるものを見たことがあれば、ずっと前にLABjsであるクレイジーなタイムシンクを放棄していたでしょう。

LABjsを人々に提供するのを手伝ってから2年間、LABjsがスクリプトタグの代替よりも遅い状況を見つけたことがないことは、100%確実に言えます。 それが_私に_起こったことはゼロ回です。 人々があまり利益を見ていないと言ったことが何度かありました。 人々が100以上のファイルをロードしていたことが何度かあったので、その多くの接続のクレイジーなオーバーヘッドは、他の方法で見たかもしれない利点を一掃しました。 しかし、LABjsによってサイトが遅くなったと誰かに言われたことは一度もありません。

私は文字通り、50以上の異なるサイトがスクリプトタグからLABjsに移行するのを手伝ってきましたが、間違いなくサイトのパフォーマンスがすぐに向上しました。 取り組みの早い段階で、私が支援したサイトを7つか8つサンプリングしましたが、それらを合わせると、読み込み速度が平均で約15%向上しました。 私が管理している4つまたは5つのサイトでは、もちろんLABjsを実装し、すぐに3倍もの読み込み速度が見られました。

もちろん、LABjsが最初にリリースされたときは、ブラウザーがスクリプトを並行してロードするのは最先端でした(これを行っていたのはごくわずかでした)。 そのため、そのときの利益は大きく、目に見えていました。 現在、ほぼすべてのブラウザーが並列ロードを実行しているため、ゲインはそれほど劇的ではなくなりました。

ただし、否定できないことの1つは、スクリプトタグをロードするためにブラウザがすべてDOM対応イベントをブロックすることです。 document.write()を見つける可能性があるため、彼らは_しなければなりません_。 並列スクリプトの読み込みは、基本的に「ブラウザ、document.writeを処理する必要がないことを約束しているので、先に進んでページを進めてください」と言っています。

このデッキのスライド10にある2つの図を見てください。

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

青い線の配置を比較します(DOM対応)。 これは、全体的なページの読み込み時間(またはすべてのアセットの読み込みを完了する時間)が改善されていなくても、知覚パフォーマンス(UX)が大幅に向上します。

... h5bpはスクリプトビルドツールを提供します...

ここでの誤った仮定は、h5bpがこのツールを提供しているという理由だけで、h5bpのすべての(またはほとんどの)ユーザーがそれを使用できるということです。 h5bpのユーザーの100%がそれを使用しているとしても、それは、h5bpがインターネットのロングテールに展開された場合、すべてのユーザーがその連結ツールを使用するという意味ではありません。 誰かがそれを使用するのを簡単に妨げることができる他の多くの要因があります。 誰かがスクリプトタグの使用から並列スクリプトローダーの使用に移行できない理由は_ごくわずか_です。

そのため、並列スクリプトの読み込みは、インターネットのロングテールに幅広い魅力を提供します。 スクリプトの読み込みの最適化を使用しないサイトの大多数にとっては、何もない状態から何かに移行する方が簡単であり、何かがパフォーマンスの向上をもたらします。 これらのロングテールサイトの中には、月額6ドルの安価な、大量共有ホスティング、非CDNのWebホスティング環境で自動スクリプトビルドツールに労力を費やす(または実験するスキルを持っている)ものはほとんどありません。

最悪のシナリオは、yepnopeやlab.jsのようなものを取得し、それをスクリプトタグのポリフィルとして使用することだと思います。 それは絶対にロードが遅くなるでしょう...

私はこの声明にこれ以上反対することはできませんでした。 LABjsは、スクリプトタグポリフィルとして特別に設計されています。 また、通常のスクリプトタグに対するLABjsの改善(当面はスクリプト連結を無視)は十分に確立されており、真剣に反論されることはありません。 LABjsを使用しているほとんどの(または多くの)サイトがスクリプトタグに戻ったほうがよいという証拠がある場合は、共有してください。

並列スクリプトの読み込みによって、ブラウザがスクリプトタグを使用して実行できるよりも読み込みが遅くなる理由はまったくありません。 それは意味がありません。 また、上記で確立したように、スクリプトタグは常にDOM対応をブロックしますが、並列スクリプトの読み込みはブロックしません。

彼らが完全に気付かないであろう多くの後方互換性と前方互換性の問題を導入します。

どのような互換性の問題について話しているのですか? LABjsのブラウザサポートマトリックスには、地球上のすべてのWebブラウザの大部分が含まれています。 それが侵入するブラウザのクレイジーな小さな断片は、それが明らかに利点を持っている多数のブラウザによってはるかに上回っています。

LABjs 1.xには、キャッシュのプリロードなど、多くのクレイジーなハックが含まれていました。これは、実際にブラウザの破損の主な懸念事項でした。 LABjs 2.xはそれを完全に逆さまにし、すべての場合に並列ロードに信頼性の高い標準化されたアプローチを使用し、古いWebkitブラウザーのハックにフォールバックするだけです。 さらに、LABjs 2.xには、「実際のプリロード」のような、間もなく登場するスクリプトロード手法(できればすぐに標準化される)の機能テストのチェックがすでに含まれています。

他のスクリプトローダーについて明確に話すことはできません-多くの人がまだハックを使用していることを知っています-しかし、LABjsに関しては、これは明らかに誤解を招くと思うので、下位互換性または下位互換性の問題を引き起こすという主張に戸惑います請求。

LABjsが実際にスクリプトタグポリフィルになる理由について少し詳しく説明します...

  1. 古いブラウザは、並列読み込みで処理できるスクリプトタグの読み込みの処理が明らかに劣っています。 ページの読み込み時間が約3倍に改善されたのは、これらの「古いブラウザ」(2年前にLABjsがリリースされたときの最新/最高)でした。 ほぼ定義上、LABjsは、それ自体をサポートしていないブラウザに機能(つまり、並列ロードのパフォーマンス)をもたらすため、より優れたスクリプトタグポリフィルになります。
  2. 新しいブラウザの方が明らかに優れています。 しかし、スクリプトローダーの利点を完全に排除しているわけではありません。 スクリプトタグの読み込みが完了している間、v12(v13で最終的に修正されたようです)と同じくらい最近のchromeはまだ画像の読み込みをブロックしていました。 IE、Firefox、Chromeの最新版を使用しても、スクリプトが動的に読み込まれている間はすべてDOM対応をブロックします。これは、 document.write()が潜んでいる可能性があると悲観的に想定する必要があるためです。

したがって、新しいブラウザーの場合、LABjsは、スクリプトタグでは不可能な方法で、ブラウザーに「非DOM対応のブロッキングスクリプトの読み込み」をもたらすという意味で「ポリフィル」です。 並列スクリプトローダーのない最新のブラウザでこれを行うための唯一の可能な方法は、 deferスクリプトタグを使用することです( asyncは順序が保持されないため、明らかに機能しません) 。 ただし、 deferにはいくつかの癖があり、そのサポートは実行可能なソリューションとして十分に普及していません(非延期のフォールバックはパフォーマンスが悪いです)。 したがって、最も基本的なケースでは、LABjsはスクリプトタグdeferのパフォーマンス特性のポリフィルであると言えます(正確ではありませんが)。

正直なところ、スクリプト読み込みオブジェクトの標準を申請する必要があると思います。 キャッシュをトリガーするためにtext / javascriptとは異なるタイプのスクリプトタグを作成する必要があります(さらに悪いことに、オブジェクトタグや画像オブジェクト、または人気のあるブラウザの新しいバージョンが必要とするものを使用する)は、何の役にも立ちません。パフォーマンスは、変数が多すぎると異なります。 まだdomノード挿入を使用してスタイルシートをロードしていることは理解できますが(ただし、これは順序によるものです)、スクリプトに関しては、もはや意味がないと思います(googleがほとんどの場合document.writeの使用を停止することを望みます)彼らのスクリプトですが、それはまったく別の話です)。

また、ここではスクリプトローダーに関する最大のポイントを見逃していると思います。すべてを事前にロードするのではなく、オンデマンドでjsコードをロードできるようにすることです(すべてがキャッシュにある場合でも、解析と初期化には時間がかかり、かなりの時間がかかる可能性があります)連結されたスクリプトの量が少なくないので醜いです)。 UIインタラクションの後に待機時間を設けることは、起動時にブラウザを少しでも「ハング」させるよりもはるかに問題が少ないです(DOMは問題なく準備できているかもしれませんが、ページを拡張するコードがあれば何が良いでしょうそして、追加の反復はまだ実行されていません。一部のサイトがすぐに読み込まれ、何か不格好なことが発生することに気づいたことがありますか?)。

したがって、厳密なパフォーマンス測定はすべて問題なく、ダンディですが、知覚されるパフォーマンスが究極の目標であると私は思います...そして悲しいことに、推定/最適化/計算ははるかに簡単ではありません。

これは激しいです。

@ jaubourg--

正直なところ、スクリプト読み込みオブジェクトの標準を申請する必要があると思います。

標準/仕様とブラウザがどのように私たちにより良いスクリプトローディング技術を与えることができるかに関して、多くの嘆願が起こっています。 このカテゴリで数年ぶりに大きな勝利を収めたのは、2月に採用され、現在リリースされているすべての主要なブラウザに搭載されている「ordered async」( async=false

私が現在イアン・ヒックソンと現在進行中の議論である次の議論は、私が「本当のプリロード」と呼んでいるものです。 私の意見では、「実際のプリロード」(IEはv4以降ですでにサポートしています)は、ほぼすべてのスクリプトロードシナリオを簡単に解決できる「銀の弾丸」に最も近いものです。 私はまだ、このような標準化されたものが見られることを非常に楽観視しています。

詳細については、このwikiを参照してください: http

キャッシュをトリガーするためにtext / javascriptとは異なるタイプのスクリプトタグを作成する必要があります(さらに悪いことに、オブジェクトタグや画像オブジェクト、または人気のあるブラウザの新しいバージョンが必要とするものを使用します)

これは「キャッシュプリロード」と呼ばれ、醜く恐ろしいハッキングとして認められています。 LABjsの方法では、v2以降、これを強調しなくなりました(古いWebkitのフォールバックとしてのみ使用されます)。 他のスクリプトローダーは、残念ながら、それを主要なロードメカニズムとして使用しています。 しかし、「キャッシュプリロード」の必要性の90%は、標準化されたハックではない「ordered async」で解決できるため、行儀の良いスクリプトローダーは「キャッシュプリロード」よりもそれを好むはずです。

したがって、「キャッシュのプリロード」はダメだということに同意しますが、そのようなハッキングを伴わないdocument.createElement("script")を使用するより良い方法があるので、これがブラウザのスクリプト要素に依存し続けることに反対する議論であることに同意しません。スクリプトの読み込み。 「実際のプリロード」を取得できれば、Script要素が必要なすべてのものになります。 私は正直にそれを信じています。

ここでは、スクリプトローダーに関する最大のポイントが欠けていると思います。それは、jsコードをオンデマンドでロードできるようにすることです。

これがスクリプトローダーがもたらす重要な利点であることに非常に同意します。 しかし、これは_this_スレッドでは一種の議論の余地があります。「スクリプト連結」の人々は、スクリプトをロードしないとユースケースを解決できないため、2つを「比較」する意味がありません。 「スクリプトコンキャット」の支持者として「問題ありません。そのユースケースは気にしません」と言うことはできますが、「XYZを使用してそのユースケースをより適切に提供できる」とは言えません。

知覚されるパフォーマンスは巨大で重要です、私は同意します。 オンデマンドの読み込みは、それを実現するための大きな部分です。 オンデマンドロードは、必要なものだけをダウンロードすると実際にダウンロードされることが少なくなる傾向があるため、実際の実際のパフォーマンス(知覚だけでなく)も向上します(作成したコードの100%を必要とするページアクセスはほとんどありません)。

知覚されたパフォーマンスは、私が上記のDOM対応の議論を提唱する理由でもあります。 ユーザーがページを操作できるように「感じる」速度は、ページが実際に読み込まれる速度に関係なく、ページがどれだけ速いかを考える上で_非常に_重要であるためです。 これは、多くのユーザー調査によって確立された事実です。

@getifyによる情熱的で長いコメントが大好きです
カイル..。

私が何らかの形で研究に貢献できれば、私は_大好き_になります。
帯域幅(コスト)は問題ではないようですので、 @ getify 、前進するために何を提案しますか?
メール(aaron [at] aaronpeters [dot]またはtwitter(@aaronpeters))で私に連絡することを躊躇しないでください

@kyle

はい、プリロードに関するスクリプトタグの「拡張機能」の説明に従いましたが、実行可能なアプローチとして「スクリプトタグにさらに別の属性を追加する」アプローチを購入していません。 私はそれがxhr仕様に何をしたかを見てきました:私たちが最終的に得るわずかな利益に関して多くの複雑さ。

明らかなことは、動的挿入を行うとき(つまり、すでにjavascriptで行う場合)にプリロード動作のみが必要になることです。それでは、なぜまだスクリプトタグインジェクションを使用する必要があるのでしょうか。 タグをそこに保持したり、DOMノードとして使用したりするのではありません。これは、ドキュメントの構造とは関係のない目的を達成するための手段にすぎません。

私はそれらの線に沿った何かではるかに快適になるでしょう:

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

これは不思議に思うでしょう。 複数のスクリプト読み込みイベントに「参加」して、必要な順序でそれらのスクリプトを実行するのは簡単です。 また、それをさらに一般的にするDOMの存在を意味するものでもありません。 スクリプトタグの挿入をできるだけ早く回避したいと思います。 その上、私たち全員が知っているトリックを使用してこれをポリフィルするのは簡単です。 また、完全なrequireシステムよりもはるかに負担が少なくなります(ただし、ブラウザーに限定されないrequireシステムの構築ブリックになる可能性があります)。

そうは言っても、私は知覚されるパフォーマンスについて100%同意します。「すべてをまとめてコンパクトにしましょう」というマントラは、私の好みにはあまりにもぼやけてしまうような信念になりつつあるため、指摘したいと思います;)

fwiw、 deferは、IE4 +、Chrome、Safari、およびFF3.5以降でサポートされています。 Operaではサポートされていません。

つまり、ユーザーの98.5%がすでにscript@deferサポートしています。

@getify

ただし、 deferにはいくつかの癖があります。

詳細plz? 私はこれについて何も見ていません

deferを使用したスクリプトは、DOM Readyイベントが発生する前または後に実行されますか?

実行順序はすべてのブラウザで保持されますか?

execの順序と、外部スクリプトとインラインスクリプトの結合はどうですか?

@ paulirish--

... 98.5%のユーザーがすでにscript @deferをサポートしています。

その多くのブラウザでサポートが提供されている可能性がありますが、それはその多くのブラウザで信頼できるという意味ではありません。 それが私が意味したことです。 (下記参照)

ただし、deferにはいくつかの癖があります。

詳細plz? 私はこれについて何も見ていません

Lemme参照... IIRC:

  1. 動的スクリプト要素での遅延のサポートは、どのブラウザでも定義またはサポートされていません...マークアップのスクリプトタグに対してのみ機能します。 これは、「オンデマンド」または「遅延読み込み」の手法やユースケースにはまったく役に立たないことを意味します。
  2. 一部のブラウザでは、延期されたスクリプトがDOM対応の起動直前に実行を開始する場合もあれば、DOM対応の起動直後に発生する場合もあると思います。 その詳細については、さらに掘り下げる必要があります。
  3. 外部リソースを参照するスクリプトタグで使用されるdeferは、インラインコードを含むスクリプトタグで指定されたdeferとは異なる動作をしました。 つまり、両方のタイプのスクリプトを延期し、それらを正しい順序で実行することが保証されませんでした。
  4. defer document.write()ステートメントによって書き出されたスクリプトタグのdeferは、 deferマークアップのスクリプトタグとは異なります。

これらの問題について、すぐに使える詳細はたくさんありません。 約2年前(LABjsの前)にdeferを使おうとして、クロスブラウザテストで十分な数に遭遇したことを思い出します。基本的にそれを脇に置いて以来、あまり再訪していません。


また、 deferは、LABjs(および他の並列ローダー)が提供するものと実際には同じではないことも指摘しておく必要があります。 私はそれがそれのようなものにすぎないという警告とともに上で言った。 実際、並列スクリプトのロードが提供するのは(少なくとも、LABjsの部分では)「順序付き非同期」であり、マークアップだけで実現する方法はまったくありません。

「orderedasync」と「defer」の違いは、「ordered async」は最初に要求されたスクリプトの読み込みが完了するとすぐに実行を開始するのに対し、「defer」は「DOM対応」になるまで待機してから実行を開始することです。 マークアップがほとんどなく、他のブロッキングマークアップ呼び出し(他のスクリプトタグのような)がない単純なページの場合、この違いはわずかです。 ただし、リソースが多いページの場合、スクリプトの実行を開始できるタイミングは大幅に異なる可能性があります。

ですから、正直に言って、 deferの接線をあまり外さないようにしたいと思います。実際には、並列スクリプトの読み込みが提供するものとの大きな比較ではないからです。 これはマークアップの最も近い例でした-私が得ていた実行順序付きの動作を説明するために使用できるのはそれだけです。 私はおそらくdefer持ち出すべきではなかったでしょう-ただ議論を混乱させます。

上から言い換えると、「最近のブラウザでは、LABjsは「順序付き非同期」動作の一種の「ポリフィル」であり、マークアップで選択することはできません。どのブラウザでものみです。」

私は「順序付けられた非同期」が好きです、それは良いフレーズです。

Kyle> afaik、deferを使用したスクリプトは、domreadyの前であっても、onloadの前に実行されます。
async属性を持つスクリプトは、できるだけ早く実行され、_always_ _before_ onloadを実行しますが、必ずしもdomreadyの前に実行されるとは限りません。

@ aaronpeters--
少し軌道に乗っていないのではないかと思います。 これが私がそれを理解する方法です:

asyncスクリプト(マークアップまたは動的に作成されたもの)は、できるだけ早く実行されます。つまり、DOM対応の前後のいつでも実行されます。 言い換えると、 asyncスクリプトは何も待たないようにする必要があります(JSエンジンの可用性自体を除く)。 ただし、 window.onload前に要求された場合、ほとんどすべてのブラウザで、ロードして実行されるまでwindow.onloadイベントを「保留」します。 asyncスクリプトがwindow.onload保持せず、正確な詳細を覚えていないという文書化されたケースがあったと思います。

deferは、具体的には次のことを意味します。DOMの準備が整うまで待ちます。 さらに、 defer設定されたすべてのスクリプトの「キュー」があり、キューはDOM対応になるまで処理されません。つまり、すべてのスクリプトはDOM対応後(つまり、後)に厳密に実行する必要があります。 DOMは準備ができており、正確には解析が終了しています)。 ただし、さらに遅延する可能性があります(読み込みが遅い場合)。 ただし、 window.onloadを保持する必要があります。 IEの一部のバージョンでは、この理論の実際の実践が少しあいまいだったことを、漠然とした過去の記憶から思い出します。

@getify

このスレッドをこれ以上脱線させたくなかったので、スクリプトのプリロードと提案についての私の考えをWHATWGページに投稿しました: http

asyncスクリプト(マークアップまたは動的に作成されたもの)は、できるだけ早く実行されます。つまり、DOM対応の前後のいつでも実行されます。 言い換えると、 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)、あなたの考えとあなたのテストページへのリンクを共有するためのtxs。

質問:なぜ「head」ページの「<script>」タグにLABjsをロードするのですか? それは間違っているようです。

@artzstudioも、古いバージョンのLABjsを使用しています。 それは意図的なものですか? もしそうなら、なぜですか?

@aaronpeters AOLには、 それらを先頭に置く必要があるため、ローダーライブラリがユースケースに含まれます。 また、スクリプトが下部にある場合、一部のウィジェットにFOUCの問題があるため、依存関係の読み込みが早いほど(jQueryなど)、より適切です。

意図的なものではありませんでした。このテストは数か月前のものです。 機会があればライブラリを更新します。

参考までに(これがいくらか興味深い/関連性があることを願っています)、Webpagetest.orgでいくつかのテストを実行して、 @ artzstudioテストページの一部を読み込んだときにIE8で何が起こるかを確認しました。
スクリプトタグ: http
うん: 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のファイルサイズが大きくなると影響があります
  • 前述のように、スクリプトタグページはLABjsをHEADにロードし(意味がありません)、もちろんそれは影響を及ぼします

これらの2つの理由から、私はYepnopeとLABjsのみを表示するビデオを作成しました。

私が興味深いと思うのは、レンダリングの開始時間がLABjsの方がはるかに優れていることです。 何故ですか? よりよく理解したいと思います。

閉会の辞:私は、YepnopeなどよりもLABjsを優先することを目的としてこれを投稿していません。 データを共有するだけ...

申し訳ありませんが、<script>テストでLABjsについてあなたが何を意味していたかわかります。 LABjsへのアップグレードとともに、修正されました。

@ artzstudio--

したがって、私はこれに対処するために独自のスクリプトローダーサイエンスプロジェクト(Boot.getJS)を開始しました。 アイデアは、すべてのスクリプトを並行してダウンロードし、何があっても、できるだけ早くそれらを順番に実行することです。

それで、これがLABjsが設計されており、非常にうまく機能していることを_正確に_知っていましたか(私がそう言う場合)? つまり、別のAPIが必要だったのでしょうか、それとも並列スクリプトの読み込み機能では不十分だったのでしょうか。


いずれにせよ、私はLABjsについて自慢するのが大好きですが、このスレッドを「見て、私のスクリプトローダーはXの方が優れている」というタイプの議論で行き詰まるのは効果的ではないと思います。 これらの議論は役に立ちますが、他の場所にあります。

結局、すべてのスクリプトローダーテクノロジは、いくつかの簡単なアイデアに要約されます。 その上にどのような種類のファンシーAPIを重ねても、どのようなユースケースに対応しても、技術は同じです。 最近は50種類のスクリプトローダーが必要ですが、実際には、技術面で異なるものはなく、APIが異なるだけです。 したがって、APIを比較することは、実際にはあまり関係のない議論です。

焦点を当てるべきなのは、現在ブラウザで利用できる基本的なスクリプト読み込みテクノロジを使用して、マークアップでスクリプトタグを使用する場合と比較して、ページ読み込みのパフォーマンスを向上させることができるかどうかです。 これは私の長年の前提であり、それは絶対に真実ですが、その前提はこのスレッドで疑問視されています。 したがって、タスク#1はその質問に答えることです。

スクリプトタグがスクリプトの読み込みよりも優れていることがわかった場合は、この狂気をすべて止めて、すべてのプロジェクトをシャットダウンできます。 しかし、そうではないと思います。 ;-)

タスク#2は、script-concatが常に並列ロードよりも優れているかどうかを確認することです。 繰り返しますが、私の前提(および私のテスト)は、すべてのファイルを1つに連結することは良いことを示していますが、その場合、その大きなファイルを2〜3のほぼ等しい部分にチャンクし、それらのチャンクを並列ロードする必要があります。 したがって、その理論も実際にテストする必要があります。

script-concatが常に最適であることがわかった場合でも、ほとんどのサイトが複数の場所からスクリプトをロードすることを考慮すると、スクリプトローダーは引き続き役立ちます(Google CDNのjquery、googleのgoogle analytics、facebook / twitter / g +ボタン、 NS)。 したがって、タスク#3として、concatが非常に優れているため、これらすべてのファイルの独自のコピーをホストし、独自のコードと一緒に連結する必要があるかどうかを判断する必要があります。

カイル、私の例のソースを表示して、LabJSをインストルメント化してページ上のすべてのスクリプトを順番に(チェーンの外でも)実行する方法を教えてください。 APIを読み間違えた可能性があります(Paulが言ったように、スクリプトローダーは難しいです、%-)。

2011年8月10日午前9: 09

@ artzstudio--

したがって、私はこれに対処するために独自のスクリプトローダーサイエンスプロジェクト(Boot.getJS)を開始しました。 アイデアは、すべてのスクリプトを並行してダウンロードし、何があっても、できるだけ早くそれらを順番に実行することです。

それで、これがLABjsが設計されており、非常にうまく機能していることを_正確に_知っていましたか(私がそう言う場合)? つまり、別のAPIが必要だったのでしょうか、それとも並列スクリプトの読み込み機能では不十分だったのでしょうか。


いずれにせよ、私はLABjsについて自慢するのが大好きですが、このスレッドを「見て、私のスクリプトローダーはXの方が優れている」というタイプの議論で行き詰まるのは効果的ではないと思います。 これらの議論は役に立ちますが、他の場所にあります。

結局、すべてのスクリプトローダーテクノロジは、いくつかの簡単なアイデアに要約されます。 その上にどのような種類のファンシーAPIを重ねても、どのようなユースケースに対応しても、技術は同じです。 最近は50種類のスクリプトローダーが必要ですが、実際には、技術面で異なるものはなく、APIが異なるだけです。 したがって、APIを比較することは、実際にはあまり関係のない議論です。

焦点を当てるべきなのは、現在ブラウザで利用できる基本的なスクリプト読み込みテクノロジを使用して、マークアップでスクリプトタグを使用する場合と比較して、ページ読み込みのパフォーマンスを向上させることができるかどうかです。 これは私の長年の前提であり、それは絶対に真実ですが、その前提はこのスレッドで疑問視されています。 したがって、タスク#1はその質問に答えることです。

スクリプトタグがスクリプトの読み込みよりも優れていることがわかった場合は、この狂気をすべて止めて、すべてのプロジェクトをシャットダウンできます。 しかし、そうではないと思います。 ;-)

タスク#2は、script-concatが常に並列ロードよりも優れているかどうかを確認することです。 繰り返しますが、私の前提(および私のテスト)は、すべてのファイルを1つに連結することは良いことを示していますが、その場合、その大きなファイルを2〜3のほぼ等しい部分にチャンクし、それらのチャンクを並列ロードする必要があります。 したがって、その理論も実際にテストする必要があります。

script-concatが常に最適であることがわかった場合でも、ほとんどのサイトが複数の場所からスクリプトをロードすることを考慮すると、スクリプトローダーは引き続き役立ちます(Google CDNのjquery、googleのgoogle analytics、facebook / twitter / g +ボタン、 NS)。 したがって、タスク#3として、concatが非常に優れているため、これらすべてのファイルの独自のコピーをホストし、独自のコードと一緒に連結する必要があるかどうかを判断する必要があります。

このメールに直接返信するか、GitHubで表示してください。
https://github.com/paulirish/html5-boilerplate/issues/28#issuecomment -1772315

物理学はコンキャットが最高だと言うでしょう。 すべての新しいHTTP接続は、CDNからの最悪のシナリオでは、別のスロースタート+100ミリ秒の税金です。

ただし、ドキュメントに関する真実は、ドキュメントが非常に長くなる可能性があるということです。 そのため、ヘッドに1つのBFJSファイルをロードすると、モジュールの初期化が不必要に遅くなる可能性があります。 最後にロードすると、迷惑なFOUCが発生する可能性があります。 大きなファイルにはモバイルの影響がある可能性があります: http

これが、Soudersの「ペイロードの分割」ルール(http://oreilly.com/server-administration/excerpts/9780596522315/splitting-the-initial-payload.html)の背後にある動機だと思います。 おそらくもっと速いこともする必要があります。

そして残念ながら、これが要約すると、「それは依存する」種類の答えであり、この問題は私たち全員を楽しませ続けるのに十分興味深いものになります。

getJS呼び出しがキューに入れられ、設定された時間間隔で定期的に連結され、モジュールの依存関係レベルで連結される(たとえば、一度に1つずつロードする代わりに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リクエストは読み込みパフォーマンスを損なうだけであり、画像などのページ上の他のアセットと競合する必要があることがわかります。 しかし、これはすべて以前に何度も言われています...

LABjs

Vanilla

スクリプトを少しずつロードすることについては反論が予想されますが、これはスクリプトのロード手法とは完全に直交しているため、説明から除外してください。

ぜひ、狂気を止めてください。

@jashkenasフル、100%ack。 スクリプトローダーは、オーバーヘッドと複雑さ、および単一障害点を追加するだけです。 単一のサーバー連結ファイルは、純粋な転送時間とJavaScriptインタープリターの効率の両方の観点から、高速(est)で読み込まれます。また、ボーナスとして、ファイルが1つしかない場合はgzipがうまく機能します。

言うまでもなく、LABjsバージョンは(バニラページと比較して)ブラウザでの読み込みが_時々_速くなりますが、一貫性はありません。 また、 onloadは常に起動するとは限りませんが、これは奇妙に思えます。

はい、gzippingを使用すると、HTTPリクエストを減らして、全体的なメリットをさらに高めることができます。

そして、これはドグマに関するものではありません。アプリ全体の_single_ JSファイルである必要はありません。 defer 2つまたは3つは、後でロードする場合と同様に、きめ細かいキャッシュに適しています。

Google Page Speedチームによる調査:

http://pagespeed-velocity2011.appspot.com/#8スライド8〜14を参照してください。これにより、議論がより不確定になります。


私はまだスクリプト@defer属性に熱心であり、独自のバリエーションのパフォーマンステストに何時間も/日を費やす予定がない限り、これが賢明な基本的なデフォルトだと思います。

@miketaylr :はい、全体的な感触を得るために、各ページを何度もシフトリフレッシュしてください。 S3のレイテンシーと画像の読み込みにより、物事は少し予測不可能になります。実際のアプリのように動作します。

さて、labjsは、shift-refreshを使用したり、要素がキャッシュされている場合でも、ブラウザー(Safari 5.1)で_常に_最も高速にロードされます。

もちろん、連結せずにスクリプトローダーを使用すると、連結されたスクリプトタグよりも遅くなります。 そのため、人々(YUI、requireJS)は、要求に応じてそれらを連結する連結ファイルとサービスをロードするスクリプトローダーを作成しました(https://github.com/rgrove/combohandler)。

この議論は意味がありません。 スクリプトローダーは、特にユーザーの操作後にオンデマンドでスクリプトをロードするためのものです。たとえば、「ログイン」ボタンをクリックしたときにダイアログとフォームの検証の背後にあるロジックをロードします。

@jashkenas@madrobbyが物事を単純化しすぎているという卑劣な疑いがあります。
スティーブは、並列ダウンロードには、さまざまなブロッキングの問題とブラウザーにいくつかの利点がある

私の元の投稿でそれが明確でなかった場合。 私は(jdaltonと)、特別な注意を必要とする高度にテストされた特定の環境でのスクリプトローダーの利点がかなりあることに同意する傾向があります。 私はそれが適切なデフォルトではないと思います。

私は@jdaltonに同意し

また、 @ getifyは、すべてのスクリプトローダーが実際に同じ技術を使用しているふりをしているので、情報が非常に少ないステートメントです。

それが価値があるもののために...
これ

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

これより良いです

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

それが非ブロッキングであるという1つの主な理由のために。 したがって、後続のイメージとCSSファイルは、そのファイルが後者のバージョンでダウンロードされるまで待機する必要があります。 前者は非同期です—これは、スクリプトローダーを使用するかどうかに関係なく、誰もが知っている必要があります。

re:「すべてのスクリプトローダーが実際に同じ技術を使用しているふりをすることは、非常に情報に通じていないステートメントです。」

彼らが上記のようにそれをしていないのなら、彼らはそれを間違っているのです

完全に公平を期すために、 appendChildは支持されなくなりました...:D

ただし、そのテストケースをAssetRaceに追加しました

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

これにより、搭載時の射撃が速くなるため、ある程度のメリットが認識される可能性があります。 しかし、終了時間はほぼ同じです...

@ded:私たちは、ブロッキング無能な大型の話をしていない<script> 「によ<head> ...私たちが持つスクリプトタグの話をしている、ここでdeferまたはasync属性。 <body>の最後にロードされ、ブロックするものは何も残っていません。

@ jaubourg--

また、 @ getifyは、すべてのスクリプトローダーが実際に同じ技術を使用しているふりをしているので、情報が非常に少ないステートメントです。

これは、私が得ていたものの完全な誤った表現です。 実際、ほとんどのスクリプトローダーは、最高の技術を使用するという点で、私がすべきだと思うことを行っていません(そして、LABjsは現在そうなっています)。 私の言いたいことは、それらすべてが最高の技術を使用したとしても、私たちが技術的にできることにはまだ有限の限界があるということでした。 LABjsが認識していない、または使用していない魔法の銀の弾丸を使用しているローダーは存在しないと確信しています。 何をするにしても、どのように数字をいじっても、光を光速より速く進めることはできません。

その下にある技術について議論することは(「ねえ、私のクールでより良いAPIを見てください」と言って)無意味です。 スクリプトの読み込みで最高の技術は、既知の有限量です(多くのローダーが無責任で、それを使用していない場合でも)。 私たちはより良い技術(私はそうです)を推し進めることができますが、ローダーで誰がより良いAPIを持っているかを議論することは、その目標には何の役にも立ちません。


このスレッドは、スクリプトタグがそれ自体で十分に優れているかどうか(延期の有無にかかわらず)、またはスクリプトローダーがパフォーマンスの向上に役立つかどうかを判断する上で最も重要なようです。 次に、concatが本当にスクリプトの読み込みのすべてであるかどうかを把握する必要があります。

また、スクリプトローダーには、マークアップスクリプトタグでは実行できない他のすべてのユースケース(オンデマンド/遅延読み込みなど)があることも(このスレッドの)重要なポイントです。 繰り返しますが、それは基本的にこの時点で与えられているので、その事実を再確立しようとすることは無意味です。

NO U

ロードレイジ!

loaders make me rage

ここで元の投稿を表示します。

また、漫画のペニスに腹を立てている人/人:インターネットへようこそ! ここから旅

OK、いくつかのポイントを説明するために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では機能しません。 すぐに実行されます。 おっとっと。 ところで、これはバグではなく、仕様で具体的に規定されています。

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

LABjsテストは、 deferテストと比較して基本的に同じ(またはそれ以上の)パフォーマンス数値を取得しますが、スクリプトの終了後にインラインコードを実行することに失敗することはありません。

最新のブラウザ(Chrome 13、FF5など)でこれらのテストを数回試してください。 私にとって、LABjsは常にdeferテストとほぼ同じかそれ以上のパフォーマンスを示しました。 私のすべての試みで、LABjsのパフォーマンスがdeferテストよりも悪いことは見たことがありません。 古いブラウザ(FF3.5やIE7など)でこれらのテストを試してみると、スクリプトローダーが他のテストよりもかなりの量でパフォーマンスを上回っていることがわかります。

LABjsテストの数値は最新のブラウザーのdeferテストと似ていますが、 deferdefer ALLコードに使用できない場合は、これは大きな問題になります(のみ機能します)。外部ファイルを介してロードされるコードの場合)。 多くのサイトがスクリプトをロードしてから、ロードしたばかりのコードをアクティブ化/初期化するためのインラインコードを持っています。 deferは、これに対する解決策を提供しません。

したがって、 deferは、「一般的なスクリプトの読み込み」テクノロジとしては不適切です。 次善のオプションはスクリプトローダーです。

@getify

それはマイクロ最適化だけではありません...そして、はい、APIは重要であり、主にマイクロ(またはマクロ)最適化のために、基礎となる技術が持つ制限の種類を一般的によく示しています。 スクリプトをロードするだけではありません。 複雑な依存関係の管理、適切なサンドボックス化、実際の実際のモジュール性は、関心がないという理由だけで洗い流すものではありません。 何だと思う? これらは実際に人々が必要とするものであり、ページの読み込みパフォーマンスは静的スクリプトタグを使用してかなり良いレベルで達成できます。

最終的には、スクリプトタグの挿入がタスクに適切なツールではないことになります。実際にはそうではありませんでした。 非常に醜いハックです。 その意味で、あなたは実際により良い技術を求めているのではありません。私たちの誰もがまだ推測できない新しい種類の警告もっと求めているのです。 ちょっと考えて、最終的にクリックするかどうかを確認してください。

本当に腹立たしいのは、スクリプトをロードするための適切なネイティブのjavascript APIとは対照的に、スクリプトタグの挿入を支持して単一の引数をレイアウトすることを拒否することです。 あなたはただ全部を無視します。 しかし、私はあなたの手間を省きます:そこには議論があり

(さらに別のLabJS広告とは対照的に)私がインテリジェントな返信に十分な価値があると最終的に判断した場合は、私のブログでそうし、このスレッドをそのままにしておきましょう。 ありがとうございました。

@ jaubourg-
私はあなたの投稿を最後の夜に深く読みました。 私はそれに応じてブログ投稿を書くことを計画していました。その大部分は、あなたがそこで提示した良い考えを称賛し、褒め称えています。 残念ながら、あなたが提案していることは、W3CとWHATWGのディスカッションスレッドのメンバーによってすでにハッシュ化されています。 あなたはそのパーティーにかなり遅れています。

まったく新しいローダーAPIをサポートする人が何人かいましたが、それが最善の方法ではなかった理由について、いくつかの重要な反論がありました。 繰り返しになりますが、私はそのすべてを説明するのを助けるために、注意深くそして理にかなったブログ投稿であなたへの返答を書くことを計画していました。

残念ながら、ここに行ってそのようなディックにならなければなりません。 今では、その理由のあるブログ投稿は時間の無駄だと感じさせられます。 あなたは明らかに私がばかだと思っており、あなたが育てようとしていることを考えたことがありません。 昨年の大部分をスクリプトローダーテクノロジと、それを改善するための仕様とブラウザを取得する方法に完全に夢中になっているわけではないためです。 ええ、私はばかです。 私は明らかに、これまでスクリプトタグ以外のことを考えたことがありません。


ポール・アイリッシュとアレックス・セクストンが提起した特定の質問に焦点を当てるという目標は_this_スレッドの方が優れていると私が言った15回は聞いていないようです。 defer十分ですか? スクリプト連結は並列読み込みよりも優れていますか?

これらはより重要な質問です。

基盤となる「ローダー」テクノロジーが使用されているわけではありません。 基盤となるローダー技術が何であるかを議論するための、別のより良いフォーラムがあります。 わかりました。スクリプトタグが気に入らないのです。 罰金。 W3C / WHATWGリストに何十時間も費やして、Ianや他の人にあなたの話を聞いてもらいましょう。 彼らはたぶんあくびをして、「私たちはすでにそれをハッシュしました、去ってください」と言うでしょう。

@getify :ばかげたストローマンテストを作成しても、ポイントを獲得することはできません。 シーケンシャルスクリプトタグがページをブロックすることは誰もが知っています。 また、「延期された」スクリプトの前にインラインスクリプトブロックを実行しても、実際のサイトでは問題にならないこともわかっています。

誤解前を確認するためにテストする場合...あなたのテストは常にその誤解を確認しようとしています。 議論は、20個のスクリプトタグと20個のLABjsスクリプトのロードについては一度もありませんでした。 これは、JavaScriptを可能な限り少ないHTTPリクエストでインテリジェントにトリミング、連結、縮小、gzipし、ロードしてからキャッシュすることです。

一方では、信頼性が高く、ブラウザでサポートされ、実績のあるアプローチがあり、実際のページで明らかに優れたパフォーマンスを発揮します。 一方、ハッキングされた「テクノロジー」は、過去にブラウザーの更新後にそれを使用していたすべてのサイトを実際に破壊し、平均して明らかにパフォーマンスが低下し、速度のばらつきがはるかに大きくなっています。

それは簡単な選択です。

@ jashkenas--

また、「延期された」スクリプトの前にインラインスクリプトブロックを実行しても、実際のサイトでは問題にならないこともわかっています。

ええと...インターネット上のすべてのサイトの約98%でビューソースを実行していないと思います。実際には、マークアップでインラインスクリプトブロックを使用して、以前にロードしたコードを実行/初期化します(ブロッキング)スクリプトタグ呼び出し。

@paulirishが、 deferで十分であり、スクリプトローダーが不要であると示唆している場合、実際にはdefer不十分である理由を指摘することが重要だと思います。

あなたはあなたがコントロールするいくつかのニッチなサイトだけを気にするかもしれません、それはあなたがビルドプロセスなどについて高度に最適化する完全な能力を持っています。半ダースのスクリプトタグ(そのうちのいくつかはインラインスクリプトブロックです!)を使用します。ここで、半ダースの$LAB.script()呼び出しを使用すると、実際にはパフォーマンスが向上する可能性があります。 それがLABjsが常に考えていたものです。 それがあなたが気にかけているものではないからといって、それが関連性がないという意味ではありません。

議論は、20個のスクリプトタグと20個のLABjsスクリプトのロードについては一度もありませんでした。

このスレッドでの議論は、3〜4個のスクリプトタグ( defer有無にかかわらず)が、並列スクリプトローダーを使用して動的にロードされる3〜4個のスクリプトよりもパフォーマンスが悪いか、同じか、または優れているかについてです。 私の「ばかげたストローマンテスト」は、実際にはそれを正確にテストすることを目的としています。

私の経験では、スクリプトローダーはページの読み込み時間を何ミリ秒も短縮します。 しかし、私たちは皆、ここでのポイントを逃したと思います。 JavaScriptにはいくつかの大きな問題があります。

  • インポートステートメントがないため、コードをモジュール方式で整理するのが困難です
  • すべての名前空間に注意を払わない限り、グローバル変数が衝突します。
  • スクリプトの依存関係を明確に確認する方法はありません

RequireJSは読み込みが速いので使用しませんが、それは素晴らしい副作用です。 NodeJSの場合と同じように、JSアプリを小さなモジュールに整理できるように使用しています。 各モジュールはその依存関係を明確にリストし、サンドボックスパターンを使用してグローバル名前空間をクリーンに保ちます。 モジュール(およびそれらの依存関係)は、事前にロードするか、オンデマンドでロードするか(たとえば、ユーザーのクリックで)、遅延ロードすることができます。 これらのテクニックを使用して、パフォーマンスを実際に微調整できます。 また、RequireJSには、すべての依存関係を1つ(または少数)のgzip対応ファイルに結合して展開するためのビルドツールが付属しています。 これらの3つの問題を解決することは、私にとって大きな勝利です。

これらの問題を解決しないスクリプトローダーの使用について人々が議論する理由がわかります。 パフォーマンスが唯一のポイントであり、議論の余地がある場合は、確かに。 しかし、RequireJSのようなAMDモジュールローダーを使用すると、議論は無関係になります。 モジュールはJavaScriptの未来です。 MozillaのDaveHermanは、AppleとGoogleの取締役会メンバーと協力して、言語自体にネイティブモジュールを追加

@getify

人々があなたを他の人と違ったやり方で扱うことを期待することはできません。 ひいきにすることはまともな反応を得るための賢い方法ではありません(そして神はあなたがひいきにしています)そして私が私のブログ投稿で言ったように、私はあなたがばかだとは思いません、私はあなたが夢中になっていると思います(あなたが言うあなた自身ところで)そしてそれがあなたの判断を深刻に損なうこと。 私のブログ投稿で述べたように、この問題を処理するのはW3CまたはWHATWGではなく、EcmaScript自体です。これはブラウザーの問題ではなく、言語の問題です。 さて、あなたがしたくないのであれば、この返事をしないでください、それはあなたの特権です。

たぶん私は厳しいものとして来ましたが、私は自分が信じていることを守るだけです。

このスレッドの購読を解除して、もうコメントします。 @paulirishと@SlexAxtonを

@getify

あなたはあなたが持っているあなたがコントロールするいくつかのニッチなサイトだけを気にするかもしれません
ビルドプロセスなどについて高度に最適化される完全な機能。
他の手は、のロングテールサイトでのパフォーマンスの向上を支援することに注意してください
インターネット、半ダースのスクリプトタグを持つもの(それらのいくつかはインラインスクリプト
ブロック!)、ここで、半ダースの$ LAB.script()呼び出しを使用すると、実際には可能性が高くなります
パフォーマンスを向上させます。 それがLABjsが常に考えていたものです。 理由だけで
それはあなたが気にしていることではありません、それが関連性がないという意味ではありません。

LABjsが、平凡なサイトの読み込みをわずかに少なくすることを目的としている場合...それは高貴な目標だと思います。 しかし、読み込みの遅いWebサイトを真剣に利用し、可能な限り高速に読み込む場合は、LABjsで許可されるよりも文字通り数秒速くなる可能性があります。その場合は、心を開いて、より簡単で壊れにくいことを認めてください。テクニックもよりパフォーマンスが高いです。

このスレッドでの議論は、3〜4個のスクリプトタグ(延期の有無にかかわらず)についてです。
を使用して動的にロードされた3〜4個のスクリプトよりもパフォーマンスが悪い、同じ、または優れている
並列スクリプトローダー。 私の「ばかげたストローマンテスト」は、実際には
正確にそれをテストします。

このスレッドでの議論は、JavaScriptをできるだけ速くロードして実行するWebサイトを構築する方法についてです。 スネークオイルをクライアントに販売し、それをWeb開発者に宣伝することは、両方にとって不利益です。

レイテンシーはインターネット上に存在します。 JSを連結、縮小、gzipで圧縮し、ページの下部にできるだけ少ないHTTPリクエストでロードします。 言っ途切れる。

@ jashkenas--

LABjsが、平凡なサイトの読み込みをわずかに少なくすることを目的としている場合...それは高貴な目標だと思います

過去2年間に私が個人的に知っているサイトは何百もあり、スクリプトタグを$LAB.script()呼び出しに置き換えるだけで、全体的にパフォーマンスが向上しました(大幅なものもあれば、控えめなものもあります)。

さまざまな業界(eコマース、不動産など)のサイトのパフォーマンスを向上させることに焦点を当てた記事が書かれています(パフォーマンスが向上するとコンバージョンが増えるため)。彼らはスクリプトタグを$ LAB呼び出しに置き換え、それらのコメントスレッドの多くの人々は、それが彼らを助けたと肯定的に答えました。

それらの記事に「OK、パフォーマンスを向上させるために必要なことは、gzipを理解し、rubyまたはnode.jsをインストールして、自動ビルドプロセスを実行できるサーバー管理者を雇うことです......」と書かれていました。それらの記事を読むことは、それを別の考えを与えることなく、釉薬をかけて去っていただろう。 しかし、「ねえ、<script>をscript()に置き換えて」は、彼らが理解して接続するのに非常に簡単なメッセージだったと思います。

私がLABjsに求めていたのは、誰かが簡単に立ち寄ってスクリプトタグを置き換えることができるシンプルなソリューションです。 個人的にサイトに相談して最適化を見つけることができれば、多くのサイトからより多くのパフォーマンスを引き出すことができると私は認識しています。 しかし、これはインターネットのロングテールに対して1人で行う能力をはるかに超えていることも認識しており、同様に、すべてのmom&popサイトに「自動ビルドシステムを入手して、gzipを使用していることを確認してください」と言っています。彼らに異星言語を話します。 OTOH、「ねえ、これらの3つのscriptタグを取得し、それらを3つのscript()呼び出しにします。それがどれほど簡単だったか見てください」と言うことは非常に成功しています。

結論として、LABjsでの私のアプローチは、ぶら下がっている果物を打つことでした。

それは、最適化へのより洗練されたアプローチが不可能であることを示唆するものではありません-それらは明らかに可能であり、私が相談する機会を得たとき、私は間違いなくそれらを探求します。 多くのWebにとって、それは彼らが喜んでまたは得ることができるよりも複雑で複雑であると言っているだけです。 そして、私は、それらのサイトが理解しやすい方法で改善できるように支援しようとしています。

@ jashkenas--

LABjsが許可するよりも文字通り数秒速くなる可能性があります。その場合は、心を開いて、より簡単で壊れにくい手法の方がパフォーマンスが高いことを認める必要があります。

LABjsがサイトの速度を大幅に低下させていることを示唆する確立された証拠はこれまでありませんでした。 それが多くのサイトを助けているという確立された証拠がたくさんあります。 だから私はこれを買わない-あなたが話しているのは、証拠にない事実を仮定した誤った前提である。

@paulirishは、 defer属性の問題を指摘する投稿を見つけました。
http://hacks.mozilla.org/2009/06/defer/

@jashkenasが言ったように、モバイルパフォーマンスの観点から見ると、3gネットワーク接続によって発生する遅延のために複数のhttpリクエストを行うよりも、連結、gzip、および1つのパッケージとして回線を介して送信するのが常に最善です。

httpリクエストを減らし、「キャッシング」を活用するためだけに、画像を文字列にbase64エンコードしてから、それらをkey:valueペアとしてlocalStorageに保存するインライン化技術を利用することで、多くの研究が行われてい//channel9.msdn.com/Events / MIX / MIX11 / RES04は、MicrosoftResearchの

httpリクエストを使用したモバイルパフォーマンスとユーザーエクスペリエンスへの影響に関するかなり優れたデッキは次のとおりです。http

私はRequireJSに取り組んで

1)JSが実行されるすべての場所でうまく機能するJSのモジュラーコードの方法を示します。
2)スクリプトをロードします。

「スクリプトのロード」の部分は、最初の目標を達成するために必要な部分です。 開発では、デバッグが難しくなり、行番号が一致しないため、すべてのスクリプトを連結することはお勧めできません。 スクリプトローダーを使用すると、JSAPIを使用してオンデマンドでコードを簡単に読み込むこともできます。 ウェブメールサイズのアプリの場合、これはパフォーマンスストーリーの必要な部分です。 ただし、通常、スクリプトを1つまたは少数の要求に連結することが、最適なデプロイメントオプションです。

しかし、requirejsの目標は、グローバルを思いとどまらせ、明示的な依存関係を促進する方法で他の人と共有できるモジュラーコードユニットを作成および参照する方法を示すために、shim / polyfill /何でもすることです。

これは、使用するAMDのAPIされた他の人たちと一緒に働いていたモジュラースクリプトローダーを作る(含まコンプライアンス・テストをJSでモジュール形式のいずれかの議論を知らせるために手助けすることを目標にし、)。 このアプローチは、実際の実装を行い、APIについて他の人と合意に達することにより、進歩を遂げる方法です。

特に、JSのネットワークの性質とWebドキュメント/アプリケーションとの関係を考えると、ローダープラグインAPIは、ES Harmonyモジュールで何らかの形でサポートできるはずです。私は、ESハーモニーモジュールのプロトタイピングに取り組んでい

パフォーマンスの人々のために

  • AMDをサポートするローダー( curlDojo 1.7loadrunner 、requirejs)にはいくつかの選択肢があり、展開用に行われる「1つのJSファイル内のすべてのスクリプト」の最適化に使用できる非常に小さなものでもあります。 したがって、コーディングのベストプラクティスを奨励しながら、優れたパフォーマンスを得ることができます。明示的な依存関係を使用して、グローバルを回避することで、コード共有が容易になります。
  • requirejsオプティマイザーはNodeで非常に高速に実行され、Rhinoで実行できます。 これはコマンドラインツールですが、最新のマスターブランチコードはノードで使用可能なモジュールとしてエクスポートするため、たとえば、オンザフライでビルドを実行できる

このチケットのコンテキストでは、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マシンでは、2つの間に一貫して3000の違いがあり、 @deferを支持しています。

ただし、Firefoxでのみテストしました。

@ espadrine--かなり奇妙です。 その底に到達したいと思います。 どのバージョンのFirefoxでテストしていますか? 結果のスクリーンショットを送ってもらえますか?

すべてのJSとCSSを連結して縮小し、HTMLページにインライン化するだけで完了します。 単一のHTTPリクエストFTW! :NS

真面目な話ですが、このコミュニティでは、アプリの読み込み方法だけでなく、もっと大きな問題に焦点を当てる必要があります。 おそらく、最も単純な方法(下部のスクリプトタグ)はおそらく十分に高速です。 優れたアプリを作成し、最後に読み込みパフォーマンスに対処するだけです。 他のことをすることは時期尚早に最適化されます。

このスレッドの人々は、AMDがJSコード編成のゴールドスタンダードであるべきだという一般的なコンセンサスがありますか? 他のオプションは実際には見たことがありませんが、ボイラープレートがコードの整理に人々を正しく設定するための素晴らしいスタートになることに同意します。

Firefox UX 8.0a1(2011-08-07)更新チャネル。

defer
LABjs

繰り返しますが、理由はわかりません。これはおそらく非常に具体的です。 LABjsは、おそらくレガシーブラウザに非常に適しています。

@getifyのテストページを笑い以外の目的で使用しないでください。 引用するには:

<script defer src = "http://labjs.xhr.me/dev/test_suite/testscript1.php?_=4911710&delay=5"> <script defer src = "http://labjs.xhr.me/dev/test_suite /testscript2.php?_=6146431&delay=3 "> <script defer src =" http://labjs.xhr.me/dev/test_suite/testscript3.php?_=9499116&delay=1 ">

@getify 、実際のテストを行いたい場合は、 @ SlexAxtonのAssetRaceリポジトリをフォークしてLABjsバージョンを追加してください...または、実際のレイテンシでJavaScriptファイルの_real_を使用するテストページを作成してください。

また、JSを1つのスクリプトタグ( deferかどうか)に実際に連結していることを確認してください。 重要なのは、1つのHTTPリクエストで提供される同じコンテンツが、10のHTTPリクエストで提供される同じコンテンツよりも優れているということです。

LABjsが大幅に優れていることを示唆する確立された証拠はこれまでありませんでした
すべてのサイトの速度を低下させます。 それが大いに役立っているという確立された証拠がたくさんあります
サイトの。 だから私はこれを買わない-あなたが話しているのは、仮定する誤った前提です
証拠にない事実。

で示したのは、LABjsが、画像、CSS、およびその他のアセットを使用して多くのHTTPリクエスト間でJSを競合させることにより、サイトの速度を大幅に低下させていることです。 @getify

ちなみに、AssetRaceリポジトリのテストページでさらに画像を取得するのが賢明だと思います。 しかし、それは確かに今のところ良いベースラインです。

@artzstudioがAMDローダーを

ゴールドスタンダードであるAMDモジュールは確かに意見です(私が共有するかもしれません)。 しかし、それを嫌い、他の解決策を提供する賢い人々(イェフダ・カッツとダン・ウェッブが頭に浮かぶ)はたくさんいます。

@danwrongのloadrunnerは、それがあなたのバッグでもある場合、両方を行うことができます: https

そこにはかなり良いものがいくつかあります。 JS以外の人にとっても、もう少し実用的かもしれません。 私は自分のものにAMDモジュールが好きですが、モジュールとして使用するライブラリの各バージョンの変換に時間を費やしたいと思う人は誰もいません。

@strobecorpは、AMDモジュールが必要とする多くの追加コードを必要としない独自のソリューションに取り組んでいることを知っています。

私はAMDをデフォルトにしたいと思っていますが、マルチライブラリ/ newbの観点からは、私が望むほど賢明ではないでしょう。

@ jashkenas--

@getifyのテストページを笑い以外の目的で使用しないでください。

あなたが礼儀正しくできないなら、私はあなたとこれ以上何も話し合うつもりはありません。 私は誠意を持って行動しています。 私は少し一般的な品位をいただければ幸いです。

@getify 、実際のテストを行いたい場合

私がやっていることは、なぜそんなにクレイジーで、笑い、そして無効なのかを説明してほしいと思います。 私はSteveSoudersから直接アプローチを取りました。彼は、彼のすべてのテストで、サーバータイミングを使用してスクリプトを制御し、テストの変動量を減らすことを提案しました。 それはまさに私がしていることです。

より制御されたテストは、有効なベースラインテストです。 それは確立された科学的実践です。 それは、実際のテストも役に立たないという意味ではありませんが、私を狙って「彼を笑ってください。彼はテストのやり方が違うので、ばかだと思います。行われるべきです。"

@SlexAxtonのAssetRaceリポジトリをフォークして、LABjsバージョンを追加してください。

喜んでそうします。 しかし、他のテストが無効であることに同意したからではありません。 私のテスト設定が無効である理由について、合理的でレベルの高い議論がある場合は、共有してください。 しかし、それについてそのようなお尻であることをやめなさい。

@ jashkenas--

重要なのは、1つのHTTPリクエストで提供される同じコンテンツが、10のHTTPリクエストで提供される同じコンテンツよりも優れているということです。

私はあなた(そして他の人たち)がこの議論がすべてconcat対not-concatについてどうあるべきかについてここで怒鳴り続けることを知っています。 スレッドのかなり前の方を読んだ場合、対処する必要のある2つの質問があることを認めました。 私に関する限り、2つの問題は正統です。 1つ目は、マークアップのスクリプトタグが、並列スクリプトローダーで使用される動的スクリプト要素と同等(またはそれ以上)であるかどうかです。 その質問は、私がまだテストで対処しようとしていることです。

まだ得られていない2番目の質問は、script-concatが常に優れているかどうかについてです。 あなたがすでにそれを確信していることは知っていますが、それがそれほど単純ではないことを示唆する反証があります。 その質問も徹底的にテストする必要があります。 しかし、それは私がこのスレッドで今解決しようとしていることではありません。

自分のやり方がより良い方法であると主張し続けることによって、あなたは議論全体を参加するのが楽しくなくなるだけです。 私がやろうとしているのは、これら2つの主要な質問のそれぞれについていくつかの証拠を系統的に確立することです。そうすれば、推測をやめて、より多くの情報を得ることができます。 あなたが私に同意しないので、私を怒らせようとするのではなく、なぜあなたが助けることができるものではないのですか?

deferテストとLABjsテストに関しては、IE9、FF8(毎晩)、およびChrome15(カナリア)で2つの直接のテストを簡単にスクリーンキャストでキャプチャしました。

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で十分ではないと思う理由の1つです。

仕様を読んでわかる限り、どちらの動作が正しいかはわかりません。 しかし、私はそれが明らかに風変わりでブラウザ間で一貫性がないことを知っています。

@getify私はジャークになろうとはしていません。 ご迷惑をおかけしましたことを心よりお詫び申し上げます。

当然のことながら、あなたが怒鳴っていると私は議論のポイントとして見ています...そして私がスネークオイルとして見ているものは、あなたは有益な前進として見ています。

2つの問題は確かに直交しています(元の投稿で使用した言語)。

1つ目は、マークアップのスクリプトタグが同等(またはそれ以上)であるかどうかです。
並列スクリプトローダーで使用される動的スクリプト要素。

私たちはこの問題について完全に合意しています-それは問題ではありません。 もちろん、並列ロードは、複数のスクリプトの順次ロードよりも高速です。 そしてもちろん、 <body>タグの最後、 defer 、またはスクリプトローダーを使用して、非ブロック方式で実行する方が、 <head>ブロックするよりも優れています。

しかし、これは要点を見逃しています。 JavaScriptのパフォーマンスを気にする人は誰もそのアプローチを使用しないため、シーケンシャルスクリプトタグを配置することは、比較するのに苦労します。 シーケンシャルスクリプトタグよりも速いものは何だと思いますか? _なんでも_。

まだ得られていない2番目の質問は、
script-concatは常に優れています。

私たちはこの質問に「到達」しました。 実際、このページの上部にある@paulirishの質問です。 あなたがこのスレッドでそれを解決しようとしていないのなら、あなたはそうする必要があります。 これは、このスレッドだけでなく、何年にもわたってLABjsが何をするかについてのすべての主張の中心にあります。

その質問も徹底的にテストする必要があります。

繰り返しになりますが、これが(公正な)テストケースです。 同じ5つの実際のスクリプト。他のアセットが存在する中サイズのページにロードされます。1つはロード順序を確認するためのLABjsのベストプラクティスを使用し、もう1つは単一の連結スクリプトを使用します。

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

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

調べたい別のテストケースがある場合、または実際のLABjsを使用して実験したいWebサイトがある場合は、それを共有してください。

@SlexAxtonありがとう。 イェフダの見解やその他の強い意見(リファクタリングが難しすぎることを除けば)を聞いてみたいと思います。 私はこれを見つけまし

@geddesignのコメントを明確にするために:今日の時点では、AMDモジュールはかなり簡単にハーモニーモジュールに変換できるようですが、ハーモニーモジュールの提案はまだ流動的であると私は考えています。後で変更される可能性があります。 厳密な実装テストはまだ行われていませんが、いくつかの足がかりを得始めています。 プラス面として、AMDローダー+ローダープラグインは、ハーモニーのアイデアのいくつかを試すための確かなフィードバックを提供できます。

@SlexAxtonのコメントへ:

ロードランナーの場合:構文が優れているかどうかはわかりませんが、異なるだけです。 AMDをサポートしているので、それでも動作します。

ストロボの場合:私はまだそれらからのコードを見ていません。 彼らはかなり内向きに焦点を当てているように見えますが、私はイェフダがその発展を開くために行った仕事に感謝しています。 アレックス、彼らが考えていることへのポインタがあれば、私はそれらを手に入れていただければ幸いです。

このアプローチでネストされた依存関係(広範なコード共有に必要)を許可する場合は、次の構文が必要です。

  • コードの単位に名前を付けます
  • 依存関係を指定する方法
  • 依存関係の準備ができるまでコードが実行されないようにするための、そのコードの関数ラッパー。 または、ビルドまたはXHRアクセスを常に義務付けます。これは、JS開発の範囲全体でスケーラブルではありません。

これはAMDが提供するものであり、構文は可能な限りスリムです。 他の何かは、名前とおそらくいくつかの種類の句読点をめぐって争っているだけです。 ある時点で何かを選択する必要がありますが、これまでのところ、AMDを受け入れられない構造上の弱点についてDanWebbやYehudaから聞いたことはありません。 requirejsなどの一部のAMDローダーは、通常のスクリプトのみをロードでき、モジュールである必要はありません。

特にモジュールのコード構文を考えるのは非常に簡単で、誰もが自分の好みを持っていることを理解できます。 ただし、AMDには、ある種の合意を得るという大変な作業を行ってきたかなり深い歴史があり、さらに重要なのは、それをバックアップするための実際のコードとデプロイメントです。 AMDが適切でない理由を非常に明確かつ明確にする責任は他の人にあると感じています(このチケットはその場所ではありません。リストから外して私に連絡するか、 amd-implementリストを使用してください) 。

しかし、 @ SlexAxtonの見解に感謝します。 HTMLボイラープレートに対するAMDアプローチの標準化は時期尚早である可能性があり、私はそれで完全に問題ありません。 ボイラープレートプロジェクトが1つを選びたいと判断した場合、AMDは幅広いJS開発に適合する強力な選択肢です。

@SlexAxton私はあなたと一緒です。 私自身のコードはずっとAMDです。 誰もがスクリプトではなくモジュールを作成することを望みますが、幸いなことにRequireJSはモジュールだけでなくプレーンスクリプトもロードできます。

Yehudaのhandlebars.jsテンプレートを参照している場合、これらはRequireJSで非常にうまく機能します。 特に、テンプレートをコンパイル/キャッシュしてそのテンプレート関数を返すプラグインを作成する場合。

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

しかし、私はこの声明に同意しません:

私はAMDをデフォルトにしたいと思っていますが、マルチライブラリ/ newbの観点からは、私が望むほど賢明ではないでしょう。

Newbsは、AMDが経験豊富な開発者以上に提供するクリーンな構造を必要としています。グローバル変数の衝突が発生しやすく、マージの競合に対処する必要があることを恐れて誰も触れたくない巨大な乱雑なJSファイルにつながるひどいコード編成です。など。ライブラリはモジュールから多大な恩恵を受けます。そのため、今後のDojo1.7とMootools2.0はAMDに移行します。 jQueryが登場することを願っています-その最大の不満の1つは、それが「オールオアナッシング」であるということです。 アニメーション、ajax、イベントなどもページにロードせずに、その優れたDOM操作を使用することはできません。 そうそう、AMDはお互いに有利です。 HTML5ボイラープレートが人々にベストプラクティスを示したいのであれば、AMDを除外するのは残念です。 JavaScriptの問題の多くをエレガントに解決します。

明確にするために。 同意します。 私は彼らがずっと必要なものを使っていたらいいのにと思います。

私は彼らがそうするだろうとは思わない。

AMDが流行語であり、すべての真面目な開発者が知っておく必要のある「もの」であることを人々はまだ認識していないと思います。 一度やったら、上司や将来の面接でそれについて知っていることを伝え、それを使用したいと思うでしょう。

私たち全員が自分の役割を果たし、「見て、それは簡単で、より良く、そして重要だ」と言ってそれを流行語にすると、群れは彼らのキャリアのために続くでしょう。

@ jashkenas--

1つ目は、マークアップのスクリプトタグが、並列スクリプトローダーで使用される動的スクリプト要素と同等(またはそれ以上)であるかどうかです。

私たちはこの問題について完全に合意しています-それは問題ではありません。

実際、私はこのスレッドへの参加を開始しました。動的なスクリプト要素の読み込みがスクリプトタグよりも優れたパフォーマンスにつながることに全員が同意したことを前提としています。 しかし、 @ paulirish@slexaxtonの両方が、_this_スレッドでその仮定を疑問視しています。

@paulirishは、 deferが、動的なスクリプト要素の読み込みの代替手段よりも、プレーンなol 'スクリプトタグを同等(またはそれ以上)にするのに十分な方法であることを示唆しています。 私はdeferで十分であることに同意しません。そして、私は今、いくつかの理由を確立しました。

したがって、最初の質問を調べて、 deferがスクリプトローダーよりも優れているかどうかを調査したことは有効だと思います。 deferで逃げることができるいくつかの限られたケースがあるかもしれませんが、一般化されたケースに関しては、スクリプトローダーはすべての癖を処理/正規化しますが、 deferはそれらの問題にさらされます。

deferが十分でない理由を誰もが見て、同意するかどうかはまだわかりません。

繰り返しになりますが、これが(公正な)テストケースです。 同じ5つの実際のスクリプト。他のアセットが存在する中サイズのページにロードされます。1つはロード順序を確認するためのLABjsのベストプラクティスを使用し、もう1つは単一の連結スクリプトを使用します。

これはあなたの(そして他の人の)誤ったテストの前提です。 1つではなく5つのスクリプトをロードする方が高速になると言ったことはありません。 一度もない。 これまで。 これ以上明確にできますか? 前提は5対1ではありませんでした。

最初のテストは、3つのスクリプトタグと3つのscript()呼び出しをテストすることでした。これは、公正なテストだからです。 そして、ビデオとテストは、そのシナリオでのスクリプトのロードが有益であることを示していると思います。

2番目の、テストの質問がはるかに複雑なのは、すべてのJSを1つのファイルに既にロードしているサイトのパフォーマンスを改善する方法があるかどうかです。 ほとんどの人はそれを改善することは不可能だと言います。 同意しません。

注:この質問が直交する理由は、スクリプトタグを使用するか、 document.createElement("script")タイプの動的ロードを使用して、この単一の連結ファイルをロードできるためです。 いずれにせよ、単一のconcatファイルの質問は有効な質問ですが、スクリプトタグまたは動的スクリプトロードの方が優れているかどうかとは別になります。

このスレッドで、そして他の多くのコンテキスト(トピックについて話しているすべての会議、ブログ投稿などを含む)で私が何度も言っているのを聞いたことは、単一のJSファイルの連結で改善できる可能性があると思います「チャンク」(大きな連結ファイルを分割すること)によるアプローチは、(最大で)2つまたは3つのチャンクに分割されます。 チャンクのサイズがほぼ同じで、並列に読み込まれる場合、接続の「Keep-Alive」や並列読み込みの効果などにより、HTTPオーバーヘッドが追加されていても、ページの読み込みが速くなる可能性があります。

実際、私はこのトピックについてずっと前に書いていました。LABjsの最初のリリースの直後の2009年11月にさかのぼります: http ://blog.getify.com/2009/11/labjs-why-not-just-concat/

そのブログ投稿で、そしてそれ以来、ビルドプロセスを使用して連結する立場にある場合(すべての人がそうであるとは限りません...実際、ほとんどのWebはそうではありません)、次のことを行う必要があります。それで。 期間。 いつも。 常に10〜20個のローカルファイルからはるかに少ないファイルまで連結します。

ただし、単一の連結ファイルを作成したら、(スクリプトローダーを使用して)並列にロードされた単一のファイルを2〜3チャンクでロードすることも有益である可能性があります。

なぜこれが良いのでしょうか? 私はそのブログ投稿にそれを並べましたが、要するに:

  1. 並列ローディング効果は本物です。 これについてビットトレントユーザーに尋ねてください。 HTTPオーバーヘッドも現実のものであり、それに対抗し、その利点を排除するように機能します。 しかし、それは利益を得ることが不可能であるという意味ではありません。 接続Keep-Aliveを使用すると、2つまたは3つの同時接続(2〜3の完全な接続オーバーヘッドペナルティなし)を取得し、より短い時間でコードをロードすることができます。 3つのチャンクでロードした場合、1/3の時間(60〜70%高速)になりますか? いいえ、絶対にありません。 ただし、20〜30%高速になる可能性があります。
  2. すべてのコードを1つのファイルで提供することで、ライフタイムコードごとに異なるキャッシュヘッダーを実行できなくなります。 たとえば、jqueryは非常に安定しており、再ダウンロードする必要はありません。 ただし、サイトのUX中心のコードは非常に不安定な場合があります(週に1回以上微調整する場合があります)。 単一のconcatファイルで短いキャッシュヘッダーを実行すると、安定したコードの再ダウンロードが不必要に頻繁に行われるため、ばかげています。 単一のconcatファイルで長いキャッシュヘッダーを実行することも愚かです。これは、キャッシュされたファイル(cache bust paramなど)を無効にし、ファイル全体の完全な再ダウンロードを強制するためです。より揮発性の高いコード。 したがって、大きなconcatファイルを2つのチャンクにチャンクします。1つは安定したコード用、もう1つは揮発性コード用です。これにより、チャンクごとに異なるキャッシュヘッダーを設定できます。 これにより、キャッシュがより効果的に使用され、ユーザーがサイトに繰り返しアクセスするため、一定期間にわたってパフォーマンスが向上する可能性があります。
  3. 調査によると、平均して、単一のページビューで使用されるJSは、ページに読み込まれるJSの100%未満です(一部の推定では、コードの約20〜30%になります)。 すべてのコードを一度に一度にロードすると、ページのロードの開始時に、その時点で不要な(そして「不要」になる可能性のある)ファイルの70〜80%をプッシュするために、行が不必要に混雑します。 コードが2つのチャンク(1つはより重要なコードで、もう1つはそれほど重要ではないコード)であり、最初のチャンクをすぐにロードし、ページのロードの数秒後に2番目のチャンクをロードする場合は解放できますはるかに重要な画像/ cssとコンテンツのパイプ。 本質的に、チャンク化により、コードに優先順位を付けることができます。

結論... concatとparallelのトピックについて...私は_常に_人々に伝えます:両方。

@getifyはよく言った。

カイルのLABjsは私のサポートがあります。
サイトのパフォーマンス向上を支援するコンサルタントとして、LABjsが何度もうまく機能するのを見てきました。
パフォーマンスが大幅に向上しただけでなく(100ミリ秒だけでなく1秒以上)、開発者もそれを気に入っていました。
理解しやすく、実装も簡単です。

そして、この機会に「カイル、LABjsの素晴らしいサポートに感謝します。あなたは私の期待を何度か超えました」と公に言います。

接続キープアライブを使用すると、2つまたは3つの同時接続を取得できます(2〜3の完全な接続オーバーヘッドペナルティなしで)

HTTPは応答を多重化/インターリーブしないため、最初に複数の接続を開かずに並列ダウンロードを行うことはできません。 永続的でパイプライン化された接続の理想的なケースは、単一のファイル(+いくつかのヘッダー)を連続してダウンロードすることと同じです。

@ pornel--

私は、ブラウザーが単一のサーバーと並行して複数の接続を開くことができることを直接見て検証しました。接続キープアライブが機能している場合、2番目と3番目の接続のオーバーヘッドは最初の接続よりも大幅に少なくなります。 それが私が話している効果です。

@getify素晴らしい、私たちはある種のコンセンサスに達したと思います。 あなたの記憶をリフレッシュするには:

スクリプトを少しずつロードすることについての反論が予想されます...
ただし、これはスクリプトの読み込み手法と完全に直交しているため、省略してください。
議論の。

はい、永続的なスクリプトとは異なるJSファイルに揮発性スクリプトをロードするのは素晴らしいことです。 特定のページにのみ必要なスクリプトを、その特定のページにのみロードすることも同様に優れています。

それで、私がWeb開発者で、JavaScriptがたくさんあるページを持っている場合、どうすればよいですか? LABjsを使用するか、永続スクリプトを1つのファイルに連結し、揮発性スクリプトを別のファイルに連結して、bodyタグの下部に<script defer="true">付けて両方をロードしますか?

アプリをキャッシュの問題、ブラウザーの非互換性、ページ上の画像との競合、およびスクリプトローダーがもたらすその他の問題にさらす必要があるのはなぜですか?

パフォーマンスのためにスクリプトローダーを使用することの全体的な前提が、2つのスクリプトタグを使用するよりも簡単で単純である場合...ブルックリンにあなたを売るための橋があります。

@getifyがWebサーバーを複数回実装した場合:keep-aliveは同時リクエストにまったく影響を与えず、後続のリクエストのコストを削減するだけです。 キープアライブを伴う2つの後続の要求を持つ分割ボディは、単一の要求よりもさらにコストがかかります。 2つの本体部分に対して2つの同時リクエストがあると、おそらくパフォーマンスが向上しますが、ブラウザーが開く同時リクエストの数は限られていることに注意してください(ブラウザーによって異なり、5前後の構成になっていると思います)。これは、すべての場合は問題ありません。 3つのjsファイルをロードしていますが、 @ jashkenasが複数回指摘しているように、画像やcssファイルなどの他のアセットがある場合は問題になります。

@ jashkenas-

それで、私がWeb開発者で、JavaScriptがたくさんあるページを持っている場合、どうすればよいですか? LABjsを使用するか、永続スクリプトを1つのファイルに連結し、揮発性スクリプトを別のファイルに連結し、両方を<script defer = "true">でbodyタグの下部にロードしますか?

TL; DR:両方

まず、Web上の多くのサイトはCMSによって組み立てられています。つまり、インラインスクリプトブロックがページ全体に散らばっているのが一般的であり、「すべてのコードを1つのファイルに移動する」と言うだけでメンテナンスの面で解決するのは非常に困難です。 したがって、_ほとんどの_サイトが、別の外部スクリプトがロードされて実行された後に実行する「インラインコード」がなくても逃げることができるという前提は、せいぜいありそうもないと思います。

次に、さまざまなブラウザでdeferDOMContentLoadedに対して異なる動作をすることを証明しました。 一部のブラウザーでは、スクリプトはDOM対応の前に実行されますが、他のブラウザーでは、スクリプトはDOM対応の後に実行されます。 スクリプトにDOM対応の前後に発生することに依存するコードがある場合、 defer使用が問題になる可能性があります。 特に、誤解や混乱が多いデリケートな領域であるため、すぐに「これは単純な解決策ではありません」になります。 もっと考えが必要です。

第三に、私が使用するようにマークアップを変更し、多くのサイトのためだと思う$LAB.script()の代わりに&lt;script>上のいくつかの自動化(または手動)bulidプロセスをインストールする方法を彼らに説明するよりも簡単に多くのことをされ、そのサーバ。 特に、そのサイトが共有ホスティング上にあり(ほとんどのWebはそうです)、サーバーの多くを実際に制御していない場合は、コードの保守性が失われないようにビルドプロセスを理解するように依頼します。 ..自明ではありません。

これらのことを克服できますか? うん。 もちろんできます。 しかし、彼らは多くの仕事をします。 場合によっては(DOM対応のもののように)、実際にコードを入念に調整する必要があります。 それをすべて整理するには、この分野で献身的な努力と多くの専門知識と情熱を持った人が必要です。

対照的に、彼らは&lt;script>タグの代わりにLABjsにドロップする「クイックウィン」を得ることができます。 彼らが考えなければならないことはほとんどありません( document.write()を除く)。 ほとんどの場合、「それはうまくいく」。 そして、ほとんどの場合、ページの読み込み速度がすぐに向上します。 ほとんどのサイトにとって、それは大きな勝利です。

だから、あなたの質問に答えるために、私は前に言ったように、両方を行うと思います... LABjsに最初にドロップし、いくつかの即時の速度の増加を見てください。 ここで、ビルドプロセスを使用して、15ファイルから2ファイル(1ファイルを半分にチャンク化)に移動することの利点を強く検討してください。 あなたがそれをするとき(あなたがそれをするなら、私が言ったように、ほとんどはそうしません)、あなたが本当に望むならあなたはLABjsを捨てることができます。 しかし、実際に害はありません(モバイルでも小さく、キャッシュも良好です)。 それはあなたの2つのファイルチャンクをうまくロードし続けます、そしてそれはdeferが引き起こすかもしれない癖なしでそうします。

また、LABjsがすでに存在していると、ステップ3を実行するのがばかげて簡単になります。ステップ3は、後で「レイジー/オンデマンドロード」できるコードを見つけ出すことです。 スクリプトローダーなしではそれを行うことはできません。 LABjsがすでに存在し、使い慣れているということは、そのオンデマンドスクリプトをロードする方法についてまったく心配する必要がないことを意味します。これはすでに理解されています。

@ rkh--

(特にApacheで、Keep-Alive設定を切り替えて)複数の並列要求がどのように影響を受けたか(Keep-Aliveがあった場合は積極的に)を実演してもらいました。 私はこの分野の専門家ではないので、それがどのように機能するかについての正確な詳細を議論することは私を超えています。 Keep-Aliveがあったときのリクエスト#2のタイミングはリクエスト#1のタイミングよりも少なかったと言えます。 ブラウザとサーバーがそれをどのように行ったか、私は部分的に情報に基づいた推測しかできません。

キープアライブを伴う2つの後続の要求を持つ分割ボディは、単一の要求よりもさらにコストがかかります。

私は2番目のリクエストが無料であるとは決して主張しませんでした。 私は、2番目のリクエストは最初のリクエストほど高価ではないと主張しました。 したがって、少なくとも1つの要求を行う必要があると仮定した場合、2番目の要求を並行して行うことは、オーバーヘッドまたは時間コストの観点から、同じサーバーへの2つの完全に独立した接続を行うことと同じではありません。

見積もりとして、リクエスト#1はサービスに対してXであり、Keep-Aliveの存在と並行する#2は0.7Xであるように見えました。 サーバーは、2番目の要求を処理する際に既存の接続オーバーヘッドの一部を利用できるため、サーバーが少し安くなると説明されました。 Keep-Aliveをオフにすると、2番目のリクエストにはそのような測定可能な減少はありませんでした。


しかし、この議論はすべて、真剣に深いウサギの穴です。 私はサーバーの専門家ではありません。 私はする必要はありません。 私はこの正確なトピックについて実際に見た(そしてテストを作成した)ことを説明することしかできません...その単一の100kファイルのロード時間と同じファイルの2つの半分を並行してロードすることをテストできますか?2番目のテストは測定可能ですか?より速く量。 私が言ったように、チャンクインパラレルテストでは15〜25%高速であることがわかりました。 それがどのように行われ、なんとかしてひどい「OMG HTTP RESPONSE OVERHEAD IS TERRIBLE」効果を克服し、2つの並列ロードの恩恵を受けたのですが、私は科学的に証明する資格がないと思います。 しかし、それは間違いなく観察によって行われました。

キリストよ、あなた方は速くタイプします。 読み終えてページをリロードすると、あと9件のコメントがあります。

私は助けが必要です。 私は、このスレッドのどこで、_ボイラープレートHTMLファイルに最適なもの_についての議論から、_スクリプトローダーがすべての場合にスネークオイルであるかどうか_についての議論に進んだ場所を正確に特定しようとしました。

@getify 、あなたは確かにLABjsを擁護し、スレッド内の他の人からの特定の批判に対応する必要がありますが、(@ jashkenasを除いて)LABjsを批判する人は、それが定型的な解決策ではないことを示すためにそうしていると思います。 レガシーページをscript[defer]よりもLABjsに変換する方が簡単だとあなたは主張しますが、それは本当かもしれませんが、それはボイラープレートHTMLファイル(つまり、定義上、最初から)にどのように適用されますか?

あなたはそれが派手なビルドプロセスを持っていない人々のために設計されていると言いますが、あなたはまた、連結、同じサイズのチャンクへの分割、そして並行してロードすることを提唱しているようです。 それはビルドスクリプトのタスクではありませんか? 繰り返しになりますが、ユーザーにインテリジェントなデフォルトを提供するように設計されたボイラープレートの選択は間違っているようです。 ユーザーが20〜30%の速度向上を望む場合、ボイラープレートが提供するものよりも後でアップグレードすることを選択できますが、それは簡単な作業ではありません。

そうは言っても、一般的なトピック(「スクリプトローダー:貴重なツールまたはスネークオイル?」)を続けたい場合は、楽しくぶらぶらしてポップコーンを作ります。

@getify :2番目と3番目の接続が最初の接続よりも速く開かれる可能性があることに同意できます。最初の接続はDNSを待機し、最初のパケットをサーバーにルーティングするのは、残りを同じパスに沿ってルーティングするよりも少し遅い可能性があります。 HTTPS SSLセッションキャッシュでは、後続の接続に大いに役立ちます。

ただし、この状況では、Keep-Aliveの関連性はわかりません。 同じ接続での後続の_requests_は、Keep-Aliveを使用するとより高速に開始されますが、これらの要求は接続内でシリアルになります。

私はここでもう終わりです-スクリプトローダーに関して、「地獄のように怒って、もうそれを取るつもりはない」瞬間に到達しました。

そうは言っても、このスレッドは、炎の祭典のために、実際にはかなり生産的だったと思います。 LABjsが不幸で無能なWebサイトの主張を主張し、実際にサイトを高速にロードしたい人々を一人にしておきたいのであれば、それは大きな前進です。

男、冷やす

@ savetheclocktower--

公正な質問。

私は、LABjs(または任意のスクリプトローダー)をh5bpに含めることを強く推奨するこのスレッドへの参加を開始しませんでした。 それは便利だと思いますが(下記参照)、私が眠りにつくことは私の大きな関心事ではありませんでした。 明らかに、このスレッドは「スクリプトの読み込み」であるすべてのものに対する全面的な攻撃に変身しました。 つまり、明らかに、私がもう少し気にかけていることです。

あなたはそれが派手なビルドプロセスを持っていない人々のために設計されていると言いますが、あなたはまた、連結、同じサイズのチャンクへの分割、そして並行してロードすることを提唱しているようです。 それはビルドスクリプトのタスクではありませんか?

私は最初に、数十のスクリプトタグすべてをLABjsのような並列スクリプトローダーに移動することを提唱します。 これには、マークアップを調整する機能しか必要ありません。 これは、たとえば、自動化されたnode.jsベースのビルドシステムを使用するようにmom&popサイトに指示するよりもはるかに簡単で威圧的ではありません。

また、ファイルのビルドを実行できる人にとっては、LABjsは、それらのチャンクを並行してロードするのに役立つため、依然としてメリットがあることをお勧めします。 チャンクが何らかの形で有用であることに同意しない場合は、 defer超えてLABjsを使用する理由はわかりません。 しかし、チャンキングが役立つ理由がわかる場合は、スクリプトローダーがそのプロセスを支援する可能性があることを確認する必要があります。

繰り返しになりますが、ユーザーにインテリジェントなデフォルトを提供するように設計されたボイラープレートの選択は間違っているようです。

スクリプトローダー(具体的には、LABjsのように、スクリプトタグとscript()呼び出しの間で1対1のマッピングを持つように設計されているもの)がボイラープレートでメリットがあると思う唯一の理由は、ボイラープレートでのメリットです。 、何かのインスタンス(タグなど)がよく見られます。ページを作成する傾向は、必要な回数だけコピーアンドペーストして複製することです。 したがって、ボイラープレートのパフォーマンスの低いパターン(スクリプトタグ)がある場合、人々はスクリプトタグを12回複製する傾向があります。 平均して、代わりに$LAB.script()呼び出しを何度も複製した場合、パフォーマンスが以前ほど悪くならない可能性は十分にあると思います。

それが私がこのスレッドに参加し始めた唯一の理由です。 これが、私が@paulirishの「ブラインドフェイス」コメントをこのスレッドで問題にした唯一の理由です。

Soooooooooooええ。


スクリプトローダーがh5bpプロジェクトに適しているかどうかについて、この議論が進んでいることは明らかだと思います。 しかし、このトピックは調査する価値があるので、それは良いことです。


とにかく、私はテスト結果と一緒に再現可能なテストケースに非常に興味があります。

また、 @deferの仕様は、ブラウザがそれに伴って提供する不安定な動作の一部を保護するために作成されたようです。 その動作を文書化する必要があります。 準備ができたら、MDCへの移行を支援できます。

すべてのブラウザ、さまざまな接続タイプ、およびネットワーク効果をキャプチャするこれらの動作に関する簡単なドキュメントが必要です。 テストリグがcuzillionまたはassetraceのどちらを使用すべきかはわかりませんが、それは決定できます。

そのhttps://github.com/paulirish/lazyweb-requests/issues/42に関心を集めるためのチケットを設定しました

webperfの調査と証拠の文書化の_superfun_タスクに興味がある場合は、そちらに参加してください。

紳士、このスレッドが閉じていると考えてみましょう。

@jrburkeがコメントで説明したように、遅延読み込みはAMDモジュールの主な利点ではありません。AMDモジュールをできるだけ多く使用することを選択した主な理由は、コード構造が改善されるためです。 これにより、ソースファイルが小さく簡潔になり、開発と保守が容易になります。開発中にcss @importを使用し、自動ビルドを実行してスタイルシートを組み合わせるのと同じ方法で、大規模なプロジェクトにも推奨されます...

私が昨年書いたこの投稿は主題に合っていると思います:パフォーマンスの教義-それはパフォーマンスだけではなく、_実際の_違いをもたらさない何かを_時間を無駄にしない_「最適化」していないことを確認してください...

そして、私は@SlexAxtonを使用しています。AMDが欲しいのですが、ほとんどの人にとっては単純なスクリプトタグでおそらく十分です。 おそらく有効なアプローチは、AMDプロジェクトを選択し、_concat_タスク( RequireJSオプティマイザーAntタスク)の代わりにRequireJSオプティマイザーを実行する新しい設定を追加することです。これはかなりクールで、おそらく実装はそれほど難しくありません。

紳士、このスレッドが閉じていると考えてみましょう。

@paulirish AMDサポートを

@benatkinは新しいチケット仲間を開きます。

@paulirish OK、ありがとう。 @jrburke始めた議論を続けるために、新しいチケットを開いて

面白くて有益です。 みんなありがとう。

誰かが新しいスクリプトローダープロジェクトを開始して、それを「Issue28」と呼ぶ必要があると思います。 :)

最も広い互換性の場合、スクリプトを下部に配置し、縮小し、gzipすることで高速なパフォーマンスを実現できますが、延期しないでください。 少なくとも、ブラウザの互換性が数年間一貫しているまでは。

ボトルネックは、広告、JavaScriptが多すぎる、HTMLが肥大化する、CSSが多すぎる、iframeが多すぎる、リクエストが多すぎる、サーバーの遅延、JavaScriptが非効率的であることが原因で発生する可能性があります。 多くのサードパーティライブラリを使用するアプリケーションには、JavaScriptが多すぎるだけでなく、それ以上に、HTMLの肥大化、無効なHTML、CSSの多さ、JavaScriptの非効率など、他の多くの問題が発生する傾向があります。 Twitterは、2つのバージョンのjQueryと2つのonscrollハンドラーを備えているため、右列のonscrollがバウンスすることを思い浮かびます。

キッカーは、自分が何をしているのかを知っていれば、それらの問題を回避できるということです。 jQueryやアンダースコアなどは必要ないため、スクリプトははるかに小さくなります。 クリーンでシンプルな有効なHTMLとCSSを作成します。 その結果、ページの読み込みが速くなり、アプリは変更に関してより柔軟になり、SEOが向上します。 そのため、スクリプトローダーを使用すると、不当な複雑さとオーバーヘッドが追加されます。

https://github.com/BroDotJS/AssetRage

ブーム! クラブを閉じて、スレッドを閉じます。

なんてスレッド…すごい。

Imo、議論はh5bpのコンテキストで始まりました。これは、Web開発者の出発点となることを目的としています。
そのため、h5bpを使用するwebdevは、実際にはクリーンなHTML、クリーンなCSS、優れた.htaccessなどを備えており、画像が多すぎたり、JSが非効率的だったり、サードパーティのJSが多すぎたりすることはありません。 Web開発者が高性能h5bpを使用することを選択し、それによってパフォーマンスが懸念され、ページに表示されるh5bp以外のものに注意を払うためです。

スレッドから、そしてこの文脈では、残念ながら、最終的な結論を引き出すのに十分な証拠はないと思います。
私はPaulと一緒に研究を進め、文書化する必要があるものを文書化しています。
ポールで私を数えてください。

サイドノート。 私はAMDにあまり精通しておらず、一見したところ、それは私にとって恐ろしいように思えます。少なくとも、私が簡単に理解できるものではありません。 私はほとんどの「普通の」ウェブ開発者が同意すると思います。
h5bpに表示されるものは、参入障壁を低くする必要があります。そうしないと、使用されず、h5bpの取り込みがそれなしの場合よりも遅くなる可能性があります。
AMDのようなものがh5bpに属しているとは思えません。
複雑にしないでおく。

そして別のコメント…。
「スクリプトを一番下に置く」および「JSファイルを1つのファイルに連結する」は、長年にわたってWebパフォーマンスのベストプラクティスリストの上位にあります。 では、社内の開発者やトップブランドのエージェンシーによって構築された平均的なサイトの90%以上が、まだHEADに複数のスクリプトタグを持っているのはなぜですか? 本当に、それはなぜですか?

そして、他の9%は、HEADに単一の連結されたJSファイルを持っています。
最下部に1つのスクリプトがあるトップWebパフォーマンス開発者によって構築されていない「通常の」サイトを目にすることはめったにありません。

開発者は、何年も前と同じようにサイトを構築し続けます。
サイトの所有者はデザインと機能に最も関心を持っているので、開発者はそれに時間を費やしています。

作業方法、ビルドシステム、コードを変更する...それは簡単で、非常に簡単でなければなりません。さもないと、それは起こりません。

私は、HEADのJSを1つのファイルに結合し、それをBODYの下部にロードすると、サイトのページが壊れてしまう多くのサイトで作業してきました。 そして、何? ほとんどの場合、それを修正するのは1時間の作業ではありません。 深刻なリファクタリングを行う必要があります...そしてこれは知識の不足、特に時間の不足のために起こりません。

(ああ、スレッドは閉じています...)

jQueryとModernizrの上に構築されたライブラリについて話しています。 本当にすべてを言います。 誰がそれを使用しますか? ああ、たわごと、私は忘れています、Twitter.comは2つのjQueryを使用し、ソースコードにも次のようなものがあります。

行352、列6:終了タグdivが表示されましたが、開いている要素がありました。
エラー行350、列6:閉じられていない要素ul。
エラー行330、列6:閉じられていない要素ul。

そして、ブラウザがエラー訂正を期待することに関する問題は、HTML4がエラー訂正メカニズムを定義していなかったため、誰がどこで何を知っているかということになるということです。 確かに、HTML5はエラー処理を定義していますが、遡及的ではありません。「古い」ブラウザはまだたくさんあります。

そして、たわごとについて言えば、ここの誰かがjQuery ES5シムを見たことがありますか?

ところで、「h5bpを使用するwebdevは実際にはクリーンなHTMLを使用する」というあなたの声明に追加するものはありますか?

@GarrettSわかりました

:-D私たちはいつでも期待できます!

死んだ馬を打ち負かす、私は知っています...しかし、私たちがこのきらびやかな議論をしているのと同時に、現在のバージョンのLABjsには実際にバグがあり、一部のブラウザーでJavaScriptが間違った順序で実行される原因になりました: https: //github.com/getify/LABjs/issues/36

ああ、皮肉なことです。

しなければならない。 抵抗。 投稿。 完全に。 [不適切。 画像。 にとって。 前。 ステートメント.... aggggh! AGONY!

私のお気に入りの部分は、 dhtmlkitchen.com (現在は完全にめちゃくちゃになっている)を作った男がマークアップエラーについて話し始めたときでした。

そのサイトはPauloFragomeniに移管されました。 はい、私はそれを作り、ここに書いたものを誇りに思っています。 弱いアバター、ジャッカスのスクリーンショットを撮りに行きます。

...そしてそれが終わったら、あなたの頭をお尻から引き出して、私の古い個人のウェブサイト(私はもう維持していません)とチームによって開発されて資金提供されているウェブサイトの違いを理解してみてください収益性の高い数百万ドルの企業(ただし、Twitterは数十億ドルの価値があるかもしれません)。

私たちがこの上品さを維持していることをうれしく思います。

jashkenasは、このディスカッションの早い段階で関連情報を入手しました。

しかし、その後、反発がありました。 番号! してはいけません! スーダーズはそれをするように言った! そして、失敗したときにどのように失敗するかを気にせずに、deferを使用するという悪いアドバイスがありました。

そして皮肉なことに、どこからともなく、h5bpユーザーが適切に物事を行うだろうという主張がありました。 そして、これは非常に皮肉なことです。なぜなら、このコメントは、明らかに無効なマークアップを生成し、サードパーティの抽象化レイヤー(およびひどいもの)を大量に使用するサポーターからのコメントの後に来たからです。 そして、延期の使用についてのコメントの後。

では、これはdhtmlkitchen.comがダウンしていることと何の関係があるのでしょうか。 明らかに、何もありません。 それは批判を聞くのに耐えられないh5bpフォーカーからの弱いジャブでした。

ブロス
お前。
ブロス

このスレッドは閉じられています。 覚えて? 家に帰る必要はありませんが、ここで炎上することはできません。

ねえ、私たちが複数の議論、個人的な炎の戦争、いたるところに怒る人々、わいせつなイメージ、そして万能の楽しい時間があった壮大なスレッドを作ったときのことを覚えていますか? それが無料だったなんて信じられない。 いつかまたやるべきです。

このページは役に立ちましたか?
0 / 5 - 0 評価