I have a page which displays around 1000 records.
The page gets loaded quite easily on firefox..around 2 seconds. But same on IE taking more that 10 seconds.
I checked performance tuning on server side, and modified the hibernate Criteria query returning this whole data. But issue is still there.
I also tried to remove almost all the plugins from IE thinking those could be the culprits. But no impact. :(
Trying to monitor the UI components on IE developer tool, but didnt find much details.
Any suggestions please. :)
Thanks in Advance :)
Performance issues like this will be down to rendering the UI. The server side processing won't vary from browser to browser, so it will be down to the way different browsers handle the drawing of the elements. Without seeing your page in action it is not easy to suggest anything to help improve your situation.
Guys Got the Culprit here... :) :)
After doing lot of RnD on Server side and Client side, I took a look at "Developer Tool" in IE.
You can find something like "Document Mode: Quirks". If you check the Wiki page for this Quirks mode, You can find a definition as "In computing, quirks mode refers to a technique used by some web browsers for the sake of maintaining backward compatibility with web pages designed for older browsers, instead of strictly complying with W3C and IETF standards in standards mode."
So this all becuase of checking for compatibility for all components on page. And hence the performance issue. :)
And When I changed this mode to IE 8 Standard. Things started working really well.
IE and its issues ...!!!! :D
Related
I don't know if I should ask this here, but I really need your opinion.
I read and read many online articles about why you should don't care about old Internet Explorer versions (because it is really outdated and insecure etc). I have taken seriously all those articles and I started to don't care about Internet Explorer <= 11 when I redesigned and re-launched my websites.
Now, it's 2018 and I need to re-design my websites and add new features (because I got a lot of user feedback, and I have a lot of exciting ideas). And because I start it from the beginning I want to think again about this. I analyzed my stats and I'm still getting hits from IE8, IE7, IE6 and... IE5.5 (Windows 98 & ME)!
I know these versions are really outdated, insecure, but there are some people using old versions and old operating systems. I know I shouldn't care about these versions, but I really care about my visitors and their experience on my website (maybe there are people who live in the mountains or in poor villages, and they have a dial-up connection - why not?).
If there are such kind of persons, then:
Is there any reason why should I not create my new website to work even in Internet Explorer 5.5?
Why should I not care about webpage size, to be loaded fast even on dial-up or low broadband (Cable, GPRS etc)?
Thank you!
I think it's not generally a bad idea to consider IE when creating a new website, but there are some aspects you must consider.
You should do extra work to support IE, which includes more time and effort in the development. So you must ask yourself, is it really worth it?
Also you might ignore a lot of new APIs and features of JavaScript and CSS, to support older versions of IE. So you are probably affecting user experience of a large amount of your users, for a small section of them which are using IE.
Or you might use some libraries to detect browser support for certain features or using conditional comments (again, extra work to do).
Another solution might be to show a specific page to the IE users and encourage them to use a newer browser, which probably has no effect to a person who is still using IE5 in 2018!
Generally I think there is no complete answer to this question. It really depends on the goal, time and budget of the project.
Can someone explain me why TWebBrowser control is working so slow on all XE editions of Delphi including XE5 and possibly XE6? To test this you need to create a new Delphi project and put TWebBrowser control in it. On form show event, navigate to this website:
http://ie.microsoft.com/testdrive/Performance/setImmediateSorting/Default.html
Please test this on Windows 7 or later. When navigation is complete, run setImmediate test and watch the results. It will take huge amount of time to complete the test. It will take about a minute to finish this.
When you open true Internet Explorer browser and do the same thing - test will be completed instantly (~200 miliseconds).
Some additional wierd informations:
When you recreate this procedure on old versions of Delphi (Delphi 7 to be precise) the web-control works as fast as it should be working and test is completed instantly. But the HTML5 speed test will still works slow (alternative test on this page).
Another weird thing is, the same slow behavior can be seen on C++ Builder but not in Visual Studio products. Is Microsoft deliberately slowing down the TWebBorwser in Embarcadero products?? I can't belive this.
I was trying to overcome this problem with diffrent methods such as:
Trying different feature options in registry such as:
FEATURE_GPU_RENDERING,
FEATURE_BROWSER_EMULATION (11001),
FEATURE_ALIGNED_TIMERS (undocumented option),
FEATURE_ALLOW_HIGHFREQ_TIMER (undocumented option),
Setting timerBeginPeriod(1) - no effect.
Please, if someone have any clue how to fix this issue - share this information with me.
UPDATE1
I made standalone test app if anyone cares. It can be downloaded here: http://mp.org.pl/download/ietest.zip It contains source and exe app with htm file. HTM file contains some js procedure that works 10 times faster in standalone IE than in TWebBrowser control. It uses setImmediate as a test (the same procedure used in test described above). But it can be easier for testing this way.
I can also see the behavior described (in your original post and in the comments). I have a few thoughts, but not necessarily an answer.
One should expect some difference in performance between the WebBrowser control and IE, in part because your Delphi app will need to build in support for certain features/APIs that IE supports out of the box.
For example, the WebBrowser control fires notifications related to tabbed browsing (old, but relevant), but it does not intrinsically handle those notifications or update the UI. You have to respond to the notifications and draw the tabs yourself. By default, IE is hardware accelerated and uses certain Windows APIs that may not be directly supported by Delphi's VCL (for resource/performance) reasons. (Hardware acceleration could account for some of the performance differences you've noticed.)
(And, for the record, I don't believe a list of differences between IE and the WebBrowser control was ever documented. I certainly don't remember seeing one in the portfolio.)
Also, the default values for various feature controls vary between IE and applications hosting the WebBrowser control. Part of the reason for this stems from the idea that IE needs to highlight performance over compatibility whereas applications generally need to emphasize compatibility over performance. You may wish to review the feature control reference to see if there are other FCKs you need to enable for your app.
Second, your loops are very tight, perhaps too tight. You've got one request piling on earlier requests and you're not really leaving much room for processing, even with setImmediate. (IIRC, we're not really supposed to use anything smaller than 250ms for setInterval without risking performance hits from the sheer number of requests.) The remarks in the setImmdiate ref. page provide some guidance, as does this article on requestAnimationFrame.
One reason why dragging the window appears to improve performance may due to the priority of window drag repaint requests. They may be forcing your loops to hold long enough (or even break) to allow other events to process. Hard to say without with tracing the system with a debugger.
Have you ever had to add application.processMessages() to your Delphi apps in order to allow the system a chance to handle the work you've already assigned? A similar need may be coming into play given the nature of your test.
Performance testing and timing is a tricky thing. You need to make sure the test isn't imposing so much overhead that it interferes with the actual work you're trying to perform.
Finally, there were some questions about the document mode of the page as it's loaded into your project. When I first started messing around with your sample, I couldn't get project4 to load slowtest.html in anything other than IE5 quirks mode (notoriously slow). Here's what eventually started working for me:
<!DOCTYPE html>
<!-- saved from url=(0023)http://www.contoso.com/ -->
<html>
<head>
<meta http-equiv="X-UA-Compatible" content="IE=edge"/>
<script type="text/javascript">
...
(Note, I deleted your initial doctype declaration and rewrite it to resolve a syntax error that was being reported by the F12 tools debugger.)
A few style key points here:
I used a mark of the web to load the page in the Internet zone. I find this makes it easier to load the page in edge mode, as pages in the intranet zone are loaded in compatibility view by default (unless you map the zones differently).
The x-ua-compatible header needs to be one of the first in the head block. It can follow title, but not much else.
Stylistically, elements need to be specified in lower case these days. There's a possibility that not following the current conventions forces the parser to fall back to an earlier rendering that supports the conventions.
Once I was able to control the documentMode at runtime, I found results I expected: older document modes ran more slowly. I also found that using requestAnimationFrame instead of setImmediate led to even better performance, but also surfaced the timing issue almost immediately.
In the end, this may be a case where the test highlights a problem, but not necessarily one you're trying to solve. (Insert Inigo meme here.) I get that you're trying to resolve a bottleneck. Are you sure you've found the correct bottleneck?
You may not be able to replicate the same performance of the native browser, but perhaps you can refactor the code to perform adequately without the extra overhead? Is there anything that might be better handled with a worker or some other implementation technique?
Hope this helps...
Internet Explorer 10 has so-called compatibility mode, which can be activated to make older sites display properly.
If the compatibility mode is enabled, does it slow the overall pages performance and/or JavaScript? And is there any other impact apart from performance eg. overall stability, memory usage etc?
After a bit of thought, I think the answer to your questions is:
It depends.
It depends on what your site does with css. It depends what your site does with markup. It's entirely possible that some new CSS thing has come out in the last few years that IE 11 added very good support for, and the team of engineers spend lots of time optimizing. The old legacy way to do it might work, but be slower because it's old code that never got refactored and optimized. Imagine that repeated over and over... an old IE8 feature that now has a much faster IE11 css or markup equivalent... and you're not getting to leverage any of it.
Or, maybe your site uses none of that functionality, and it's (about) the same no matter which mode you're in. While the likely scenario is that you will probably see some sort of performance hit by running in compatibility mode, it certainly isn't guaranteed.
We have a website that a few people are complaining about it running extremely slow. We're struggling to figure out why and to even recreate it. Most are mentioning that it's running slow in IE.
It's not limited to any specific section of the site, just the whole thing in general.
There's been several developers creating/adjusting the code so it's overly bloated but we can't see any specific reason why this should happen.
Can anyone see why?
We've also run a speed test:
I was running a profiling test with IE on your website and there is a call to:
http://www.playforce.co.uk/-ms-transform.htc
Which is giving error 404 not found and taking 1 second to complete (0.91 sec).
If is found all around your css under this line:
behavior:url(-ms-transform.htc);
Am no expert !! Am welcome to better suggestion and corrections of what i am about to say
You can try using a trial version of Borland Silk meter ..
They tend to measure the speed with which each element loads using various browsers and various geographical locations which are configurable by you.
Also , since only some of the user's are complaining about the speed being an issue you should also check the speed of their internet and their browser version and other addon etc of those users. Because sometimes the problem is not only with the server .
Try the above tool to confirm nothing is wrong in your server and then proceed to checking the client's browser and network.
I've been building a site, running Wordpress 3.2.1 and noticed
the performance is sluggish in the front and back end.
I believe the problem is hosting specific.
The problem seems to be the connection loading the actual HTML
which is taking about 5.5 seconds. It appears to finish after
about 500ms, but does not stop loading for 3-4 more seconds.
Here is the development URL:
http://d1001488.u57.ukisp.com/dev/
Hosting:
Windows NT
PHP Version 5.2.10
There are a couple of jQuery select boxes that get
replaced and styled onload (in the footer), these take a
long time to get replaced after the page fully loads.
The hosts are claiming all is running properly. Is there
any thing I can try and tweak or monitor to see what
is going on? Or any suggestions?
Thanks.
For largely extrinsic causes, try YSlow. This will identify a number of things you can work on. It won't tell you anything about the internal behavior of your server, but it may help you narrow down what's going on.
The problem may be a specific plugin. Here's what I would recommend:
Try going through each plugin, deactivating it, and see if that makes your site load faster. Do this for each plugin, and if a deactivated plugin doesn't improve performance then just reactivate it and move to the next one.
Try temporarily activating the default Twenty Eleven theme. See if the default theme loads faster. If it does, then we can look at your custom theme.
These two things may help narrow down at least where the problem is coming from. Let me know how it goes!
Do you have CPanel access with your hosting account? If you do, look in the left side toolbar at the bottom you should see where it says server status (click to view) you will see various details about your server performance.