Grow your store with our weekly podcasts, videos, and letters. JOIN NOW
Ethercycle logo

Slow is annoying.

People like things fast. Fast cars, fast good, and fast downloads. Who wouldn't? There's nothing more annoying than sitting on your phone and waiting for something to load. And if something takes too long to load, we move on. That's why performance of a website is so important.


We know from surveys that people expect pages to load in two seconds or less. That's our definition of fast because it's what our users expect. We also know that nearly half of people say they'll abandon a page that takes longer than four seconds to load. In actually testing we know they're a little more patient than that, but if a page takes longer than five seconds, we can expect about half of people to abandon the page.


Your bounce rate isn't going to reflect people who leave due to excessive load times. If the user gave up mid-download, your Google Analytics snippet probably never even had time to load. (Your javascripts are in your footer, right?) Using tools like Pingdom's Full Page Test, Webpagetest, or YSlow.


For that reason we need to consider performance as part of design when we create anything for the web. The reasoning behind it is simple: the faster our page loads, the more people that view our site, and the happier they'll be. More happy users means more conversions.


There are three approaches one can take to reducing the page load on the site. The most direct is to reduce the file size which we can do by stripping out content, or by compressing existing content via minification or gzip. First ask, "Do we really need this?" and then ask "How do we make what's left smaller?" Editing and then compressing content is fairly straight forward because we're just making it smaller.


We can also reduce load time by reducing overhead. In addition to considering the page size we also need to consider the total number of requests made by a page. Each request has its own overhead in that the browser has to handshake with the server, and the server can only handle so many concurrent requests. That overhead gets worse when the request is to a separate server because now it also includes an additional DNS lookup. Solving this is easier than it sounds. We can combine style sheets in to a single file, combine javascripts in to a single file, and even combine images. By creating "sprites," we can load a group of related images in to a single filmstrip and then "crop" it to just the relevant image using CSS. For site's that use a lot of SVG icons (you're using SVGs, right?) we can load them all at once in an icon font. We generate ours using IcoMoon.


Now that we've gotten our page down as small as it will go, and we've reduced our total number of requests, we can take our third and final approach which is to make our page render faster. By altering the order in which things load we'll give our site the appearance that it's loading faster. Browsers render things in the order they appear on the page. We can exploit that by loading our stylesheet first in the site's head which will render the site faster. If we move our JavaScript to to bottom of the page after the body tag, we'll add our JS functionality only after the site is rendered. Doing this doesn't change the size of the page but it will have the effect of making the page render faster. In some browsers we can even take this a step further and use the "async" and "defer" attributes on javascript. Async will specify that a file can be loaded asynchronously, and defer will specify that a file should be loaded only after the rest of the page is loaded. The final tool in our belt is to use good old progressive JPEGs instead of optimized JPEGs. Sometimes they'll be a little larger, but they render faster so they'll appear to load faster.


These are all things an experienced developer should be doing to begin with. Websites that load fast aren't just best practice, they're fun. Tweaking a page to reduce its load time is like playing golf. You want get your score as low as possible through careful optimization of techniques.

How do frameworks and grid systems work with the Mobile First approach?

Dorit Willenbrock asked:


"I'm just wondering - and maybe I have missed something, sorry for that in advance - but if I want to do a mobile first approach to redesigning my website, then I don't see how a default framework or grid system can work out. Sounds like the search for the perfect framework or grid system to match my requirements, all that analyzing and testing, wouldn't that be more work than just starting building mobile first...?"

Dorit,


