How to Make Your Website Serve Pages Faster?

I made this list for CNN but it might be useful for any website owner. In the HTML source code on any CNN.com page, there is a hidden message. CNN Labs team asks for ways to speed up their website.

This article was originally published on CodeProject.com

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 someone 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.
• Lazy-load JavaScript files, CSS stylesheets, images and videos using JavaScript code in the static HTML pages. (My unreleased CMS does these two things already – check out www.vsubhash.in. While this CMS is targeted at people with personal websites, these two ideas can reduce waiting times for any kind of website.)
• 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.)
• Don’t use images when the same effect can be achieved by CSS. But, don’t use a CSS or JavaScript framework when a simple image would do.
• Don’t use a third-party CMS or big JavaScript frameworks for your high-traffic website. This kind of software suffers from code bloat as CMS developers try to cram more features or try to make certain features work in all situations. Write your own CMS with custom JavaScript and CSS optimized for your website. Maximum control & efficiency should be the goal. (CNN web pages, typical of off-the-shelf CMS-driven websites, contain a ton of JS and CSS and very little HTML.) Another problem with popular CMS programs are that site admins well-versed with them are not easy to find. Even if you do find them, it may be difficult for them to determine what a piece of code is doing. You eventually end up hiring developers who can add extra or customized functionality over the CMS-generated Javascript and CSS. Good developers will write their own code but many will resort to using more third-party CMS plugins. Over time, the code bloat will get beyond control. Very few developers in the Web team will be familiar with the site’s code and be able to troubleshoot effectively.
• 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).
  • ensure that their code is within limits. Many ad networks download a ton of (the same) JavaScript libraries to do the simplest of things.
  • 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 page 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.
• Don’t use social media plugins as-is-where-is. They usually block the loading of the page. Study their no-script versions and use your JavaScript to generate valid links dynamically.
• Get rid of (Google) analytics. They add to code 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.
• Don’t think that as JavaScript engines are so fast, browsers will have no problem with all the gunk you have included in your webpages. Nah-hah! JavaScript engines may claim to be fast but HTML and CSS rendering is still slow. Don’t believe me? Check out my Javascript benchmark test. After that, add network latencies (over which you have no control) to the mix and judge for yourself.
• 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.