Examples of fast pages: http://www.3riversstadium.com/index2.html http://www.pmichaud.com/toast/ http://home.mcom.com/home/welcome.html
I am a fast webpage
151–160 of 292 posts
Re: I am a fast webpage
#152The bit about being hosted on SSDs is silly. I could host that site in unused registers of my CPU.
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?
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.
Re: I am a fast webpage
#153I 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…
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.
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...
Re: I am a fast webpage
#154Earlier quoted context omitted.
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.
Re: I am a fast webpage
#155Earlier quoted context omitted.
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 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.
Re: I am a fast webpage
#156> "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…
I tried to create an SVG version to see how an SVGZ would compare, but evidently I'm too crap at Inkscape and kept screwing it up.
Re: I am a fast webpage
#157A good sequel to http://motherfuckingwebsite.com/ , which is probably too understyled for most people.
Re: I am a fast webpage
#158Earlier 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.
You are completely wrong. Inline styles on a static page is not a security issue. If you read that blog post you linked to, you would know this. CSP will do absolutely nothing for a single static html page containing all assets it needs as inline.
Re: I am a fast webpage
#159As 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.
Re: I am a fast webpage
#160Earlier quoted context omitted.
> Hate to break it to you, but your virtual private server (VPS) is likely sharing a bare-metal server with other VPS. ;-) Likely? Isn't that the point of a VPS?
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.
It's all virtualized and cloudy.