we build a Sencha Touch application, which allows to search and display html documents. Nothing special, simple html document which user can scroll up and down.
Some of the documents are pretty big ~ 5mb of pure html. These documents slow down the application, sometimes it even crashes.
Do you have any ideas how to fix this?
5mb-size HTML file is very large, even for laptop browser. If you run it on mobile devices browsers than there's a very high probability that they will be crashed. (Nearly 100% for BlackBerry browsers.)
It's highly recommended that you should keep the size of each HTML file not exceed several hundred KBs (let's say 500KB). Then in each of your HTML files, provide "Read more" button for the users to navigate to the next chapter of your HTML content.
Please keep in mind that, the more complex the DOM is, the slower your Sencha Touch application will become, as it always has to completely manage your DOM structure.
Related
We have website that was developed for desktops and now I've been blessed with a task of creating mobile version of it. The mobile design might be quite different from desktop version and the website is build on Wordpress. Now I'm not sure what would be best approach:
shall I stick to CSS changes only (as much as possible) and use media queries to target smaller screens? I'm worried about large images still being downloaded even if these are display:none. There is also quite a bit of JS happening on every page and this JS will not be used in mobile version of the site so I would have to build in additional checks possibly etc. Any other possbile problems with this approach?
server side code should detect if its mobile browser and should return custom html? Any other possbile problems with this approach?
mixture of two above?
any other options?
If anyone has experience with similar project and could point me to what proffered solution would be that would be great.
Use media queries as much as possible for layout changes.
For you JS, create yourself a small breakpoint handler that will trigger the js to run or stop.
I think a lot of people don't realize that a 2x image compressed is smaller than a 1x image compressed. So, if you use compression for you images, you will actually get a better network performance using just large images. How much of that image gets displayed is a potential issue that can cause negative performance, but I imagine that it's insignificant.
Are you using completely different UI for mobile than for desktop or is is just a different positioning of elements? If you have to support two templates then you will want o think about Adaptive(responsive from the server), where the server will determine based on the UserAgent which template to send to the client. UserAgent wont really get you much except for the type of Browser the client has. To figure out the dimensions of the device's screen you will need to know the dimensions or use a service like WURFL.
If you can do all of your UI change in one template using media queries then it might be best to start working on this from a Mobile First approach and basically start from scratch on your mobile look of the site and then figure out how you can re-position the elements on the page to match as close as possible to the current desktop look. Using the Responsive vs Adaptive approach will eliminate the need for UserAgent detection and you will only work with the width of the device.
Thinking of Responsive in "Mobile" vs "Desktop" is really limiting and causes a bit of confusion. Mobile should refer to devices that change location. Try using names like small, medium, and large to describe the layouts(breakpoints) for your Responsive Page.
Finally, there is not preferred way of doing "Responsive." Each site will have it's own requirements that need to be met. It is up to you to learn as much as possible and create the preferred way for your needs.
I am a big fan of the Responsive Theme Wordpress has. It is very customizable, and will allow you to use one site for both Mobile and Desktop.
https://wordpress.org/themes/responsive
You could always use:
<meta name = "viewport" content = "width = device-width">
in your header. Then the whole site will resize to fit the mobile device.
All your js should still work on mobile devices. It would just be 'flash' that wouldn't.
The site isn't "responsive" with this but, depending on the site and how much interaction etc the visitor needs, sometimes this is adequate and simple?
How do I get the timings and layouts of different frames generated while painting an HTML page which involves javascript manipulations and CSS3 animations by a webkit browser?
You can get the page layout by dumpRenderTree() provided by webkit, if that's what you wanted. Regarding the timing data, as far as I know you may need to build the webkit engine to enable it then you can get the timing data regarding rendering, network, Javascript, etc. - at least this is feasible for Android webkit.
I created a webpage that contains a list of posts (think facebook list view of posts). This webpage causes the safari browser on the iPad to crash. I'm not sure if this is because of too many divs in the page, or due to javascript of the page using up too much memory.
Any ideas on if there is a max number of divs, or maximum memory per page on iOS safari?
The webpage loads and performs normally on Chrome/FireFox/Safari-on-MacIntel
I don't think there is an EXACT number of divs. However I bet there is a limit.
I'd try limiting images or videos to bring down the amount of memory.
Your best bet is to keep the MB low for the iPAD since it doesn't have as much RAM as the Computer.
Hopefully that helps.
There is no div limit, just over load ;)
Cut some corners on the page; reduce image size/change formats, take off any 'fluff'. Remember, mobile sites aren't supposed to look and function like a desktop site. An efficient, minimal, clean mobile webpage is the way to go. You may be able to find some mobile jQuery plugins to help out too. As #TheZ mentioned, try Pagination.
I'm developing a HTML-based iPad application that makes heavy use of JavaScript for its UI. GUI is going to be magazine-like i.e. chopped into screens/views that the user then navigates between with touch events and webkit transitions. All of this runs locally on an iPad (via a native wrapper such as PhoneGap, etc.).
Lets say the application is going to have 50-100 of those screens - filled with standard web elements like text, images, tables and forms.
How to structure that for best performance? Which of the following 2 methods is preferable and why?
having only 3 immediate (current, previous, next) views/screens in DOM and then appending new ones (and deleting the old ones) into DOM as the user navigates forward/backward?
having the entire 50-100 HTML screens generated at start and then hiding (display:none) all of them but the above 3
So basically what works better memory/performance-wise? From one side continuous DOM operations might be costly (and worse make the transitions between app screens jerky) - and from the other side - don't know if having up to a 100 HTML screens pre-generated in a single document DOM won't make Mobile Safari choke to death. Of course even though those screens are in DOM, most of them are display:none most of the time - but is the mobile safari garbage collector that good? Has anyone tried this out?
BTW please note that this is not an image-memory problem/leak type question. I'm aware of that problem and will be handling it via small-dummy-image unloading trick no matter which way I go. This is only about HTML views - skeletons if you will.
If the content is all going to be downloaded to the device at the time of launch, and everything is locally cached, then definitely go with the first method, as it will have a significantly smaller memory footprint.
If the content is downloaded on the fly, however, I would go with a mix between 1 and 2... probably prefetching and rendering the next two or three slides in either direction, or maybe one in each direction and one for each link on the page.
My organisation are an ecommerce company and have a numberv of pages displaying a long list of products, some pages can have 20 products while others may have up to 100! - Don't ask me why!
I have been tasked with improving the load times of these pages, profiling shows that the majority of the load time is from the markup - there is too much of it!! Due to the amount of info the business must show the markup cannot really be reduced.
This leads me to looking at alternatives and one would be lazy loading of the product markup as the user scrolls down the screen (we currently use this technique for product images).
Does anyone have any experience with doing such a thing that they could share? - the worry is that this could impact performance within the page
Any alternate methods would be listened to as well
Look forward to any opinions
You can dynamically load content while scrolling.
You can load all key data in your barebones HTML and then add necessary markup flourish with Javascript.
Alternatively, you could send a compact XML document and apply an XSLT transform on client side if client accepts it (see 'Accept:' header).
One thing to look at is adding in compression to what the browser is sending. This will substantially reduce the page payload.
As others have mentioned, loading page content can cause a number of problems, especially for users with accessibility needs (which is a much larger percentage than most people think)
I used the following aproach to hide the makeup time to render/create the content (android, jq and jq-mobile)
a) The content is generated in the background. Always small pieces are created (duration 20-30ms) and insert into the dom. After around 50ms (setTimeout) the next piece is created and inserted into the dom
b) Android specific: I noticed that the first selection of an DOM element (e.g. $(‘#xyz’) )takes relatively long (approx 10ms) . If the element is accessed the second time, it takes only 1ms (Samsung S3).
Hope this helps