I am a fast webpage

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.<p>Is it desirable to inline your CSS, &quot;like a boss?&quot; 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.<p>Same with images. If I&#x27;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.<p>Not only is this not particularly useful advice, it&#x27;s bad advice.

Just to point out, there&#x27;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.

&gt; &quot;I am not on a shared host, I am hosted on a VPS&quot;<p>Hate to break it to you, but your virtual private server (VPS) is likely sharing a bare-metal server with other VPS. ;-)<p>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&#x27;s have nodes located around the world.

Not that wickedly fast unless you&#x27;re really near Dallas where the server is:<p><a href="https:&#x2F;&#x2F;performance.sucuri.net&#x2F;domain&#x2F;varvy.com" rel="nofollow">https:&#x2F;&#x2F;performance.sucuri.net&#x2F;domain&#x2F;varvy.com</a><p>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 &quot;inferiority porn.&quot; Titles like &quot;the secretly terrible developer&quot; or the closing statement of this particular article: &quot;Go away from me, I am too far beyond your ability to comprehend.&quot;<p>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.

I make my personal pages fast this way since last century. Probably a huge amount of people did the same. It&#x27;s pretty obvious.<p>When you need fancy graphics (a static photo album), things become less easy: you e.g. may want to preload prev &#x2F; next images in your album to make navigation feel fast.<p>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.<p>When things become ugly is when you want to extract some money from page&#x27;s popularity. You need to add trackers for statistics, ad networks&#x27; 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.<p>(Corollary from the above: subscription is more battery-friendly than an ad-infested freebie.)

A good sequel to <a href="http:&#x2F;&#x2F;motherfuckingwebsite.com&#x2F;" rel="nofollow">http:&#x2F;&#x2F;motherfuckingwebsite.com&#x2F;</a> , which is probably too understyled for most people.

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.

looks like this whole thing is a scheme to promote his webhsting affiliate link: <a href="http:&#x2F;&#x2F;www.knownhost.com&#x2F;affiliate&#x2F;idevaffiliate.php?id=1136_0_3_1" rel="nofollow">http:&#x2F;&#x2F;www.knownhost.com&#x2F;affiliate&#x2F;idevaffiliate.php?id=1136...</a><p>The fastest and most reliable hosting is, by far, based on my own experience is amazon&#x27;s e2 cloud and S3 bucket services.

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?

Ehh, I just got 10.91s load time in Chrome 53 from Colorado, USA.<p>Image of Chrome Dev Tools: <a href="https:&#x2F;&#x2F;reportcards.scdn3.secure.raxcdn.com&#x2F;assets&#x2F;uploads&#x2F;files&#x2F;company&#x2F;452e0fdee5904b10046de11c0f7bfccb.png" rel="nofollow">https:&#x2F;&#x2F;reportcards.scdn3.secure.raxcdn.com&#x2F;assets&#x2F;uploads&#x2F;f...</a><p>As an aside, does HTTP&#x2F;2 provide any benefit for a single HTML file with no external assets?

<i>&gt; my hard drives are SSD</i><p>Of course that&#x27;s entirely irrelevant as the page completely fits into the ram of the server (or even the CPUs cache for that matter)

Cool... Unfortunately in practice it&#x27;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.

&gt; &quot;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.&quot;<p>This does not work in most cases when you use big images. From StackOverflow answer [1]: &quot;It&#x27;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&#x27;s only an advantage for large numbers of very tiny individual images. &quot;<p>[1] - <a href="http:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;11736159&#x2F;advantages-and-disadvantages-base64-image-encode" rel="nofollow">http:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;11736159&#x2F;advantages-and-d...</a>

Dlang forum (with dynamic content) is insanely fast! <a href="https:&#x2F;&#x2F;forum.dlang.org&#x2F;group&#x2F;general" rel="nofollow">https:&#x2F;&#x2F;forum.dlang.org&#x2F;group&#x2F;general</a>

