Thought on modern webpage layouts + iPhone OS Resource limits
With the death of IE6 (or imminent death), the use of creative new webpage layouts has steadily increased. Many of these layouts use complicated nested structures + css2/3 styling. These newer layouts have also led to an increased use of the transparent png-24 image format and the widespread use of background images. Unfortunately these layouts, along with new platforms, have created new challenges for developers.
One of the most common problems I used to face with clients was the use of a sweeping gradient background with drop shadows cast over the gradient to provide a sense of depth to page elements. The problem is that IE6 fills transparent sections of a png-24 with a shade of grey. If a matte color for the transparent sections is applied then the shadow suffers undesired effects like a “halo” or the lack of blending with the background. Two years ago I would have addressed the issue by directing the graphic designers to modify the design — removing the need for a gradient background, or removing the drop shadow over areas of the gradient where a “neutral” matte color was insufficient. Now I use a png-24 transparent image to create the drop shadow effect (which makes designers happy as well). Many times these transparent images have large dimensions to provide sufficient content area coverage. As I started to test page builds on new platforms such as the iPhone an interesting issue started to appear. Many of the background images, even those with very small file sizes (30-100KB) were not loading. My first thought was that the mobile version of safari was having trouble rendering the nested structures but after resorting to simpler layouts it quickly became apparent that the layout wasn’t the issue. Something about the images themselves was causing the problem. After an extensive search I found the following information in the apple knowledge base.
Your webpage performing well on the desktop is no guarantee that it will perform well on iPhone OS. Keep in mind that iPhone OS uses EDGE (lower bandwidth, higher latency), 3G (higher bandwidth, higher latency), and Wi-Fi (higher bandwidth, lower latency) to connect to the Internet. Therefore, you need to minimize the size of your webpage. Including unused or unnecessary images, CSS, and JavaScript in your webpages adversely affects your site’s performance on iPhone OS.
Because of the memory available on iPhone OS, there are limits on the number of resources it can process:
- The maximum size for decoded GIF, PNG, and TIFF images is 3 megapixels. That is, ensure that width * height ≤ 3 * 1024 * 1024. Note that the decoded size is far larger than the encoded size of an image.
- The maximum decoded image size for JPEG is 32 megapixels using subsampling.
JPEG images can be up to 32 megapixels due to subsampling, which allows JPEG images to decode to a size that has one sixteenth the number of pixels. JPEG images larger than 2 megapixels are subsampled—that is, decoded to a reduced size. JPEG subsampling allows the user to view images from the latest digital cameras. - The maximum size for a canvas element is 3 megapixels. The height and width of a canvas object is 150 x 300 pixels if not specified.
- Individual resource files must be less than 10 MB.
- This limit applies to HTML, CSS, JavaScript, or nonstreamed media. JavaScript execution time is limited to 10 seconds for each top-level entry point. If your script executes for more than 10 seconds, Safari on iPhone OS stops executing the script at a random place in your code, so unintended consequences may result. This limit is imposed because JavaScript execution may cause the main thread to block, so when scripts are running, the user is not able to interact with the webpage. Read “Debugging� for how to debug JavaScript on iPhone OS.
- The maximum number of documents that can be open at once is eight.
Even though the actual file size of the images in question were small, they exceeded the resource limitations of the iPhone by being larger than 3MP. I was able to address the issue by shrinking the dimensions of the images without an impact on the design or the layout’s logic.
Next time you’re building a site keep these limitations in mind. It will save you a world of trouble in the long run.
Apr 30th, 2010 at 2:54 pm
*Really* good to know! Thanks!
reply