Jump to content

Recommended Posts

I ran into a small contest (no deadlines or prizes) on another php site.

The idea is to build a webpage that is no larger than 10k in size. All the info is in that link.

 

Apparently, it is based off an older contest from back in 2000 where people were challenged to pull off a site in under 5k. This one is far more forgiving (a single page under 10k).

 

I was intrigued and figured I would give it a shot. Turns out, 10k isn't much. I had to really crunch stuff down (code and graphics). Here is my entry. While I dropped the ball on creativity, I think I managed to make it somewhat presentable. But in my case, I made the site 8.6k total (but my php code and css is gzipped). So admittedly, once everything is downloaded and unzipped, I bust the budget, but the person running this accepts the size of things coming 'down the download pipes' as acceptable so long as it is under 10k. Things were so tight at one point that I had to drop one of the definition list bullet points to fit within the 10k limit.

 

Would be interesting to see what others can pull off (if you're interested) as a small fun exercise.

Makes people really think about optimizations!

Link to comment
https://forums.phpfreaks.com/topic/151453-anyone-up-for-the-10k-challenge/
Share on other sites

@corbin

 

Thanks dude ;) It was harder (read: more challenging) than I originally thought. I might take another stab at it. If I do, this time I think I'll gun for something more 'creative', thus making it all the more challenging.

 

Make a normal web page and serve the gzipped version?

 

Gzipping is optional of course. If you're suggesting it's just a matter of creating a regular web page and gzipping it, that all depends on what size 'normal' is (which these days tends to be much more than 10k - unless your name is google or something)... In my case, I rapidly ran out of room for additional stuff (since I'm sitting at approx 8.6k, I could have added a tad more, but as I mentioned, adding just one more bullet point description put me over 10k (ended up at 10.1 or something.. maybe it was the size of the bullet markup or something... not sure why). So I have personal doubts that a 'normal' (read: average) page gzipped would cut it (unless there is very, very little in graphics / markup / text / css and whatnot).

 

You could do a few more optimizations:

 

1) Use tabs instead of spaces for indentation. That's a 4:1 ratio. Better yet, strip all the whitespace before outputting.

 

2) Use HTML instead of XHTML. This will allow you to do a few things like dropping a few closing tags, not using self closing tags, not needing quotation marks around certain attribute values, being able to use minimized attributes.

 

3) Don't know if you did this, but lots of times there are a lot of meta data in PNG files which can be stripped off.

 

4) The following:

<dl class="DefList">
<dt class="dtimg"><a class="gui leafBullet"></a></dt>
<dd>More info can be viewed over at the <a href="http://news.nationalgeographic.com/news/2004/12/1206_041206_global_warming.html">National Geographic Website</a>*</dd>
</dl>
<!-- repeats itself, sort of -->

could be reduced to:

<ul>
<li>More info can be viewed over at the <a href="http://news.nationalgeographic.com/news/2004/12/1206_041206_global_warming.html">National Geographic Website</a>*</li>
<!-- repeat in here instead (you could even drop the closing </li> in HTML) -->
</ul>

which will allow you to add rules to to #panel ul and #panel li to add the leaf instead of a standard bullet.

 

 

Granted, some of it is micro-optimization, but on a large scale it would matter, and it could matter in a "smallest possible size" competition.

That's good advice, Dan! Thanks ;)

 

As for 1) Never thought of that. Good one.... It would be interesting to see how much it would shave off however. If I redo the challenge, I just might do that (if the savings really add up, which I guess depends on the doc size / amount of nested / indented code there is).

 

For point 2, I would have to make a comparison of a html doc vs an xhtml doc, with the same markup effect, and see how much of savings this yeilds. I never thought of that however. Nice to know.

 

As for number 3, I shove my images through smushit.com, which does plenty of 'under the hood' optimizations. I'm not sure if smushit removes anything like meta data, but I am going to *assume* its a possibility.

 

I would have to compare the size difference of #4 between both methods. Yet something else I didn't think of. I am so accustomed to using definition lists instead of li.

 

Indeed, (especially for contests like this), the more squeezed out, the marrier. Thanks for the heads up, Dan. I'll definitely look into employing those if I have another go at it in the contest.

 

Learn something new every day lol.

As for 1) Never thought of that. Good one.... It would be interesting to see how much it would shave off however. If I redo the challenge, I just might do that (if the savings really add up, which I guess depends on the doc size / amount of nested / indented code there is).

 

Actually, given the way that compression algorithms work, if you gzip your page then this might not have any effect at the end of the day.

Actually, given the way that compression algorithms work, if you gzip your page then this might not have any effect at the end of the day.

 

Ah, ok. I do gzip stuff like the index.php file (as well as the css stuff), and seems to do quite an admirable job at compressing them. The index.php file unzipped is 4.7K, but zipped, clocks in at 1.5K, so perhaps you're right. Perhaps this stuff is accounted for? (so many unknowns man...)

Well, if you imagine the following string: "          " (the space character repeated 10 times), then when reading it aloud, instead of saying "space, space, space, [...]" you would probably say "10 spaces" or something like that. Compression algorithms work sort of the same way in the sense that it looks for repeating pattern and figures out if there is a way to express that in a shorter way. Though gzip is obviously more sophisticated than my simple "look for consecutive identical characters" algorithm.

 

Stripping whitespace, or replacing multiple spaces with tabs, might still have a small effect, but it's marginalized by also using a compression algorithm of some sort.

Right-O (that spaces examples sounds like image compression.. pure black pixel 35 times in row followed by a pixel with colour value of #123FF2  6 times,  etc..). I'll conduct a small doc test using two identical docs, one using spaces for indentation, the other using tabs. Gzip'em and see who comes in smaller. But you may be right, it might not make a difference.

Well Dan, your initial spacing vs tabs argument is valid :)

 

I did a test, one file (my 10k file submission) using spaces as indentations, while the other (identicle) but using tabs instead. The space one clocks in at 1.7k zipped, while the tab one clocks in at 1.4k zipped. And that's a small file.. the savings are even larger on much larger files to be sure. So indeed, even with gzipping, tab based indentation saves on some memory.

 

One thing I really like about space indentations though is that when I paste my code snippets from my IDE to a forum, it is formatted correctly, where as when using tabs instead, I have to go into the pasted code and manually fix its indentation (a real annoyance).

 

In any case, in the spirit of mythbusters, this myth is confirmed! ;)

One thing I really like about space indentations though is that when I paste my code snippets from my IDE to a forum, it is formatted correctly, where as when using tabs instead, I have to go into the pasted code and manually fix its indentation (a real annoyance).

 

What do you mean? Tabs work fine here...

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.