You say this website is only fast because it's "without any content". If there's no content then tell me how it communicated its point so clearly. If it's inherently fast then tell me why the same thing posted to Medium is so slow.
A hallmark of a great solution is that people who see it decide the problem must not have been very hard.
http://www.csd.uwo.ca/~magi/personal/humour/Computer_Audienc...
Search works well because they have relatively few features to support by default (for things like the calculator I bet they ship that in with the response).
I think Google's CSS embedding is terrible advice for the meaningful web, but logical advice for adwords landing pages or sites with content so bad or sparse you wont be navigating them.
Not all websites can do without all of that - imagine a photography site, or an e-commerce site, etc. without pictures?
I agree though that this is great advice for landing pages; load times are probably among the reasons of most bounces.
No, but I can imagine an photography site, or an e-commerce site without useless non-content pictures and shit-loads of CSS and JS.
> Not all websites can do without all of that - imagine a photography site, or an e-commerce site, etc. without pictures?
How does HN's CSS enforce a ban on img elements in pages pointing to a photo's canonical location? Or preclude putting your standard frames into it?
Imagine a photography site where no photo link is shared across any pages (but 90 page base64 encoded URLs are repeated randomly), an ecommerce site where a product is shown in a strange new light at every step in the checkout process using a mishmash of entirely different CSS.. Google's advice is approving the most idiotic behavior on sites that are barely keeping their head above water in terms of technical understanding, letting them hold onto strange ideas because they are "fast."
HTTP2 allows CSS to specified in the HTTP header. However Google AMP doesn't support it yet.
To shame people who build slow, bloated websites.
Saying that no bloat equates to no content is part of the problem.
There is no silver bullet solution to all problems when building webpages, and if you think this guy's advice is catch-all for everyone and that "shaming" people who don't follow those rules is good, then you're a bad developer.
Someone else said it elsewhere in this thread, but different contexts need different solutions based on determined use cases and needs.
Being diplomatic about it and not assuming everyone who deployed a Joomla installation with a ton of bad plugins because it HAS TO WORK NOW is an idiot is OK. But wrapping bad engineering practices in "different contexts need different solutions based on determined use cases and needs" is a very different story.
Obviously, different contexts and use cases need different solutions. That's no excuse to pick the bad ones, nor to pretend they're not really, really bad.
To have this single page experience as good as possible, I pack the CSS directly in the HTML. First I packed also the image of the molecule, but it was not good for SEO, because I have quite some visitors coming from search of the drawing of molecules. Google would be smart to index the inlined images, I would switch back to use them.
All these optimisation techniques are only good if the context is the right context. That is, you need to pay attention to the assumptions used to make these rules.
There are lots of people self-managing small sites that don't have a clue about any of this stuff - it's a decent resource for such people - nothing more.
An affiliate link in the last paragraph.
No, that most "content" making webpages slow is useless BS bloat.
The main driving point is probably the fact that there is sometimes no need to build pages that rely on all manner of JavaScript etc.
It's not being negative to point out the glaring flaws in a person's statements. My assumption is the entire thing is an advertisement for that hosting service.
(Or better yet, serve the thing off S3 and let Amazon be your CDN.)
I'm not in agreement with many of the commenters regarding CDNs. I don't believe in a free lunch. Free software is one thing, but CDNs require infrastructure, which incur costs. Somewhere, the people offering those services expect to make those costs back. You'll either pay for it directly, or you'll pay for leeching off someone else's bill in karma. For a very tiny, low-traffic, low-bandwidth website, I think not using a CDN is perfectly reasonable.
Just because Godaddy sucks doesn't mean that all shared hosting sucks. NearlyFreeSpeech.net is fine for most people, or Amazon S3 if you're into AWS / webgui stuff.
If you're actually using a decent amount of bandwidth (ie: image hosting), something like Hawkhost.com would be good. Just gotta stay away from EIG (https://en.wikipedia.org/wiki/Endurance_International_Group), which is a conglomerate that's buying up all the shared hosts and making them crappy.
Bam. Now you have economies of scale AND far cheaper hosting than any VPS.
If you're website is that unimportant, then you could probably get by with any free hosting services where your page would be yourpage.serviceprovider.tld
You can always go with cheap, fully virtualized GNU/Linux server, or you can go with a virtual, true UNIX server running at the speed of bare metal[1].
Your choice, but quality, correctness of operation, data integrity and performance still cost something. It you don't care about any of those things, fork out $5 for the alternative and call it a day.
My (limited) experience with Vultr[2] has also been fairly satisfactory.
[1] https://www.digitalocean.com/ [2] https://www.vultr.com/pricing/
Correctness of operation does not only refer to end-to-end data integrity, but also to adequate capability to diagnose and inspect system state, in addition to being able to deliver correct output in face of severe software or hardware failures. Linux is out as far as all of those.
In other words, if you want JustWorks(SM), rock solid substrate for (web)applications, anybody not running on FreeBSD, OpenBSD, or some illumos derivative like SmartOS is out, at least for me. Perhaps your deployment is different, but I don't want to have to wake up in the middle of the night. I want for the OS to continue working correctly even if hardware underneath is busted, so I can deal with it on my own schedule, and not that of managers'.
From my perspective (as a freelance web tech/dev professional who routinely manages close to two dozen hosting accounts for clients), what you're saying above comes very very close to driving a nail with a sledgehammer.
Hosting clientele is notoriously high maintenance; the more technology ignorant, the higher the maintenance in terms of support, and the more fallout one has to deal with when there is downtime.
My time is expensive. My free time is exorbitantly expensive. Therefore, when I pick a solution and decide to deploy on it, it has to be as much "fire-and-forget" as is possible. Picking a bulletproof substrate to offer my services on also increases the time available to provide higher quality service to my clients: since my time dealing with basic infrastructure is reduced as much as possible, I have more of it to spend on providing better service and adding value, thereby increasing the client retention rate. Because of the economy involved in this, and especially considering how razor thin hosting margins are, I feel that the nail with a sledgehammer metaphor is inapplicable to this scenario.
Edit: that's obviously a non-issue in this particular case since everything is static. But as a best practice this needs to be considered and inline CSS doesn't make you a boss.
CSP will do absolutely nothing for a single static html page containing all assets it needs as inline.
If we only do a half assed job of sanitising user input by attempting to blacklist whatever javascript we can think of, we'll still be open to XSS attacks from people smarter than us who put css into our user supplied data, so the answer is to prohibit inline CSS - not to properly sanitise user supplied data.
I think there are better pieces of security advice around than that...
The vulnerability means they can inject arbitrary markup including <link> or <script> that load offsite sources.
You can use CSP to whitelist allowed offsite domains. But if you're not careful, "you never know" and "you might as well" are more likely to waste your time chasing low value things.
For instance, inline CSS is valuable as an intermittent developer convenience, and disabling it takes that away while protecting your from an unlikely event.
Also, you generally should be escaping-by-default and not sanitizing. A templating system should escape by default and make it obvious when you opt out.
In the worst case scenario, where the server doesn't have all the blocks of the file cached in random acces memory, the server can fetch the single, inlined file with fewer input operations per second from local storage far faster than one's web browser can fetch multiple files over the network. This means that latency is lowered, and thus delivery time is accelerated.
Is it desirable to inline your CSS, "like a boss?" Maybe if you have one single web page. What if you have dynamic content and your users intend to browse more than one page? With externalized CSS, that is all cached.
Same with images. If I'm building a web application, I certainly do not want inlined images. I want those on a CDN, cached, and I want the page to load before the images.
Not only is this not particularly useful advice, it's bad advice.