I'm interested in improving the initial page load of an app that is currently rendering entirely clientside. Right now the app loads an initial app frame and then, once the initial page is loaded, fires a request to the server to fetch the data. While the request is processing, the user effectively sees a partially rendered page. Once the data comes back from the server, the page finishes rendering on the client.
What is the best way to remove the delay caused by fetching the initial page and data separately? Should I just bootstrap the data into the initial page load, or should I leverage some sort of server side templating engine (Jade, Handlebars, etc)? It seems like doing the latter means not being able to leverage features like dom-repeat as easily, thus losing the ability to have Polymer handle some of the more complex re-rendering scenarios.
I had the same problem, the page took 4.5 sec to load cause it has to receive data from the client, And I look for ways to make polymer faster, I think that I found out, now I load the page in 1.2 sec (with no cache) and the request to the server take 0.4 sec.
Steps To Make Polymer Faster
Dont show things that you dont need. Use dom-if to not render, like if you have pages that show only if the user click on button, DO NOT RENDER THEM.
You can make request to the server before the body. so you will receive the response faster.
If you want that the user fill that the site load faster you can remove the unresolved property from the body Thus the user will see the components in the loading process (But the user will see something and not a blank screen).
use this script (before import polymer)
window.Polymer=window.Polymer ||{dom:'shadow'};
this make the browser use the shadow dom (if supported) and not the shady dom.
it faster to use shadow dom but not all the browser support it yet.
Use vulcanize https://github.com/polymer/vulcanize to merge all the import files and also minimize the file.
For long list you can use the iron-list, it render only what that is on the screen.
If you use script import, you can use the async parameter and dont block the process of the rendering.
Edit
if you dont want to use iron-list their is new option in dom-repeat
<template is="dom-repeat" items="{{items}}" initial-count="20">
</template>
this is not block the thread for a long time but render the list in parts.
Related
What is the order of loading?
php
html
java script
css
jquery
ajax
please give me little explanation too
Thanks,
1) HTML is downloaded.
2) HTML is parsed progressively. When a request for an asset is reached the browser will attempt to download the asset. A default configuration for most HTTP servers and most browsers is to process only two requests in parallel. IE can be reconfigured to downloaded an unlimited number of assets in parallel. Steve Souders has been able to download over 100 requests in parallel on IE. The exception is that script requests block parallel asset requests in IE. This is why it is highly suggested to put all JavaScript in external JavaScript files and put the request just prior to the closing body tag in the HTML.
3) Once the HTML is parsed the DOM is rendered. CSS is rendered in parallel to the rendering of the DOM in nearly all user agents. As a result it is strongly recommended to put all CSS code into external CSS files that are requested as high as possible in the section of the document. Otherwise the page is rendered up to the occurance of the CSS request position in the DOM and then rendering starts over from the top.
4) Only after the DOM is completely rendered and requests for all assets in the page are either resolved or time out does JavaScript execute from the onload event. IE7, and I am not sure about IE8, does not time out assets quickly if an HTTP response is not received from the asset request. This means an asset requested by JavaScript inline to the page, that is JavaScript written into HTML tags that is not contained in a function, can prevent the execution of the onload event for hours. This problem can be triggered if such inline code exists in the page and fails to execute due to a namespace collision that causes a code crash.
Of the above steps the one that is most CPU intensive is the parsing of the DOM/CSS. If you want your page to be processed faster then write efficient CSS by eliminating redundent instructions and consolidating CSS instructions into the fewest possible element referrences. Reducing the number of nodes in your DOM tree will also produce faster rendering.
Keep in mind that each asset you request from your HTML or even from your CSS/JavaScript assets is requested with a separate HTTP header. This consumes bandwidth and requires processing per request. If you want to make your page load as fast as possible then reduce the number of HTTP requests and reduce the size of your HTML. You are not doing your user experience any favors by averaging page weight at 180k from HTML alone. Many developers subscribe to some fallacy that a user makes up their mind about the quality of content on the page in 6 nanoseconds and then purges the DNS query from his server and burns his computer if displeased, so instead they provide the most beautiful possible page at 250k of HTML. Keep your HTML short and sweet so that a user can load your pages faster. Nothing improves the user experience like a fast and responsive web page.
~source
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
So, in short:
The html will load first obviously as this instructs the browser on the extended requirements: images, scripts, external stylesheets etc
After that, the load order is pretty random - multiple connections will be initiated by most browsers and the order in which they return cannot be predicted.
I'm building a single-page Dart web app that will essentially consist of 1 Dart file (cross-compiled to JS) and 1 HTML file that has several "views" (screens, pages, etc.). in it. Depending on what "view" the user is currently located at, I will hide/enable different DOM elements defined inside this HTML file. This way the user can navigate between views without triggering multiple page loads.
I would still like to use each browser's native history-tracking mechanism, so that the user click can the back- and forward-buttons in the browser, and I'll have a Dart Historian object figure out what view to load (again just hiding/enabling DOM elements) depending on what URL the browser has in its history.
I've pretty much figured everything out, with one exception:
Say the user is currently "at" View #3, which has a URL of, say, http://myapp.example.com/#view3. Then they click a button that should take them to View #4 at, say, http://myapp.example.com/#view4. I need a way, in Dart, to tell the browser to:
Set http://myapp.example.com/#view4 in the browser URL bar
Add http://myapp.example.com/#view4 to the browser's history
If not already enabled, enable the browser's back button
I believe I can accomplish #1 above like so:
window.location.href = "http://myapp.example.com/#view3";
...but maybe not. Either way, how can I accomplish this (Dart code communicates with browser's history API)?
Check out the route library.
angular.dart also has it's own routing mechanism, but it's part of a much larger framework, so unless you plan on using the rest of it, I would recommend the stand-alone route library.
If you want to build your own solution, you can take a look at route's client.dart for inspiration.
There are two methods of history navigation supported:
The page fragment method that you've used. Reassign the window location to the new page fragment: window.location.assign(newPathWithPageFragment). Doing this will automatically add a new item to the browser history (which will then enable the back button).
The newer History API, which allows for regular URLs without fragments (e.g. http://myapp.example.com/view3. You can use window.history to control the history.The History API is only supported by newer browsers so that may be a concern (although given that dart2js also only supports newer browsers, there are probably not too many instances of a browser that dart2js supports that doesn't support the History API).
One issue you will have to handle if you support History API is the initial page load. When a user navigates to http://myapp.example.com/view3, the browser expects to find a resource at that location. You will have to setup your server to respond to any page request by serving your Dart application and then navigate to the correct view on the client-side. This issue will apply whether you use route, angular.dart, or build your own solution, since this is a general server-side issue and the above are all client-side libraries.
I see in Javascript; Sending user to another page and how to change page from within javascript references to using the window.location to switch to a new page. It is also possible to have a similar result by including a meta tag http-equiv with a refresh value.
While these work as advertised, I need something that will continue to retry in the event the host application is not available at the time the client starts up.
A cross-browser solution would be particularly appreciated.
Update:
My current solution does as suggested. Initial AJAX to verify connectivity, followed by an update of the window.location. My concern is exactly the one given - the status can change between getting the response and updating the page reference.
I could update a lower level element body.innerHtml, for example, in the page body, but prefer to change the top level element to cleanly switch over to the new page.
The purpose of the initial page is just to bootstrap a long running application that similarly uses an AJAX loop to fetch updates of both content and periodic page refreshes. The intent is to be able to drop off web display panels and have them automatically configure themselves when they are eventually connected to a network.
I have a situation where my page loads some information from a database, which is then modified through AJAX.
I click a link to another page, then use the 'back' button to return to the original page.
The changes to the page through AJAX I made before don't appear, because the browser has the unchanged page stored in the cache.
Is there a way of fixing this without setting the page not to cache at all?
Thanks :)
Imagine that each request to the server for information, including the initial page load and each ajax request, are distinct entities. Each one may or may not be cached anywhere between the server and the browser.
You are modifying the initial page that was served to you (and cached by the browser, in most cases) with arbitrary requests to the server and dynamic DOM manipulation. The browser has to capacity to track these changed.
You will have to maintain state, maybe using a cookie, in order to reconstruct the page. In fact, it seems to me that a dynamically generated document that you may wish to move to and from should definitely have a workflow defined that persists and retrieves it's state.
Perhaps set a cookie for each manipulated element with the key that was sent to the server to get the data?
I'm trying to do everything I can to increase the load speed of my pages, and in particular the ajax loaded components.
In firebug, my out put looks like this
I'm not entirely sure if I'm reading this correctly, but it is either +2.19s for DOMContentLoaded (or it mayonly be .8 if we are supposed to subtrack that from the waiting response).
But then 4.67s for the 'load' (event).
Both of these seem like significantly long loading times.
I haven't been able to figure out what would cause these sorts of times.
These stats are from loading a straight html page which I normally load via ajax.
But this is just the HTML. No javascript in the page, and the page is being loaded directly, not through an ajax request.
However when i do load this page via ajax, I recognize a significant delay while the page attempts to load.
Any suggestions?
I've been looking through the html in IE debugbar, and it all looks surprisingly clean.
There are 30 images in the page. Could that be what the 'load' event is waiting for? And if so, is there any way to speed this up?
In particular, as the user will never load this page directly, but only via an ajax request, is their a way to improve the page loading performance in ajax. The problem isn't with the ajax loading script, but with the html page specifically.
----------------------EDITTED------------------------------
The results of the page are loaded into a jquery cycle where multiple images are visible at a single time, so using lazyloader provides a pretty horrible user experience. (assuming it is the images which is causing this problem).
Those firebug stats are telling you that:
It takes 2.1 seconds from the time you started the request for your server-side code to start returning a response
It then takes 19ms to download the response (i.e. the HTML)
71ms or so after that, the DOMContentLoaded event fires
After the page has completely loaded (after the images are all downloaded), the load event is fired.
DOMContentLoaded fires as soon as the DOM is ready. The load event waits until the whole page is loaded (including any external resources like images)
Most of the time in your request (other than downloading the images) is spent waiting for the server to construct the HTML. Maybe your server-side code can be optimized to run faster?