One of the interesting problems we ran into when using the masonry layout on remember was the effect it had on perceived page load time. The first version naively waited for all images to load before laying out the “bricks” which was pretty unacceptable with the number of user-contributed images we have. If you are unfamiliar with the masonry layout, the engine starts with a block and then places it in the least-tall column. Placing the block increments the column height by the block’s height, so if you don’t know the real height at placement time, you’ll end up with overlapped blocks.
Given this knowledge, the simplest way to overcome this is to know the width and height of the images before loading. If you know how tall an image will be, you can set its dimensions prior to the image loading which adequately avoids our overlapping problem and let’s us load immediately on domready. Implementing thishaws great, but there were some times we were still getting overlapping boxes.
I was able to faithfully reproduce the issue by turning off the cache in my browser, so then it was a matter of logging and break points to determine the cause: fontface. While a remote font is loading, the text does not render and the empty area that serves as a placeholder for the text isn’t the eventual correct height. The first instinct is to point at line-height, but a variable character-width/kerning can easily change the number of lines the text will use and that information is only available when the font has loaded. In my experimenting in Firefox, I wasn’t able to manipulate the placeholder area by changing the font stack. I was hoping it was rendering the text with the fallback font and just hiding it from view. This would have let me choose a font that closely matches the spacing characteristics but simply changing the stack didn’t seem to have much effect on the size of the placeholder white space.
So we’re back at the masonry mechanics where we can safely layout the bricks when we know the height of all the bricks. Unlike the images, waiting on a single font doesn’t seem like it would be so bad. We can just use typekit to load the font which allows us to subscribe to a loaded event where we can trigger layout. What I found, though, is that fontface is prioritized differently than other assets. Fontface as a presentational element gets put at the end of the queue for assets to load over the network. This means it comes after all those user-submitted images we so elegantly sidestepped earlier. I did read that browsers will not download the font till it encounters a CSS rule that used it, but even trying to force it using hacks from Paul Irish’s excellent fontface write up didn’t change the ordering. [todo when not on my iPod: take screenshots of waterfalls]
So in the end, we had to ensure our fonts in the masonry layout were local/synchronously loaded or bypass the load order by only loading images after the font had loaded. The latter strategy did sound like a fun experiment but I’m afraid it’s too brittle for too small a gain, so we chose new fonts. Not the happiest of endings but we were able to avoid waiting for all the images to load prior to showing the page.