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.
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
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.
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.
Just to point out, there's no particular reason to host a page like this on a VPS at all. You could just throw it on S3. Even better, you could put it behind a CDN like Cloudfront and the total cost would be a dollar or two a month, not $25+ and it would be significantly faster.
> You could just throw it on S3. Even better, you could put it behind a CDN like Cloudfront and the total cost would be a dollar or two a month, not $25+ and it would be significantly faster.
I apologize for quibbling (really, I do! but I'm an infrastructure guy! This is my bag!). Yes, host it on S3, but ALWAYS put a CDN in front of S3 with long cache times (even just Cloudfront works). S3 can sporadically take hundreds of milliseconds to complete a request, and you know, AWS bandwidth is expensive (and CDN invalidation is damn near free). And you can use your own SSL cert at the CDN usually instead of relying on AWS' "s3.amazonaws.com" SSL cert (although you will still rely on the that S3 SSL cert for CDN->S3 Origin connections; C'est la vie).
EDIT: It also appears Cloudfront supports HTTP/2 as of today. Hurray!
Yeah I notice that was weird too. The creator speaks a lot about about html optimizations but one of the most widely-used methods of page speed increases are global CDN distribution.
The SSD is really meaningless in this context. The website is so small that it will be loaded almost 100% from the filesystem cache. As long as it has more than 512 MB of ram...
If I wanted my website to load incredibly fast, I would absolutely not put it on an obscure VPS. Not that there's anything inherently wrong with it, but it's generally not going to make your site faster.
The clever internet marketer who set up the page missed a trick!
Instead of the affiliate link to some host no on has heard of,he should have affiliated linked to AWS (if possible) and a CDN. Then he could have added that as a strong feature that helps makes the page so fast?
Has any one dealt with DDoS attack on a static hosting (S3 + Couldfront) set up?
I sometimes fear that if something like this happens the bandwidth bill will be too much to handle for small personal projects. Also it's a pain that AWS doesn't allow one to set hard limits on cloud spending. Yes, they allow to set up some billing alarms, but no hard limits. No guarantee that no matter what, the month's hosting bill will not exceed $10 for this project.
For small personal projects a tiny VPS seems to be safer from this angle. At max a DDoS will cripple the VPS but the hosting bill will stay the same.
If you have been through this, did you get any discounts from AWS for resources being used during DDoS attack or you had to pay the full amount.
> "I am not on a shared host, I am hosted on a VPS"
Hate to break it to you, but your virtual private server (VPS) is likely sharing a bare-metal server with other VPS. ;-)
Also, you can look into content delivery networks (aka CDN), which will most likely deliver this page faster to clients than your VPS especially when you consider your VPS is in Dallas and CDN's have nodes located around the world.
Hosting on a single VPS is never gonna be very fast globally no matter what you pay your hosting. In fact our free plan on netlify would make this a whole lot faster...
OP has certainly nailed Hacker News psychology. My old coworker called the technique "inferiority porn." Titles like "the secretly terrible developer" or the closing statement of this particular article: "Go away from me, I am too far beyond your ability to comprehend."
As many people have pointed out there are faster methods of static hosting through a CDN, and many of the techniques of this site are inapplicable for larger sites. But A+ on the marketing.
IMHO there is mainly one way to get attention - it's to get (great and instant) emotion from the user. You can give good emotions or bad emotions.
Personally, I think, that to create a good emotion takes much more effort than to create a bad one. The website/product can say how great am I, but it will not 'click' as instantly as someone telling me I am a dumb baby and I suck [0][1] or I am not superior mere mortal baboon [2], for which most people will get instant rage and will start flame wars in whatever comment section, as there "is no such thing as bad PR".
Most popular writer/bloggers in my country have created these dipshit arogant characters (I tend to believe that they are "normal" people, but they clearly know what sells) who always say that they are richer, smarter and better than you. They create stories about "cheap restaurant breakfast for 60€" and so on, though the most interesting thing is that people buy their shit and then rage on whatever websites about how dared the writer call them a dumbass homeless bum.
I probably sound like I'm tooting my own horn but it definitely felt really contrived to me. I upvoted it because of the comments containing better tips or caveats provided for the good ones.
I'd say that the general idea of watching out for external and/or bloated resources is absolutely applicable for larger sites. Media sites are particularly egregious: not only does the js take the lion's share of what's transferred, rendering of the content I'm interested in typically blocks until everything is downloaded and processed.
I make my personal pages fast this way since last century. Probably a huge amount of people did the same. It's pretty obvious.
When you need fancy graphics (a static photo album), things become less easy: you e.g. may want to preload prev / next images in your album to make navigation feel fast.
Things become really tricky when you want interactivity, and in many cases users just expect interactivity from a certain page. But client-side JS is a whole another kettle of fish.
When things become ugly is when you want to extract some money from page's popularity. You need to add trackers for statistics, ad networks' code to display the ads, and complicate the layout to make room for the ads, placing them somehow inobtrusively but prominently. This is going to be slow at worst, resource-hungry at best.
(Corollary from the above: subscription is more battery-friendly than an ad-infested freebie.)
Took me almost 30 seconds to load, maybe because the server is being hammered by HN traffic right now? Also like others here were saying, using a CDN would definitely help with the initial latency.
I think this is the ironic lesson: for many sites, optimizing for consistent performance (i.e. CDN, geographic caching) is a more important objective than prematurely optimizing for a subset of users.
Example:
Business A - average render time 0.3s, but under load 5-10s
Business B - average render time 0.8s, but under load 1-2s.
Subjectively, around ~10s response time is the point I would close the tab and look for another business if I was trying to do shopping online, anything involving a credit card etc.
Is this image inlining thing something new? Am I reading it correctly that the images are encoded in base64 and delivered as html? Surely this is a bad idea... no?
Cool... Unfortunately in practice it's easy to find a list of best practices, much harder to implement in a scalable and durable manner on any project of sufficient size, especially if working with a legacy codebase.
> "My images are inlined into the HTML using the base64 image tool, so there is no need for the browser to go looking for some image linked to as an external file."
This does not work in most cases when you use big images.
From StackOverflow answer [1]: "It's only useful for very tiny images. Base64 encoded files are larger than the original. The advantage lies in not having to open another connection and make a HTTP request to the server for the image. This benefit is lost very quickly so there's only an advantage for large numbers of very tiny individual images. "
A VPS is shared hosting to me, it's just an instance on a shared system. Shared hosting used to mean a folder on a shared web server but I consider sharing resources in a hypervisor equally shared. ;)
If they truly wanted speed through control of resources they would have used bare metal.
But yeah, the website is easy to optimize when it's simple, the hard part, often outside of your control, is DNS and actual connection handling. Many have already mentioned CDN so there's that.
But you also don't know what kind of firewalls are being used, or switches, or whatever else may impact your site. Why not just do what others have suggested and put it all in the cloud so that Amazon can worry about balancing your load.
Ok I'll bite as this is near and dear to my heart. Instead of showing me a fast webpage with a minimal content, tell me how to make my tons of css and js load fast! That's a real problem.I deliver web apps, and interactivity is a must.
IMO, the real problem with the web is the horrendous design choices and delivery of very popular news and daily reading sites (ahem cnn) where subsequent loads of ads and videos start shifting the page up and down even when you have started reading something. Let's address that problem first!
[+] [-] jlmorton|9 years ago|reply
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.
[+] [-] twhb|9 years ago|reply
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...
[+] [-] nhebb|9 years ago|reply
[+] [-] gaur|9 years ago|reply
To shame people who build slow, bloated websites.
Saying that no bloat equates to no content is part of the problem.
[+] [-] Loic|9 years ago|reply
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.
[0]: https://www.chemeo.com/cid/45-400-7/Octane
[+] [-] dazc|9 years ago|reply
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.
[+] [-] huhtenberg|9 years ago|reply
An affiliate link in the last paragraph.
[+] [-] acagle|9 years ago|reply
[+] [-] coldtea|9 years ago|reply
No, that most "content" making webpages slow is useless BS bloat.
[+] [-] 72deluxe|9 years ago|reply
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.
[+] [-] sankalp_sans|9 years ago|reply
[+] [-] KirinDave|9 years ago|reply
[+] [-] jrmacmillan|9 years ago|reply
[+] [-] simbalion|9 years ago|reply
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.
[+] [-] TheGreatestEver|9 years ago|reply
[deleted]
[+] [-] ajmurmann|9 years ago|reply
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.
[+] [-] zackbloom|9 years ago|reply
[+] [-] toomuchtodo|9 years ago|reply
I apologize for quibbling (really, I do! but I'm an infrastructure guy! This is my bag!). Yes, host it on S3, but ALWAYS put a CDN in front of S3 with long cache times (even just Cloudfront works). S3 can sporadically take hundreds of milliseconds to complete a request, and you know, AWS bandwidth is expensive (and CDN invalidation is damn near free). And you can use your own SSL cert at the CDN usually instead of relying on AWS' "s3.amazonaws.com" SSL cert (although you will still rely on the that S3 SSL cert for CDN->S3 Origin connections; C'est la vie).
EDIT: It also appears Cloudfront supports HTTP/2 as of today. Hurray!
https://aws.amazon.com/about-aws/whats-new/2016/09/amazon-cl...
[+] [-] matt_wulfeck|9 years ago|reply
The SSD is really meaningless in this context. The website is so small that it will be loaded almost 100% from the filesystem cache. As long as it has more than 512 MB of ram...
If I wanted my website to load incredibly fast, I would absolutely not put it on an obscure VPS. Not that there's anything inherently wrong with it, but it's generally not going to make your site faster.
[+] [-] niftich|9 years ago|reply
[+] [-] bbcbasic|9 years ago|reply
Instead of the affiliate link to some host no on has heard of,he should have affiliated linked to AWS (if possible) and a CDN. Then he could have added that as a strong feature that helps makes the page so fast?
[+] [-] pritambarhate|9 years ago|reply
I sometimes fear that if something like this happens the bandwidth bill will be too much to handle for small personal projects. Also it's a pain that AWS doesn't allow one to set hard limits on cloud spending. Yes, they allow to set up some billing alarms, but no hard limits. No guarantee that no matter what, the month's hosting bill will not exceed $10 for this project.
For small personal projects a tiny VPS seems to be safer from this angle. At max a DDoS will cripple the VPS but the hosting bill will stay the same.
If you have been through this, did you get any discounts from AWS for resources being used during DDoS attack or you had to pay the full amount.
[+] [-] JDiculous|9 years ago|reply
[+] [-] neoCrimeLabs|9 years ago|reply
Hate to break it to you, but your virtual private server (VPS) is likely sharing a bare-metal server with other VPS. ;-)
Also, you can look into content delivery networks (aka CDN), which will most likely deliver this page faster to clients than your VPS especially when you consider your VPS is in Dallas and CDN's have nodes located around the world.
[+] [-] bobfunk|9 years ago|reply
https://performance.sucuri.net/domain/varvy.com
Hosting on a single VPS is never gonna be very fast globally no matter what you pay your hosting. In fact our free plan on netlify would make this a whole lot faster...
[+] [-] begriffs|9 years ago|reply
As many people have pointed out there are faster methods of static hosting through a CDN, and many of the techniques of this site are inapplicable for larger sites. But A+ on the marketing.
[+] [-] trymas|9 years ago|reply
IMHO there is mainly one way to get attention - it's to get (great and instant) emotion from the user. You can give good emotions or bad emotions.
Personally, I think, that to create a good emotion takes much more effort than to create a bad one. The website/product can say how great am I, but it will not 'click' as instantly as someone telling me I am a dumb baby and I suck [0][1] or I am not superior mere mortal baboon [2], for which most people will get instant rage and will start flame wars in whatever comment section, as there "is no such thing as bad PR".
Most popular writer/bloggers in my country have created these dipshit arogant characters (I tend to believe that they are "normal" people, but they clearly know what sells) who always say that they are richer, smarter and better than you. They create stories about "cheap restaurant breakfast for 60€" and so on, though the most interesting thing is that people buy their shit and then rage on whatever websites about how dared the writer call them a dumbass homeless bum.
[0] https://www.youtube.com/watch?v=0nbkaYsR94c
[1] https://news.ycombinator.com/item?id=12448545
[2] https://varvy.com/pagespeed/wicked-fast.html
[+] [-] brazzledazzle|9 years ago|reply
[+] [-] andreareina|9 years ago|reply
[+] [-] nine_k|9 years ago|reply
When you need fancy graphics (a static photo album), things become less easy: you e.g. may want to preload prev / next images in your album to make navigation feel fast.
Things become really tricky when you want interactivity, and in many cases users just expect interactivity from a certain page. But client-side JS is a whole another kettle of fish.
When things become ugly is when you want to extract some money from page's popularity. You need to add trackers for statistics, ad networks' code to display the ads, and complicate the layout to make room for the ads, placing them somehow inobtrusively but prominently. This is going to be slow at worst, resource-hungry at best.
(Corollary from the above: subscription is more battery-friendly than an ad-infested freebie.)
[+] [-] userbinator|9 years ago|reply
[+] [-] ksubedi|9 years ago|reply
[+] [-] AOsborn|9 years ago|reply
Example:
Business A - average render time 0.3s, but under load 5-10s
Business B - average render time 0.8s, but under load 1-2s.
Subjectively, around ~10s response time is the point I would close the tab and look for another business if I was trying to do shopping online, anything involving a credit card etc.
[+] [-] turtlebits|9 years ago|reply
[+] [-] dmlittle|9 years ago|reply
[+] [-] PunchTornado|9 years ago|reply
[+] [-] paulpauper|9 years ago|reply
The fastest and most reliable hosting is, by far, based on my own experience is amazon's e2 cloud and S3 bucket services.
[+] [-] Mao_Zedang|9 years ago|reply
[+] [-] Annatar|9 years ago|reply
[+] [-] quinndupont|9 years ago|reply
[+] [-] leesalminen|9 years ago|reply
Image of Chrome Dev Tools: https://reportcards.scdn3.secure.raxcdn.com/assets/uploads/f...
As an aside, does HTTP/2 provide any benefit for a single HTML file with no external assets?
[+] [-] pilif|9 years ago|reply
Of course that's entirely irrelevant as the page completely fits into the ram of the server (or even the CPUs cache for that matter)
[+] [-] vonseel|9 years ago|reply
[+] [-] usaphp|9 years ago|reply
This does not work in most cases when you use big images. From StackOverflow answer [1]: "It's only useful for very tiny images. Base64 encoded files are larger than the original. The advantage lies in not having to open another connection and make a HTTP request to the server for the image. This benefit is lost very quickly so there's only an advantage for large numbers of very tiny individual images. "
[1] - http://stackoverflow.com/questions/11736159/advantages-and-d...
[+] [-] zodvik|9 years ago|reply
[+] [-] INTPenis|9 years ago|reply
If they truly wanted speed through control of resources they would have used bare metal.
But yeah, the website is easy to optimize when it's simple, the hard part, often outside of your control, is DNS and actual connection handling. Many have already mentioned CDN so there's that.
But you also don't know what kind of firewalls are being used, or switches, or whatever else may impact your site. Why not just do what others have suggested and put it all in the cloud so that Amazon can worry about balancing your load.
[+] [-] josephjrobison|9 years ago|reply
[+] [-] cyberferret|9 years ago|reply
Note: Just checked, and even a simple Medium blog post page won't fit on one those old 3.5" floppy disks..
EDIT: To stay on topic - the OP's page loaded instantly for me here in outback Australia...
[+] [-] smoyer|9 years ago|reply
[+] [-] pacnw|9 years ago|reply
IMO, the real problem with the web is the horrendous design choices and delivery of very popular news and daily reading sites (ahem cnn) where subsequent loads of ads and videos start shifting the page up and down even when you have started reading something. Let's address that problem first!