When designers hand over a PSD for a new website the first thing that happens is my eyes crawl the design. I am already building the architecture and framework of the site in my head. What becomes immediately apparent is whether I can accomplish a visual design element with code or whether I will have to use an image. Then comes the part where I begin to shatter any hopes for the designs survival.
I hate doing this! But it is necessary!
Often times I begin by citing that the file will be too large or this would require too many “requests to the server”. Quickly I begin to blabber a bunch of developer gibberish and I feel as though I am coming across pompous. While using an arsenal of jargon meant to prove my point, I am making excuses as to why I am tearing apart their beautiful design.
Quickly we can see that this process is flawed, that we should have had this discussion before the design process. Furthermore, if site performance is indeed an element of the design than not only is this process flawed, it is flat-out the wrong way to go about it!
If you are like me, a freelance developer, you have most likely encountered this very same scenario. Most of the designers I have worked with ( not all of them ) come from a print background and have a very limited knowledge of code and front end technologies. While it is almost essential for any “web” designer to have a working understanding of HTML and CSS, we are still in a period where many design professionals and agencies simply have not taken the time to understand these technologies. We are still in transition into the post PSD era.
So how can we improve this process? It is clearly a result of poor communication and poor understanding. Hopefully no one came along and said, “Hey, I’m going to design a site that is really slow and no one will use it!” Beautiful websites don’t have to be slow, they can be fast and functional as well.
A lot of discussions have recently surfaced surrounding this issue. It involves creating a performance budget. A goal of obtaining optimal performance through the budgeting of resources while building the website. Perhaps with the use of a max number of resources to include with the project. This number of resources can be translated as the page weight, page speed, or the number of requests made to the server. Sounds technical, but it directly relates to the design.
Remember that awesome parallax site you saw last week? Or that really cool site with all those awesome images and animations? Generally those types of sites are horrible for performance. If I receive a design with a giant slider and huge background images as well as giant background textures I immediately see little hope for the websites performance. This is the hard part, communicating to our clients that what looks pretty can in fact hurt us. For example, if the client is trying to sell something and the page load time is inhibiting the user from even viewing a product on their phone, that means no dollars spent. On the web, pretty websites are only a piece of the design. A good content strategy, well thought out visual design, and site performance are just some of the considerations we need to make. This separates you from the parallax template that just looks cool. Besides, your client may be calling you back in several months with a laundry list of problems related to that pretty parallax template.
It is up to us to deliver something better to our clients. We have to communicate that good performance is good design, which is good business, and is better for business!
Decisions about a performance budget need to be made early on in the game. Developers need to sit with designers early in the process to communicate how some decisions will affect a sites performance. This involves content and design decisions.
In our fast world this ideal situation happens in some contexts. In most others, it is skipped. Wouldn’t it be great to have a non-technical designers a guideline to delivering performant web designs? This would be something you could use as a reference while designing a site, things to keep in mind during the process. Once you get used to it, you probably won’t even need to reference the guideline anymore!
Lets start with something simple, a goal, a budget!
“Our site should weigh no more than 500kb and have no more than 15 requests.” or “Our sites should take no longer than 8 seconds to load on a typical 3G connection.”
In order to meet these goals we have to start with our design assets, these are the fonts, the images, the textures that make up the design. So if you have a goal of 500kb than you should only budget max 100kb for fonts.
An example of font budgeting could be easily determined by the number and types of fonts you choose. For example, a site with 3 weights of Museo Slab for Headers and 3 weights of PT Sans for body copy is a heavy ask! Have you ever used the google fonts tools that shows the page weight meter increasing as you add different weights? Think of that tool every time you add another font to your design.
Remember every font requires a request to the server for that asset. We can insert the font using Data URIs into the stylesheet but that in turn can weigh down our stylesheet quite a bit! So, a better decision about fonts is going to have to be made. Something like 1 or 2 font weights for headlines and 1 for body copy. Better yet, use web safe fonts for body copy.
Images are a hot topic in responsive web design. They can easily weigh down our sites. Too many images will blow our performance budget out the window! There are several types of “images” we need to consider when designing sites:
- design elements
- foreground images
Design elements are things such as background textures or images related to the presentation or layout of the site. These images should be used sparingly or not at all. There is so much that can be done with CSS and HTML in modern browsers that can produce amazing results. Just take a look at what people are doing over at Codepen!
If you are going to be using a background image or texture be conscious of its size and only load the image on larger viewport widths. A repeatable pattern is desirable for background textures if you are to use one. Subtle Patterns is a great resource for such items.
We all know what icons are, those cools images that indicate things like a user profile, or a location, social icons, maybe tags and categories in the case of WordPress. Your logo may even be an SVG. These images could and should be one of two things, either an icon font or an SVG sprite. So when creating these assets one way to make your developer super happy is to convert all the icons into font using a tool like icomoon. You can also use this tool to generate an SVG sprite of your icons. Ask your developer if they are going to be using inline SVGs as well. That may be a good option if your icons have some color variations in them, and inline SVG is super cool!
Foreground images are usually elements loaded in by the user in the CMS of choice, but the decision of where and how these images will appear in the design is usually up to the designer and developer. I would put sliders and carousels in the category. With that said you may want to slap yourself in the face or pour a bucket of ice water over your head before putting in a slider. There is plenty of research that suggests they are not as effective as one would think. An alternative may be to use the very popular hero image instead. But you should limit the amount of hero images you use on a page as you scroll down. I’d stick to 1 if you really want to maintain your performance budget!
Oh, and … when delivering images you must always optimize them, always!
From a developers perspective there is nothing more frustrating than made up feature requests based on a design comp. Such as, “When they click the button that flies in from the top, it will open a window that allows them to see a slider with a form below it that lets them upload images to the slider.” – and … no! We have to be deliberate and smart when creating design decisions based on features and communicating with the developer and the client about features performance should always be on the table. That feature could cost up to 1 megabyte!! I have often seen clients reactions when you tell them a desired feature is going to slow their site down, usually they prefer the fast loading website!
So what is the key here? Communication, Collaboration, Education
We have to find the balance between great design and performance! It can be done, it must be done, and you can do it!