The goal of this document is to start a discussion around how we can better communicate and estimate the performance cost of designs according to what is what information is displayed on a pages.
Often the limitations and performance implications of a design only become apparent after the design and even after the design was implemented. Resulting in slow(-er) pages and the need to go back and tweak or fix at least the implementation of the design and sometimes even the design itself.
This is an attempt at making the performance cost of a design more visible and communicable.
To start communicating and reasoning about the cost of a design we need to establish a vocabulary that helps us express the intended limitations of a design. (more on that later) Intended limitations are design choices about how many things can be displayed, at most.
Examples of intended design limitations:
- how many items go in a list
- how many menu items will fit in a navigation bar
- how many related products can be show on a product page
- how many images will be displayed in a gallery or grid
- how many sub levels are there in a navigation bar
When this information is incomplete or absent a developer has no choice but to impose a arbitrary limit or, worse, impose no limit at all. A the same time there is no high level understanding of the maximum amount of information that might eventually find it's way on a page. There are a number of problems with this in practice. First, it is hard to understand which parts of a page have the largest performance impact (Do I need to pay special attention to the nav-bar or is it the main content that makes this page slow). Second, it is hard to understand which pages/designs will grow slow over time as the client adds more content to their site.
The problem with our current approach is that these limitations are implicitly communicated by means of the design itself. So it seems like an obvious solution to figure out a explicit way to communicate this information. To do this I believe a math-like notation might work best as it can be used virtually any where. In photoshop and illustrator notes, in Slack, basecamp and email and in the actual code of the implementation. The notation should be compact and simple so that it is easy and quick to annotate a design with the intended limitations.
The notation should be able to express how complex a particular part of a design is while not getting into the nitty gritty details of how the design would actually be implemented. The goals is not to have an exact picture of complexity or cost. Rather the goal is to help build a high level understanding of the cost of various components on a page.
1 is the cost of loading a single item.
- loading a single object from the database. usually to display a menu item or a detail view.
- loading a single image/video or other type of rich media.
X is the cost of loading an indeterminate number of items.
Any time a list is displayed it will have a variable name (A - Z) as the real number of items can change as the website owner changes/adds/removes content. In other words use X when the exact number of items in the list is not known at design time.
There is also a subscript variant X{i} (and X{i,j}) representing a number of sub-levels. X{i} is the number of children of any item X.
- menu items
- sub menu items
- a grid of images
- a list of events or products or pages
- a list of related products
- a slideshow
- loading all products from the database to show them in a list.
- loading all images associated with a product to show them in a grid.
min(X, limit) is the cost of loading a known number of items.
min(A, 10)for loading at most 10 products from the database to show them in a paginated list.min(B, 5)for showing at most 5 top level menu items.min(C, 4)for showing at most 4 related products.
This is the header of Couleur Local:
Here we can immediately see that the Shop menu item is way to costly in comparison to every thing else. A so simply making the the Shop sub menu's lazy loaded brings down the cost of the page down to a reasonable level.
