Is WebKit too fast for its own good?
Let me start by saying I have the utmost respect for the WebKit team, and all the amazing things they have delivered with their rendering engine. Also, very important, for putting pressure on other rendering engine vendors and making them step up.
What I would like to talk about today is the rendering speed in WebKit. As we all know, it is very fast and has gotten very good standards support, combined with a number of new exciting features.
But, as of lately, when testing a couple of web sites I have worked on, I have experienced rendering glitches in both Google Chrome and Safari (both based on WebKit). Or rather, inconsistencies. It always loads very fast, but it’s just that things might look weird (as in things not positioned exactly where expected, miscalculated height values in script after the
Let me be the first to say that it might just be my code that sucks, that I should try another approach in some scenarios and that there’s no more to it. However, these web sites/pages have never once shown any inconsistencies in Firefox or even Internet Explorer, which does makes me wonder.
Currently we have a performance war between web browsers, and we all know that rendering speed is a quite important part in creating a good end user experience. But, if this is at the cost of inconsistent rendering, I don’t want it, and it makes me wonder if the WebKit rendering is sometimes too fast for its own good?
Am I the only one who has experienced this, or have you seen this too?
You know, software doesn't make mistakes because it goes fast. 🙂
But programmers optimizing code may.
I have yet to run into those type issues with WebKit based browsers.
Maybe you're just dreaming Robert?
I don't understand. How do you jump from "rendering speed" to "inconsistent rendering"?
I've had some issues in WebKit when the page loads so fast that it neglects the height of images (if they are not cached) causing weird looks. I haven't really dug to much into the issue but for now I guess the solution is to specify height and width attributes when possible. Sometimes it feels like it doesn't render top to bottom, but rather in it's own way, it's hard to tell, maybe I'm just my imagination (or crappy code heh).
Even thought it may be inconsistent, webkit (safari) is now my choice of engine when surfing, because it doesn't bog my entire computer down (like Firefox does) when using a lot of heavy-duty web apps. So YAY for speed wars! The only thing of course, preventing me from the full switch is the most invaluable developer tool ever (no mention needed).
I have tracked numerous bugs in Bugzilla for Mozilla where they implement a feature that is also in Webkit. It is striking how often they find inconsistencies in Webkit as part of their own procedure. My estimation is that.the.Webkit team. prioritize being first (as in Acid3) while Mozilla prioritize being thorough.
Of course .examples exist where the opposite is true.
What I think Robert is thinking about is that the team's focus om speed has lead to some bugs as a result of certain performance-tweaks. And I have seen some examples of that as well.
Same question as paul:
How do you jump from “rendering speed” to “inconsistent rendering”?
I've almost completely switched over to Chrome because of its speed, but I too have noticed rendering glitches. On one particular site I use both :first-letter and a custom font and on some loads the whole page is all over the place with an infinite scrollbar and other weirdness on others there are only minor glitches but it's almost never the way it should.
Using Ubuntu and Chrome 5.0.307.11 beta
@Paul and @Christophe: the rendering speed of Webkit or any rendering engine is not pure optimization of each step of the rendering. A good deal of it is using clever parallelization. All rendering engines start rendering the page before they get all the necessary information. And many steps in the rendering process require other steps to be complete. Sometimes you can work around that, make clever guesses and still parallelize stuff—but this means your guesses might be wrong, so you have to correct your assumptions.
The more aggressive you have with parallelization and clever assumptions that let you do some work earlier (and thus get better overall rendering speed), the more risks you take.
Doesn't DOMContentLoaded just mean that the HTML is loaded? If that's the case, then image heights or CSS might not be rendered yet just the HTML so behavior can be added to the page.
Thanks for your comments!
Right, it might be due to that.
I wish I was…
Sorry if I wasn't clear, but to me it's a given that when you try to optimize really hard for performance, you're bound to introduce some scenarios during certain circumstances – just like Michael and Florent explained above.
Interesting, and yes, I believe part of it has to do with images and their rendering.
I have heard that too.
Exactly, and good to hear I'm not alone in seeing them.
Interesting, haven't seen that with the <code>:first-letter</code> pseudo class so far.
Thanks for a very good explanation!
Good point! But if image dimensions have been declared, shouldn't that part of the page be reserved when <code>DOMContentLoaded</code> fires, even though the images haven't loaded?
I think this information is relevant: http://webkit.org/blog/66/the-fouc-problem/
And this: http://lists.w3.org/Archives/Public/public-html/2…
Well, my problems haven't really been like the regular FOUC problems, but it's still an interesting post about how it works. Good digging! 🙂
I think I have even seen weirdness with the google chrome home page the new tab option with your top sites displayed.
After a refresh its fine.
Have seen problems a few times, where it loads weirdly. If you then refresh it looks fine. So does seem inconsistent.
But again hard to tell if it's bad code or not…
Yep, hard to tell. But still, inconsistency is never a good thing.
I experienced the same problem. If for example some images have not set any dimensions on page load you couldn't use these dimensions to calculate with them in any webkit browsers. So, a solution is to set dimensions before. But what if you, for eg., want to let your users to generate images for page headings dynamically with different fonts and font sizes trough the cms. you don't know which dimensions the genereated image gets.
Exactly! With completely dynamic content, knowing the dimensions isn't always an option.
I’ve definitely encountered a weird webkit rendering bug. To test, setup two paragraphs of text using the same image file floated to the left (without a height and width). The first image will render properly, the second will be overlapped by the text. Hitting refresh either makes the bug show or disappear depending on if you’re using Chrome or Safari. My fix was to set in HTML the height to the image. It definitely gives the impression that the browser is rendering too fast but I think this is a symptom of parallelization that @florent was talking about.
Yes, it’s seems to usually be image related and in regards to the dimensions of the element.
I’m experiencing the exact bug you describe in a charting app I’m developing. The doc loads and the dynamic content is generated before css has burned in. Any fixes?
It could be images. If possible try to specify their dimensions with width and height attributes.
I’m getting the same problem in Chrome also. Inconsistent rendering, which works fine in both Firefox and IE.
Specifying display:block fixed the problem for me.