Looking to tailor your UX to your individual users’ needs? Colin Eagan and Jeffrey MacIntyre have a workshop framework for you!
Ste Grainer takes a brief look at the history of the web, where we are now, and how we can shape its future.
In this article, Aaron Gustafson muses on some of the many ways we can—and should—harness the capabilities of AI to create a more accessible world.
A List Apart founder and web design OG Zeldman ponders the moments of inspiration, the hours of plodding, and the ultimate mystery at the heart of a creative career.
In this excerpt from In Fulfillment: The Designer’s Journey, Justin Dauer ruminates on the past and the importance of keeping an open mind.
This sums up the paradoxes of site design. On the one hand, you get the designers who’s main aim seems to be to make the underlying code look as neat and attractive as possible. On the other hand you get the more pragmatic developers who lump most of the js, css and html into one file, to cut down on requests.
They both seem to miss the point a bit.
I always thought one of the main benefits of separating css and javascript manifested when the second page loaded.
If its all incorporated into one file, then there is no benefit.
If however you have separated out, then the second page would load a lot faster due to caching.
The optimisations discussed here don’t seem to take that into account. Surely the true speed test would take into account the average page views per visit?
It is amazing that your comment is the first time I have heard anyone comment about this. If you regularly visit a site you will cache the images, js & css and this will save bandwidth and load time in the long term.
Some people for example seem to want to put every image in a single sprite form, but this means that every time you want to refresh some of the sprites you have a new massive download. It only makes sense for a sprite to be used when it is used to build a single element.
Such as how the Bing search box is designed, it would be unlikely to alter just one or two of the elements within the sprite rather than the whole thing so its use as a sprite makes sense. However imagine a toolbar done as a sprite, every time a new tool is added you need to re-download the whole sprite rather than the single new icon…
Pre-loading resources especially if they can easily be predicted can easily beat ultra efficient all-in-one html/js/css, although this has to be balanced against the possibility of expensive bandwidth, i.e. where a customer has to pay more when they download more than Xmb.
Good observations.
Tesmond, the problem with cache on mobile is that it’s so unreliable. I’ve lost my link to a fantastic article by a Mozilla engineer who conducted some good analysis on this (this article hints at the difficulties), but mobile cache is a) tiny b) sometimes outright ignored c) sometimes cleared on application exit. As an iPhone user, I’m perpetually irritated by frequently-visited sites showing FOUC — sometimes during a contiguous session.
I believe Google and Bing mobile sites were doing this as long as 4 years ago: the way to get around the inefficiencies mentioned in the comments above is to load everything in the single file as discussed, then carve up the data strings with Javascript, and assign chunks of distinct resources assigned to unique keys in localStorage. Think of these keys as URLs: On subsequent page loads, use the same key-based logic: if the keys for the resources are there, load them from localStorage; if not, compile a list of keys and request them from the server as a single resource.
A few more Steve Souders articles exploring these issues:
http://www.stevesouders.com/blog/2010/07/12/mobile-cache-file-sizes/
http://www.webperformancetoday.com/2012/07/12/early-findings-mobile-browser-cache-persistence-and-behaviour/