document.write() Intervention!

The use of document.write() has always been a bad “code smell” in JavaScript. Most web performance guides such as WebPageTest and Yahoo Exception Performance have warned against this practice.

In most cases, document.write() can be replaced by inserting innerHTML into an empty element after the rest of the page loads. This approach also allows the developer to “think” about how the page might react in cases where JavaScript is disabled or not available on the client.

Google has recently changed the default behavior, such that when on a slow (currently 2G) connection, but discussions have also leaned toward including any slow connection.
As such, right now, the following will occur on slow (2G) connections:

  • Chrome 53+ (warning displayed in debugger console)
  • Chrome 55+ (blocked – code will not execute, warning message will appear in debugger console)

For users on slow connections, such as 2G, external scripts dynamically injected via document.write() can delay the display of main page content for tens of seconds, or cause pages to either fail to load or take so long that the user just gives up. Based on instrumentation in Chrome, we’ve learned that pages featuring third-party scripts inserted via document.write() are typically twice as slow to load than other pages on 2G.


My advice – remove all use of document.write() for required content in your code now, as your users MAY NOT see that content if you do not.

REFERENCES:

Google Chrome installation for Ubuntu

With a few simple steps, Google Chrome can be installed on Ubuntu.


wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | sudo apt-key add -


sudo sh -c 'echo "deb http://dl.google.com/linux/chrome/deb/ stable main" >> /etc/apt/sources.list.d/google.list'


sudo apt-get update


sudo apt-get install google-chrome-stable

or…


sudo apt-get install google-chrome-beta

Brotli Compression

If you look at HTTP Headers as often as I do, you’ve likely noticed something different in Firefox 44 and Chrome 49. In addition to the usual ‘gzip’, ‘deflate’ and ‘sdhc’ , a new value ‘br’ has started to appear for HTTPS connections.

Request:

Accept-Encoding:br

Response:

Content-Encoding:br

Compared to gzip, Brotli claims to have significantly better (26% smaller) compression density woth comparable decompression speed.

The smaller compressed size allows for better space utilization and faster page loads. We hope that this format will be supported by major browsers in the near future, as the smaller compressed size would give additional benefits to mobile users, such as lower data transfer fees and reduced battery use.

Advantages:

  • Brotli outperforms gzip for typical web assets (e.g. css, html, js) by 17–25 %.
  • Brotli -11 density compared to gzip -9:
  • html (multi-language corpus): 25 % savings
  • js (alexa top 10k): 17 % savings
  • minified js (alexa top 10k): 17 % savings
  • css (alexa top 10k): 20 % savings


NOTE: Brotli is not currently supported Apache HTTPd server (as of 2016feb10), but will likely be added in an upcoming release.

http://mail-archives.apache.org/mod_mbox/httpd-users/201601.mbox/%3C54[email protected]%3E

Until there is native support, you can pre-compress files by following instructions here…
https://lyncd.com/2015/11/brotli-support-apache/

REFERENCES:

opensearchdescription.xml

OpenSearch is a relatively obscure topic that I’ve only crossed a few times, here is the premise.

A simple tag can be added to your content, in this case HTML, but a feed can also contain this element.

<link rel="search" href="http://www.giantgeek.com/opensearchdescription.xml" type="application/opensearchdescription+xml" title="giantgeek.com" />

That link refers to a file that resembles the one below, in it you can specify the URL to the search facilities on a website, or as in the case below, use the parameters for a Google search of your website.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE OpenSearchDescription>
<OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/" xmlns:moz="http://www.mozilla.org/2006/browser/search/">
<ShortName>GiantGeek.com</ShortName>
<Description>Use Google to search our web site.</Description>
<InputEncoding>UTF-8</InputEncoding>
<Tags>giantgeek skotfred</Tags>
<Contact>[email protected]</Contact>
<Image width="16" height="16" type="image/x-icon">http://www.giantgeek.com/favicon.ico</Image>
<!-- NOTE: this uses Google, you can give your own search url instead -->
<Url type="text/html" method="GET" template="http://www.google.com/search?q=site:giantgeek.com {searchTerms}"/>
<Url type="application/opensearchdescription+xml" rel="self" template="http://www.giantgeek.com/opensearchdescription.xml"/>
</OpenSearchDescription>