A VPS is shared hosting to me, it&#x27;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. ;)<p>If they truly wanted speed through control of resources they would have used bare metal.<p>But yeah, the website is easy to optimize when it&#x27;s simple, the hard part, often outside of your control, is DNS and actual connection handling. Many have already mentioned CDN so there&#x27;s that.<p>But you also don&#x27;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.

Pretty good at 97&#x2F;100 on Google&#x27;s PageSpeed Insights - <a href="https:&#x2F;&#x2F;developers.google.com&#x2F;speed&#x2F;pagespeed&#x2F;insights&#x2F;?url=https%3A%2F%2Fvarvy.com%2Fpagespeed%2Fwicked-fast.html&amp;tab=desktop" rel="nofollow">https:&#x2F;&#x2F;developers.google.com&#x2F;speed&#x2F;pagespeed&#x2F;insights&#x2F;?url=...</a>

Interesting exercise, in an age where web pages are now bigger than most business applications I used to use in the early days of DOS&#x2F;Windows.<p>Note: Just checked, and even a simple Medium blog post page won&#x27;t fit on one those old 3.5&quot; floppy disks..<p>EDIT: To stay on topic - the OP&#x27;s page loaded instantly for me here in outback Australia...

&quot;Look amazing on any device&quot; ... The right edge of your text is coiled on my phone (not so amazing).

Ok I&#x27;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&#x27;s a real problem.I deliver web apps, and interactivity is a must.<p>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&#x27;s address that problem first!

&quot;Faster than 100% of tested sites&quot;<p><a href="https:&#x2F;&#x2F;tools.pingdom.com&#x2F;#!&#x2F;ehdlhb&#x2F;https:&#x2F;&#x2F;varvy.com&#x2F;pagespeed&#x2F;wicked-fast.html" rel="nofollow">https:&#x2F;&#x2F;tools.pingdom.com&#x2F;#!&#x2F;ehdlhb&#x2F;https:&#x2F;&#x2F;varvy.com&#x2F;pagesp...</a>

For speed optimization it&#x27;s really important to always fine-tune for you particular use case and apply some common sense. For instance, inlining everything as suggested here is faster only if you expect visitors to open just that one page and bounce away, so browser caching is not helpful. Consequently, it&#x27;s a very good tip for e.g. landing pages, but it makes no sense at all to serve pages that way to your logged-in users.

Few more possible optimizations:<p>- Brotli instead of Gzip. Likely saves around 10% size.<p>- Minify everything, including HTML. Could save around 3% size on that page.

Submit to 10k Apart: <a href="https:&#x2F;&#x2F;a-k-apart.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;a-k-apart.com&#x2F;</a>

How much does HTTP&#x2F;2 mitigate the need for such techniques, if at all?

Inline all your CSS and you are forcing all your users a full reload whenever you need to change&#x2F;add something.<p>This can be tricky if your page grows in complexity&#x2F;size and you need to change something.<p>Please, when is more appropriate don&#x27;t inline your CSS and prefer to take advantage of cache.

I think it <i>feels</i> fast because it loads at once, but I&#x27;m actually not getting very impressive results programmatically if you measure how long the entire TCP transaction takes (which is what I consider page loading):<p><pre><code> # Both DNS records are cached before request &gt;&gt;&gt; print requests.get(&#x27;https:&#x2F;&#x2F;varvy.com&#x2F;pagespeed&#x2F;wicked-fast.html&#x27;).elapsed.microseconds 226515 &gt;&gt;&gt; print requests.get(&#x27;http:&#x2F;&#x2F;www.google.com&#x27;).elapsed.microseconds 92027 </code></pre> Even google.com (92 ms) is about 250% faster than OP (226 ms) to establish connection, read all of the data, and close.

Honestly? I am surprised to see this page with such high vote on the first page. If you really wanted a fast &quot;static&quot; page, you would put it on a CDN. All you wanted to do is put a marketing link in your last paragraph.

