3

私は現在、主にリソースローダーのためにrequirejsを使用しています。フォールバックを管理する方法が気に入っています。

私の JavaScript アプリはまったく複雑ではなく、いくつかの jQuery UI ウィジェットとその他の微調整だけです。

requirejs を使い始めるまで、FOUC が何であるかさえ知りませんでした。それは非常に目立つので、現時点では次の方法で回避しています。

var protect_from_FOUC = function(element) {
    if(typeof element === 'string') {
        element = document.querySelector(element);
    }
    element.classList.add('ui-helper-hidden');
};

<div id="main" class="main_block" role="main">
<!-- a block affected by FOUC -->
</div>
<script>protect_from_FOUC('#main');</script>

そして私のスクリプトでは:

require(['jquery', 'jquery-ui' /*, ...*/], function($) {

var recover_from_FOUC = function(element) {
    $(element).show({
        effect: 'blind',
        duration: 200
    }).removeClass('ui-helper-hidden');
};

$(document).ready(function() {

    // Themed buttons:
    $(':button, :submit, :reset, .button').button();
    // ... Some other similar changes
    recover_from_FOUC('#main');

});  // document.ready

});  // require

これは私が持っている最高のものであり、私が見つけた主題に関するすべてのオンライン リソースは、これらの線に沿ったものを推奨しています。

私の質問は、UI のみに影響を与えるスクリプトについて話していることを考えると、requirejs はそれだけの価値がありますか? 私が言ったように、私はそのリソースフォールバックシステムを使い続けたいと思っていますが、「FOUCのパッチ適用」全体は逆効果のようです...

すべての jQuery UI の例には head にスクリプトが含まれていますが、インターネットの誰もが、body を閉じる前に、または非同期ローダーを使用してスクリプトを含めることを推奨しています。このアドバイスは「非 UI」スクリプトにのみ適用されますか?

そのような場合、何が最善でしょうか?

近いとはいえ、これは単なる「FOUC の質問を回避する方法」ではないことに注意してください。

編集: my page と my に含まれる外部ファイルを追加するrequire.config:

<!-- This is in my head right below the meta tags and exactly in this order -->
<link rel="shortcut icon" href="images/favicon.ico"/>
<!-- Keep before the site css to allow overriding jquery's style -->
<link rel="stylesheet" href="style/lib/jquery-ui/ui-lightness/jquery-ui.css"/>
<link rel="stylesheet" href="style/lib/chosen/chosen.css"/>
<link rel="stylesheet" href="style/lib/icheck/minimal/yellow.css">
<link rel="stylesheet" href="style/reset.css">
<link rel="stylesheet" href="style/style.css"/>

<!-- Here I have the definition of `protect_from_FOUC` in an inline script -->

<script data-main="js/main" src="js/lib/require.js"></script>

main.js で:

require.config({
    paths: {
        // Common:
        'jquery': ['//code.jquery.com/jquery-2.0.3.min', 'lib/jquery'],
        'sugar': ['//cdnjs.cloudflare.com/ajax/libs/sugar/1.3.9/sugar.min', 'lib/sugar'],

        // UI:
        'jquery-ui': ['//code.jquery.com/ui/1.10.3/jquery-ui.min', 'lib/jquery-ui'],
        'autosize': ['//cdnjs.cloudflare.com/ajax/libs/autosize.js/1.17.1/autosize-min', 'lib/jquery.autosize'],
        'chosen': ['//cdnjs.cloudflare.com/ajax/libs/chosen/0.9.15/chosen.jquery.min', 'lib/chosen.jquery'],
        'icheck': ['lib/jquery.icheck'],

        // django i18n:
        'gettext': [translations_url + '?noext']
    },
    shim: {
        'jquery-ui': {
            deps: ['jquery']
        },
        'autosize': {
            deps: ['jquery']
        },
        'chosen': {
            deps: ['jquery']
        },
        'icheck': {
            deps: ['jquery']
        }
    }
});

require(['style', 'interaction']);
4

2 に答える 2

3

scripts-right-before- の賛歌の理由</body>は、それらが解析をブロックするためです。

これは、Javascript を介して含めているもの以外に、解析およびレンダリングを待っているページに多くのコンテンツが存在する可能性が高いユースケースを考えると、特に悪いことです。

スクリプトを最後に含めると、HTML に直接含まれるすべてのものを、スクリプト (および要求 -> 解析 -> 実行のサイクル全体) を待つことなく、問題なく解析およびレンダリングできます。

ただし、この戦略には問題があります。そして、それはあなたの体の最後にスクリプトタグを積み上げることは、良い(何か?)依存関係の管理を可能にしません。これが、requirejs が作成された主な理由の 1 つです (コードのカプセル化、バージョニング/フォールバック、テンプレート プラグインなどの目的の中でも特に)。

そうでなければ管理するのが面倒な有効な目的でrequirejsを使用しているため、この場合、requirejsは「価値がある」と確信しています。

「FOUC パッチ適用」が非生産的と思われるというあなたのコメントについては、なぜそのように思われるのか正確にはわかりません。パッチが提供するものを考えてみましょう: スムーズな読み込み UI とブロックされていない HTMLの両方です。ヘッドにブロック スクリプトを挿入することは、確かに有効な決定となる可能性がありますが、それは、ページ上のほとんどのコンテンツが、可能な限り迅速に読み込まれることに依存している場合に限られます。これはめったにありません (実際、デモ/開発用途以外ではアンチパターンのようなものです)。

ユーザー エクスペリエンスについて考えてみてください。具体的には、やや古いスマートフォンの低速な接続/遅い JS 解析/実行速度について考えてください。これらのユーザーを 3 ~ 5 秒以上空白の画面に表示し続けるのではなく、非同期で読み込むことで、認識される読み込み時間を大幅に短縮できます。UI ベルとホイッスルは、スクリプトが最終的に利用可能になったときに、FOUC パッチで表示できます。

したがって、requirejs を使用して依存関係管理/スマートなリソース フォールバックを取得しながら、非同期スクリプトを使用して一見高速なページ ロードを提供し、ロード時に JS を強化することができます。私にはいいですね。

于 2013-09-10T20:09:05.633 に答える
1

外部 CSS ブロッキング レンダリングのフォローアップ例として。次のページのレンダリングは、遅い外部スタイル シートによってブロックされます (私がテストした Chrome と FF で)。

<!doctype html>

<html>

<head>
    <style>body { background: white; }</style>
    <link rel="stylesheet" type="text/css" href="http://deelay.me/0/http://rawgithub.com/gitgrimbo/6487200/raw/red.css">
    <link rel="stylesheet" type="text/css" href="http://deelay.me/5000/http://rawgithub.com/gitgrimbo/6487200/raw/blue.css">
</head>

<body>
    <h1>Top header</h1>

    <script>console.log(new Date()); document.write(new Date());</script>

    <h1>Bottom header</h1>
</body>

</html>

しかし、2 つの<link>要素をページ本体に (の最初の要素として<body>) 移動すると、Chrome と FF でわかることから...

Chrome では、<link>要素がドキュメントの<head>.

FF では、青の前に赤の背景が 5 秒間表示されることがあり、青の前に赤のフラッシュが表示されることがあります。これがなぜなのかわかりません。

スクリプトをブロックしていますか?

<script>CSS の遅延により、Chrome と FF の両方がブロックの実行をブロックしているようです。なぜこれがどちらになるのかわかりません。

于 2013-09-08T18:39:10.573 に答える