Jason Ormand

Even better. I was lazy since they are typically already loaded for the stuff I do day to day. But for a snippet like this, removing dependencies is a great idea.

The code snippet is only meant be a tool for measuring the efficiency of the images you are displaying. In our case, yes, the totality of what we do to load images improves the page load event time. We use javascript on the front end to ask the server for the best possible image, for whatever element needs and image...at that break point/size for that DPI/PPI/scale. We have sufficient resources to do all the fancy image processing on the server side, so no worries. But of course we cache the images on a cdn after we generate them, so only a maximum of 1 page load per break point / image size would incur any server side image work - most of which is done before the first user hits the page since our editorial team would have already previewed the article. And each image at each size generated has a unique url, there are no caching inefficiencies. The end result is that the blocking assets load first (html/css/essential js/etc) and we lazy load the best image possible asynchronously after the load event fires. So yeah, using this methodology our pages have a perceived decrease in load time VS say loading static images synchronously.