Your page can be very fast and uses minimal resources and is hosted in a good place. But you always gotta watch out for proximity to user, time to first byte and dns resolution time. Perceived speed is highly affected by those.<p>It took 2 seconds to load the page on a fresh ec2 box:<p><pre><code> time_namelookup: 0.061 time_connect: 0.100 time_appconnect: 0.223 time_pretransfer: 0.223 time_redirect: 0.000 time_starttransfer: 1.935 ---------- time_total: 2.066</code></pre>

Yes you are. You&#x27;re so fast I don&#x27;t even see you refresh.

Probably wouldn&#x27;t make much of a difference, but there is still room for performance improvement by minifying the HTML page.

&quot;No Javascript&quot;<p>Amen.

You can do much better! What&#x27;s about html-muncher for css class minification?<p>Those png are not fully optimized and an SVG would probably even be smaller too and even if it isn&#x27;t in the case of the orange one it would have could be compressed much better.<p>Making use of data: urls might look good on first visit but honestly with HTTP&#x2F;2 just push in the resources and externalize them.<p>Because seriously cache for 300 seconds? How about offline support anyways? It&#x27;s 2016.<p>Furthermore where&#x27;s my beloved Brotli support?<p>By the what&#x27;s about WebP support? Ok TBH if the PNG would be properly optimized WebP would actually not beat the file size but hey: &quot;It isn&#x27;t&quot;<p>So even though it&#x27;s only this tiny static page there&#x27;s still so much wrong with it. Please improve! By the way what&#x27;s about QUIC?

Easy to make a website fast when it has nothing on it. In the real world a site isn&#x27;t this light. It has images, analytic scripts, stylesheets, fonts, Javascript (jQuery at the least). Using a combination of a CDN and realistic caching, I can make a fast website as well.

Simple text, few links to &#x27;tipps&#x27;, a little bit of base64 images without any deeper knowledge. For example there was a website which showed the impact of base64 images just a few weeks ago (when i remember correctly)<p>But it has a referral link.<p>Thats probably the point of this page.

This is odd. Clearly anyone can make a lighting fast page by making a single page since then you can have css inlined versus needing to link to css style sheets with multiple pages, and of course not having javascript would make it faster, but thats a requirement for most all typical sites these days, and loading images that way is nice for hackers but not for real people using cms&#x27;s by common people and clients. Also paying $25-35 for hosting is not very bright since you can get a $5 digital ocean server ssd, not shared, that would load this particular page just as fast if not faster.

His affiliate link for VPS service has its cheapest option priced at $25 a month. You can get a nice little VPS for static hosting on SSD from digital ocean for $5 a month. $6 a month with backup.

I can&#x27;t wait for half of this advice to become obsolete with HTTP2

What an arrogance, the page is done with me? I done with the page yet. I can get the same page much faster by putting the png in an inline svg, strip the source of unnecessary whitespace and returns, serve brotli (or sdhc compressed pages) with firefox, chrome and opera dynamically... or even just do the decompression inline with javascript. Might save another 20% <a href="https:&#x2F;&#x2F;github.com&#x2F;cscott&#x2F;compressjs" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;cscott&#x2F;compressjs</a>

I can see in the source code that you&#x27;re expressing all dimensions in terms of ems and %s. A technology such as Bootstrap will always be the way to go; however, could you tell us a little bit more about how you did this? How did you ensure that it looks good not only on your screen but on any screen?<p>I know people are saying it has some errors on certain mobile devices, but that&#x27;s still some pretty good job manipulating CSS properties.

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, &#x27;Choose (and likely expect to pay) for some sort of superior hosting solution which will prioritize allocating resources to your site(s)&#x27;.<p>The general point could be made without leaving so much room for everyone to argue over specifics.

Examples of fast pages: <a href="http:&#x2F;&#x2F;www.3riversstadium.com&#x2F;index2.html" rel="nofollow">http:&#x2F;&#x2F;www.3riversstadium.com&#x2F;index2.html</a><p><a href="http:&#x2F;&#x2F;www.pmichaud.com&#x2F;toast&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.pmichaud.com&#x2F;toast&#x2F;</a><p><a href="http:&#x2F;&#x2F;home.mcom.com&#x2F;home&#x2F;welcome.html" rel="nofollow">http:&#x2F;&#x2F;home.mcom.com&#x2F;home&#x2F;welcome.html</a>

