Ian Hickson wrote:
All three of the above basically boil down to the same thing -- there are
hosting providers that don't provide the simplest of features. That's
certainly true, but there are also hosting providers that provide these
features for very cheap (e.g. $120/year or less) that provide all this and
more, so I don't buy this argument. If you're having trouble finding one,
contact me privately and I can give you a coupon code for one.
Thank you but I have my own servers. You make a pretty big assumption
here about the usage model of the Internet being corporate + ISP. You
ignore:
* Web applications and HTML documentation on the local filesystem.
* Local testing in WYSIWYG editors.
* Autorun frontends on CDROM that are typically employed by magazine
coverdiscs.
* Embedded servers in storage devices, media centers, routers and other
gadgets.
* Minimalist HTTP servers for simple usage, websocket tunnels or high
load services.
* Users taking advantage of free hosting services with limited features
(like Sourceforge or Geocities).
* Charities and OSS groups with better things to spend their money on
than hosting package upgrades.
* Companies like many in the building and equipment hire industries that
spent $500 on a website and call it expensive.
Far from being a small minority these groups and applications possibly
make up the majority of HTML content after blogs.
If it's just a static site, then you can just pre-generate the pages and
upload the completed pages, so there's no dependency on the server. This,
incidentally, also works when the server-side hosting provider doesn't
support SSIs at all.
If it's not a static site, then the SSIs are going to be the least of your
problems when you change to a different server.
I assume that by "pre-generated" you're referring to
Dreamweaver/WebObjects templates rather than copy-and-paste. I find
these irritating as quite often you are given one format but require
another (as a FOSS user I can't/won't use Dreamweaver). Some of the best
editors don't have any kind of template support and when they do it's
typically native to the application. Sometimes they're even native to an
installation (you can't export your templates). These things are bad for
the web without some kind of accepted open specification. CSI could be
that specification.
Speed. Concerns about speed are generally only valid for the first page
on the first visit to a site. Subsequent pages can be much faster than
SSI and even static html since common banners and footers can be cached
seperately - requiring only a unique content download. This is less
trivial than it sounds since global drop-down menus, ad frames, tracking
code, overlays and embedded JS and CSS often account for a vast majority
of the source code.
We're talking about such a small amount of data here that the latency far
outweighs the bandwidth cost on most connections. Given that you still
have to do an If-Modified-Since check, you don't really gain anything
here.
I'm not sure where you get your statistics but these claims don't match
my direct experience. In the typical case a web page is heavily
dependant on included content such as CSS files, images, plugins and
other non-embedded elements. Even geek sites like orielly.com and
slashdot are not immune. According to websiteoptimization.com the
orielly home page has 60 external objects. Many common sites are even
worse. Your claim that adding HTML includes will have any noticeable
affect on overall page loading times needs more analysis.
orielly.com:
Total HTML: 5
Total HTML Images: 31
Total CSS Images: 14
Total Images: 45
Total Scripts: 7
Total CSS imports: 1
Total Frames: 0
Total Iframes: 4
report:
http://www.websiteoptimization.com/services/analyze/wso.php?url=http://oreilly.com/
If we did want to optimise for small parts of the content being
common over multiple pages, we should investigate dictionary-based
compression with site-specific dictionaries. That would get us much, much
better performance than cached CSIs.
I like this idea, but it isn't an alternative to CSI from a designers
perspective nor is it likely to have significant gains over current gzip
implementations.
This isn't an argument over SSIs. I agree that for inclusions, the <iframe
seamless> feature isn't optimal. It was not designed for that, it was
meant for including sandboxed blog comments and the like.
I absolutely agree that iframes aren't an alternative to CSI, not
vice-versa.
A TCP round-trip is very expensive. A client-side parsing-level
include would mean that the parser would have to stop while a complete
round-trip is performed. There's really no way to get around that
short of making it a higher-level construct like <iframe seamless>.
There is actually an easy solution for this, though it is less flexible
than my original proposal. The solution is to require each include to be
balanced (equal number of open and close tags) so the surrounding block
is guaranteed to be a single node. Anything left open is forcefully
closed (as when reaching </body> with open blocks). In other words:
<div id="content" style="min-height:500px">
<include src="content.ihtml">
</div><!-- always closes content -->
What do you do when the CSIed page includes script that manipulates
content after the include? Now you have a race condition. This is just as
bad as blocking, if not worse, since it's now unpredictable.
You do the same thing you always have when external JS or inter-page
requests raise the same issue. Defer JS until the DOM is in a sane state
(onload). In my experience trying to access an object below your script
in the source is a terrible idea and nearly always results in null
object references that crash your page scripts.
Anyway in conclusion I don't understand what CSIs give us that is actually
worth the massive amounts of effort they require. Just generate your pages
server-side or upload them to your server pre-generated.
As a developer I tell you this is not really a good option, and I
disagree with your claim of "massive effort". It is a fairly
straightforward feature as they go. Embedded SQL is a massive effort,
WebWorkers is massive effort, client-side includes is quite trivial,
relatively speaking. Certainly worth further investigation in light of
its obvious benefits.
Shannon
