reply
|

đź’¬ Replied to: a post

“Which leads me to the question: Is there an easy way to determine the total load size of a webpage (including dependencies / includes like stylesheet images and such)?”

an author ( )

I use the browser developer tools’ network tab to help determine the size of a page (usually accessed through the F12 key). Disable the cache before reloading, and most will tell you the combined size of every request which makes up the page, and the amount of data sent over the network. You can also (imperfectly) test the page under different network speed conditions if you want.

For example, Firefox says the post I’m replying to comes in at ~796KB, including all resources (uncached). 299KB of that is your header image, and 38KB is the HTML itself. My entire home page was 1.5MB, until I turned off embedding Tweets and Instagram widgets a moment ago. Now it’s around 492KB (but only text). It just goes to show you how much those external resources can pump the size up!

Page weight and excessive resources is something I’ve tried to stay conscious of when developing my site. Previous iterations have been better at this than what it is now – which is pretty far from “heavy” – but I’m still hoping to trim things back further.

article

|

That cool little “Coder for Raspberry Pi” project from Google which I linked to earlier doesn’t just run on Raspberry Pi. You can run it on any old Linux PC (Mac works too, but the instructions are slightly different).

I set it up in less than 2 minutes using these commands (note that I’m running Debian Sid):

sudo useradd -M pi
sudo apt-get install redis-server
cd ~/projects
git clone https://github.com/googlecreativelab/coder.git
cd coder/coder-base
npm install
npm start

Node.js is also a requirement, so if you don’t have that, you’ll need to install that at step 2 as well.

Once everything is up and running, point your browser at https://localhost:8081/. You’ll need to specify a password the first time you run Coder, after which you’ll be able to try the environment out. It’s pretty neat, and the sample clone of Asteroids is quite addictive!

note

|

The beauty of web development is that, ultimately, the code behind it is simple. Yes, web apps have taken leaps and bounds over the last few years, and are capable of so much more than ever before, but lets face it – we’re not exactly writing DNA sequencers. Yet.

It frustrates me when I find someone has made life difficult for themselves or the person who will inherit their code, by using the wrong tool for the job. I’m not claiming to be a saint here either – I often look back at some of my own code and shudder (it helps keep me right in the future!).

Consider the following snippet, from the View (presentation) file of an MVC app I inherited:

<?php
echo "<h1>$category</h1>";
echo "<h3>$company ($name)</h3>";
echo "<p>";
echo "$address<br />";
echo "$town<br />";
echo "$city<br />";
echo "$post_code<br />";
echo "$phone<br />";
echo "$email<br />";
echo "</p>";
echo "<br />";
echo "<br />";
?>

PHP needs to be used to output the data passed from the Controller, yes, but there’s no need for it to be outputting the HTML too. Let HTML itself worry about that!

<h1><?= $category ?></h1>
<div>
<h3><?= $company ?> (<span><?= $name ?></span>)</h3>
<address>
<span><?= $address ?></span>
<span><?= $town ?></span>
<span><?= $city ?></span>
<span><?= $post_code ?></span>
<span><?= $phone ?> </span>
<span><?= $email ?></span>
</address>
</div>

I don’t know about you, but the HTML-based version above is easier to follow and spot coding errors. No doubt someone will point out there’s more HTML tags/bytes in this example than the first, but that is because I coded it with semantics and microformats in mind; add in the right classes and you suddenly have a hCard.

Possibly more importantly in my mind, the HTML example is easier to follow for someone who isn’t PHP literate, like many front-end designers I know.

I’m picking on this example as it’s the most recent I’ve come across, and the first to come hand. It’s not the first example I’ve come across, it won’t be the last, and it’s certainly not the worst!

Pure, simple HTML can be a wondrous thing. Lets try not to spoil it by abusing it with our fancy server-side languages. K.I.S.S!

note

|

I loves me some jQuery – without it I probably wouldn’t write any JavaScript at all (seriously, I hate the stuff). Anyway, today I needed to add some “open in new window” links to an internal application using jQuery. Being the Standardista I am, I wanted to make it a)Accessible, and b) Unobtrusive . If the user has JavaScript disabled (it happens, even on “controlled”, intranet environments), the link should just go to the new page anyway — new window be damned.

My first attempt (below) didn’t work as expected. The following code takes all <a> tags with a class of “newwindow” and applies an onclick event to open a new window.

$(function(){
$('a.newwindow').click(function(){
var w = window.open($(this).href(), 'newWindow', '');
return false;
});
});

Nothing would happen with the above, because of the return false;. Removing return false; would open a new window, but also send the opening window to the new page. In the end, the following worked the way I wanted:

$(function(){
$('a.newwindow').click(function(){
var w = newWindow($(this).href(), 'newWindow', '');
return false;
});
});
function newWindow(url, wName, opts){
w = window.open(url, wName, opts);
return true;
}

Basically the “heavy lifting” was moved to a seperate function. It’s slightly longer to type, but not exactly finger-breaking stuff. No doubt some bright-spark could tell me an even betterway (feel free!), but this’ll do for now.