I am familiair with tools like pagespeed, yslow, firebug, dynatrax.
Sadly they won't help me, because I need to measure it in a browser called PocketBrowser from Motorola (PB2.22) on a PDA(MC55)
So I need some custom plain javascript which can help me get very close to the actual rendering time of a page in that specific browser.
A normal browser is fast enough so I don't have any issues at all there, but in the pocketbrowser it's too slow.
Related
One of my web components is taking a long time to render in chrome (multiple seconds of screen freeze when it loads the data).
The same component renders almost instantly in Firefox.
When debugging performance, I can see that a lot of time is spent rendering in chrome, but I can't see a way to dig into it to see if perhaps there's certain style rules that are taking a long time. The other tabs seem to only indicate which events caused a re-render, rather than breaking down the rendering time itself.
There are multiple ways to minify your rendering time:
Minify Unnecessary Codes.
Limit The Number of External Resources in the HEAD.
Defer Loading Javascript. ...
Make Use of HTTP/2 Protocol.
Cache on the Client-side.
Articles:
https://web.dev/critical-rendering-path-render-tree-construction/
https://edgemesh.com/blog/how-to-improve-your-website-start-render-time
I have large CSS rules which are mainly based on CSS3 transitions.
When I check the rendering time for a typical page with online tools like webpagetest.org or developer tools like firebug; the rendering time is extremely different in various browsers. For example, MSIE: 1.5s, Chrome:2.5, FireFox:47.0.
How can I debug which part of my CSS has caused unusual problem in FireFox?
Common tools like firebug only shows the total rendering time, and does not show which process (DOM and its CSS rule) is slow and blocking.
How to find the slow process in CSS rendering of FireFox?
No, unfortunately, we don't have anything much better than trial-and-error right now (see here). Chrome's native dev tools currently give us the most complete information about rendering and, from what I've heard, that's one of the most common requests they get.
As far as third party tools, ones that measure this at all are relatively rare. I knew of 2 in the past that I no longer use (http://ejohn.org/blog/browser-paint-events/ and http://www.browserscope.org/reflow/about). Mostly these help you know when repaints or reflows happen and estimate how long they take total.
However, CSS Paint Times and
Profiling CSS for fun and profit mention ways to do profiling by property, but, if you look, neither is probably what you're hoping to see.
Is there a definitive way to measure "time to paint" for performance? and
How to measure browser layout performance
provide related information.
Also see http://jankfree.org/, which has up-to-date information and no links to a tool that automates the current trial-and-error approach.
I would like to know if it is possible to modify Chrome or Firefox display settings, so that it would only show rectangles of HTML DOM objects? What I want to do is to decrease rendering engine job amount as much as possible, so it would only build layout of the page.
People usually refer to this mode of operation as "headless" (i.e. without UI).
Usually there's an additional requirement - to be able to run it server-side without the usual for client software installed. If you're running it client-side, I wouldn't bother about optimization, it shouldn't give you a big win anyway.
Otherwise, try searching using that term. I've seen it asked for several times, but haven't seen a working out-of-box solution.
[edit] just saw http://hg.mozilla.org/incubator/offscreen, which seems to be a headless version of Mozilla.
I wouldn't go as low-level as modifying the renderer. Instead, I suggest you use Firefox's Greasemonkey to replace the elements from the page with whatever it is you need. You'll need to know a bit of JavaScript, but it's not that hard.
However, this will only work on client side. If you want to do this on server-side ( so that it will work on any page a user requests through your own ), my guess is you'll need to grab the page's content in a string, and then modify it using a HTML parser.
Our web application renders fast in some IE browsers, slow in others... It seems to be an HTML rendering problem... The first 10% of the page displays immediately, the last 90% takes up to 10 seconds, and this is static content. I've run with firefox/yslow, renders very quickly. Seems to be isolated to some users/configurations of ie. Quirks mode does not seem to make a difference.
Is there a tool or application that I can use to help me discover a rendering bottleneck? Am I doing something egregious in my code? Could it be a javascript issue? Any help or suggestions will be much appreciated. thanks.
Use Fiddler to look at the times to load images, css, js files, etc. In other words, is caching a problem? Javascript can definitely cause issues in different browser versions. There's lots of optimizations you find in some versions that aren't in others. Also, make sure your html is well-formed xhtml if possible. How the page is arranged can also affect life. If your document tree is deep, it may need to wait to render large sections until it reads all the child nodes. Another thing to note, certain toolbars and plugins do look ahead loading and can slow down life. An HTTP Proxy can help you watch what's going on network-wise at least.
Not sure if anything of those ideas might help your exact problem, but they can help life overall.
If it runs fast in FF or Chrome then it's a javascript issue for sure. IE7 is VERY slow in processing large amounts of script and complicated HTML. We had a sharepoint page that took 10 seconds to render in IE and sub 1 second in FF and Chrome. We benchmarked the page by adding a timer to the server-side processing and sending the output to the client via a Response.Write(). By doing this we could determine the server time to process the page and the client time to render the page (since you would see the timer results on the screen and then wait 10 seconds for the rest to render). The bottleneck was 100% IE on the client. This also explained why the speed was variable on different peoples machines, because depending on how fast the client machine was the page would render at some speed between 8-15 seconds.
We even had MS look at the issue and they confirmed that IE has a "rich rendering" engine which is slower.... IE8 runs much faster but that is no help to anyone today.
Are you using any behaviors in your CSS? I've seen behaviors bring an app to its knees if too many are used and/or if they affect too many elements. Check for any .htc files lurking around.
Of course behaviors only pertain to IE and they use JavaScript, so I'm sure different IE versions handle them more competently than others.
There is a special tool for such scenarios called dynaTrace which is available for free at this website:
http://ajax.dynatrace.com/pages/
This tool could really help you out because its tracking almost everything and its specially build for IEs.
Check for memory leakage in the script.
http://www.javascriptkit.com/javatutors/closuresleak/index.shtml
Steve Souders gives an excellent presentation on 14 (simple) steps to improve the performance of your web pages:
http://developer.yahoo.net/blogs/theater/archives/2007/08/steve_souders_high_performance.html
If it's hanging in the middle of the page, the first thing I would personally look to do is ensure or move all my JavaScript is at the bottom of the page.
IE is great at being a bad performer, particularly with JavaScript, so if you move it to the bottom, IE can render the page, then get on with processing the JavaScript.
I use HttpWatch for troubleshooting linked assets (images, script, css), network or HTTP related problems in IE. There's a free & paid version. Free is fine but you lose out on some nice features.
While browsing with Chrome, I noticed that it responds extremely fast (in comparison with IE and Firefox on my laptop) in terms of rendering pages, including JavaScript heavy sites like gmail.
This is what googlebook on Chrome has to say
tabs are hosted in process rather than thread.
compile javascript using V8 engine as opposed to interpreting.
Introduce new virtual machine to support javascript heavy apps
introduce "hidden class transitions" and apply dynamic optimization to speed up things.
Replace inefficient "Conservative garbage colllection" scheme with more precise garbage collection scheme.
Introduce their own task scheduler and memory manager to manage the browser environment.
All this sounds so familiar, and Microsoft has been doing such things for long time.. Windows os, C++, C# etc compilers, CLR, and so on.
So why isn't Microsoft or any other browser vendor taking Chrome's approach? Is there a flaw in Chrome's approach? If not, is the rest of browser vendor community caught unaware with Google's approach?
Chrome's approach is difficult to write, and requires forethought from the developers. IE and Firefox are both attempting to move to a process-per-tab model, but due to backwards compatibility are not able to transition quickly. Chrome, being an entirely new browser build on a clean rendering engine (WebKit), was easier to write in this way.
They have crossed over from a web browser as a tool to view web pages, to a tool optimized to work for web applications. There may be some flaws in this initial release, but they are changing the game.
IE8 uses a similar individual process per tab module, though they do not use a single process per tab, but instead spread all tabs across a process pool.
#pix0r but they added a little thing in the bottom right corner so you can expand the text box any direction you want, which I love because I use a wide display and prefer to type in a wider screen.
Thats actually a WebKit feature, Chrome just inherited it.
Virtually all of these features existed in other browsers before Chrome. IE8 had process isolation for tabs. Firefox / Safari had most of the JavaScript stuff. Most browsers do their own memory management.
Chrome has a few unique features (hyperrestricted render processes, etc) which are difficult to put into other browsers due to add-on/application compatibility concerns.
The primary thing Chrome has going for it is an extremely hardcore focus on minimalism and high-performance. By focusing on these as their competitive advantages, they can appeal to users who find this area of focus compelling.
As time passes, I'm sure you will see the homogenization of features as the browsers attempt to one-up each other.
In the meanwhile, I still stick with Firefox over Chrome for the simple reason that Firefox is (i) non-profit and has a (ii) huge addon community.
Addons such as NoScript and AdBlockPlus are almost essential for me.
One chink in Chrome's armor is the fact that it renders these darned textareas on StackOverflow are so small that it's making my eyes bleed!
One chink in Chrome's armor is the fact that it renders these darned textareas on StackOverflow are so small that it's making my eyes bleed!
Yeah. I mentioned this on uservoice and got declined because the current size is evidently the default under webkit. Every other site I've tried with Chrome that uses textboxes to compose content manages to have a decent sized font. The default definitely doesn't work, but there's obviously some way to override it. Jeff needs to fix this!
Edit:
Jeff was nice enough to point out how to fix this problem yourself.
#pix0r but they added a little thing in the bottom right corner so you can expand the text box any direction you want, which I love because I use a wide display and prefer to type in a wider screen.
I also wanted to point out that Google completely built Chrome from the ground up, with the exception of using webkit, so they have some of the advantages of not having to not deal with old-code. And of course there is the INSANLELY cool/smart developers.
The biggest chink I've found is its lousy proxy support compared to IE, FF and Opera. So it's pretty much useless at work, render pages at random, and requesting authentication for the proxy, where the others pass it seamlessly.
That said on my home machine it works great, if it wasn't for the OTT EULA I'd use it now.
thing2k
One "flaw" about Chrome is that it uses more memory upfront than all of the other browsers. I'm just guessing that this is due to the overhead associated with all the separate tab management.
After it's been open for some time, however, it doesn't use more memory than other browsers.
Many companies play a game of "What's the least we can do to get the leg up?" Marketing creates a laundry list of features needed to be better than the competitors. Project management ensures engineers stick to those features for fear that the project will exceed the time allocated... which of course it will. There's not a whole lot of room in such a system for a big picture leap-ahead. The incremental improvements you see in products, and browsers, is a consequence.
You have to keep in mind that Microsoft primary business is Rich environement (GUI) Application. Web tool is a threat to them as it is platform independant (not promoting they main product).
Of course the IE team probably had figured something like that but... Microsoft definetly won't invest a lot of money in IE if what they are selling is a Rich application platform.