Responsive Images with Picturefill 2.0

Responsive Web Design seems to be the way that the majority of websites will be developed in the near future. For a while, everyone was creating a separate website that catered to mobile devices in addition to the main website that desktop browsers were able to access. Web Developers and UX Designers quickly discovered that this was a less than ideal approach as it required maintaining two separate websites, and the mobile website tended to remove data that was visible on the desktop version of the site.

HTML 5 has allowed Web Developers to be a bit more efficient at optimizing the web browsing experience for visitors of all display resolutions. With Responsive Web Design, current browsers allow you to customize non-image elements with CSS Media Queries. Unfortunately up until recently, there was not a standardized way to handle responsive images such that a device with a 320x480 screen does not receive an image that is 1200x600, but instead receives a smaller version of the image.

The first rule of website performance is to limit the number of bytes that must be downloaded to display the website. Thankfully, the <picture> element has been somewhat standardized and is starting to be implemented in Chrome and Firefox, while Internet Explorer continues to lag behind in new functionality implementation. However, there is a working polyfill for the <picture> element that works with all major browsers. The Picturefill polyfill is the major polyfill out there that is known to work across browsers and is supported by the Filament Group. Using this polyfill simply requires the developer to add the script to the head of the html, and make sure the <picture> elements adhere to the standard and a slight workaround for IE9.

Images tend to make up the majority of the download size for any website and this will allow web developers to limit the image sizes that will be downloaded by clients. Take this polyfill and experiment with it and start utilizing Responsive Images today.

Tags:

Related Posts

Apr 14, 2014
One minute

Varnish and Magento Performance Mystery

One of the things that you think you will solve when you implement a Varnish caching server in front of a Magento website is performance problems. However, this is not necessarily the case.

When I set Varnish up to cache content in front of my Magento website, I get what seems to be much improved performance. If I run a few tests in the developer tools of Chrome, it seems that the waterfall chart makes sense and the data is loaded appropriately and in a timely manner with the main HTML being downloaded in about 300ms.

#magento #varnish #performance
Read More
May 6, 2014
One minute

Unintended Consequences with Magento Observers on Sales Orders

Anyone that uses Magento to place orders will be hard-pressed to consider this process a speedy one. While it takes a while to process the order under the best of circumstances, there are a few things that you can do that actually make it worse.

One of those things that can make it worse is creating an observer that runs in the middle of the saving of the order processes that is always slow-running, or continues to get slower over time as the data that the Magento site grows. While the observer may run well at first, over time as the data grows, some random symptoms may show up, including database deadlocks and even some missing sales orders.

#magento #performance
Read More
Apr 30, 2014
2 minutes

Always Namespace Variable Names in JavaScript

After running into a few issues with variable naming collisions over the past few days, it drives home how much we all should be namespacing our variable names in JavaScript. When writing JavaScript code that is only in use on your own website, you should still always namespace your variables. If you are writting a JavaScript library that will be in use on any website a user puts it on, namespacing your variable names is a minimum requirement.

#javascript #design-patterns
Read More