Many modern browsers that provide a ‘search box’ in the browser interface, can then add the capability to perform a search of your website even when the user is not there already.

REFERENCES and Additional Reading:

Hiding Firebug Lite controls in browser

I started getting extremely tired of the FireBug Lite overlaying content in some of my legacy websites. By taking a look at the markup it was adding, I found a quick and easy way to hide it for most users.

Adding the following to one of your CSS files should do the trick…


/* Begin hide FireBug Lite */
#jsConsole,
#jsConsoleShowSourceButton,
#jsConsoleHideSourceButton,
#jsConsoleShowConsoleButton,
#jsConsoleHideConsoleButton { display:none; }
/* End hide FireBug Lite */

NOTE: I have not yet confirmed, but this approach should work in other browsers such as MSIE, Chromium and Safari that also may use FireBug Lite.

HTML5 speech input

Adding speech input to your webapp is much easier than it might first seem.
This is part of the proposed HTML5 enhancements to FORMS and is already implmented in some browsers.

Google Chrome (WebKit 534.24) added this in version 11 in April 2011.

XHTML compatible example:
<input type="text" x-webkit-speech="x-webkit-speech" speech="speech" value="" />

NOTE:
In this example, ‘x-webkit-speech’ is the proprietary attribute used by Google Chrome (WebKit). ‘speech’ is the expected HTML5 attribute when it is finalized.

REFERENCES:

Google ChromeFrame

There was some debate back when this was first revealed in 2009, but the use of ChromeFrame is still relevant for some organizations that are stuck on older browsers for legacy applications.


<meta http-equiv="X-UA-Compatible" content="chrome=1" /><!-- this is for all versions of IE -->
<meta http-equiv="X-UA-Compatible" content="chrome=IE6" /><!-- this is for IE6 and lower -->
<meta http-equiv="X-UA-Compatible" content="chrome=IE7" /><!-- this is for IE7 and lower -->
<meta http-equiv="X-UA-Compatible" content="chrome=IE8" /><!-- this is for IE8 and lower -->
<meta http-equiv="X-UA-Compatible" content="chrome=IE9" /><!-- this is for IE9 and lower -->
<meta http-equiv="X-UA-Compatible" content="IE=Edge,chrome=IE6" /><!-- this is for IE9 and lower, passes Edge to others -->

NOTES:

  1. Installation can be done without Administrative rights on the Windows OS.
  2. Installation will append the ‘chromeframe’ version to the ‘User-Agent’ HTTP header sent by the browser to allow it to be parsed.

REFERENCES:

Killing hung, frozen or zombie programs

As a web developer, I’m often doing new (and interesting) things to stretch the boundaries of the browser. Sometimes, in doing so, the browser can hang or freeze, remaining in a state that makes it unresponsive.

Here are a few simple methods to force-close the browser on Windows and Linux, they can be expanded for other software executables as needed.

Windows:
taskkill /f /im iexplore.exe
taskkill /f /im firefox.exe
taskkill /f /im chrome.exe
taskkill /f /im safari.exe

Linux/Unix:
for i in `ps -A | grep firefox | awk '{print $1}'`; do kill -9 $i; done

Defining word-break and word-wrap in CSS

I recently found a case where WebKit (Chromium, and Safari) was acting as if ‘overflow-x:visible;‘ was set in cases where text could not be wrapped inside a DIV due to a lack of spaces or hyphenation as it was a java stack trace. In this case I had to explicitly set the ‘word-wrap:break-word;‘ attribute for the problematic DIV.


.breakword { word-wrap: break-word; }

Also, for Unicode languages where there are other rules to complex to describe here…

.wordbreak { word-break: keep-all; }

Prevent resizing of HTML textarea in browser

Newer versions of Webkit based browsers (Safari & Chrome) as well as Firefox now allow users to resize HTML <textarea> elements by default. This can have unpredictable results on your user interfaces. Thankfully, you need only add a simple CSS attribute to prevent this newly default behavior.

textarea {resize:none;}

REFERENCES: