You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I wanted to write a long post about all and everything in web development, but this proved to be very difficult, that's why I turn it into a collection of links and just an overview of technology, and write so more detailed posts on each technology later.
11
+
12
+
#The problem
13
+
I have learned CSS back in 2005. Since then I've been thinking about writing CSS as a rather boring and mundane task. It's nothing like Domain Driven Design or MVC architecture, just a number of declarations bound by a selector.
14
+
Over time I've noticed one ugly tendency: as the project grows, CSS code becomes the most ugly code of the project, looking like some stinking spaghetti. During last few months, I've discovered how flawed my practices had been, now I want to share the fruit of my latest discoveries with you, my dear reader!
15
+
16
+
The BAD way:
17
+
18
+
> 1. Designer prepares design combs in Photoshop and hands it in to you.
19
+
> 2. You prepare a semantic HTML5 markup, with all of those `section` and `article` and what not.
20
+
> 3. Then you go page by page and write CSS code, targeting your html elements and so-called 'semantic' class names like `.news`
21
+
22
+
What you got:
23
+
24
+
> 1. CSS that is a pain to maintain. For every new page of website you have to write new code.
25
+
> 2. Inconsistent design: how many shades of grey has designer used? Different margins on every page. You bet!
26
+
> 3. CSS tied deeply with HTML structure. Change markup and styles would have to change too. No good!
27
+
> 4. Designer and developer don't have a common language to talk about design.
28
+
29
+
Here comes a set of patterns and tools to remedy the situation!
30
+
31
+
#Styleguide
32
+
The foundation for any complex website design should come in a form of a styleguide -- a collection of reusable modules and patterns, out of which the pages are built.
33
+
Styleguide is a bridge between a designer and a developer, a common language for the project. It takes time to build, but then constructing new pages becomes like playing Lego -- a lot of fun!
34
+
35
+
Nowadays styleguides don't come in the form of multipage PDF documents -- styleguide must live in a browser and be deeply tied with your CSS code, in fact that's where it must originate from. But more on that latter.
36
+
37
+
To read:
38
+
1. alistapart
39
+
40
+
#Atomic design
41
+
This may be my most valuable discovery -- atomic design pattern by Brad Frost.
42
+
Atomic design is a language to talk about your web page elements: breaking design down to atoms and molecules is very energising!
43
+
An *atom*: smallest particle of your design, something that is undividable and used everywhere like different types of headings, base colours and so on. By itself it may not carry a lot of sense.
44
+
A *molecule*: a molecule usually joins a couple of atoms. i.e. a searchbox molecule may consist of a label + input field + a button atoms.
45
+
An *organism*: even larger part of webpage. Consists of a combination of molecules i.e. a website header organism = site-title+menu+searchbox molecules.
46
+
47
+
For more details head straight to Brad Frost's [Pattern lab], you'll find some great examples there, though I can't recommend his tools or the style of writing CSS he uses.
48
+
49
+
50
+
##Atoms
51
+
* Unbreakable units of design.
52
+
* Rarely applied directly in HTML, more like silent placeholders -- more often extended in molecules.
53
+
54
+
##Molecules
55
+
* Compound units, consisting of multiple _atoms_.
56
+
* Include atoms via SASS `extend`.
57
+
* In backend, molecules may be defined in separate partials, though not necessary.
58
+
* We don't create @extend molecules as we do with atoms.
59
+
60
+
##Organisms
61
+
* Organisms, in its own place, consist of multiple molecules.
62
+
* Almost certainly each organism is defined in separate partial in backend.
63
+
64
+
With atomic design, now you have a ubiquitous way to talk about your design elements with absolutely non-techie people (like designers).
65
+
66
+
#OOCSS, SMACSS
67
+
68
+
#BEM
69
+
Block, Element, Modifier, a great naming scheme for your CSS classes.
70
+
```
71
+
.block__element--modifier
72
+
.search-box{}
73
+
.search-box__button{}
74
+
.search-box--small{}
75
+
```
76
+
Getting your mind around BEM.
77
+
78
+
#Designer+Developer
79
+
Every designer should understand the medium he's designing for, that's why any designer must know how to code!
80
+
For the same reason, and developer should now something about #UX and the basics of designing things.
81
+
Ideal situation, of course, is when designer and developer are the same person!
82
+
[link to spiekermann]
83
+
84
+
#Tools
85
+
Now for the little nifty tools I use to implement the forementioned.
86
+
87
+
* Hologram -- helps you to build styleguides directly from your CSS stylesheets.
88
+
* CSScritic -- CSS _IS_ testable! Especially helpful during refactoring.
89
+
* Browsersync -- better then live-reload: no need for a browser extension, view your site simultenuasly on multiple devices. Who would resist of building a test lab?
90
+
* GruntJS -- Here's my grunt file to automate the tools above.
91
+
* SublimeText -- userfreindly editor with hell of power. There's even a VIM mode!
title: "5 tips on making your Foundation based site faster"
4
+
date: 2014-07-18 23:23:32
5
+
tags: css optimisation foundation
6
+
comments: true
7
+
---
8
+
I'm so ashamed for the performance of the sites I used to build. Hundreds of requests, megabytes of code… oh poor mobile visitors! I knew I had to stop being lazy and finally do something about it!
9
+
In this post I'm going to suggest a few easy steps towards making your css framework based sites more speedy.
10
+
11
+
## 1. Partial load of components
12
+
This one is easy. Don't import all of the Foundation's components into your stylesheet, you won't need them all! Foundation is really good at making code modular, that's why I'm not ashamed of using it even on production website, and only for mock-ups.
13
+
Comment out general Foundation import:
14
+
15
+
```
16
+
@import "Foundation";
17
+
```
18
+
And only import things as you need them.
19
+
```
20
+
@import …
21
+
```
22
+
23
+
## 2. Don't output unneeded classes to HTML, use mixins
24
+
25
+
Another strong point about Foundation, is that you can avoid outputing unneccessary style defenitions at all.
26
+
For example, for the `block-grid` component you probably don't need all of possible definitions for different screens and sizes in your code.
27
+
Solution: use mixins!
28
+
First disable output of block-grid's styles into the stylesheet: `asdfas`
29
+
And than import desired mixin where needed.
30
+
```
31
+
32
+
```
33
+
34
+
## 3. Remove unused styles (with unCSS)
35
+
36
+
This is a good test of how well you did with previous advices. Determine how many style definitions you have left in your stylesheet. I used the extension for Firefox called AAA, you may look for other tools as well. After optimization, I only had about 15% of overhead in CSS, which is only I couple of KB's. I suggest that you try to optimize CSS on your own, but if you give up, try to use unCSS utillity. It works as a grunt plugin, so there should be no problem adding it to your Gruntfile.js.
37
+
38
+
## 4. Lazy load everything you can
39
+
40
+
### JS
41
+
42
+
If you have not overused JavaScript, your page should look pretty fine without it, except for few animations. So why make people wait for your JS code to load?
43
+
I've seen people using `defer` and `async` attributes for this purpose, but with most browsers it wouldn't work! Use this old school code instead:
44
+
45
+
```
46
+
```
47
+
### CSS
48
+
49
+
Yes, CSS is render-blocking too. If you have a large CSS file you'll make your user stare at a blank screen while CSS is loading. On mobile, that may be a problem.
50
+
51
+
There is only one real solution: separate CSS code for above-the-fold content from your main CSS, load it first and defer loading of main CSS with this script:
52
+
53
+
```
54
+
```
55
+
56
+
But if your CSS is written in a modular way, it will be very hard to separate the code which is responsible just for this part of the page. There are tools which help you do it (), but I decided that in my case it's not worth it.
57
+
58
+
To make the pain of mobile users a little easier, I've thought out an idea of using CSS loading screen, which will reassure the user that the page is loading indeed, and may even show some critical information. Here I've written about this technique in greater detail: []()
59
+
60
+
### HTML
61
+
62
+
If your landing page is very heavy, I suggest to leave only the most critical top-most parts in HTML, and load the rest with AJAX requests. News, related articles, all but the most important content are a good candidates for being pushed out of main HTML.
63
+
It should be pretty straightforward using jQuery, so I'm not going to write about it.
64
+
65
+
## 5. Learn atomic design or other OOCSS technique
66
+
67
+
This is probably the hardest part: learn to write CSS in a modular way! This is not just some technique, and therefore requires you [put your thought in it]. Google-up OOCSS, SMACSS, atomic design and learn to think about your CSS code in a new way.
68
+
Once refactored, your code size will decrease dramatically and will scale great! And maintanace will become a joy, guranteed! :)
0 commit comments