I needed to spend some time taking care of some other adventures, one of which, as you all might know by now, was the launching of the Miagi-Do Blog. With much thanks to David Greenlees, we now have our own little place on the web to call home. I wrote the second missive to appear there. If you haven't read it, please do.
Also, I was immensely surprised and given a big reason reason to smile yesterday when I saw that Cem Kaner wrote about "credentialing in software testing", in which he said about Miagi-do:
"I think this approach is probably reasonably attainable, and to me, it is definitely credible. Whether it scalable and commercially viable has yet to be seen. I think this is a clear and important alternative [...] I hope it is successful".
We hope it is, too :).
Tonight, however is not about Miagi-do. It's about Meetup Culture in San Francisco and elsewhere in this area that I call home. This continues my thought experiment that you cannot swing an umbrella in San Francisco without hitting a meet up someplace. Tonight brings us to Yelp, and a conversation that's a little different than what I normally come up for. Since STP-CON, however, I have felt that performance is an area I definitely want to beef up my knowledge about, and thus, here I am.
 |
| Some early arrivals/Yelp employees playing pool before the talk starts. |
The Top 5 Performance Shenanigans of CSS Preprocessors
with Nicole Sullivan
Thursday, May 9, 2013
7:00 PM
Yelp
706 Mission Street,
San Francisco, CA
Tonight's topic is focused on a specific aspect of performance, the front end display of web pages and the use of CSS. More to the point, CSS preprocessors and their overall effect on site performance, usability and maintainability, and what we can do to help tip the odds of keeping them on their good sides in our favor.
The sessions started with a conversation about "Living Style Guides". A style guide used to be all about a definitive guide for every item (logo size, spacing, colors, etc.)... do we really care about how the logo for AOL should look on a hat? Structured style guides don't really work. They take months to produce, they are often out of date before they are finished, and they are design centric. Living style guides focus on existing site styles, it lives in code, so that it evolves as the app evolves. Plus, engineering and design teams can work together with it. Design and Engineering have a cap between them, and that gape is often where performance gets optimized or falls all over itself.
An example using Trulia was presented. They demonstrated a process that used a number of steps:
Visual Inventory: Finding the right data to make decisions.
Trulia chose ten pages to analyze, which was meant to get an idea of the site as a whole in the smallest footprint. Often styles are duplicated over and over again. Analyzing duplication and finding variations are the most important first steps. grep is a good tool to start this process. grep for various selectors, properties and values. The main point is to determine how big a mess you have, not a granular count.
Examples shown from Trulia's audit showed lots of duplication (font size appears over 2,000 times, for example. Padding appears almost 4500 times... and this is actually pretty typical). Many of these values can be put into classes to greatly decrease the amount of repetition. Unused CSS and background images can be a huge hit to performance. Remember, all that stuff needs to be loaded, even if it isn't actually having a visible effect for the page. Positioning shows up a lot, and may be a good indication that an abstracted way of laying out the page would be hugely helpful.
Design inconsistency can also be a killer. Profiling and looking to see how often items appear, or don't appear, can help make systems consistent (imagine having dozens of almost the same but not quite the same color of blue. Each one is being used individually, instead of one declaration.
Going through and creating a reference library of the items used, the images, the layout boxes, and any number of element types (images, headers, light boxes, font sizes, font styles, buttons, text boxes, etc.) can help to create a reference for each of the items so that they act as a living style guilde, one that can be seen in real time and more easily determined which aspect and element is preferred to be used, or which items are used frequently vs. one offs.
The gosl is to do this for all component types, and try to identify ans many variations that are there.
Rationalized Styles
When we see the cumulative effect of a million tiny choices, we can see how styles proliferate, see how many styles don't do anything. It can show all present the tangled web of options that are listed and how many of them are "just there', not doing anything.
Get people involved early in the process. This can help make sure that everyone has the time and the focus to see which items are most important. Decide on a single aspect or item so that they can be iterated later. Try to match current styles where possible and appropriate.
Component Library
Once all this is done, we can create a legitimate style guide, and in this process, the discusion shifted to SASS. Some examples shown were the idea of nesting CSS so that you don't have to repeat the class names for every mention. Another option described was the use of mix-ins. when you have a small number of property value pairs or groups. Using @include and @extend allows the designer to create and design a variety of element groups in one wrapper.
Additionally, if you want to see what your output for SASS will be, you can check in the config.rb file. You may be surprised how much complexity is created when you are hoping to simplify CSS calls with extends and includes.
Several examples show how we think that we are simplifying our code and layouts, when in reality, we are very often adding way more than we think we are.
In the process of describing this style guide, we went well beyond five Performance Hits, we're up to number none now, which is "semantic grids are a terrible idea". It causes massive duplication, unreadable HTML and CSS that solves too many problems.
Build simple components first, as they often get used in complex components. An example, they create variables for colors rather than using the direct color value. Create basic typography before more advanced and specialized styles. Creating base variables make it much easier to make changes where needed, and it's easy to see what the changes are and what they represent. Anyone can make changes (well, almost anyone ;) ).
The last part was a live demo of the style guide, which would be way too difficult to explain here, but suffice it to say it was pretty cool to see. It helps me make sense of a lot of the stuff I've seem my friend Rich do for the past couple of years :).
Deployment
Choose the most trafficked pages, most important flows, go for 80% of Page Views. Only convert other pages as new features are added. For new features, add additional functionality to the library first. Use real user measurements (what matters to the users?). The example of the changes made caused a 40% reduction to the overal HTML code transmitted, and they increased page load speed by about 60%.
The examples shown helped me see where a number of areas could be improved in ways I hadn't considered. There's a lot of duplication in sites, and there are some relatively simple tools to find out where. Using OOCSS and SASS together can help people make performant pages. Also, it's important to remember, good performance is a feature :).
About the presenter:
Nicole Sullivan (@stubbornella):
Nicole is a front-end performance consultant, CSS aficionado, and author. She started the Object-Oriented CSS open source project, which answers the question: how do you scale CSS for millions of visitors or thousands of pages? She also consulted with many companies including Facebook, Salesforce, the W3C, Adobe, Paypal, Trulia and Box. She is the co-creator of Smush.it, an image optimization service in the cloud, and CSS Lint (http://csslint.net), a tool that helps correct common CSS errors before they are pushed to production. She is passionate about CSS, web standards, and scalable front-end architecture for large commercial websites. She co-authored The Web Performance Daybook, Vol 2 and Even Faster Websites and blogs at http://stubbornella.org.
No comments:
Post a Comment