How dare HN spread this kind of speed-shaming hate slander! ;)<p>We need to see the bloaty-positive alternative, not all websites have to be Google models.

A lot of this stuff is outdated now: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=12448539" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=12448539</a><p>For instance, delivery one giant JS&#x2F;CSS file is now bad because it is harder to cache, since HTTP&#x2F;2 removes the overhead of multiple requests there is no downside for many files.

This took almost 10 seconds to load for me...

The best &quot;Shift+Reload&quot; refresh I&#x27;ve managed to get out of this page from where I&#x27;m sitting, in Firefox 48.0.x, according to its Network Console, is around 360 ms. It doesn&#x27;t beat this HN discussion page by a whole lot, and this has actual content, which is dynamic.

Interestingly, Google has been going after this with AMP (accelerated mobile pages): <a href="https:&#x2F;&#x2F;www.ampproject.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.ampproject.org&#x2F;</a><p>It enforces a set of rules to accelerate web pages. These rules can be used to validate your pages.

Well, many of these points make sense.<p>If I&#x27;m doing a single page application, surely I&#x27;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.

A couple of problems rendering on iPhone 6s<p><a href="http:&#x2F;&#x2F;i.imgur.com&#x2F;EpoC9lG.jpg" rel="nofollow">http:&#x2F;&#x2F;i.imgur.com&#x2F;EpoC9lG.jpg</a><p><a href="http:&#x2F;&#x2F;i.imgur.com&#x2F;qHS5v2H.jpg" rel="nofollow">http:&#x2F;&#x2F;i.imgur.com&#x2F;qHS5v2H.jpg</a>

If it&#x27;s really all static, you can bundle it into a static Mirage unikernel image with <a href="https:&#x2F;&#x2F;github.com&#x2F;mirage&#x2F;mirage-seal" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;mirage&#x2F;mirage-seal</a>

I&#x27;ve always wanted to play with putting &#x2F;var&#x2F;www into a ramdisk for PHP&#x2F;html stuff. Would be much faster loading since it&#x27;s all just text in the end of the day. Completely cut out the bottleneck of SSd&#x2F;HDD

2.43s TTFB for me - nice and fast once that happened, but that TTFB is a killer.

Maybe a lot of people are hitting it, but this webpage loaded slowly for me.

I&#x27;m curious - would this page see any speed improvement with HTTP2? I ask because the new protocol seems optimized for the exact opposite of this - many asynchronous fetches.

I was a fast webpage.

Loaded in about 15-20 seconds for me. Even if you think medium.com is slow, they can handle the sudden extra load that your site couldn&#x27;t.

By the site&#x27;s own admission, this page&#x27;s visible content not prioritized. I would have knelt before it if not for that flaw!!

It took me several seconds to load (compared to about 1-1.5 for HN)... this page needs better hosting for Asian users.

Ego aside, this kind of site (and associated commentary on the suggested tactics) i feel is helpful.

All being on the html, and doing less external css improve speed? How much? Is it worthwhile?

This simple webpage was barely faster than hacker news&#x27; list view...

Well, not including any javascript was one massive shortcut :)

In an ad-free Internet, many more pages would be this fast.<p>Alas.

Took about 15 seconds to load for me...

Really cool!<p>Almost instant even here in New Zealand!

what is that `.unit{display:inline-block;<i>display:inline;</i>zoom:1` (the stars..)

now we need a framework that targets that standard. as very fast dumb client.

Some pages have big egos.

Its back to 1985

The bit about being hosted on SSDs is silly. I could host that site in unused registers of my CPU.

&gt; I make no external calls, everything needed to load this page is contained in the HTML.<p>Wont that make your webpage load slower?

Inline CSS <i>shudder</i>