Performance notes
traintimes.org.uk
traintimes.org.uk
Hurrah! I am very bored of sites which need you to run 100 bits of JS, often from multiple sites, before displaying any actual content? Why?
As I've said before, I try and make the first ~10kB delivered to the browser be able to render everything important above the fold, and have everything work reasonably in the absence of JS, eg for those of us running NoScript or similar out of caution.
I have gone even more aggressive these days - just stop running JS on client machines at all. Every time a page is slow, breaks, tracks, etc, there is almost always one culprit.
My rule is now that if you can't load your page in lynx - it's broken. There are few exceptions to this rule in my eyes.
On the other hand offloading some computing tasks to the client can save you quite a bit in terms of hardware expenditure on the back end. Again, depends on the site, but many people now have (effectively) supercomputers, so why not leverage some of that? Sometimes it can even enhance the experience, and maybe improve both the perceived and actual performance.
There are also cases where a site simply can't be expected to work without JavaScript. One of my side-projects is an HTML5/JavaScript games site. If somebody disables JavaScript they'll get a nice message explaining why they need to enable it to play the games, otherwise what would my fallback option be? Flash? Bleurgh! No thanks.
I agree, but seems ridiculous that my ("super") computer at current is using 7.4GB of RAM and 7% CPU for just FireFox alone, for what is mostly static content.
>One of my side-projects is an HTML5/JavaScript games site. If somebody disables JavaScript they'll get a nice message explaining why they need to enable it to play the games, otherwise what would my fallback option be? Flash? Bleurgh! No thanks.
That's an edge case, of course, that requires client side computing. The alternative is exceptionally infeasible for everybody involved.
The fact that on many corporate sites I cannot even get to see the company name until I have enabled JS in three rounds with NoScript is silly. Sometimes I just don't bother. As yes I am running a supercomputer right now, I quite agree, but I don't want nefarious stuff run on it. And on my mobile I don't want to be wasting my battery power on emulating Deep Thought to get past the throbber.
Most sites want you to see some text. Many don't let you see any without scads of JS.
(Note: I do use JS to enhance my sites, but the JS is small and the sites work fine without it running.)
It's frustrating when some site uses lots of JS to just reimplement browser features (like displaying text, showing a web form, history/links) which makes my laptop's fan spin up -- but doesn't bother using JS to implement genuinely useful things like validating the credit card checksum (https://en.wikipedia.org/wiki/Luhn_algorithm) in JS on the client before submitting the form.
That's interesting, because that's a case where I would consider it not needed. I've seen some interesting behavior from a network provider where they test "password security" - despite a password I generated meeting all of their rules, the JS fights me because of some bad implementation.
Either way, the server must validate the data regardless. From a design perspective, it makes sense to me to have validation done in one place, rather than several. It just seems that they may become out of sync, or lead the back-end developers into a false sense of validation security on a web form.
The cost of memory is less in this case (no JS in RAM). The CPU time is probably about the same in total. The energy is probably slightly more. The network usage will be about the same (form submission vs JS validation code). We're talking small amounts here, though.
The other thing is that basic HTML is very well nailed in all browsers, whereas JS reliability seems to change depending on the features used, etc. A wake up call for me was when using a slightly older IE browser and using the kindle experimental browser. Both had JS enabled and ran, but ultimately caused the JS rendering to fail for a website I had built in a destructive way (they did half the job of swapping out elements).
My current design philosophy is to avoid JS at all possible costs. Minimalism spruced up with CSS.
A handful of lines of JS that runs the Luhn checksum on the number in the "credit card number" field is not at all CPU intensive and can save people from such data entry errors.
If I typo the card number and there's no JS code to tell me that, I need to submit the form, wait for it to error out, have to re-enter all the billing address information, re-enter the card number, and try this whole process again. I've resorted to re-typing the card number in the "find" box and making sure that it matches the number in the form's field, just to avoid this crap.
That doesn't necessarily have to be the case. If done correctly, the page could come back with errors and the form already filled out. If the connection is secure enough to fill out the form - it must be secure enough to return your data you entered.
I think javascript is a nice addition to client side validation of forms, but it must not impact how they use the system. Having a piece of JS run and not allow me to submit a form is really terrible design, especially when the validation it is doing is running incorrectly.
(And yes, I just tried my current pet site and it worked like a charm in Lynx! B^> )
My daily commute to Walsall has been made extra-efficient through this work
Many thanks, and, for the record, works fine on Seamonkey with NoScript on OpenBSD which is pretty minority.
Well done.
These types of write-ups are some of the best resources as I've grown as a developer. It's a great feeling to come across one that exactly answers something you're stuck on, or explains some concept that you're pretty sure exists but you have no idea where to start.
For anyone wondering what I'm talking about, the kilo prefix is lower case K, the symbol for a byte is upper case B and lower case B is a bit. Kb = kilobit with badly capitalised kilo. kB = kilobyte. kb = kilobit.
Also, interestingly, the JEDEC unit for 1024 bytes is KB while the metric one is kB. This is the only somewhat unambiguous JEDEC unit, the other two are corruptions of metric units.
However the SI k prefix means 1000 (10^3) rather than 1024, which would be Ki.
Also, Ki is an IEC prefix and distinct from the metric system. Metric doesn't have anything other than decimal prefixes as far as I know.
The technical problem is that if you visit the site at all without Javascript, it puts a cookie in an incorrect path, which causes all subsequent searches on the site to fail (even with full JS). Despite my attempts to get past the front line support I've still not found anyone there who is able to understand why this would be a problem. This level of incompetence makes me wonder about the whole operation.
It was actually the thing that made me switch to using http://traintimes.org.uk/ permanently.
By contrast traintimes.org.uk is simple, highly usable, small, accessible, respectful of privacy and works as plain html.
For me it's an easy choice but your mileage may vary!
I can use the service worker to cache all the things, and I can embed their hashes in the service worker so it knows when to refetch code that has changed, but how do I tell browsers to refetch the service worker script itself (to get the latest hashes)? I've read some people suggesting a no-cache header on just that file, although I see that isn't used here, and it seems to defeat the purpose somewhat. How do other people handle that?
EDIT: At least I'm not the only one: https://github.com/w3c/ServiceWorker/issues/893
> If you don't have a CSS cookie set, I inline the CSS in the HTML, load the CSS file asynchronously with a slightly adapted loadCSS JavaScript, and set the cookie.
What is the purpose of the cookie here? Is CSS being stored in the cookie? Does the value of setting the cookie exceed using an Etag to only load the CSS if it's modified?
It is as krallja says; inlined on the very first request (so any caching headers such as ETag wouldn't help, though I do set them for anything subsequent) so there is no display blocking fetching the CSS needed for display (as I have little CSS, I inline all of it, but you might want critical CSS only).
Though to be honest most things don't, I blame being rural.