Our company develops big corporate solution for business (web-site). After approving to support Apple iPad we saw, that our site is very slow on it. So, I was tasked to optimize performance for iPad by optimizing GUI (Html, JS...), because server part of application is pretty fast.
I've found some solutions tricks with customer's approve:
* Reduce grids columns count and leave only the most useful.
* Turn off all the animation.
* Decrease resizing as much as possible.
And of course, I minified all the scripts and stylesheets.
Can you make me some additional advises how to improve performance?
There's several things, many of which apply to desktop web as well as they are just part of good practice.
In no particular order:
Remove extra whitespace and HTML/CSS/JS comments
GZip all text based content (HTML,CSS,JS)
Optimize all your images (e.g. use a service like http://Smush.it )
Move your images/static content to a separate server (increased HTTP pipelining), and don't serve cookies on that server
Don't serve up anything to "mobile" that they don't need (where possible)
Don't scale down images on the client, served scaled down versions from the server
Since most mobile browsers handle CSS well, convert "lists" of data that render in tables, to use unordered lists etc.
Serve common scripts like jQuery from a CDN like Google
most mobile browsers support some kind of offline caching, or local lightweight database - if there is anything that you can cache to reduce future loads consider doing so
If you want to get really fancy, you can do things like not directly loading images... and then checking on the page which images are currently in view (or delay slightly), and loading them as needed... the helpfulness of this will depend highly on the content
Consider delaying the load of search results if applicable (e.g. like a Twitter stream that might only load the first 20 items, then only load additional items on demand.
Some of the practical things which i would like to tell are;
Avoid use of iframes on your pages. They do not work well on iPad.
Use a library like Sencha touch which is highly optimized for the iPad.
Make links or buttons to have large touvh areas, as users can get frustrated with incorrect link clicks..
Avoid use of CSS absolute positioned elements.
Also to add a few more points;
It is best to use the meta viewport setting as width=device-width...This ensures that your viewport is set based on your device and not hard-coded.
Avoid use of CSS :hover properties in your iPad CSS...They can cause unnecessary issues (false hover's)
Related
What is the right way to design the page structure of a WebWorks app? I'm using jQuery-mobile as well.
A: Should all the pages be in a single HTML, each page being a:
<div data-role="page">...</div>
B: Should pages be separated in different HTML files linking to each other?
I am currently using approach A, but the app is a slow when transitioning from a page to another. I suspect one of the reasons is the size of the single HTML that includes all pages.
Also another issue I'm having is that pressing the physical "back" button on the phone exits the app which is another reason I'm doubting my approach in having all pages in one HTML.
A very opinionated answer: You're using the wrong framework. jQuery Mobile is extremely bloated and I've seen it perform poorly even on recent iOS devices, not to mention BlackBerry's not exactly very performant OS.
If you continue to go down the jQuery Mobile route, I would still recommend you have all your pages in a single HTML file, not least because the user experience on WebWorks is a bit sub-par when moving between separate HTML pages. For example, you'll get very noticeable "white flashes" when you follow a link to a different HTML file, especially on older/less powerful devices (although you can mitigate that a bit by setting a background colour for your rim:loadingScreen element in the config.xml). It's up to you to decide whether that is better or worse than the slow transitions in jQuery Mobile.
As for the back button, you can override the default behaviour by attaching an event handler to the back key like so (don't forget to have the blackberry.system.event feature enabled in your config.xml):
blackberry.system.event.onHardwareKey(blackberry.system.event.KEY_BACK, function() {
// Back key pressed, go back to previous screen
}
If you're still open to an alternative solution though, I highly recommend you give bbUI.js a try (https://github.com/tneil/bbUI.js) - it's a semi-official framework that looks a lot more at home on the BB than jQuery Mobile and is better optimised for the platform (e.g. allowing you to only load scripts that you need for the particular page you're showing at that very moment, working around some WebWorks/BB-specific issues, etc.) - combine it with Zepto (http://zeptojs.com/) which is a blazingly fast jQuery replacement and you'll end up with an app that is significantly less sluggish than a jQuery Mobile based one.
You can use which ever way suits your project best. For a large app, it's probably worth having a single "index.html" which then links off to several other pages. Can make editing your code easier as well.
There seems to be a lot of conflicting information out there. It might be that support has increased recently, or changes to adobe.com/air have made some information difficult to find - but I can't track down a definitive list of things to avoid.
I know that actionscript won't run in loaded SWFs, I know that some people say that filters and blendmodes and halo components won't work. I've also read many posts saying they will (at least that blendmodes will, and that halo will run, but slowly so still use spark)
I have a large amount of AS3 code to plan for upgrading to work on iOS, but at the moment I have no idea what things will break (or what things will break when those things have been fixed!)
Is there a list of unsupported APIs, or iOS dos and don'ts?
Thanks
:S
First, yes. Externally loaded SWF's will not run. You can however embed SWF's/SWC's into your project and include them inside of your package.
As far as Flex components, stay away from Halo. You should use Flex 4.6 and stick to components with mobile skins. I recommend downloading Tour de Flex http://www.adobe.com/devnet/flex/tourdeflex.html to get an idea of whats available.
As far as blend modes go, I'm not really sure. I haven't used them in mobile yet. However filters are supported but they are expensive. For drop shadows on rectangles there is something called RectangularDropShadow. This is actually a component and therefor less expensive. However it can only be used on rectangular groups.
You should have access all of the AIR API's. You will however be restricted when using some of File related classes since I don't believe you can leave your Appliaction Storage Directory.
One big performance tip I can give is to use AS3 over MXML whenever possible, ESPECIALLY when creating item renderers. Use BitmapImage over Image whenever possible, again especially in item renderers. Use cacheAsBitmap whenever you have images that don't change often. And stay away from any Flex component that doesn't have a mobile skin.
You may also want to read up on View and destruction policies.
http://www.adobe.com/devnet/flex/articles/flex-mobile-development-tips-tricks-pt1.html
This link also has some more performance tips
http://www.adobe.com/devnet/flex/articles/flex-mobile-performance-checklist.html
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 into creating an Web or iPad application that will use HTML5. After some research I've discovered that HTML5 has Database caching, and was wondering how large that cache is?
I'd be looking to provide an offline solution so the users can still fill out forms, and pull information from the database if they're out in the field and cannot obtain a 3G signal. The database caching would be fairly large ( a couple tables with thousands of records each ), and would have re-cache weekly.
Is there a limitation to how much data HTML5 can cache?
I haven't been able to find anything regarding a hard size limitation or any indications of a size limit through searching any HTML documentation.
I believe that Safari has a 5MB cap on application storage for iPhone / iPad (You had mentioned using an iPad.)
Here is the HTML Standard regarding Offline Web Application's / Caching
Here's a good link involving implementing an offline cache with HTML5 - it also has several good links towards the bottom.
Hope this helps you out!
I'd like to use a non-standard web font to improve the appearance of my HTML.
Is it preferable to embed a web font or use something like sifr?
My understanding is sifr is a flash-based viewer for vector fonts but I've been reluctant to try it because it seems somewhat complicated.
There does not seem to be a lot of encouraging talk about web font embedding (because of legal issues) so maybe sifr is more of a standard way to do this?
Any feedback would be appreciated. Thanks.
Web fonts are supported in Safari 3.1, the upcoming Firefox 3.5 and the upcoming Opera 10. Internet Explore has supported a (different) format since IE4.
At this point, the biggest problems with the implementation in Safari, Firefox and Opera is that they require you to upload the original font file to your web server. For many fonts, this would constitute a violation of the license you received from the type foundry. Therefore, web fonts right now are not an appropriate solution if the type foundry has not given you permission to use them. However, there are freely licensed fonts available.
This leaves us with roughly three other options: images, Flash, and JavaScript-based solutions. Images are often preferable in that they have minimal impact with regards to browser quirks and performance, however dynamic image generation in, say, PHP often does not look as good as other solutions. You could of course manually create images in Photoshop, but that would usually defeat the purpose.
sIFR uses Flash to render the text, and is quite flexible in that you can select the text, change it dynamically, and have some control over the styling of nested HTML elements. Hoefler & Frere-Jones has given sIFR the OK, provided you pay for a server license and take all possible measures in limiting the sIFR Flash movie to your domain name.
Cufón is a purely JavaScript solution that has implemented its own rendering engine, which is insanely clever. At this point its not as flexible as sIFR, and its legal issues are still unclear.
That said, images, sIFR and Cufón are all hacks, and we need proper web fonts yesterday.
(Disclaimer: I'm the lead developer of sIFR, so I might be somewhat biased.)
You could also consider the JS alternative(s). However, for best cross browser compatibility you're better off using images and perhaps a background-image and text-indent CSS trick to replace static text with your images.
The technique I mentioned above (and others) can be read here: http://css-tricks.com/nine-techniques-for-css-image-replacement/
Something to consider:
For every visitor who sees your 'better looking' fonts, there are just as many who won't due to having an incompatible browser or disabling that feature. Having just the right font probably isn't the most valuable design change you could work on.
Written from my mobile browser which doesn't do embedded fonts.
Note that CSS3 Web Fonts module, which defines font embedding is still a Working Draft. Indeed, the practical support of font embedding isn't good. I'd say it's better to wait another 2-3 years.
Also worth nothing: TypeKit, a service that gives you a line of JavaScript to abstract all of this away.