Kicking ass and making games.

More Faster

I’ve been getting a little obsessed over speed lately, likely because I’m hitting that “anal about assets” point at work which leads to hunting down and killing every unnecessary or unused asset contained in the build. It’s a good feeling.

With the web that spills over into optimizing load times to minimize not just memory usage but also bandwidth. Returning to my photography site after a busy Fall and Winter I took the opportunity to stab at load times a bit.

First up: Moving photos off the web server and onto the AWS S3. This provided some minor, but visibly noticeable, performance improvements (once I found the CORS config that was somehow eluding me). It also provided some peace of mind that photos hosted on my site are only being hosted on my site. Plus, content is now poised to be served by the CDN.

Next up: Fixing the, uh, (every image is being loaded twice) bug spotted while looking at network usage from the S3. Once I noticed it, it was glaringly obvious, but “Oops!”. Ah well, quick fix and 50% speed improvement. This gave me an excuse to push the loaded image BLOB into a base64 object for CSS, though I ended up pulling that out because it proved to be an unnecessary conversion that just added some overhead to the client.

Finally: Google Analytics User Timing. So this isn’t exactly a load time reduction, but it will help keep an eye on where we’re at, and is absolutely worth the time to put in place.

So what’s next? Adjusting load order on the page may or may not have much impact because it’s the script that is going to display the content in the end anyway, but we can reduce HTTP requests for some gain (and sanity) and minification will help some. We can also push all the remaining static scripts over to S3, speeding up their delivery, and potentially compress the site content.

Before diving into this level of detail it would be prudent to benchmark more aggressively for comparison.  🙂

, , , , ,

Comments are currently closed.