Client side performance compromises worth making

Client Side Performance
Compromises Worth
Making
Sydney Web Apps Group: 19.9.13
@cathyblabla

What!!?
Good client-side performance really is simple -
smaller files, fewer HTTP requests, less DOM
manipulation. Use YSlow and understand the
rules it is based on.
OK, so there are lots of tricky details that we
could go into, like CSS selector performance,
but is your site huge enough for things like that
to make a difference? Probably not. So….

Where to draw the line
Where do you draw the line between good
performance and maintainability? Class names
like ‘a1’ to make your CSS files smaller? No
way! But there some situations where ‘The
Rules’ can and should be bent...

Multiple sprite images
Sprites allows us to download all our image
assets in one request. If you use Compass, it’s
sprite functionality makes this super simple.
But all those disparate colour palettes add up,
resulting in either a big 32bit PNG or degraded
colour reproduction. The solution? Split up your
sprites into similar colour groups and stick to a
set pallette. It’s a few more HTTP requests but
worth it.

Like this...
$green-sprites: sprite-map("sprites/green/*.png");
$grey-sprites: sprite-map("sprites/grey/*.png");
%mail-icon {
background: sprite($grey-sprites, mail) no-repeat;
&:hover {
background: sprite($green-sprites, mail) no-repeat;
}
}

Scaling images in HTML
Ideally, we would only download images at the
exact size they will be displayed, but your
responsive site will probably call for fluid
images to cater for different devices - what to
do!?
If you can, serve different sized images based
on device categories then allow CSS scaling to
take over.

Choose image sizes that match your target
devices closely and that are close to the upper
end of your breakpoint to minimise image
degradation.
Include the served image’s width and height in
your html to reduce the visible effect of reflows
once your image is loaded.

Load (most) scripts at the bottom of
the page
Inserting scripts at the end of your page stops
script downloads from blocking the rest of your
content. But long pages can result in a
noticeable lag for script effects - while your
overall page load time may be improved the
users’ perception of load time could be
affected.

...so should I load my scripts in
<head> after all?
One approach is to load your ‘must have’
scripts in the head, then load the rest at the
bottom of the page. While this introduces some
maintenance overhead, your page loads as fast
as possible while also giving your users a
seamless experience.

Script loaders FTW!
RequireJS is a script loader that present a
unique solution to this problem. Out of the box,
RequireJS loads modules asynchronously as
they are called for. There is also an
optimisation tool that provides an automated
build. All the files required for your project are
minified and concatenated, this file is then
loaded asynchronously. Your scripts are
optimised, available earlier and are non-
blocking. Yay!

What about lazy loading?
It is possible to squeeze even more
performance out of your Require scripts by
splitting them up and lazy loading those that
are less often needed. Read about it here.
YUI includes a script loader that is based on
RequireJS but also utilises a server side combo
handler that serves back separate files in one
request. The combo loader is open source and
you can get it here.

Some OO in your SASS
Love the modular approach of OOCSS but don’
t like your HTML getting cluttered up with non
semantic class names? With SASS you have
the tools to write modular, concise code that
can be constructed in any way you wish.
Create a structural hierarchy within your SASS
code and push design complexity back to the
style layer to keep your HTML simple and
readable.

Use placeholders to create re-usable
structures...
%btn {
@include rnd( 3px );
border: 1px solid grey;
cursor: pointer;
line-height: 2.3;
padding: 0 17px;
text-decoration: none;
}
.my-button {
@extend %btn;
color: green;
}

Build up top level rules from
combinations of re-usables
.news-module {
@extend %media-block;
@extend %media-module;
.top-stories {
@extend %stories-list;
}
.more-link {
@extend %btn;
}
}

Mixins give you more flexibility...
@mixin button ($colour: green) {
@include background-image(
linear-gradient(white, $colour)
);
border: 1px solid darken($colour, 40%);
color: 1px solid lighten($colour, 20%);
}
.delete-button {
@include button(red);
}
.active-button {
@include button(blue);
}

But be careful of the final output...
Placeholders generate a single rule with all
selectors combined. If you have too many, IE
goes kaboom!
.btn1, .btn2, .btn { //styles extended from %btn }
Mixin styles are repeated wherever they are
used, so use them minimally, ideally for styles
that are unique (ie, based on a parameter).

.delete-button {
background-image(
linear-gradient(white, red)
);
border: 1px solid #660000;
color: 1px solid #FFBFBF;
}
.active-button {
background-image(
linear-gradient(white, blue)
);
border: 1px solid #000066;
color: 1px solid #99CCFF;
}

Client side performance compromises worth making

Recommended

Recommended

More Related Content

What's hot

What's hot (18)

Similar to Client side performance compromises worth making

Similar to Client side performance compromises worth making (20)

Recently uploaded

Recently uploaded (20)

Client side performance compromises worth making