Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I am a fast webpage

varvy.com

Post reply on HN
Print view View original

161–170 of 292 posts

Re: I am a fast webpage

#161

Post by ajdlinux »

simbalion wrote: post #155
mikepurvis wrote: post #150

Earlier quoted context omitted.

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 directl…

Economies of scale...

Re: I am a fast webpage

#162

Post by chriswarbo »

quinndupont wrote: post #12

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?

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.

Re: I am a fast webpage

#163

Post by paulddraper »

rocky1138 wrote: post #130
33degrees wrote: post #65

Earlier quoted context omitted.

You can, however, embed images in CSS, which gives you both reduced requests and caching.

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?

If it's inline, then it's cached with whatever it's inlined into.

Re: I am a fast webpage

#164

Post by paulddraper »

matt_wulfeck wrote: post #109

I think it feels fast because it loads at once, but I'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): # Both DNS records are cached before request >>> print requests.get('https://varvy.com/pagespeed/wicked-fast.html').elapsed.microseconds 226515 >>> print requests.get('http://www.google.com').elapsed.micr…

But what's 130ms?

Okay, okay, it "matters". But it's nothing compared with the 3s to load all the JS and CSS and the subsequent sluggishness as 20 analytics scripts are loaded and processed.

Re: I am a fast webpage

#165

Post by ajmurmann »

bigiain wrote: post #153
ajmurmann wrote: post #128

Earlier quoted context omitted.

It's also a security issue and you should set up CSP to prohibit online CSS. See a random Google search result http://dontkry.com/posts/code/disable-inline-styles.html or like I did read "The Tangled Web" 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.

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 sec…

Why not do both and be safe if your sensitization has a bug?

Re: I am a fast webpage

#166

Post by tbirdz »

honkhonkpants wrote: post #21

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

What? No you couldn't. The site html is 11092 bytes, so you'd need to have 1,387 unused 64-bit registers to host the site.

Re: I am a fast webpage

#168

Post by vacri »

simbalion wrote: post #126
jlmorton wrote: post #77

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…

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.

Where does it say that the VPS is used only for that one page?

Re: I am a fast webpage

#169

Post by wingless »

paulddraper wrote: post #160
neoCrimeLabs wrote: post #145

Earlier quoted context omitted.

You can reserve entire machines, even using VPS. Heck, you can even luck out and be the first VPS on a newly provision host. Chances of either, slim. Still I try not to assume when I don't have the data.

Sure you might but be sharing, but the point is that you don't generally have to care. It's all virtualized and cloudy.

VPS performances wildly vary from provider to provider though.

Re: I am a fast webpage

#170

Post by vacri »

usaphp wrote: post #118

> "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…

> Base64 encoded files are larger than the original.

This is one of the reasons to discourage using large attachments on emails (which then stick around forever).

Post reply on HN