We are running a web service, that is struggling with some pretty high page rendering times especially IE8 (around 20 sec). We are very skilled at building high performing backend systems, but not as skilled at optimizing the frontend.
Currently it seems (from newrelic) that page rendering and dom-parsing is the biggest issue.
We have tried to optimize js scrips, and that helped a little, but still the page renders terrible slow in IE8, and I have a feeling that some low hanging fruits is out there. My problem is, that I have really no idea where to start, and what would work and if there is some red lambs flashing that I'm not seeing. I need an experienced eye.
Can any one help me in the right direction (I'm open for everything!)?
The slow page is here: the slow page
PS. we are running Rails 3.2
I recommend you to analyze your website via the tools above (YSlow is also a good tool)
Or with this Online-Tool Pingdom. There you'll see in a very easy way, where your speed is gone.
Theres a free available summary from the performance optimization books in Hooopo's answer (which are excellent!) Yahoo! Developer Network
"Currently it seems (from newrelic) that page rendering and dom-parsing is the biggest issue." Therefore i recommend you to study this book: High Performance Javascript from Nicholas C. Zakas.
Put as much JS as possible to the bottom of your page to improve progressive rendering.
I sometimes found CSS-selectors that are a bit long (doesn't matter if it's a small site, but in this case..). this can make your page-rendering very slow, especially in IE.
Example (from your site):
table.results_table td.car_details .content > .left { ... }
Try to break down this large selector to this (if possible):
.car_details .content .left-child { ... }
Short: optimize your JS performance and keep your css-selectors as small and simple as possible.
Hope this helps.
To optimize the front-end, try these two tools and follow its suggestions:
http://www.webpagetest.org/
https://developers.google.com/speed/pagespeed/insights
You could also use css sprite image to reduce http requests. Try https://github.com/Compass/compass-rails
Recommend two books to you:
http://www.amazon.com/High-Performance-Web-Sites-Essential/dp/0596529309
http://shop.oreilly.com/product/9780596522315.do
Related
I want to capture chrome performance summary. Scripting, Rendering, Loading, Idle and Other time programatically. I want know is there any metrics lighhouse generates which I can use?.
I have tried https://github.com/axemclion/browser-perf. It doesn't calculate Other and idle time. I looked at chromium source code (TimeLineUtil.js) to see if I can use the same logic to capture these details. It seems bit complex. Thought of asking this question here. If anyone already implemented the same.
You are probably looking for The Page Speed API: https://developers.google.com/speed/docs/insights/v5/reference/pagespeedapi/runpagespeed#response. Or is that insufficient?
I have a reoccurring problem with Safari and Chrome on iOS freezing when a Select is focused. I've seen some older posts about this but with no resolutions.
I have a page with a fairly high number of HTML inputs and selects. I tried to design the page in a way to use DIVs that look like inputs to lower the overall count, but some of them are still needed.
Here is the page in question:
http://www.pokedit.com/pokemon-maker/index.php
The page doesn't always freeze when focusing, but when it does, it's for a long time and the browser usually crashes.
Info:
There are some selects on the page that are display:none or inside hidden DIVS. Some of those can be revealed by changing different toggles.
There are no input type="hidden" inputs on the page.
The freezing problem does not happen in Android, Windows, Mac, or Ubuntu in any browsers that I've tested.
Since Apple is an amazing company and designs their software well, you're going to have to compensate by heavily altering your design even though it works fine in every other modern browser. Think of iOS as the EI 6 of our time. It's sure to leave a legacy.
Now it's back to the drawing board for you and anyone else with this delightful technicality. You're going to enjoy wasting lots of time writing code to do things with basic functionality that selects and inputs are already supposed to do. That will ensure your pages can load just a smidgen slower whilst wasting a bunch of time and effort writing extra code for no reason at all.
Special thanks to Steve Jorbs.
Having decided to go with D3.js and SVG for visualizations it now looks like SVG will work fine in a desktop browser or native shell but I'm really perplexed by the drop in performance speed on the iOS mobile platform.
According to the following tests it now looks like SVG performance is getting better and not that far behind Canvas speeds, this is the good news:
http://bl.ocks.org/2647924
http://bl.ocks.org/2647922
The bad news is that if you run these tests in the Safari browser on the new iPad the speeds drop a lot for both SVG and Canvas. The terrible news is that if you run these tests in the new Chrome browser for the iPad the speeds drop much more.
I've read that Google is forced to use the UIWebview that is not accelerated by Apple's Nitro JavaScript engine. I've also read that Apple is pushing HTML5 but the demos only run in their own Safari browser.
What is the problem here anyways? The best target for my app is mobile yet even with great API's like D3.js and HTML5 standards like SVG performance is being pinched, is this just because Apple wants to hold up progress for their own agenda? Thats how it looks to me anyways. I'm not sure what these tests look like on Android? It would be great to know. If the tests would be positive maybe I will get rid of the iPad and just go with Android already.
The bottom line is that I'm just not sure if it is feasible to make my app using HTML5 technology due to these speed issues? I also have no interest in learning Objective-C as the future is going to HTML5. I believe in the web and its standards but it looks like they are being blocked. I'm very interested in knowing solutions to this dilemma.
iOS7 has notably bad performance animating SVG with JavaScript - although static SVG drawing is massively faster. We wrote a blog on the performance of the iOS7 release, which you can see for more gory details.
Update: iOS7.1 fixed the javascript animation performance problem. It's back to 50 fps
I found d3.js/SVG on my first gen iPad massively slower than running the same app on desktop browsers (FF/Chrome/IE 9+).
I wrote up the various improvements I attempted here: http://hivemindmap.blogspot.co.uk/2013/01/html5-and-interactive-graphs.html
Performance will usually be lower on mobile devices than on desktop kit. In general their hardware is less powerful (it's geared more towards low power consumption than outright speed) and they have a hell of a lot less RAM and storage to play with. Chrome on my desktop has multiple processors, 8gb RAM and a ludicrously powerful GPU at it's disposal. On my iPad it doesn't have anywhere near that level of power.
3rd party iOS applications (including Chrome) cannot use Nitro, that much is correct. I believe this is because Nitro is able to mark memory as executable and (for security reasons) 3rd party applications are not trusted to do that. Most HTML5 stuff will work in any browser on iOS (with the possible exception of Opera Mini). Canvas and SVG animation will be slower than in Safari because it's all driven by Javascript - again the lack of access to Nitro holds them back. This is no longer true: As of iOS 8 third party apps can now use the WKWebView framework which does have access to the same high speed javascript engine as Safari.
Native code will usually be faster because it's much closer to the hardware, hitting the display APIs directly, rather than going through the web stack.
The solution is usually to simplify everything. In the same way that native game developers had to massively reduce the complexity of their 3D games to make them work on iOS devices, so web developers have to reduce the complexity of their SVGs and canvas apps. Less stuff flying around the page means higher performance, in general.
There's a number of tricks you can do, and a lot of reading around the subject. Have a read of http://www.html5rocks.com/en/tutorials/canvas/performance/, http://www.html5gamedevs.com/tag/performance/, and the rest of Google. Personally I'd build a proof of concept and test it before completely abandoning the idea :)
Designing a web application with ASP.NET MVC I asked myself how can I also please those people using a smart phone, ipad, etc.. (everything thats touchable...) and not only a desktop/notebook with a browser.
How can I develop a better user experience.
I would be pleased to hear about technical advises concerning the asp.net mvc framework so I can later implement your suggestions concretely.
There are a few levels of friendlyness. You can start with the basic "does this site render well enough to be usable in a mobile browser?" This really should not be a problem for anything new that is using modern web standards but older sites could have problems. Corallary to this is "is my site a bandwidth hog that takes forever to render over 3g because each page is 14mb of animated GIFs and spaghetti HTML?" Or "does my site make mobile devices melt due to aggresive scripts?" Luckily this set is pretty easy to deal with -- modern websites tend to handle this pretty well by default.
The second level is "does this site do anything maddening from a touch perspective." The big thing that can clip you here is hover based menus -- there is no hover on a touch UI. The other common issue is using small links or buttons that one can't hit at least without zooming in to crazy levels. The solution here is testing -- some issues are obvious to all but you won't see some things until you are interacting without a mouse.
The final level is using a touch UI for fun and profit. If you make it this far, you are doing better than many web publishers in this day and age. What is involved here is using touch-friendly UI tools, such as jquery mobile, to handle swipe events and other touch features to make things work more like one expects with a touch UI. An easy example would be making an image carousel swipe-able rather than having to wait for the buttons.
Make the interface chunky - big icons are easy to click, text is very difficult to touch accurately. Set a minimum size for every element, at the very least as big as the individual keys on an iPhone/android's virtual keyboard and preferably much larger.
Ensure that the most relevant options are near the top, and after that the aim is simply to make it intuitive. Fewer menus are generally better.
Go through my tutorial ASP.NET MVC 4 Mobile Features
create mobile-specific views.
-use the HTML5 viewport attribute and adaptive rendering to improve display on mobile devices.
I'm looking to revamp our mobile site with something simple for phones below the ambiguous smart phone category and something a little more interesting for the phones above this category. I'm not interested in WAP/WML for this project. I'm building a ASP.Net 4 MCV 2 app and using MBDF
What I'd like to know is how best to define this differentiation when using MBDF? Screen size, Javascript, SpportsTouchScreen etc. are all in MBDF along with others but I'm not sure where to draw the line and where the data is most accurate for the broad number of devices.
What do those of you out there developing for this spread of hardware & software split on?
Thanks,
Denis
P.S. I've done my research on xHTML MP1.0 - 1.2 and the best practises for implementation to ensure broad coverage but I don't want to restrict the newer phones out there to what the base line can see.
I personally use simple mobile browser dedection script and limit max screen width to 240px. I also use simple AJAX and JavaScript calls too.
Above setup works fine for 90% of my visitors but my sites aren't business critical sites.
You can try http://wurfl.sourceforge.net/ but .net api is not as good as PHP one
So after a bit of testing myself I think I'm going to stick with testing if they support JavaScript and Touch using the MBDF. This line in the sand isn't perfect but it seems like the best out there to me.
Here is a neat little tutorial on Browser Detection using JavaScript
Browser Detection