Browser performance impact of charset/codepage assignment

Most developers (myself included) are often unaware of the performance impact of the Content-Type / charset of a web page. Ideally you should set this as an HTTP Header vs. using META http-equiv. It’s often though that this only helps with the transport and display of data, however, the browser also makes use of it when parsing CSS & JS assets. Tags related to those provide an optional ‘charset‘ attribute should they ever need to vary from your content.

General guidance is to set this at the very top of the <head> before <title>; and within the first 1024 bytes, though there are reports that Firefox will look at the first 2048 bytes of the page for this META information.

Not doing so may cause the browser to do a codepage restart to re-parse assets that were interpreted in the potentially incorrect codepage.

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

REFERENCES:

Prevent Firefox browser auto update

Often you find a neeed to keep an old copy of Firefox around for testing or to use a specific plugin (Example: Selenium). In these cases it can often prove problematic to allow the browser to auto-update. Here are some simple steps to prevent this behavior.

Enter “about:config” into the Firefox URL bar, then change the following values. You can click on them to toggle.

app.update.auto = false
app.update.enabled = false

Alternately, on Windows you can edit the config file at: %APPDATA%\Mozilla\Firefox\Profiles\.default\prefs.js

REFERENCES:

No JavaScript support

There are still a measurable number of internet users that browse without the use of JavaScript, use the NoScript plugin, or have disabled it for security purposes. In those cases, as well as for SEO. It’s often a good idea to manipulate the display to better accomodate these users. One of the most common methods is shown below, as we can toggle a CSS class on the HTML tag easily and use CSS “cascade” to hide or show alternate content.

NOTE: this example currently requires PrototypeJS, but can easily be changed to not do so.


<!DOCTYPE html>
<html class="no-js">
<head>
<script type="text/javascript">
var ar = document.getElementsByTagName('html');
var i = ar.length;// should only be one!
while(i--){
Element.removeClassName(ar[i],'no-js');
}
</script>
<style type="text/css>
html .no-js-show { display:none; }
html.no-js .no-js-show { display:block; }
html.no-js .no-js-hide { display:none; }
</style>
</head>
<body>
JavaScript is:
<p class="no-js-hide">enabled</p>
<p class="no-js-show">JavaScript is disabled</p>
</body>
</html>

Browser Performance/Capability Benchmark Testing

In the past few years the browser wars have heated up again. Performance and capabilities of some browsers varies greatly. There are several standard tests that are publicly available to benchmark your systems. WebKit (Safari, Chrome & Chromium) and Mozilla (Firefox) based browsers, as well as Opera perform pretty well, MSIE is currently trailing in most cases.

Here are a few common ones…

JavaScript language attribute

Occasionally I’ve stumbled upon legacy javascript code that is used to determine javascript support by the visiting users. This often proves comical, because they are many times wasting time making checks for some “VERY OLD” browsers indeed! Here’s a rundown of the versions of javascript as well as their release dates and some common browser versions that implemented them.

  • JavaScript 1.0 (March 1996) = Navigator 2.0 / MSIE 3.0
  • JavaScript 1.1 (August 1996) = Navigator 3.0
  • JavaScript 1.2 (June 1997) = Navigator 4.0-4.05
  • JavaScript 1.3 (October 1998) = Navigator 4.06-4.7x / MSIE 4.0
  • JavaScript 1.4 = Netscape Server
  • JavaScript 1.5 (November 2000) = Navigator 6.0 / Firefox 1.0 / MSIE 5.5 – 8.0 / Safari 3.0-5 / Chrome 1.0-10.x / Opera 6.0
  • JavaScript 1.6 (November 2005) = Firefox 1.5
  • JavaScript 1.7 (October 2006) = Firefox 2.0
  • JavaScript 1.8 (June 2008) = Firefox 3.0 / Opera 11.50
  • JavaScript 1.8.1 = Firefox 3.5
  • JavaScript 1.8.2 (June 2009) = Firefox 3.6
  • JavaScript 1.8.5 (July 2010) = Firefox 4.0 / MSIE 9.0 / Opera 11.60

The language attribute has long been deprecated and should generally be avoided, it’s original purpose was to support other scripting languages, notably VBScript, or particular JavaScript versions. Modern conventions rely on specifying the MIME type instead via the ‘type’ attribute.

<SCRIPT LANGUAGE="JavaScript"> is now <script type="text/javascript">

<SCRIPT LANGUAGE="JavaScript1.1"> is now <script type="text/javascript1.1">

<SCRIPT LANGUAGE="VBScript"> is now <script type="text/vbscript">

<SCRIPT LANGUAGE="TCL"> is now <script type="text/tcl">

REFERENCES:

JavaScript TextNode for special characters

It can be difficult to create or output some characters as JavaScript TextNodes. Typically you might try to use the ampersand notation, unfortunately the ampersand itself gets escaped to & as such   becomes &nbsp; Use of the Unicode notation can easily resolve this issue.

Example for NBSP:
var nsbptextnode = document.createTextNode('\u00A0');

Sniff for SSL capability of browser

If you run a secure server, you often have some non-secure content prior to authentication of a secure session. To provide a mechanism to show a page prior to authentication, you can “sniff” for the clients capability with a small bit of JavaScript.

First establish a global variable on the page:
<script type="text/javascript">
var sslok = 0;
</script>

Then, include a JavaScript file that is ONLY available via a secure
<script type="text/javascript" src="https://www.giantgeek.com.com/secure/sniff.js"></script>

The ‘sniff.js’ file should contain (at a minimum):
sslok = 1;

Finally, check and act on the value:
<script type="text/javascript">
if (sslok === 1) {
window.location.href = 'https://www.giantgeek.com/secure/';
}
</script>

Done!

JavaScript code quality

I’ve programmed in a lot of different languages, and with various IDE’s. The one area that has always been lacking is a simple means to review JavaScript code for common errors, both syntactical and format. This is where JSLint and JavaScript Lint come in…. these represent the tooling previously available to other languages like C++ and Java, where you can analyze code without actually executing it to identify problem areas. Often, these are items like ‘missing semicolons’ that occasionally cause difficult to find errors in browsers.

These can be scripted to execute from the command line or within (some) IDE’s on several operating systems.