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!
How long S3 takes to fulfil a request does not affect bandwidth.
I personally went the other way. I still use CloudFront as a CDN but made it cache items for short periods of time. Invalidation was too much of a hassle, and it took too long. Admittedly, I should use hashes or something of the sort to keep my items versioned, but laziness always gets in the way.
> How long S3 takes to fulfil a request does not affect bandwidth.
Correct. Did I insinuate that? I apologize if I did. They are two distinct issues, both of which a CDN prevents.
1. S3 outbound bandwidth is expensive. Use it only as an object store of last resort. Your CDN bandwidth is orders of magnitude cheaper (don't believe me, go compare the pricing).
2. S3 response times can vary wildly at times. Use a CDN to avoid this.
And of course feel free to use a cache key instead of invalidating via an API if ~15 minutes it too long to wait for fresh content to appear at edges.
PS Don't apologize for laziness. When directed appropriately, its a most productive force.
My mistake! I assumed you meant the time it takes to fulfil a request and the bandwidth cost were related because they were mentioned in the same sentence.
IIRC, the CDN isn't charged separately, and the object store is available (within a certain quota) within the GAE free tier, so, within certain limits, yes, "for free".
Don't you have to provide a CC to sign up for even the free tier? (That's how it was when I was trying it out a couple of years back.) It was really cute too, Google would send me a $0.00 invoice each month.
No, thanks for correcting me. The names are similar enough and the purpose is too, so it's easy to confuse. I mean, if you hadn't commented, I would have wondered why it got downvoted.
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.
Meaningless-weaningless, but that site loaded instantly on my iphone 4-without-s and did not lag, unlike all others (except hn ofc). No CDN can hide modern js freezotrons.
That's because all those other sites are poorly built. It's not because the article's site is a brilliant example of "doing it right".
Putting bare text on the web is always going to be fast. So what. If he presented a real full-featured website with the bells and whistles that people expect today, and made it operate that fast, he'd have something to show. Instead he presents polished garbage.
Wait - what precisely do users demand from your website today? Usually I'm happy to find a website which loads quickly, is clean, and steers me in the direction of whatever I'm trying to find, personally.
My expertise is not marketing so I don't feel I could adequately answer that question but there are plenty of focus group studies which show what sort of UX works best. It's a safe bet that most of the big corporations who are already focus-grouping everything they publish, such as Disney for example, are also using focus groups to design their websites.
They're using split testing, conversion rate optimisation, and bizdev to design their sites. When something appears on a corporate website, it's there to benefit someone in the corporation, not the users (although it might benefit them as a side effect).
His site is at least full-featured article (you can load, scroll and read it, yay). Most sites I open are article sites, and they are rarely full-featured articles, because load/scroll features aren't easily accessible.
Regardless of where on this globe you put your VPS, someone will be accessing it at 1000 ms latency. It doesn't make sense to optimize the browser page load speed to 10 ms, and forget that it takes 600 ms to fetch the data from Asia.
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?
You can setup jobs to run that fire when CloudWatch alerts fire noting that your bill is going up or that your hit rate for certain objects is going way up. I think there's a way to setup billing such that you can't exceed a certain amount in a month but that's a weird situation to try to hard stop charges without deleting everything in your account.
I guess everyone's needs are different, but for me, hardly anyone reads anything I write. If I have a sudden surge in interest in something I wrote, last thing I want is to cut off access to it. Would rather keep paying the infinitesimal amount per page view to keep people reading it.
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.
I think he is contrasting VPS service to shared hosting services like Go Daddy or one of the many cPanel providers. Unless a VPS is using OpenVZ, the box isn't over provisioned. A cPanel host is usually very over provisioned. 500 customers per server wss not uncommon 10 years ago.
I think the pedantry is unnecessary here. "Shared hosting" colloquially refers to multiple websites sharing a single web server, database, and PHP process. Everything is set up for you by the provider, you simply supply the files. What "shared hosting" does NOT usually refer to are containers, virtual machines, bare-metal, IaaS deployment environments, or anything like that.
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...
It's still pretty fast all over the world, because that total time is all you need. For most sites, that three seconds is just the start, ensued by several more seconds of downloading CSS, JavaScript, images, analytics, widgets, and whatnot.
It is. Linode's Atlanta data center has been getting DDoS'd on and off since Sunday. This site isn't hosted on Linode, but could there perhaps be congestion in Atlanta from that attack causing general slowness?
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?
There is an increase in size to base64 encode, in addition to what I assume is the lost capability to cache images, as well as load them intelligently.
Base64-encoding induces a factor 1.333 size increase of the byte stream, so it's likely not worth it if the site is served on HTTP2. To get exact figures, one would of course have to calculate the size of the additional TCP packet(s) and HTTP headers.
No, it's been around since forever. Just not used terribly often.
> Am I reading it correctly that the images are encoded in base64 and delivered as html? Surely this is a bad idea... no?
It depends. Making a new request to fetch the image always has overhead. Whether that overhead is bigger or smaller than the overhead of base64-encoding the image depends on:
• file size (naturally)
• file compressibility: The difference isn't as pronounced after gzipping everything, especially if the source data is somewhat compressible
• protocol: http2 allows a correctly configured server to push attached data with the original request, so no second request is needed. Even without server push, http2's multiplexing will reduce the overhead drastically compared to plain HTTP1.1 or the worst case, HTTPS1.1 to a different domain. The latter requires a full TLS handshake, and that's what, >30kb data exchanged if you have more than one CA certificate in the chain? That's a lot of image data.
You forgot the most important factor: Whether you're reusing that image on a different page. Embedding images in the HTML is basically saving an HTTP request at the expense of not being able to cache the image separately from the HTML.
This seems like it should work, but have you ever tried it? Or, can you point me to some results of a test to show that it indeed caches the image embedded in the CSS?
The problem is that now it's going to be sent with every request. So it'll make the first page faster for the initial request, but slower in the long run.
Depends. If you consider that in each request a big chunk of time is spent one opening the connection, and that you can even start opening the connection to download the linked picture after you have received the response from the first hit, then maybe it's not a bad idea. It's one round trip worth of time that you shame off the total loading time.
However, if the image is very large, it will make the initial request large as well. I would only use this for images that are small and above the fold.
I think it depends on the image size and use case. For small images where the round trip time of an extra request would make a bigger impact than the file size, inlining them might make sense. Especially on mobile where latency tends to be higher.
I think it depends on how much of an image we're talking about.
If it's small, the overhead from base64'ing it (if the page is gzipped) is lower than the overhead of opening a new HTTP connection just to retrieve that one image.
Other reasons to embed images using base64 are to have pages work standalone, to reduce complexity (no need to keep pages and associated resources in sync) and increase locality (things are defined where they're used).
These probably aren't particularly important for most sites, but it's something I do on my personal site ( chriswarbo.net ) since I care more about ease of maintenance than load times.
The biggest problem with inlining images (imo bigger than the base64 size increase) is that when you change something (like a word in the text of the page) you are forcing your users a full reload of the page (images included). Most of these performance tips assume things won't change.
HTTP/2 with server push will eliminate the inlining hacks, and automatically compress content.
But the other points remain: No Javascript is still the fastest Javascript framework, and while you can do lots of crazy hacks with CSS, maybe you shouldn't.
Don't really think PageSpeed score really accurately reflects page loading speed (maybe initial page loading speed). It seems to not really care about lazy loaded resources as one of my JS heavy webapps I made (around 200KB) actually scores higher than this one https://developers.google.com/speed/pagespeed/insights/?url=.... Funnily enough the screenshot on the test only shows the loading spinner.
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.
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.
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.
was thinking exactly this, keep loaded in mem for the duration of the server's lifetime. Not too familiar with HTTP2 but could you cache the compressed packet and reuse with minor modification to the headers when needed to speed up the communication?
Preformatted payload can be a big win for page speed, especially if your payload cannot vary based on request headers, or has only a few variants.
A special case of preformatted response used to be baked into microsoft IIS. If you connected to an address that could only redirect to another address, IIS wouldn't even wait for the request, it would just send the 302 response and hang up. This, it turns out, was not really compatible with Mozilla at the time, and may have violated some RFCs, but I kind of liked it as a hack.
If I'm doing a single page application, surely I'll have infrastructure in place already to compile, minify and do whatever I need to. So I could just serve the monolithic page and be done with it. Much like desktop applications used to do.
The whole hosting issue seems to open a can of worm, at least if this comment stream is any indication. I think it probably would have been better if they stated something more along the lines of, 'Choose (and likely expect to pay) for some sort of superior hosting solution which will prioritize allocating resources to your site(s)'.
The general point could be made without leaving so much room for everyone to argue over specifics.
The best "Shift+Reload" refresh I've managed to get out of this page from where I'm sitting, in Firefox 48.0.x, according to its Network Console, is around 360 ms. It doesn't beat this HN discussion page by a whole lot, and this has actual content, which is dynamic.
Around the same for me, running fibre in New Zealand. Long delay before content even began loading - as mentioned in other comments, would likely have been a non-issue if a decent CDN was used.
291 comments
[ 3.0 ms ] story [ 268 ms ] thread- A very happy customer.
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...
I personally went the other way. I still use CloudFront as a CDN but made it cache items for short periods of time. Invalidation was too much of a hassle, and it took too long. Admittedly, I should use hashes or something of the sort to keep my items versioned, but laziness always gets in the way.
Correct. Did I insinuate that? I apologize if I did. They are two distinct issues, both of which a CDN prevents.
1. S3 outbound bandwidth is expensive. Use it only as an object store of last resort. Your CDN bandwidth is orders of magnitude cheaper (don't believe me, go compare the pricing).
2. S3 response times can vary wildly at times. Use a CDN to avoid this.
And of course feel free to use a cache key instead of invalidating via an API if ~15 minutes it too long to wait for fresh content to appear at edges.
PS Don't apologize for laziness. When directed appropriately, its a most productive force.
Agreed on all other counts.
GAE doesn't charge for their object store nor their CDN service?
On my home account I've only used it for demo projects that are scarcely used, but it's fine for that.
[1] https://cloud.google.com/appengine/docs/quotas
I don't know how up to date this page is, but here's how it used to work: https://sites.google.com/site/gdevelopercodelabs/app-engine/...
Edit: Nevermind, confused Cloudfront with Cloudflare. Thanks for the correction, toomuchtodo.
EDIT: cm3: I didn't mean to call you out, just wanted my reply in here for historical context. Its very easy to confuse the two.
From what I see, S3 is $.09/GB to the Internet, and Cloudfront is $.085/GB to NA/Europe...and $.14/GB for Asia. How is this cheaper?
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.
Putting bare text on the web is always going to be fast. So what. If he presented a real full-featured website with the bells and whistles that people expect today, and made it operate that fast, he'd have something to show. Instead he presents polished garbage.
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?
I guess everyone's needs are different, but for me, hardly anyone reads anything I write. If I have a sudden surge in interest in something I wrote, last thing I want is to cut off access to it. Would rather keep paying the infinitesimal amount per page view to keep people reading it.
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.
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.
Kernel Same-Page Merging allows you to de-dup common pages across virtual hosts (such as kernel) for example. http://www.linux-kvm.org/page/KSM
Likely? Isn't that the point of a VPS?
Chances of either, slim. Still I try not to assume when I don't have the data.
It's all virtualized and cloudy.
But its also the point of shared hosting, which the site hates on.
A good shared host (ex: HawkHost's semi-dedicated) will run circles around a Lowendbox VPS.
I think the pedantry is unnecessary here. "Shared hosting" colloquially refers to multiple websites sharing a single web server, database, and PHP process. Everything is set up for you by the provider, you simply supply the files. What "shared hosting" does NOT usually refer to are containers, virtual machines, bare-metal, IaaS deployment environments, or anything like that.
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...
stop the presses for the entire company to have a meeting on how to shave off 300 milliseconds for the poor residents of Japan!
Almost instant even here in New Zealand!
You'd think HTTP/2 server push would stand for this, but I can imagine inlining is still a bit faster.
For that image I would prefer to use inline SVG...
No, it's been around since forever. Just not used terribly often.
> Am I reading it correctly that the images are encoded in base64 and delivered as html? Surely this is a bad idea... no?
It depends. Making a new request to fetch the image always has overhead. Whether that overhead is bigger or smaller than the overhead of base64-encoding the image depends on:
• file size (naturally)
• file compressibility: The difference isn't as pronounced after gzipping everything, especially if the source data is somewhat compressible
• protocol: http2 allows a correctly configured server to push attached data with the original request, so no second request is needed. Even without server push, http2's multiplexing will reduce the overhead drastically compared to plain HTTP1.1 or the worst case, HTTPS1.1 to a different domain. The latter requires a full TLS handshake, and that's what, >30kb data exchanged if you have more than one CA certificate in the chain? That's a lot of image data.
ex: "・"
On windows you can do alt+numpad 2022
On whatever is handling input for this XFCE system, control+shift+U 2022+Enter types it.
Characters like →, —, €, £, ©, ™, µ, ①, ②, , °, “ and ”, … and ‽ are easily available, as well as most European-ish letter accents: àáâäąȧåảāãæ.
(I live in Denmark, but rarely type Danish. The compose key is more than adequate for typing København, Østerbro and the Æ in my street's name.)
https://en.wikipedia.org/wiki/Compose_key
However, if the image is very large, it will make the initial request large as well. I would only use this for images that are small and above the fold.
http://davidbcalhoun.com/2011/when-to-base64-encode-images-a...
If it's small, the overhead from base64'ing it (if the page is gzipped) is lower than the overhead of opening a new HTTP connection just to retrieve that one image.
These probably aren't particularly important for most sites, but it's something I do on my personal site ( chriswarbo.net ) since I care more about ease of maintenance than load times.
Not all browsers support SVG, and not all support all properties, but those that do give some pretty good results.
We know life doesn't work that way.
But the other points remain: No Javascript is still the fastest Javascript framework, and while you can do lots of crazy hacks with CSS, maybe you shouldn't.
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.
A special case of preformatted response used to be baked into microsoft IIS. If you connected to an address that could only redirect to another address, IIS wouldn't even wait for the request, it would just send the 302 response and hang up. This, it turns out, was not really compatible with Mozilla at the time, and may have violated some RFCs, but I kind of liked it as a hack.
If I'm doing a single page application, surely I'll have infrastructure in place already to compile, minify and do whatever I need to. So I could just serve the monolithic page and be done with it. Much like desktop applications used to do.
Amen.
Here's an idea: WebAssembly, but use existing Opcodes from the JVM.
The general point could be made without leaving so much room for everyone to argue over specifics.
The fastest and most reliable hosting is, by far, based on my own experience is amazon's e2 cloud and S3 bucket services.
- Brotli instead of Gzip. Likely saves around 10% size.
- Minify everything, including HTML. Could save around 3% size on that page.
It enforces a set of rules to accelerate web pages. These rules can be used to validate your pages.