If you don't have to use a framework, then don't. :) Sure, a framework has (someone's idea of) best practices baked in to it, but it also comes with a lot of overhead that you may not need for your project. If you're comfortable not using one, then good on you!


Mobile first just means that the base style of your website is for a 320px wide screen, and anything bigger than that is done in a media query. The only concession this requires is conditionally loading respond.js to add media query support to IE8. If you don't care about IE8, then skip this, but IE will always use your 320px base default.


Remember, the "magic" of responsive web design is committing to doing your CSS in percentages. The rest is just 5th grade math.

Did Responsive Design Kill the use of Photoshop for Web Design?

We still use Photoshop, and we definitely still create high-level visual design comps. However, we do it much later in the process now, and we only mock up key pages. Our workflow now looks like:

  1. Strategy, research, meetings, planning, etc. Until we know the business, we can't do any effective design. (Remember, this is design, not art.)
  2. We write a design brief to frame the design in the context of a business problem or objective.
  3. We write a 2-4 page content inventory and basic strategy that outlines the content we need from the client or that we need to create. Design does not proceed until we have this content.
  4. We create wireframes of key pages that show how the content will be used.
  5. Our strategy milestone is complete! Celebrate.
  6. Design begins. We create and revise moodboards (or style tiles, whichever you prefer) to define the visual without confusing it with content.
  7. Once the moodboard is approved, we can then apply it to the wireframes to create the traditional visual comps of key pages that Photoshop was traditionally used for.
  8. After feedback, revisions, and approval, the design phase is complete, and we celebrate once again.
  9. Development begins!

Though it's worth nothing that prior to this, we may have created development prototypes to test concepts. For example, when working on the Crain's Top 40 under 40, we created a prototype of the sliding tile interface before we had content or design just to test the concept. This is especially helpful when working on short deadlines where revisions aren't an option.

Responsive design has in no way killed Photoshop, but it has changed workflows and certainly made us question our processes as an agency.

Deciding on what to target for your next web project? Find out which mobile devices are most used.

Unique Visitors by Mobile Device Model

  1. iPhone: 59.08%
  2. iPad: 14.36%
  3. iPod: 2.67%
  4. Galaxy S III: 1.92%
  5. Not set or Other: 21.97%

Unique Visitors by Operating System

  1. iOS - 76.23%
  2. Android - 21.91%
  3. Windows Phone - 1.12%
  4. BlackBerry - 0.55%
  5. SymbianOS - 0.15%
  6. Other - 0.04%

Unique Visitors by Screen Resolution / Viewport

  1. 320x480 - 46.23%
  2. 320x568 - 15.17%
  3. 768x1024 - 14.05%
  4. 720x1280 - 5.37%
  5. 480x800 - 3.15%
  6. Other - 16.03%

Based on 520,198 visits to calmingmanatee.com during the month of February 2013. Of which, 24.32% of traffic was from a mobile device, a 3.83% decrease over the previous month.

Compared with the overall internet population, the site's users tend to be under the age of 35, and they are disproportionately childless women browsing from school and work who have incomes between $30,000 and $60,000.

Over the last year responsive web design has been going strong, many new ideas and tools have been popping up and there were (and still are) many lessons to be learned.

(Note: This post was originally written by Holger Bartel, and published to his blog on January 30th, 2013. It is republished here, in full, with his permission. -K.)

One of the big challenges with responsive design lies within its performance. At SmashingConf in September 2012, Brad Frost mentioned the term “Performance is Design” in his talk and it made total sense. Now, he sparked this conversation anew, with his recent article Performance as Design. There’s also a very good follow up article on this topic by Tim Kadlec: Setting a Performance Budget.

Previously there have been articles about Performance Implications, Bad news for site owners and mobile users and Trends. But from a short discussion on Twitter it seems that there were no numbers on average pagesize and load times of responsive sites available.

Kurt Elster (@kurtinc) took the initiative and started creating a list of responsive sites and their sizes. I contributed to that list and now we do have some numbers for 34(+4) responsive websites, which at least gives somewhat of an indication on the size trend.

Interesting is that numbers sometimes vary quite a bit between the used test tools in which cases Web Inspector or YSlow show much larger numbers than Pingdom. Also might the load times differ depending on location etc. We haven’t tested these sites with Webpagetest, but it seems that these results would also differ slightly.


The results from the findings in short:

Average Requests:
Pingdom 54
Chrome Web Inspector 54
YSlow 64

Average Size:
Pingdom 1337K
Web Inspector 1429K
YSlow 1235K

Average Loadtime:
Pingdom 2.41 sec
Web Inspector 14.73 sec
YSlow n/a

See the complete Responsive Performance Benchmark Comparison on Google Docs


Better Performance for Today’s Web

It’s nothing new that responsive websites tend to be quite heavy. Considering the rise of mobile, sites should actually be smaller and faster again.

If you’re working in a web project, devote the same amount of attention to your site’s performance as you would to its clear structure, visual appearance or quality of code. Because Performance is Design. And it does matter.

Ever wonder why a site seems to be loading super slow?

Not only can you find out a page's size and load time, but you can see how many requests it makes and what they are. This is the first step in troubleshooting slow websites.

Pingdom Tools
You can use Pingdom Tools Full Page Test to perform remote tests. It's easy to use, and will even make recommendations.

Google Chrome Developer Tools

  1. From the toolbar, click View.
  2. In the Developer menu, choose Developer Tools.
  3. The Developer Tools window should open. Choose Network.
  4. Right click anywhere in the list of resources, and choose Clear Browser Cache to remove any cached resources.
  5. Go to (or refresh) the page you want to test. Developer Tools will list all requests made to load the page.
  6. At the bottom of the Developer Tools window, it will show the data transferred and the page's load/render time.

YSlow
YSlow is a browser extension for Firefox, Chrome, Opera, Safari, and more. It not only analyzes web pages, but gives recommendations on why they're slow based on Yahoo!'s rules for high performance web sites. Get it from YSlow.org

Part of our beginner's guide to WordPress.

Adding an image

While adding or editing a post...

  1. Click the Add Media button.
  2. Select a photo from the previous uploaded under Media Library
  3. Or upload a photo from Upload files. Just drag & drop.
  4. Under Attachment Details in the right sidebar, enter a Caption. It will appear under the image.
  5. For improved SEO and better accessibility, write a short description of the image in Alt Text.
  6. Under Attachment Display Settings, you can set the image's alignment. If you set it to Left or Right, your article text should wrap around the image.
  7. Click the Insert into post button in the lower right.

Adding an image gallery

While adding or editing a post...

  1. Click the Add Media button.
  2. Click Create Gallery on the left side.
  3. If you have new photos, click Upload Files to add them. Otherwise...
  4. Select your photos from the Media Library
  5. Click Create a new gallery
  6. Drag and drop to reorder images.
  7. Click the caption below each image to edit it.
  8. Click Insert gallery in the lower right.

Editing an image

While in the Media Library...

  1. Select the image to be edited
  2. On the right sidebar, click Edit Image
  3. Click and drag across the image to make a selection. Click the crop icon in the upper left to crop to your selection.
  4. Click Save below the image

From our Beginner's Guide to WordPress.

Adding a new post

From dashboard...

  1. Click Posts
  2. Click Add new
  3. Enter a title. (SEO Tip: 70 characters max!)
  4. Past your article in to the Visual editor.
  5. Under Featured Image, click "Set featured image" to set the post's thumbnail. (This may also used when people share your article.)
  6. In Excerpt, enter a short summary of your post. It should be 140 characters, just like a tweet.
  7. In the right sidebar, under Categories, check which category the article belongs in. Pick one. (If you choose a subcategory, your post is automatically included in its parent category.)
  8. Under Tags, enter your tags, separated with a comma. WordPress will auto-suggest tags as you type.
  9. You're ready! Click Publish post.

Operating System

  1. 74.41% iOS
  2. 24.04% Android
  3. 0.74% BlackBerry
  4. 0.71% Windows Phone
  5. 0.04% SymbianOS
  6. 0.06% Other

Mobile Device

  1. 54.18% iPhone
  2. 17.32% iPad
  3. 2.78% iPod
  4. 1.56% Galaxy S III
  5. 1.33% Droid Razr 4G
  6. 1.23% Nexus
  7. 71.05% Galaxy S II
  8. 0.9% Galaxy Nexus
  9. 0.75% Nexus S

Viewport

  1. 43.52% 320x480
  2. 16.92% 768x1024
  3. 12.79% 320x56
  4. 85.82% 720x1280
  5. 2.77% 480x800
  6. 18.18% Other

Based on 553,967 visits to calmingmanatee.com during the month of January 2013. Of which, 28.15% of traffic was from a mobile device, a 5% increase over the previous month.

Compared with the overall internet population, the site's users tend to be under the age of 35, and they are disproportionately childless women browsing from school and work who have incomes between $30,000 and $60,000.