-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathpage-d.html
134 lines (119 loc) · 6.85 KB
/
page-d.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
<meta charset="utf-8" />
<title>Page D</title>
<link type="text/css" rel="stylesheet" href="css/style.css" />
<script type="text/javascript" src="js/init-d.js"></script>
</head>
<body>
<div class="app">
<div class="app-title">applicationHost</div>
<div class="page">
<div id="applicationHost"></div>
</div>
</div>
<div class="lazie">
<div class="page">
<div class="primary">
<h1><a href="page-d.html">Page D</a></h1>
<p>
The following content represents a basic overview of this page's script structure and [intended] execution flow. When a particular script is mentioned below, it is linked to the "debug" version, as a convenient reference, but the page actually uses the minified versions when available. For a better (more reliable?) explanation of this page's loading behavior, re-run the WebPagetest.org results.  ==>
</p>
<h2>1.  Load <a href="js/init-d.js">init-d.js</a></h2>
<p>
<a href="js/init-d.js">init-d.js</a> is hard-coded in the page's <code><head></code> section. This is the only hard-coded <code><script></code> element in this document; the other scripts are dynamically appended to the <code><head></code>.
</p>
<pre>
<code>
<head>
<meta charset="utf-8" />
<title>Page D</title>
<link type="text/css" rel="stylesheet" href="css/style.css" />
<span class="highlight"><script type="text/javascript" src="js/init-d.js"></script></span>
</head>
</code>
</pre>
<h2>2.  Execute <a href="js/init-d.js">init-d.js</a></h2>
<p>
<a href="js/init-d.js">init-d.js</a> is just like <a href="js/init-c.js">init-c.js</a>.
</p>
<pre>
<code>
<span class="highlight">(function() {</span>
// Define configuration object for require.js
require = {
// ...
// callback: undefined
// deps: undefined
shim: {
'sammy': {
deps: ['jquery'],
exports: 'Sammy'
}
}
};
// Define a function that will execute on page load
var lazyFunction = function() {
var s = document.createElement('script');
s.type = 'text/javascript';
s.src = 'lib/require/require.js';
s.setAttribute('data-main', 'app/main-d');
document.getElementsByTagName('head')[0].appendChild(s);
}
window.onload = function() {
lazyFunction();
}
<span class="highlight">}());</span>
</code>
</pre>
<h2>3.  Load & Execute <a href="lib/require/require.debug.js">require.js</a></h2>
<h2>4.  Load <a href="app/main-d.js">main-d.js</a> and Begin App</h2>
<p>
The main difference between this page and the others is that this page uses modified copies of Durandal's router plugin (<a href="lib/durandal/plugins/router2.js">router2.js</a>) and shell (<a href="app/samples/shell2.js">shell2.js</a> & <a href="app/samples/shell2.html">shell2.html</a>. The modifications are intended to make the sample application load its default route <b>without changing the URL</b> (e.g., by appending a hash 'n' slash). In other words, on pages <a href="page-a.html">A</a>, <a href="page-b.html">B</a>, and <a href="page-c.html">C</a>, the sample app is coded such that all routes depend on a URL hash ( <code>#/</code> ). So for example, <a href="page-a.html">page-a.html</a> automatically changes to <a href="page-a.html#/">page-a.html#/</a>, and `#/` triggers the default route. In contrast, Page D is coded such that <a href="page-d.html">page-d.html</a> alone (i.e., without a hash) triggers the default route.
</p>
<p>
This distinction seems to make a huge difference in how WebPagetest.org's waterfall graphs are rendered. Specifically, only Page D's waterfalls look as you'd expect: with a few HTTP requests before the <em>Document Complete</em> line, and everything else (i.e., the sample app's modules) loading after it.
</p>
<p>
Yet to be determined...is whether this difference is due to browsers behaving differently or WebPagetest.org calculating the <em>Document Complete</em> event differently.
</p>
<p>
<b>Update:</b> See related discussion on WPT forum:
</p>
<p>
<a href="http://www.webpagetest.org/forums/showthread.php?tid=12184">Single-page App Won't Lazy-load When Hash Fragment is Present</a>
</p>
</div>
<div class="secondary">
<h2><a href="http://www.webpagetest.org/">WebPagetest.org</a> Results</h2>
<ul>
<li><a href="http://www.webpagetest.org/result/130414_MX_VG1/">IE6</a></li>
<li><a href="http://www.webpagetest.org/result/130414_PF_VGH/">IE7</a></li>
<li><a href="http://www.webpagetest.org/result/130414_0J_VGM/">IE8</a></li>
<li><a href="http://www.webpagetest.org/result/130414_A8_VH3/">IE9</a></li>
<li><a href="http://www.webpagetest.org/result/130414_W7_VHB/">IE10</a></li>
<li><a href="http://www.webpagetest.org/result/130414_AJ_VHN/">Firefox</a></li>
<li><a href="http://www.webpagetest.org/result/130414_JS_VHH/">Chrome</a></li>
<li><a href="http://www.webpagetest.org/result/130414_CH_VHS/">Safari (Windows)</a></li>
<li><a href="http://www.webpagetest.org/result/130414_QM_VJ2/">iOS 5.1 (iPhone 4)</a></li>
<li><a href="http://www.webpagetest.org/result/130414_D9_VHX/">IE6 + Chrome Frame</a></li>
<li><a href="http://www.webpagetest.org/result/130414_W7_VJ9/">Android 2.1 (Nexus S)</a></li>
</ul>
<h2>Test Pages</h2>
<ul>
<li><a href="page-a.html">Page A</a></li>
<li><a href="page-b.html">Page B</a></li>
<li><a href="page-c.html">Page C</a></li>
<li><a href="page-d.html">Page D</a></li>
</ul>
<h2>Github Repo</h2>
<p>
Fork this demo on <a href="https://github.com/dslatten/lazie">github</a>.
</p>
</div>
<div class="clear"></div>
</div>
</div>
</body>
</html>