When using an application developed with backbone.js Chrome freezes for about 7-10 seconds when adding to the DOM the content of a large document that has been retrieved with an AJAX call. Chrome's event timeline shows that the main issue is a single 'layout' event that takes about 6-8 seconds (times measured in a modern MB Air if that matters)
The content being loaded is about 800kbs of uncompressed HTML, 15000 DOM nodes, memory usage after the content is loaded is about to 30-35 Mbs; it's a large document but such a long freeze just doesn't feel right.
is such a large "layout" time to be expected for a document like that, or is this a sign of other issues? (like too complex CSS rules, bad HTML structure, etc.)
what other factors besides document size may have an impact in the performance of the 'layout' event?
besides the obvious and probably right solution of breaking the content in pieces, is there any trick that can be done to make it easier for the browser to compute the layout event? (I am thinking in something like placing the monster content inside an iframe or a div with fixed positioning, or avoiding specific CSS features inside the content)
Related
In brief: I've got a page with KO-code that operates absolutely cool in Google Chrome, Firefox, Safari, etc. But the performance is gone in Internet Explorer. I tried IE10, IE11. It takes from 10 to 25 seconds to render about 150 rows.
Details: There page represents a work queue for users, where their tasks are shown. The requirement is not to use any paging on that page. Each row of the table has at least a dozen of variants to display (links, buttons, inputs, css styling, handling user events, custom js plugins, etc.). The average number of rows on prod is 100-200+. User is able to apply different filters and sortings.
Things I've already tried:
reduced the number of computed properties (changed to pureComputed, where possible)
reduced the number of using the template, if and ifnot bindings (according to profiler they are the most time consuming task) - I use the visible, where possible
tried to use the knockout-fast-foreach custom binding (https://github.com/brianmhunt/knockout-fast-foreach)
profiled the code with IE and Chrome tools to eliminate the memory leaks
profiled the code with ko.bindingReport.js (https://gist.github.com/kamranayub/65399fa247a6c182bc65)
The approaches specifed above tuned the code (according to ko.bindingReport.js) almost two times faster in Chrome. But IE is still too slow - about 10 seconds for rendering.
Chrome:
Internet Explorer:
Folks, any ideas?
"The table binding provides a fast method for displaying tables of data using Knockout. table is about ten times faster than nested foreach bindings."
This claims to be 10x faster.
https://github.com/mbest/knockout-table
You reduced the amount of computed observables, but did you also reduce the amount of observables? I'm not seeing a lof of editable fields. The ones that are not being edited on the page probably don't need to be an observable? This has boosted my performance quite a lot of times.
My website for architectural visualization: http://www.greenshell3d.com
I noticed on the networking tab / incognito it takes 15 seconds or so to load the above-the-fold content. (most notably the image slideshow.)
Some of the images in the slideshow load at the very end instead of the beginning of the website load process. Now I understand the browser handles this order, but perhaps there is another way. As it stands, the bounce-rate is too high and I expect it is because of load time.
I've seen a jquery snippet on github that allows one to control the order of image loads - do you think this is a good option? I'd be glad to hear any opinions before investing the time to fix this.
Any ideas? Thanks!
You said you are interested in any opinions as well, so first some general thoughts: There is no page fold. The web that we produce content for exists in so many different screen sizes + resolutions that it’s impossible to say "The fold is below this big image!". Yes, Google changed the pagespeed insights tool to make people load stuff on top of the page first, but I think their wording there is really bad.
Now to your image loading issue:
The first thing I would recommend is to reduce the size of all the images. They seem to be around 280 - 300 kb per image and you have a few of them. Since there is a translucent overlay over them anyways you can probably get away with reducing the image quality without people noticing it (because they don’t see the image directly). Play around with the values here.
I would then look into optimizing the code for the slider to load the first image first, then the rest of the page and the other images asynchronously maybe after that. Another trick could be to increase the slide fade time from the first slide to other slides so the slider doesn’t change if the next image isn’t ready yet. You said you found a jQuery script to implement that, that’s where I’d start.
As a general guideline: the position of requests in the source code usually determines the load order of things on the page. If your images are requested by JavaScript at the end of the page, that lead to the images being loaded later than you want them to be loaded.
I can't find an answer to this question, when the browser takes an SVG from the cache does it re-compute the xml or not, does it store the 'IMAGE' that it has already created? (How?)
I would've have thought not, but then I've noticed how fast repeated svgs load.
I've also noticed slowness on a page logo (in mobile browsers) which make me think THEY re-compute the SVG, so i've moved to PNG's (which are obviously cached) for mobile to save a lot of computational work for the low end phones.
So maybe, does the answer depend on the browser / browser type / browser settings?
*my svg's are compressed svgz's by the way
Sometimes it does and sometimes it doesn't. Most browsers go to some effort not to rerender things unless they have to. There is a buffered-rendering property in SVG 1.2 Tiny that may help if you're using Opera, other browsers try to do things automatically without requiring such hints though.
Browsers generally don't cache SVG content as a simple bitmap though. They do cache things like the absolute position and size of shapes and text with transforms applied, the css tree structure, gradients etc and then use this information they can redraw the content much more quickly than having to work it out each repaint. Such information allows browsers to copy with javascript and SMIL animation of parts of the SVG content as well as user scrolling.
Link to article
A single HTML document can contain one or many 'page' containers
simply by stacking multiple divs with a data-role of "page". This
allows you to build a small site or application within a single HTML
document; jQuery Mobile will simply display the first 'page' it finds
in the source order when the page loads.
I'm wondering about the limitations of this.
I'm building a site for a gallery exhibition which contains 340 images and 19 media files (audio and video)
The exhibition is divided into 16 seaprate galleries, each containing anythign from 4 to 90 images each.
Is this method descibed by jQuery mobile possible?
Obviously i'll be keeping the image size reasonable for this.
Thanks
I haven't built anything that large even in my demo time playing with jqm, but if you start to see your entire page document being more than say a 1MB in total size with images, html, css etc you are going run into some longer than recommended load times. I recommend checking this with google speed tools - It will give you a nice graph of all your resources loaded and the total page size (you will need to be on the dev channel of google chrome to use this tool)
I'm curious to see how usable this ends up. Let us know. If you do run into issues you may just have to find some logical points to split your document or possibly look at using json & flickr api to load some of your image galleries.
My website seems to take on this "squeegee" type load effect, where all of the graphics load from the top down with an ugly top to bottom wiping effect. Is there a way to make the actual way in which your website renders graphics prettier?
I'd be more interested in why your page is taking so long to load and/or render. If it takes several seconds to draw, even on a fast connection, you might want to look into why that is. Tools such as Fiddler, Firebug, IE Developer Tools, etc can help you look at what resources your page is downloading and how big each research is.
If you have massive resources on the page (such as BMP or PNG files that are several hundred K), see if you can convert them to other formats or resize them on the server to the size they render at.
If your HTML is massively complex, such as huge nested tables, you might want to look into simplifying that with more modern HTML and CSS styling.
If you do have huge, high-res bitmaps that need to be loaded, you might want to preload them with script and then render them dynamically when they finish loading.