The following is a guest post by Rajoshi Ghosh and Tanmai Gopal of 34 Cross. They emailed me to show me their new website and how performant it was despite having cool features, being visually rich, and responsive. I was like, hey, you should write about it! This is that. Bask in the math.
Update: they have updated the site since this article was published. They have kept the site up that this article refers to at old.34cross.in”, and I’ll change the links in this article to that.
Another Update: Looks like the “old” site is dead now too, we’ll just remove all links to it.
At 34 Cross, we wanted to develop our new website to be responsive, mobile-friendly, and easily load on even 2G networks using only HTML and CSS. In this article, we’ll tell you about the challenges we faced in both the design and speed optimization of the site, and how we overcame them. First, we’ll focus on the scrolling parallax effect. Next, we show some interactive features that are possible through CSS alone. Finally, we include a checklist of things to consider for performance in general.
Part 1. The CSS only parallax effect
We built our CSS parallax based on (perhaps the first) CSS parallax concept by Keith Clark. His key idea behind parallax is beautifully simple. Essentially elements that are “closer” to you move more quickly and elements “farther away” move slower as you scroll. It is a layered effect of different elements moving at different speeds.
This is unusual for a website, where normally all elements are placed on a flat plane and everything moves at the same speed when you scroll. But if we look at a website as a 3D world projected on our computer screen, we can move some stuff really far behind our screen, and let some other stuff remain in front. Scrolling vertically then makes things further away move slower and the things in front move faster. Voila, parallax! Exactly how it works in the real world.
1.1. A brief aside into CSS 3D geometry
CSS’s 3D transforms allow us to look at the elements of a website like this:
C is the computer screen center, and the top-left corner of the screen (from the user’s point of view) is the origin. Web elements can be positioned anywhere, and the browser rendering engine will project those elements onto our screen and let us view them. This is essentially the same thing as drawing in 3D.
The first step here is defining the perspective:
- Choose an element to be your 3D projection surface. It doesn’t need to be the entire screen.
- Tell the browser how far you want the projected surface to seem to be from your eyes.
Both of these things are done by defining the
perspective property on an element. The
perspective property essentially defines the length
p from the figure above (Fig 1). The lower the value of
p, the more intense the 3D effect. The larger the value, the less intense it is.
1.2. Implementing Parallax
Let’s define the element through which we’ll be viewing our 3D world.
- We want the entire viewport to be our view into the 3D world, so we’ll create a
#containerelement that covers the whole viewport.
- Let’s define our value of
1px. By default the perspective origin is the center of the element (point
- We’ll chunk the parallax elements into groups. The group we create will have an element in the background (by moving it back along the `-z` axis) and one in the foreground.
This results in the following action:
Special points to note:
- For reasons that we don’t truly understand, we need to chunk our parallax effects into groups. Chrome doesn’t really need that, but Firefox does.
preserve-3dis an important instruction for
#group1, asking it to respect the 3d properties of its parent element. Otherwise, the perspective instructions would be ignored.
Now we have a gap of 500px from the top of the viewport in the foreground plane. The background appears smaller because it has been pushed away. It also has some whitespace around it because of its projection (
d in Fig 1).
The next things we want to do is make it appear to be 500px in height so that it fills up the 500px gap. From Fig 1, the projected height is
Basic trigonometry tells us that:
p/(p-z) = h_1/h
Which gives us the projected height:
h_1 = h * (1 + z/(p-z))
Since we set z to -1px and p to 1px, we get:
h_1 = h / 2
So that would mean that the translation scales our image down by
1/2, and so scaling up our original element by 2 would make it appear to be 500px in height.
Let’s look at that in action. All the other CSS is as before.
The far away element is now 500px in height, but there still seems to be some whitespace remaining atop the element. Open the Pen above in a new tab and resize your window vertically. The whitespace on top of our pretend-foreground pastel-red-div will keep changing. Where is this whitespace coming from?
This calls for a little bit of detail into how scale works. Scale, applied on an element, scales that element from its center. Let’s look at a sideways view of our elements before and after scaling:
Going back to our HTML, we see that even though we scaled the image up so that it would be perceived at the same size, the element has a certain offset from the top. Let’s try correct this by solving for the top gap
his the height of the element in the background (
sis the scale applied. So,
s.h = E_2F_2
v/2is half the height of the viewport
eis the vertical distance from the perspective origin to the element center, and
e_1its projection on the viewport
1 + z/(p-z)is the factor any height at `z` distance is multiplied with to result in the projected height.
- Using the constraint that on the viewport projection:
x + E_2'O' + e_1is half of the viewport:
x + s/2 * h * (1 + z/(p-z)) + e * (1 + z/(p-z)) = v/2
x = h/2*(1-s) + h*z*(1-s)/(2*(p-z)) - v*z/(2*(p-z))
- Applying our properties:
z = -1, p = 1, s = 2we get:
x = (v-h)/4
It is important to note that the gap
x depends on the viewport height. If we offset the top of our background element by this value, the top-edge will always be aligned. But since
x is the perceived value of the gap, the background element will move up by
(1 + z/(p-z))^-1 times that. That means we should move our element up by:
((p-z)/p) * x, which in our case is
2 . x.
But how do we apply this formula version of CSS height? CSS calc() to the rescue! With our element of height 500px, we get:
top: calc(250px - 50vh);
Let’s see this in action:
Perfect! Now we can just keep adding more groups. Within each group, we position the elements as we need. Hack around with the
z-index values to make sure the right elements come out on top.
Here’s a Sass module to help get you set up with the basic translate and scale math for parallax.
Part 2. Pure CSS Interactivity
2.1. Responsive menu navigation with CSS only
The site has an average links-in-a-row navigation bar when there is room for it. But on small screens, we wanted a CSS only push-down style navigation. This requires some interactivity (tap to reveal). The few HTML elements that have interactivity without any JS are form elements, like checkboxes. When these elements change state, CSS selectors allow us to detect those changes and do things.
How this works:
- A checkbox in the HTML:
- A pseudo state selector in the CSS:
- A sibling selector in the CSS to select the adjacent
input:checked ~ div, for toggling the height of the div on state change
max-heightto transition height of the div rather than
height, because the final height is probably unknown.
You can be creative with this, and make re-usable transitions for things like “read more” accordions. The key constraint that you have to respect is that the
expandee element must follow the
input element for the sibling selector to work.
position: absolute will be your friend if you want the trigger element (like a “read more” link or arrow button) to appear to be below the element that’s getting expanded.
2.2. Animate the scroll with only CSS
This is just a trick, with a fairly big caveat.
:target selector to animate the
top value of the container
<div> to a particular value slowly. The caveat is the user loses scroll control, since the top value has been set by CSS.
So while you can animate a scroll (as we’ll show here), you might not want to do this if you think users prefer just scrolling.
How this works:
- A click on an anchor link appends a fragment to the URL. (e.g. http://site.com/#id)
- The CSS
:targetpseudo selector activates when the URL fragment matches that ID (e.g.
- This can be used to animate the
topproperty, creating a scroll-like effect
In the sample below, we created some in-page anchor links. Instead of typically placing the anchors near the appropriate content, we create fake anchors that help us trigger the CSS animation.
Part 3. Optimization checklist
Optimizing page load speed is an endless effort. You’ll need to figure out a sweet spot between how much time you can dedicate to improving your existing infrastructure, upgrading your infrastructure, and how much you need to care. There are a few obvious, but very important pointers:
- Reduce the amount of data transferred per request: use only minified/compressed assets.
- Improve your servers response time. Use nginx for static content and Apache otherwise. Tune the servers to get the maximum performance out of them. Use good application layer caching, especially if you have content that is frequently dynamically generated (say, through a complex SQL join).
- Don’t write irrelevant CSS rules. Always plan to write your CSS efficiently.
Images are a huge contributor to slow page loads. Here’s a checklist to follow to get the most out of your images:
Different image formats have different advantages. Most formats are scale-sensitive like JPG, PNG and some are scale-invariant like SVG.
- Native image dimensions should be exactly or close to rendered image dimensions (i.e. it’s best if a 400x400px JPG is displayed at 400×400). Or use a scale-invariant format like SVG.
- Image types:
- Millions of colors (like a photo): JPG and lossy compression
- Illustrations or transparency requirements: PNG8, and then if you really need more than 256 colours, PNG truecolor
There are many ways to compress and optimize images. Here are some close-to-the-metal techniques to reduce image sizes that will help you squeeze out the last few unnecessary bytes from your images.
convert -strip -interlace Plane -gaussian-blur 0.05 -quality 85% source.jpg result.jpg
If you don’t want blur, use:
To compress PNGs manually:
- Step 1: pngcrush tries a variety of methods to reduce the colour palette, discard useless chunks etc.
Source: File size reduction - YUI blog
- Step 2: pngquant reduces your png to a 8bit format from a PNG truecolor. This is always worth checking for static images because sizes reduce to about a third! The only caveat is that you’ll have to look at the image manually and make sure that the quality is good enough.
Protip: Use progressive rendering for JPG or interlaced to get better looking image loads. See Progressive rendering on Coding Horror.
An image sprite is a large image that contains many smaller images at different positions. They are most commonly rendered through CSS
background-position shifting around to display the part you need. The important part: sprites reduce the number of overall requests to the server, which as we already covered, is good for performance.
Another advantage to spriting is that all the images are loaded, so lazy-loading problems are prevented. For example: when a hover transition displays a separate image, then there is an image flash, because the image is only fetched when required. Sprites prevent image preloading problems.
The biggest disadvantage to spriting is that it can be a pain to manage building the sprite yourself. This article has lots of techniques for that. If you have a set of similarly sized images, making a sprite is a painless task with ImageMagick’s montage:
montage -mode concatenate -tile 2x10 1.jpg 2.jpg ... out.jpg
This makes a 2 column by 10 row montage of images called
Data URIs are a nifty technique of embedding the required images within HTML or the CSS. Like sprites, data URIs reduce the number of overall requests to the server. However, beware: data URIs are up to 6x slower on mobile.
There are enough resources on good minification and caching techniques, however, here’s a dead-simple solution that is good to implement: Pagespeed’s nginx-module. The pagespeed modules for Apache and nginx are a lot of best practices combined. There are a lot of filters and options available, all worth reading about in detail. Build your own nginx with the pagespeed module, or use a docker image like this.
- There’s a lot you can do with just CSS. Some interactivity added with CSS is essentially a hack, but there is undeniable power in adding interaction and transitions declaratively.
- Always optimize your images! Use lossy compressions wherever you can and dedicate the time to get them right. Build automatic compression and resizing into your build processes.
- Pages should load fast! There’s probably nothing as effective (for the minimal effort) as Google’s pagespeed modules.