I hate to be negative, but what really is the point of this? That a simple webpage without any content can be fast? Of course it can.
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.
This guy's advice is exactly what Google advises you to do, and exactly what Google does.
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.
Google doesn't do this on their more full-featured apps like G-Mail or Google Docs. Docs ships a bunch of files and stylesheets.
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).
HN is neither of the two and IMO represents where people spend most of their time.
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.
HN has a purposely minimalist stylesheet / layout, with NO icons (except the one Y on the upper left corner), NO images or other media, NO fanciful animations.
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.
Yes, and HN is in violation of Google's performance guidelines for putting those sensible rules in a sensible place.
> 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."
Please don't consider this as an attack but, I tend to believe that Google is not in the possession of the absolute truth. They even usually contradict themselves.
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.
There is no silver bullet, no technology that is good everywhere, but there are things that are bad everywhere, like unnecessary reliance on JavaScript, code and resource bloat and so on.
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.
It really depends of your website usage. I am maintaining a free database of chemical properties. Usually people are landing there from Google and looking at a single page[0] before leaving.
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.
I have come across this guy's site before and he does offer some useful tips. Not anything you won't find anywhere else but in a clear and concise manner that almost anyone can understand.
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.
We know that if speed is your goal there are tradeoffs you will have to deal with, such as inline images and css that are harder to maintain. This is a well known architectural tradeoff (along with usability vs security). If you are willing to pay for your load speed in the form of increased page complexity and reduced scalability, this is a legitimate option.
I suppose if we are in control of the backend database that our content is delivered from, we can build a page with inlined images and CSS when the content that drives the page is changed, so it is possible to build quick pages.
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.
After some benchmarking, we did something of this sort on a media site. A middle-fold path works best for us. I'm yet to see any media site do this (yes, we are content-heavy, but we also load fast).
Admittedly, the only thing slowing down the page load is the ads, but we don't bombard those either.
Link: http://www.sportskeeda.com/?ref=san
It is relevant for resource limited IoT devices. It can be a struggle to get embedded web sites running fast using modern frameworks. Throw in TLS with large keys and you enter a whole new world of slow where it pays to shave off every byte possible.
the guy says he's not an idiot then brags about spending $30 per month on a VPS (idiot), for a single-page static HTML website with all inline-code (idiot+1).
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.
Also, whether the VPS has an SSD or not is totally irrelevant— if you really were serving a single page it would be cached in the memory of your webserver.
(Or better yet, serve the thing off S3 and let Amazon be your CDN.)
I'm not saying a VPS is not appropriate for a static HTML web-page, but there are perfectly capable VPSes avaible for $3.50 to $5.
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.
Keeping in mind that you can get a VPS for as low as $3.50 per month, I don't see that there is ever a reason to use shared hosting, and several reasons not to, performance is only one of them.
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
the guy says he's not an idiot then brags about spending $30 per month on a VPS (idiot),
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.
Not disrespecting your opinion here, but $5 Digital Ocean droplets[1] have been working quite well for me as well as for nearly two dozens of my clients, spanning across the last several years (taking into account all the four important parameters you've specified: quality, correctness of operation, data integrity and performance).
My (limited) experience with Vultr[2] has also been fairly satisfactory.
As far as I am aware, Digital Ocean is running on Linux, and because Linux requires turning off memory overcommit and integrating ZFS on Linux, at a minimum, there is no correctness of operation. As there is no fault management architecture (like fmadm), and support for debugging the kernel and binaries is incomplete (no mdb, no kernel debug mode, no kdb, incomplete DWARF support), there really can be no assertion about correctness of operation.
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'.
As a reality check, we're talking simple (and even not-so-simple) web site/app hosting options here (and not some NASA/space/military/healthcare grade requirements).
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.
That would only hold true if your or my time were worthless, or had a very low valuation.
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.
Yes, of course that's correct. And I wouldn't have felt that pointing out that it can be is necessary if he hadn't written that he is inlining it "like a boss". That makes it sound like it's some awesome best practices we all should be adhering to.
So if I'm reading that page correctly, the basic gist of the claim is:
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...
I still don't understand what it accomplishes. Why does inline matter?
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.
I still don't understand what it accomplishes. Why does inline matter?
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.