Getting a website up is no longer difficult, at least on the surface. Anyone can claim to set up a website for you. But the secret about a high-performance website is what is done at the backend of the server and are steeped in technical complexity that most web designers have no interest or knowledge of. Let’s explore some of these secrets that would propel your website skywards with better PageSpeed and YSlow scores (for better SEO), and especially for mobile users.

The fallacy of web design

To some clients, all they care about is a “pretty” website. They want flashy blings, with full-screen images, heavy-duty videos, and flashy scripts of all kinds. To these clients, they have this mistaken notion that paying customers and visitors like websites this way. Unfortunately, it is a fallacy that is still supported by some agencies and web designers who either do not know better, or are too afraid to spend time to explain how websites actually work.

You see, a good website is intended to provide information with call-to-action (CTA) so that visitors can be turned to leads and customers. A good website must therefore serve 2 primary objectives:

  1. Can be found by visitors through the search engines (think Google).
  2. Must be fast to any visitor around the world, especially since we live in a global economy now, with Amazon as the prime example.

Both these primary objectives are intimately tied together. Google will only index your website if it is relevant (not full of “spam”), secure (with no malware or malvertising), fast (optimized content), and mobile friendly. Failing any one of these criteria will penalize your website, and sinks is further and further behind in the Google index.

And for users? Users are impatient, and increasingly so.

If your website is loading very slowly on public Wifi, or a mobile, they will move on (in a measurable metric known as “bounce rate“). If your website is heavy and slow, visitors will wait a few seconds, and click away elsewhere. You have just lost the one and only opportunity to engage a new prospect.

Some web designers will run your prototype website on a local disk which obviously will have no speed penalty, and you may not realize how slow your website will be in real life. Some may host your prototype website in a local fiber backbone, and you may also think the website is pretty fast. But the reality is that the website will only seem fast if you are on the same backbone and not going through too many hops.

Designing for mobile phones is also not as easy as it seems. Most web designers will use a CMS (content management system) theme that is “responsive”, and in usual circumstances, your website will be able to be viewed on a mobile phone.

However, the devil is in the details, and many such themes use frameworks that are very heavy, and will drag your website speed down, especially for mobiles, and will rank poorly in mobile tests.

Let us now examine just how to test your website to see if will be Google-friendly, bandwidth and mobile-friendly.

Education bias is a problem

Many schools focus on web design, and forget that DEVELOPMENT is just as, or even more important than design when it comes to getting a good website up.

And since many people only focus on aesthetics rather than technical complexities, the development component in missing from many website workers out there. I know, as I have interviewed countless candidates, and most fell short of the kind of work I needed to get done. Even web hosting providers are not exempted.

I have talked to very friendly colleagues in technical support fields of web hosting companies, and they were honest enough to admit to me that what I communicated with them, were “above their pay grade” (quoting their words). I had to troubleshoot and solve many technical complexities myself along the long arduous journey since 1996 to now (21 years!).

Is the website truly mobile-friendly?

It is easy to get a mobile friendly (responsive) theme automatically working. What many people don’t realize is that a website not only has to be visually compatible with a smartphone, it has to be bandwidth-compatible too – i.e. actually loading fast enough on a mobile on a 3G or maybe 4G connection.

The free and simple way to test your website is with the very browser the king of search engines has created – the Google Chrome browser.

Under the browser’s Developer Tools option, select Network, and Throttling options, and select “Good 3G” (a good estimate for many smartphone users in this part of the developed world), and click “Disable cache“.

At the bottom of the screen, you will notice 3 readouts:

  • Requests,
  • (data) Transferred, and
  • Finish (time to load page fully).

The fewer the Requests, the smaller the data Transferred, and the shorter the Finish (time to load page fully), the more mobile-friendly your website is in terms of mobile bandwidth.

For example, our website makes 23 Requests, is 640kB in size, and loads fully in 6.6 seconds on a mobile 3G connection, despite having large graphics and animation.

20170423_chrome3g_mb1

Chrome Network Throttling test – our own site

Here is an example of a web design agency page, which makes 79 Requests, is a whopping 1.5 MB in size, and loads in 9.81 seconds on a mobile 3G connection.

20170423_chrome3g_webdevcd1

Chrome Network Throttling test – web company

Here is an ecommerce web store we designed, that hosts 50 product choices on this page, and makes 70 Requests, is 1.1 MB in size (due to the 50 products), and finishes loading in 9.76 seconds.

20170423_chrome3g_ecommepshub1

Chrome Network Throttling test – ecommerce site we developed

Here is an ecommerce web store of another company, with 244 Requests, 6.7 MB in size, and finishes loading in 39.91 seconds. It is extremely unfriendly to a mobile user and the bounce rate will be high. It would have been wiser to reduce the number of requests on each page with smarter design, and thereby reducing the total page size and its loading time.

20170423_chrome3g_ecommchallgr1

Chrome Network Throttling test – a large local ecommerce site

While we can measure how friendly a website is to mobile and its corresponding bandwidth, what determines these performance? We will find out in a bit.

Server administration and security skills are vital

For a typical CMS website, the typical web designer tinkers with just the WordPress portion of it, with themes, plugins, and content (text, images, and links to video and other content). It is really not rocket science and even then, many web designers fail at the critical component of securing the WordPress site properly.

I have the privilege of being a security practitioner since 1996, and have done security programming, and consulted at strategic levels, to at least understand what needs to be done. But many young designers will not have this tenure or knowledge. For WordPress security plugins, misconfiguration can bring down the website (500 forbidden errors) and even lock out legitimate users altogether. And the lack of security can bring the website down very easily through the frequent DDoS (distributed denial of service) and brute force attacks. It is a critical factor, and not to be treated lightly.

