|
|
 |
|
| |
Using
FULL CSS
makes surfing FASTER
- MYTH.
FALSE. UNPROVEN. (and if not a myth, how much
faster?) Has this statement above actually
been proven true on a variety of websites?
Has there
actually
been
a true performance test done? As far as one
can tell,
users cannot see, or notice, a bit of difference
between a full CSS website and nested tables
website. What about the size of that initial
.css file? That's going to be bigger; and
then if you have one main .css file, who says
they are going to visit enough pages on
your website anyway to really enjoy the benefits
of having that extra large .css file download
initially. Don't you want that first page to
be fast?
...50%
of bandwidth is Images anyway. Then there
is 25% for the original
authored content, 5% for the JavaScript,
5% for the CSS page, and 5% for all the
other
HTML like
anchor tags, body, head, etc..... In
the end, there is not much left to reduce
in
the first place...
There are many mis-informed people that think
that CSS-P reduces the web page's size dramatically
for a large table using
CSS. The clue here is "large
table".
.Let's see 100 to 500 or more rows.
POINT:
" Using
CSS-P would make a 500 row table display
faster."
COUNTER POINT:
"Have
you ever actually written the CSS-P for
a 500 row table?
It's incredibly large to say the least.
Next,
the user
would
have
to
download
the CSS-P stylesheet for a 500 row table
and that the CSS-P stylesheet could easily
be larger in size than the data in 500
row
table
in the first place. You could easily be
asking the user to essentially download
your CSS-P
500 row table web page twice!!"
DOSE
of REALITY:
What
good is it to say that CSS-P is faster
than tables when you can't even make or
maintain a CSS-P table in the first place? That's even worse than saying, "The fastest way down this mountain is to
jump off the edge of that cliff over there." CSS-P,
realistically, CANNOT and SHOULD NOT be
used to make a 10, 20, 100, or 500 row
table in the first place as you couldn't
even maintain it, or for that matter, even
build a 500 row table in CSS-P anyway.
So
CSS-P loses on the very point it trumpets
to the world: 'its so-called advantage
of speed over tables'. Second, CSS-P loses
again
on another point (that's just
as important), maintainability."
CSS-P elitists say that tables are good
for tabular data, but then immediately
say that CSS-P displays large tables faster
while forgetting that it's a nightmare to write
a 100 row table with CSS-P. The people who
do a lot of the CSS-P "talking" rarely
ever do a lot of "doing" . Talking and Doing are
2 different things.
Additionally, how many people
sit and read 100 rows of search
results
even on Google or Yahoo? As
you can see, these numbers and reasoning are
quite twisted.
Even if it did display faster, will users be
able to notice? Do users actually see
a bit of difference in ESPN
or Wired when compared to <table> website
versus so-called ground breaking pioneer
websites for the fanatical pro-CSS crowd? Just
as important, Display faster doesn't always mean Download faster.
CSS Elitists
are quick to point out, "The
css page is only loaded with the first page,
after that, it's faster."
Ok, three points to make below:
POINT
ONE: CSS-P immediately lose on the first page,
of which is the most important page to a visitor's
first
impression, especially for advertising campaigns
as well as 15 minutes
of
fame via the "bring
down the server" Slash Dot link. Ok, it's
not as bad a loading a FLASH intro movie like
you see on some sites, but we are comparing this
to tables with css as opposed to just using
CSS-P and no tables.
POINT
TWO: CSS-P on the following pages where
the CSS style sheet has already been loaded is
virtually
the same and unnoticeable to the user when compared
to other non-CSS-P sites that use table and css.
Oh, but CSS-P will talk about total bandwidth
saving per month. Ok, click here to
see a break down and R.O.I. of their so-called
total bandwidth
savings.
POINT
THREE: Subsequent Pages after the first page only SEEM
faster only because visitors had to wait longer
for the initial page with it's larger css-p
stylesheet to load in the first place as compared
to the subsequent
pages.
POINT
FOUR: One forgets that many times,
a lot of bandwidth is in the graphics and images,
not
the HTML code. Thus, it's images (.gifs
and .jpg) that can take up 50% or more of the
bandwidth
anyway.
Then there is the
content itself, 25% at least! As why would people
visit that page anyway if there was no original content.
And then out of the 25% left there is the HTML,
of which some of it is the anchor tags,
style tags, head and body tags. (Anchor tags
can take up a lot on clickable lists like search
results.) And then there is the JavaScript (~5-10%)
and then the CSS style sheet (~5-10%). As you
can see, table tags don't make up a large percentage
of the total bandwidth. Depending upon
the type of page, 5-15% is only left for table
tags in the first place.
So, what's the savings? Half the bandwidth
on 5-10% of the total bandwidth is 2.5 - 5%
savings...MAX!!! Wow, lots of savings there!!!
That's, TWO-POINT-FIVE to FIVE percent, not
50%...that's not a misprint.
CSS-P
= "Workaround and Hack City" =
Pain in the neck
- CSS-P "workarounds" for cross-browser
support will also cause a full CSS page to
load SLOWER because you have all this extra
browser-detection-JavaScript to write as well.
Then they don't mention
about all the "extra" CSS stylesheets
to write because a single stylesheet won't
work for multiple browsers. So you might end
up having DOUBLE or TRIPLE the number of stylesheets
to write and also maintain. Oh, but wait, I
though we were talking about pages that load
faster of which is becoming more of a myth.
But wait, one more thing, you should forget
about Netscape 4.x browsers of which people
STILL use. And what about accessibility? Ha!
How about getting it to look decent on the
Apple Macintosh first? Double Ha ha!
Fix one thing with a
CSS-P website for this browser and another
thing breaks on a different browser.
So let's see. You have more JavaScript
to write and now you double or triple the number
of CSS pages you have to support. Great! That
will increase performance. That is, for the
person who has to maintain a full CSS site
will have to INCREASE their PERFORMANCE to
keep it up and running.
2019 UPDATE - CSS-P
- CSS pages have dramatically increased in size over the past 10 years. Hence, to say that CSS pages load faster is completely untrue. How can you say CSS loads faster or displays faster when the CSS page is larger in size than the HTML file? Next, how will the browser know how to draw the page when it doesn't yet has the full CSS pages? Also, what good it it to start drawing the page when later CSS data changes the initially loaded CSS, or when other info from HTML or images override and rearrange the page based upon browser size and device orientation?
Most web have been designed for single column anyway, that is, Twitter and its philosophy of "Mobile First" and its Boot Strap kit.
Hence, many web sites all have the same UI and look and feel.
Aside, notice how many CSS-P pages do not use or display column lines
for the layout. This is even more true for any tabular data displays like shopping cart lists or order history.
|
| |
|
|
|
