I made this list for CNN but it might be useful for any website owner.
I am always on the lookout for junk-serving domain names that I can add to my OS hosts file and CNN provided a number of them. Browsing through their source code, I found a message asking for ideas to improve site speeds. The CNN Labs team has already implemented several speed improvement techniques such as CDN, DNS prefetching, aysnc loads, and code minifying, and were interested in anything developers curious enough to look into their code could provide. Here are a few that I came up with:
- Load HTML first. Everything else should be loaded afterwards. When CSS and JS are loaded along with HTML, they will block the display of the page content for at least one or two seconds. To do it properly, pre-press static HTML pages from your CMS and serve those static HTML pages to your visitors. Don’t put your HTML content in a database and serve them using a server-side script every time some one requests an article. Static HTML pages are served without any server-side processing latency. Like an image file, static pages are copied to the browser without any processing. They will not be parsed and interpreted like a PHP or ASPX script. (Pre-compiled scripts may be faster but not as fast as a simple file copy to an output response stream.) Use server-side scripts for what they were originally meant for – really dynamic stuff such as Ajax requests, database searches and changes, handling live data and processing user input.
- Don’t use custom fonts that get automatically downloaded from your website or even the Google fonts repository. (CNN uses its own “CNN” font.) Use a universal stylesheet instead. Browsers can render web pages faster if they can use fonts already installed on the device. Does that make your webpages appear differently on different devices? Sweet mother of God! How will you survive? Really? No, sir, we don’t think much about your corporate/branding font. It barely registers on our minds. You are serving English text to an English audience. You don’t need a custom font. Custom fonts are meant for languages that don’t have universal device support or if the text is in a non-Unicode non-standard encoding tied to some legacy font. The need to display bar codes on a shopping site is a good use-case for a custom font. Emojis are not. Your EOT font download is likely to get stuck with all the other junk your page is downloading simultaneously. The visitor sees blanks everywhere in place of text, wondering what has gone wrong. Is that good for your corporate image? Don’t shock the user. Please learn about the Principle of Least Surprise (PLS).
- Don’t think people with enough bandwidth will have no problem. Whether you are on a PC or a mobile device (good Linux computers exempted), there are hundreds of processes that are forever talking to base and downloading/uploading files and data. Your webpage is competing with that and other tabs already opened in the browser. (Google’s policy states that Android will be talking to base, even if no app is running, even if it is in sleep mode, even if you have turned off wireless… So, imagine the situation when the device is being actively used.)
- When you use ad networks, it is inevitable that you lose some control. However, you:
- can load their script asynchronously (as CNN has already done).
- do not use more than one ad network in one page serving. You can rotate different providers on different browser requests. If you hit so many third-party sites for one request, as CNN does, what efficiency will you achieve?
- Don’t use autoplay videos, even if you are a TV news channel. Are you misrepresenting video plays to advertisers? What? Top tech companies do it as well? Well, it is not a matter of just ethics but money too. Be assured that autoplay videos are a waste of bandwidth when the visitor just wants to read your article or is already listening to music. Even with the inflated statistics, you will still lose money… over time.
- Why use a third-party service to serve related articles from your own site? Ensure that your articles are tagged and categorized appropriately and serve their links on the sidebar, ordered by date and/or popularity. Ensure that this “related” stuff is not part of the static HTML churned out by your CMS. Lazy-load related content as well.
- Limit the number of redirects in the links you post online. CNN links on Twitter pass through a maze of domains before settling down. These hops are time-consuming because they are on a https connection. Here is a list of redirects for one of their links (https://cnn.it/2DtZSme).
- t.co (Twitter) to cnn.it
- cnn.it to bit.ly
- bit.ly to trib.al
- trib.al to www․cnn.com
- www․cnn.com to edition.cnn.com
- Is your website accessibility-friendly? When you create an accessible website, you create a fast website by default. If you see more CSS+JS than HTML in a ‘View Source’, then your site is not accessible. It is not search engine-friendly either.
- Don’t use pages that automatically reload. Are you a moron? (Not you, sir/madam, but I can list a dozen websites, a prominent news aggregation site among them, that do this without shame and this question is rhetorically addressed to them.) Use Ajax unobtrusively to change only the updated content.
- Understand the principle behind Ajax. You display a page first and then use Ajax to inject data into it without reloading. Gmail does this in reverse. It will make you wait while it loads several megabytes of XML data, containing all your emails, before it displays your inbox – totally defeating the idea behind XML requests. Load what is not needed, not everything from the beginning of time.
- Analytics code increases bloat , reduce the responsiveness of the site and increases bandwidth usage. Do you really need them? There are many free server software that can process server log files and generate insightful visitor stats. Check your CMS or ask your hosting provider. If you need to study click-intensive regions for improving site effectiveness, use them on a temporary basis and get rid of it once you have generated enough data.
- Over time, your pages will become overweight and be lethargic. Either give your site a redesign or start afresh. If not, do regular weight trimming. Measure the dry and wet weight of a web page. Is it really worth it? Regular code reviews help identify parts that are no longer required and provide ideas to optimize CSS and JS.
Available on CodeProject.com
With the last release of Subhash Browser, I promised to provide the source code for the Book View feature. Here it is:
In the stands.
In the stands – get the July 2016 edition
When I wrote my first AndroidWithoutStupid article on CodeProject, this “Richard MacCutchan” had posted a negative comment.
When I published the recent “User Scripts (JS) and User Styles (CSS)” article, the same “Richard MacCutchan” came back, this time as a moderator. He marshalled a few others (Jochen Arndt, OriginalGriff, ProgramFOX, Sascha Lefèvre), probably trolls like him, to not only ban the article and also close my account.
A negative comment is no big deal. But, when the same person deletes that article by closing its account, well… this guy is a stalker. By the time my account and articles were removed, this “MacCutchan” dude had deleted his comment, as he was then posing as a moderator. Fortunately, CodeProject e-mails all comments and this is how I can display the screenshot of the deleted comment.
The first email asked me to provide a reference to the original article. When I did that, I got a mail informing me that my account has been closed. An astounding reason was given – one that I had trolled “10 times!”
I e-mailed CodeProject that I had followed instructions in the email and yet my account was closed. They said that some guy on HubPages, that outpost of web scrapers, had the original article. Apparently, some douchebag copied the article from OSFY website and “Richard & Co.” reasoned that that was the original article. Later, CodeProject mailed that the article and my account was restored but a more prominent reference was needed as per their plagiarism rules. I added a prominent reference right below the title and updated the article. CodeProject allows reposting an article, provided that I held the rights to the article (http://www.codeproject.com/Articles/64119/Code-Project-Article-FAQ#repost). I do as I am the original author and I used the version before OSFY made their edits.
Again, the same troll got his gang to delete the article and close my account, despite my new note. I wrote another email to CodeProject telling them that the other articles of the hubpages guy were also copied from other sources from the web and there was no reason to deign him as an original. Eventually, the article and the account was restored. CodeProject also posted a comment asking moderators not to “report the article”. The article eventually made it to the CodeProject email newsletter on 5th May.
Google does not just read your email; it also spies on you.
Update: Apparently, the troll snaked his way to this blog post and responded with a post on CodeProject Forums titled “Who is the troll?” Yes, one should question oneself this way. I am not sure how much of a Google troll he is but he is a persistent little feller. Anyway, my policy is “Don’t feed the trolls”.
And “Cool FFMPEG tricks” – two articles in this month’s Open Source For You (OSFY) magazine.
One of five Vastu-compliant house plans – one for each direction and one Nalukettu house with nadumuttam (open central courtyard).
In another article “Vastu Shastra FAQs”, I have provided the Vastu basis on which all of these plans were created. It will provide answers to all your Vastu-related questions.