Some web designers do not focus (or have no expertise in) server administration, which makes the difference in your PageSpeed and YSlow scores, as well as the mobile performance, since many of these parameters can only be configured on the server.

A good website that has quality SEO (search engine optimization) and content optimization needs programming and server administration knowledge, such as Apache web server configuration/security, PHP scripting language and SQL database management for tweaking WordPress CMS. These technical skills are the domain of programmers and developers.

Some trivia that may help your website performance and security, but may be neglected by mere designers, are also the versions of your Apache web server software (or other comparable web server software), PHP, and SQL.

For example, are you at least running Apache 2.4x, PHP 7 and MariaDB 10? Again, these will require some tweaking to make your website work properly.

GTmetrix to the rescue

GTmetrix is a great testing platform to check your website’s speed and optimization. If you are selecting a web designer or agency, use GTmetrix as the litmus test for their skills. A good designer or agency should at least be able to optimize their website for speed.

There are 2 scores that you need to know about, PageSpeed, and YSlow, which are common ways for industry practitioners to measure the speed and optimization of a website, and to find out how to improve the website accordingly.

It is easier to achieve a higher PageSpeed score, while the YSlow score is much more stringent. You may score a B for PageSpeed and may well score a D for YSlow. In my opinion, a good website should be an A for PageSpeed and a B or better for YSlow.

What is your website’s score?

Other than PageSpeed and YSlow scores, other critical factors that you can discern from GTmetrix are:

1) Fully Loaded Time – a true measure of the speed and size of a web page, since some people may use “lazy load” to load images asynchronously, but users still need to load the whole page to read everything.

2) Total Page Size – is it small enough for mobiles? Is the web page bandwidth friendly on slow public Wifi or 3G? This is where you need sanity rather than obsession. One of the common failings of web designers (including some large shops) is that images are not optimized for the Web. For example, you do NOT need a 4,000 pixel (width) image for the Web, which is more meant for print. A 1,200 pixel (width) image with optimal image compression is good enough. Also, serve “scaled images”, which demands more from the web designer, but will help with PageSpeed and performance. Remember that our human sight is based on fuzzy-logic, and is very sophisticated to make out details without the need for full or high resolution. As a pioneer in interactive media design since 1986, I assure you there are a lot of incredible tricks one can employ to bring image sizes down dramatically and make the website lightweight.

3) Requests – the number of HTTP requests to various sites and servers in order to fulfill the serving up of the whole page. Some sites make hundreds of server requests, which are way too many. For legitimate requests such as CSS (cascading style sheets) and JS (Javascript), combine and minify them if possible. Inline small CSS and JS files whenever your can. Unnecessary HTTP calls can reduce the usability of a website, increase error rates, reduce speed, and also raise security and privacy concerns. Such requests often occur with cookie domains, advertising providers, video platforms, social media platforms, and so on. Use requests judiciously. If necessary, choose the lowest denominators and consolidate or streamline requests.

4) Caching – other than server-level caching, you can also leverage browser caching to allow your users to cache the content on their own disks. This will reduce loading time when your visitors return, since they would have cached some of the content. You can configure this at the server backend. And on your website, configure a good quality caching plugin.

5) GZip – configure your server to serve compressed content, especially text files such as HTML, JS and CSS. Some pages can be compressed by up to 70%, and will help with your overall load times.

6) Keep-Alive – configure your Apache to enable persistent HTTP connections so that the same connections can send and receive synchronous requests, increasing the speed for your users.

7) Expire headers – yet another server-level configuration that can be configured on the server or on the website level. Most content can have a designated expire header, where transient content such as text can have a shorter expiry, while images, videos, documents, and scripts can have a longer expiry since they are less likely to change often. The caveat is with some external scripts (such as Google’s scripts), since we won’t have server-level control on those, and so we cannot designate expire headers to them.

Here is an example of our GTmetrix scores, showing A for both PageSpeed and YSlow, with a very short Fully Loaded Time (1.8s), small Total Page Size (693kB), and 22 Requests:

20170423_gtmetrix_mb1

GTmetrix score – our own website

Here is an example of a web hosting provider, having an E for PageSpeed and YSlow, with 7s Fully Loaded Time, 2.22 MB Total Page Size, and an incredulous 170 Requests.

20170422_gtmetrix_sgwebhost1

GTmetrix score – large local web host

Here is an example of a web design agency, having an A for PageSpeed but a C for YSlow, with a really slow 23.9s Fully Loaded Time, Total Page Size of 2.66MB, with 52 Requests.

20170422_gtmetrix_sgwebdesign1

GTmetrix score – local web design firm

CDN boost

A content delivery network (CDN) can add an extra boost, even though it is not entirely necessary if you have done good quality configuration to enable an A score for PageSpeed. YSlow attaches a value to CDNs, so if you don’t run a CDN, your YSlow score will reduce. There are different CDNs out there, and as much as possible, SPEND on a good CDN since free CDNs will never perform as effectively as a paid dedicated CDN. There is no free lunch in the world.

So, if you have a website, I suggest testing it against GTmetrix and Google Chrome right now, and get a sense of what can be improved. If the scores are abysmal and unsettling, don’t worry, as there are proven techniques on your server back-end to get things right. It won’t be a short easy walk in the park, but it will be worth it as you get your scores up and reduce penalties on SEO. And if you haven’t got a website yet, and are talking to potential web designers and agencies, test their own websites against GTmetrix and Google Chrome. Then find the right people to help you move forward.