I'd like to know when does a web page appear the first time, especially in relation with events like the DOMContentLoaded or or the Load event.
If I knew the event in question then I could minimize the HTTP requests up until that point and lazy-load resources after that. My knowledge on the subject is admittedly limited and I know that it's a very broad topic but I'd rather like some practical info.
According to Google, this is the general sequence of events:
Process HTML markup and build the DOM tree.
Process CSS markup and build the CSSOM tree.
Combine the DOM and CSSOM into a render tree.
Run layout on the render tree to compute geometry of each node.
Paint the individual nodes to the screen.
According to Google again,
domContentLoaded typically marks when both the DOM and CSSOM are ready.
Together, I would say that in general, DOMContentLoaded is the closest event related to the painting of the markup, and Load is the closest event to when the rendering and loading of external resources is finished.
But, this could vary based on browser implementation, HTML version (4, 5, etc.), and probably other things I'm not thinking about.
Related
I am very intrigued by the excessive number of "composite layers", "recalculate style" and then "update layer tree" events in one of our webapps. I'm wondering what's causing them here.
If you point your Chrome to one of our fast moving streams, say https://choir.io/player/beachmonks/github, and turn on your "FPS meter", you can see that the app can achieve about 60fps most of the times when we are on the top.
However, as soon as I scroll down a few messages and leave the screen as it is, the FPS rate drops dramatically down to around 10 or even lower. What the code is doing here is that it renders each incoming message, prepends it to the top and scroll the list up Npx, which is the height of the new message, to keep the viewport position intact.
(I understand that scrollTop will invalidate the screen but I have carefully ordered the operations to avoid layout thrashings. I am also aware of the synchronous repaint that happens every second, it's caused by the jquery.sparkline but it's not relevant to this discussion.)
Here is what I see when I tried to profile it.
.
What do you think might be causing the large number of layer operations?
The CSS property will-change: transform on all elements needing a repaint solved the problem with too many Composite Layers for me.
I had the same issue. I fixed it by reducing the size of the images.
There was some thumbnails in the scrollable list. The size of each thumbnail was 3000x1800 but they were resized by CSS to 62x44. Using 62x44 images reduced the time consumed for "Composite layers".
Some info about the Composite Layers that can help
from what I see here it says
event: Composite Layers
Description: Chrome's rendering engine composited image layers.
for the meaning of the word composite from wikipedia
Compositing is the combining of visual elements from separate sources into single images, often to create the illusion that all those elements are parts of the same scene
so this the process of making the page we actually see by taking the output of coding/resizing images, parse HTML and parse CSS to make the final page we see
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)
I'm attempting to synchronize a DOMRange (representing a user-selection from a Cocoa WebView) to the original HTML source currently rendered in that view, as a kind of Dreamweaver-split-editor:
My first idea was to get the DOMRange object's startContainer and offset and walk up the DOM tree from there, accumulating the overall character offset up to the body tag.
Unfortunately this task presents some problems:
Clearly the document's outerHTML will differ from the original HTML source if the DOM was manipulated via Javascript or the parser needed to clean up malformed tags.
I can't figure out how to get the offset of a node within its parent text node (e.g., 4 characters to target in <p>some<div>target</div>text</p>), and normalize doesn't seem to make this any easier.
Trying to account for some of the problems in #1, or just going from HTML source to WebView will probably require separately parsing the HTML and then correlating the two DOM-trees.
One ray of hope is that HTML5 specifies a standard parsing algorithm for dealing with invalid HTML (which WebKit has since adopted), so in theory it should be possible to use an off-the-shelf HTML5 parser to generate the same tree as WebKit — right?
This is the most similar existing question I could find, but it's for a slightly different problem:
Getting source HTML from a WebView in Cocoa
Your problem #1 is actually not so bad; you can just turn off JS interpretation.
Look at QWebSettings::JavascriptEnabled, or just drop this in before you load any html:
QWebSettings::globalSettings()->setAttribute(QWebSettings::JavascriptEnabled, false);
That should leave your DOM un-mangled by JS. Good luck!
I have a gwt list grid which i need to show more than 1000 messages.
But it takes 40millsec to display each message. So it is very slow.
Can u help me so that i can show all messages in less time.
Thanks Nagaraju
As Bogdan said paging is your best bet.
However if your requirement strictly needs you to have the 1000+ lines at one time I would reconsider the grid approach.
When you are working with such a large amount of elements an iterative dom "touch" will be dirt slow.
See if you can rather create a component that gets the messages into String form with their markup. Then set the inner HTML once. You can then use something like jquery or gwtquery to attach handlers to the elements in a timely fashion.
Failing that you could use a lazy render method where you render only whats on-screen but that gets much more complicated.
Answering this 2 Year old question Just for Kicks -
GWT has progressed a lot since 2 Years.
GWT provides hell lot of options to User to do performance tuning.
GWT as done a lot of perormance tuning on widgets. GWT 2.5 has Cell
Widgets like CellList/CellTable/DataGrid which make displaying large
data easier , faster and with light weight heavy DOM.
Reference -
https://developers.google.com/web-toolkit/doc/latest/DevGuideUiCellWidgets
Summary -
Cell widgets (data presentation widgets) are high-performance, lightweight widgets composed of Cells for displaying data. Examples are lists, tables, trees and browsers. These widgets are designed to handle and display very large sets of data quickly. A cell widget renders its user interface as an HTML string, using innerHTML instead of traditional DOM manipulation. This design follows the flyweight pattern where data is accessed and cached only as needed, and passed to flyweight Cell objects. A cell widget can accept data from any type of data source. The data model handles asynchronous updates as well as push updates. When you change the data, the view is automatically updated.
In addition, cells can override onBrowserEvent to act as a flyweight that handles events that are fired on elements that were rendered by the cell.
Note -
1) CellTable being capable of displaying large data also come with Pager options and also AutoPage on Scrolling option ( example CellList )
2) Also, if you come across any other performance issues in GWT you can call in the Bazooka features of GWT - SpeedTracer, Logging, Chrome Dev tools Profiling, GWT Light Weight Metrics, Code Splitting, GWT Compiler Metrics, GWT Closure Compiler, Resource Bundling to crush it !!!!
1000 items for a web-based application is too much. Try implementing some sort of paging algorithm. You could look at the PagingScrollTable from gwt incubator ;)
I have an idea to implement a deep zoom type interface hosted in a browser for sports training data (speed, distance, heart rate etc.) However, rather than images I actually want to zoom into a hierarchy of information. For example, the initial display would contain a grid of years - hover over 2008, for example, and spin the mouse wheel (or click) will zoom into that year but during the zoom I want 2008 to fade out and be replaced with a calendar of months. Again zoom into a month and the months are replaced with the months calendar, zoom into a day and you finally see a chart with the training data plotted on it. All the time only dates with actual data would be highlighted in some fashion.
My question is whether this would even be possible and whether anyone has seen examples of this already. I'm imagining that most of the time the next level of information could be cached in the browser (in fact, because this is calendar-based, I can calculate most of that and cache the dates to be highlighted.) I could also zoom into an empty chart whilst an Ajax thread is fetching the data to display.
I've never tried anything like this before and I'm especially interested in whether DHTML would be capable of this sort of zoom (I suspect not and I would have to resort to Silverlight) and whether the Ajax execution would be uninterrupted whilst the browser rendering thread is kept busy zooming.
For Deep Zoom on images in JavaScript/Ajax there's the excellent Seadragon Ajax library by Microsoft Live Labs.
If you're looking into smooth and interactive zooming on content besides images such as text, video & vectors, have a look at the open source OpenZoom SDK I've developed over the last couple of months.
You probably could not achieve very smooth zooming with an javascript/ajax type interface, but a zoom interface would be possible. The pragmatic ajax book has a great chapter on implementing a Google maps clone. Theres no need for the technique to be restricted to zooming in and out of tiled images. The image elements can just as easily be any HTML you want. A fade effect could be applied to the zoom operation so when you move up and down a layer you get something similar to what you described. I recommend grabbing the book (Its a pragmatic programmers book, so theres a cheap and immediately downloadable PDF version available. Read the chapter, think about the techniques and then see if you think its practical for your vision. good luck.
Seadragon Ajax continues to evolve and is now OpenSeadragon:
http://openseadragon.github.io/
I've also been keeping a list of various zooming technologies, many of which use JavaScript:
https://github.com/iangilman/zooming
I don't believe ajax or dhtml are good solutions for what you are trying to achieve. I think flash/flex or silverlight may be the best option.
Check out the "scale" effect in jQuery. Here's a link. I haven't used it myself, but it might be able to do what you want. You'd have to swap out some content for different content at the right point, or your html would get too big.