About 15 years ago a group of us were gathered around a computer waiting for “The Phantom Menace” trailer to download.

It was still early enough in Internet time that an online debut was a problem. The combination of a big movie file and huge demand led to a giant trainwreck. It took hours to download even on our company’s fast internet.

The trailer had 10 million downloads, which I seem to recall was the most popular download of its time, though it’s likely been surpassed since.

Within seconds of “The Force Awakens” trailer popping up, thousands, if not millions had seen it and were already tweeting about it.

How times changed. One thing to remember is that in 1998, “The Phantom Menace” trailer looked awesome. Go watch it. It’s got some Jar Jar, sure, but face it, but there’s nothing to suggest it would be terrible. Good trailers mean nothing, case in point one, and case in point two.

My response to the Millennium Falcon and the “Star Wars” theme is almost pavlovian, so it’s hard to make a rational assessment of any “Star Wars” trailer.

Rather, the implicit message of “The Force Awakens” trailer seems to be a sort of relationship counseling. “We know you’ve been hurt in the past. It’s OK to love again.”

MG Siegler seems to have hit the nail on the head with this tweet:

Pretty sure that teaser is already better than any of the last three Star Wars films.

The trailer has left me giddy, sure. But …

I posit “The Star Wars Problem”. Most people fell in love with “Star Wars” as children. We love it completely and irrationally, so irrationally that no movie including “Star Wars” itself could ever meet expectations.

What I want is that moment in a theater when the lights go down, a “long time ago…” appears to silence followed by a blare of of horns, the “Star Wars” logo and the iconic theme music and crawl. “It is a period of civil war …”

It’s a moment of pure transcendent transporting joy back into the comfort of childhood that no movie can possibly equal it.

Whatever comes after that moment just needs to be “not terrible.” Guess we’ll know for sure in about a year.

A few years ago, I made a key lime pie for a party. One of my friends was raving about it. “Oh my God. You have to give me the recipe.”

“Well,” I said. “There’s no secret. It’s the recipe on the key lime juice bottle.”

This is sort of how I feel about my web optimization efforts. Smart people at Filament Group and Google and elsewhere have already figured it out. Just follow the recipe.

If it was that easy, we’d all be Gordon Ramsay. Err, maybe not.

But, like with pie, experience has taught me some finesse. For instance, make your key lime pie crust with vanilla wafers and a little bit of cocoanut.

Recipes are only general directions. Every site is a little bit different. The browser is always right. And sometimes the browser is like a cranky toddler banging a spoon on its highchair.

With this site, my results have been solid. My index page has a start-render time of ~.2 seconds and load time of around 2 seconds. It’s among the top 3 percent of fastest pages on webpagetest.org. Not bad for an image-driven site with giant hero art.

Mainly trying out these techniques was a learning experience. Here are a few insights that I gained that might help others trying to optimize a site.

###What worked

• Inlining “above the fold” CSS doesn’t speed up overall load times so much as make the page seem to load faster. So fast it seems to be loading from cache. In terms of user experience inlining CSS is a big win. Beware, though. It can be difficult – well, crazy-making – to implement and maintain manually. Next time I’ll probably try this.
• Hot-swapping hero images This Google-suggested technique loads a super-low-res version of hero art and then swaps with it a high-res image on DOM ready. Downsides include Javascript implementation, increased page weight, a double download, and the lead art looks gross until the real image loads. The designer in me should hate this. But the most damning thing of all … I think I can live with it.
• Lazy loading fonts gave me a large overall speed improvement. I saw Jason Parmentel’s session on this at Artifact and went home that night and added the Adobe webfontloader to my dev site. My start render time dropped below 1 second after this. The downside is flash of unstyled text, but a blank page awaiting a font download is a worse user experience.
• Lazy loading CSS After testing, I’d scrapped this because it was actually slowing load times. I tried another technique suggested by Google, but the site was breaking in – wait for it – IE. A few days later I took yet another crack at it and inlined all of Filament Group’s loadCSS tool in the header. Success. It cut about a half-second off my start render time. If you are bothered by inline JS, I’d forego this one.
• Inline SVGs were another huge win for initial render times. Codekit made building out pages with inline SVGs quite easy (and fun!). Although inlining them made the HTML5 validator head for its fainting couch like Tallulah Bankhead until I cleaned up the SVG code. The downside of this technique is graphics can’t be cached and your nice, neat HTML pages are a horror show of SVG code. If you do plan to use inline SVGs, this icon sprite method combined with CSS styling is the best way to go.

So that’s the positives. I also learned some negatives and gained some insights, but this post was getting pretty long so I’ll cover those in Parts 2 and 3 in a few days.

I’ve been to several design conferences in the past couple years, and typically within the first few hours some sort of discussion will break out – usually on Twitter – over “should designers code”.

A lot of pixels and a some vitriol have been also spilled on the subject. But it’s really nothing but a bunfight. Opinions get tossed around but no one actually gets hurt.

My position has always been of course designers should code. Why would you not? It’s the fundamental technology of the web.

But “designers should code” sounds a little bossypants. I’m not sure I like that.

After all, it’s not a necessity to do the job. Whatever genius drew the bite-the-back-of-your-hand beautiful lines of an Aston Martin probably doesn’t know how to design a fuel injection system.

Coding and building have always been a natural fit for me. I’ve been studying both computers and design since I was teen. In high school I programmed an Apple II to to draw an endless array of swirling colored lines. It felt like magic then and years later coding a website still feels a little like magic.

But a lot of designers didn’t follow my path into the industry. They were painting and drawing and studying graphic design while I was pecking away at a keyboard.

Their art-before-science approach has value. So I’d like to make a more nuanced case for designers learning to code.

Web “design” is all in how you define it, like the tale of the elephant and the blind men. The argument is whether a designer should understand the parts or the whole.

A visitor to this or any other site sees the images and color and typography choices, aesthetics – designer stuff, the parts. But they’re seeing the whole thing. They’re seeing your data structure, your site architecture.

They’re seeing the HTML/CSS/jQuery – the equivalent to a building’s structural steel. They’re seeing that your site is lightweight and fast when it loads seemingly instantly. They’re seeing that the code and the structural parts have real beauty in how they support the overall need.

There’s joy in how the most mundane parts of a thing are made. When Jonny Ive talks about the design of a unibody Macbook he’s as enthusiastic over the process and the functionality itself as much as beauty of the final object.

That’s how designers should think about their work.

Greatness comes from the entire object. And the only way to understand a thing is to make it, to get your hand hands in the dirt.

This is design. And it’s in the code as much as the final product.

We’re live. Finally. It still has that new website smell.

I’ve been working on a new Davidputney.com pretty regularly since early October. It’s not so much done as kicked out the door. Please be patient as I still clean up some of the messes that I made.

This replaces an older jQuery-based site that I built over a three-day weekend because I needed a portfolio site to apply for a job. This redesign is about the fourth guise for a domain that I’ve owned for 14 years now, probably to the dismay of other David Putneys who have would like to have it.

Building this was also an interesting exploration for me. I have an upcoming post on some of the technology and philosophy that went into it.

Until then, welcome.