Archives for July 2019

Minify HTML, CSS & JS – “Minify your HTML, CSS and JS files to remove white space and unnecessary or redundant code (such as comments) which in turn minimises code across your site’s pages and script files.

This will reduce file size which in turn reduces bandwidth usage and page load time. There are manual tools to help with this such as:

• https://cssminifier.com/
• https://javascript-minifier.com/

There are also resources available which will generate minified code dynamically. There are a number of plugins available for WordPress sites:

• https://en-gb.wordpress.org/plugins/tags/minify/

Whilst developers can find code to do this such as:

• https://gist.github.com/tovic/d7b310dea3b33e4732c0
• https://github.com/mrclay/minifyAlways

Always make sure you test your minified code to ensure the CSS and JS files still work.”

Sprite Maps – “In general, any way to reduce the number of round trips (http requests) to and from the server during page load is a good idea. Similar to JavaScript and CSS aggregation techniques, using a sprite map for collections of icons can help reduce server requests. Let’s say you need to render twenty small icons in various places on your web page. Instead of loading twenty small icons individually, use Illustrator, or your design tool of choice to lay all twenty icons next to one another on a single image file. Then you only have one image file to load. Now you have reduced twenty http requests down to only one. You can then use the CSS background rule to render each icon in the sprite map, individually, where you like on your page.

Here is a pretty good blog post on creating sprite maps:

https://fiorecommunications.com/2018/06/08/creating-and-using-css-sprites-to-improve-google-pagespeed-scores/”

Reduce Redirects – “Redirects are instructions, which automatically take visitors of your website from one location to another. They are often necessary when you move or delete pages, and are the best way to eliminate issues with broken links.

Having too many redirects creates additional requests, which can significantly decrease the speed of your website, especially on mobile devices. This means, it’s best to keep them to a minimum. Google says that site owners should try to eliminate them completely.

There are two types of redirects: server- and client-side. Server-side use HTTP to direct the browser to the new location of the file. Client-side use HTML or JavaScript code in the user’s browser. If you can’t remove all redirects, make sure you use the server-side ones. Web browsers can handle them much quicker and can cache the correct location of the file.”

Be Consistent (& Accurate) With Your URL – “If your site is at https://www.hopstudios.com, then make sure you ALWAYS use https, and you ALWAYS use www, in every place you link to your site, publish it, mention it, print it, etc. If someone tries to visit http://hopstudios.com/, that’s going to require at least one, possibly two redirects before they arrive at the final proper request to load your home page, and that can add a delay of several seconds to the initial page load. The current best practice is to have https as the default, and the non-www as the canonical URL, but regardless of what you choose, just make sure that you are consistent.”

Minimise all HTTP requests – “Around 80 per cent of a site’s load time is due to the loading of:

• Images
• Style sheets
• Scripts
• Other page components

Each of these elements can require a separate HTTP request, prolonging the page’s loading time.

You can reduce the number of such requests through your browser. Use Google Chrome’s developer tool to see how many HTTP requests your site is making:

• Right click on the page
• Click ‘Inspect’
• Click ‘Network’ tab (If you can’t see the tab, consider expanding Developer Tools sidebar)
• The ‘Name’, ‘Size’, and ‘Time’ shows the corresponding details of the files on the page
• Pay particular attention to the ‘Time’ since this shows how long it takes to load a file
• Down on the left corner is the number of total requests your site makes

You can now check and remove the files not necessary for your site’s loading. Otherwise, you may combine some of the files instead.”

Lazy Loading Technique – “One of the techniques we use here at Web Choice for speeding up websites is called Lazy Loading Technique also called Asynchronous Loading which will help images to load only when pages are scrolled down.

eremy Wagner who contributes to Webfundamentals says this:

The portion of images and video in the typical payload of a website can be significant. Unfortunately, project stakeholders may be unwilling to cut any media resources from their existing applications. Such impasses are frustrating, especially when all parties involved want to improve site performance, but can’t agree on how to get there. Fortunately, lazy loading is a solution that lowers initial page payload and load time, but doesn’t skimp on content.

Read his full article here

If you are using WordPress, Joomla, or Drupal- most of the SEO plugins and extensions may already have Lazyloading integrated into it. If you are using a bespoke solution, your web developer can use scripts like this.”

Write Smarter CSS/SCSS/SASS – “Lots of designers / developers talk about compressing CSS files into one document (and for good reason, that helps with page load), but very few people talk about being smarter with how those files are written BEFORE they are combined together

Too often do we see hyper-specific CSS sheets that are 8 selectors deep before their property is rendered, or the shameful, but sometimes necessary evil “!important” tag contained within your stylesheets. As website professionals, we can’t just rely on compression algorithms and hope that processors and internet speeds keep increasing. We need a fundamental shift in how CSS is written.

So what am I actually talking about?

When developers are writing the CSS for a site, many will be using a framework which contains some ground-rules to get the site looking good right away. The problem with these is that they are often rammed full of very specific selectors which can make it difficult to change how some elements look. Or worse still, they use 1 variable which is used in hundreds of places when you might only want to change a colour/size in one location.

This can lead to creating classes like: header > nav > .top-nav > ul > li > a > span.primary{ your classes }

What we really want to do is think about how we can potentially reduce those very specific selectors down to something more manageable, as well as strip away the fluff we don’t need. It’s not too hard to see a world where, with a bit more planning and mindfulness of how we write code, that we see something like: nav > ul > span.primary{ your classes }

CSS preprocessors are partly to blame for this as we often see neatly written code within a SCSS document, but rarely bother to check the final output to see if it makes any sense at all, often leaving hundreds of unused classes that have been generated by the final output.

How would this help your page load speed?

Being more careful about how CSS selectors are used within preprocessors (and just standard CSS code, too) will help in two ways:

1. The File Size Will Be Smaller – the first and most obvious point is that we’re generating less classes, less code, and thus a smaller document. It may only save you a few KBs on a big project, maybe just a few bytes on a smaller one, but these add up over time in a web project to create a better, faster user experience.
2. Faster Render Time – not only will your documents load faster (see above) but individual browsers will also be able to render your pages faster. Without having to go down hundreds of selectors and find the most !important !important!!! class, computers, phones and browsers will have an easier time painting your site.
3. Manageability – ok so this isn’t load-speed related specifically, but a smaller code base makes it more manageable, easier to review and edit, and ultimately nicer to work with.

Concluding, our final goal is to get our sites looking exactly as we want, loading as quickly as possible, and providing a good user experience. Just shaving off a few selectors within code can make all the difference in the world.”

Optimize DNS Options – “An often overlooked aspect of site speed optimization is your Domain Name Settings (DNS). If you already own a domain (and maybe a website too), you may know where and how to do this. If not, I’ll try to give some instruction on how.

First: what are you telling me to do? There are two main types of DNS records used to tell a site visitor’s browser where to go to find your website. 1) the A record. An A record identifies the IP address for the server which hosts your website, and 2) a CNAME identifies a domain to lookup, which will take the site visitor to a URL, which will then redirect their request to your website.

Which one is faster? Well, the A record of course. There are legitimate reasons to use a CNAME, such as on shared hosting where the hosting company might move your site to a different server without telling you, and then your website would be down until you updated your A record. But for the most part, that is a rare occurrence: it has only happened to me once in 10 years, and my team corrected the problem within minutes.

Generally, using an A record will be the best option as it speeds up your load time. Sometimes this only saves a few milliseconds, but as you’ll find while optimizing your website, every single millisecond adds up quickly.

The most common way people do this is by using a CNAME for the “www” version of their website, and then they set the “www” version of the site to be the live version. They then redirect all other variations to that “www” version. The problem here is that even if a site visitor goes to their naked domain (e.g. mydomain.com, not www.mydomain.com), the site visitor is then redirected to “www” which goes through a CNAME and then finally redirects them back to the website. This all happens in milliseconds and you don’t see it happening generally, but understanding what is going on is important to speeding things up.

All you need to do to change this is to delete your CNAME for “www” and replace it with an A record directing people straight to your server’s IP address, rather than to a redirect (e.g. myhostingplan.hostingcompany.com, etc.).

I share this tip with this word of caution: if your hosting plan is shared hosting (which includes most managed WordPress hosting providers such as WP Engine), then you’ll want to keep a close eye on this, as they sometimes move servers around without telling you. The best way to do stay on top of this is to use a monitoring service such as Uptime Robot, which will send you a text message if your website goes down.

If you are just building your website for the first time and have not already built a lot of backlinks to your website, I recommend starting with the naked domain, not “www” sub-domain. This is sometimes counter-intuitive, as a lot of customers are so used to that, they think they still need that prefix in order to access a website (just make sure it redirects properly!). Not having that extra sub-domain simplifies things for you.”

Configure your Expires Headers – “You’ve probably heard about browser cache, so in other words when a user visits your website, the website files are stored on their computer so that your website loads faster for them on their next visit. What is not so well known is that the file header contains an expiration date that controls how long those files are stored on their computer.

Constantly downloading the same files when they are unchanged wastes precious load time, so Expires Headers not only reduce the load of downloads from the server, but also the number of HTTP requests for the server.

Expires Headers obviously won’t improve page speed for first time visitors, who will have to download all the files for the first time, but using them will definitely help decrease load times for returning visitors.

Expires headers can be set for specific files or even file types, so when the browser comes to the website, it can see the last time those were downloaded. If this was recent then it will display them from the cache. If the visitor hasn’t visited the site for a while, it will download the newest version from the web server.

Usually set to 24 hours by default, you can set the expiration date so that it doesn’t impact your server and page load time. The idea is to set late expiry times for items that don’t change on your website (logo, colours etc) and set short expiry times for things that change regularly.”

Remove Redundant Code (particularly in the back-end) – “This tip mostly applies to multi-language web applications that share back-end code. It could be done as one single package with each language or country as one module in the package. Each module could have the same code with the other modules like product listings and user session handling.

Let’s look at the products. Each localisation, a country or language, might have a different set of product attributes. Say in the US, a product could be using UPC (Universal Product Code) code as unique code and in Japan, it could be using JAN (Japanese Article Numbering). But both countries use the same core set of attributes: product name, product description, dimensions, weight, and price. Instead of creating two separate back-end codes for both US and Japan localisations, we can create a common code for the two, say base products. The base products could have its own module. Each localisation will then inherit the base product module and add their own unique set of product attributes.

What happens now is there is the base products module, the US products module, the Japan products module. Modifying the base products module is done only once, no matter how many localisations are there. Redundant code is now lessened. If you’re using compiled languages like C#, you’ll appreciate this improvement more. Each module is a DLL file loaded in memory. As the site gets bigger, you’ll notice a hit in performance or page loading speed. Removing redundant code that way is very helpful.”

Conditionally Enqueue Styles and Scripts – “In addition to writing code that is clean and efficient, one way to optimize and speed up your WordPress website is by conditionally serving scripts and styles only when needed on a page. WordPress uses wp_enqueue_style and wp_enqueue_script to load your styles and scripts of your website for the best performance.

Let’s look at an example of how to enqueue scripts and styles conditionally in your WordPress theme functions.php. Say you have a Fancybox pop-up that only needs to be on a specific template page.

The following code shows how to write an enqueue function in your functions.php to load global scripts & styles (bootstrap & theme css) with a condition for enqueuing Fancybox only on the Gallery template page.

https://github.com/ashleycam3ron/functions/blob/master/wp_enqueue_scripts2.php

WordPress offers an extensive list of conditional tags to load styles and scripts anywhere – pages, posts, categories, archives, etc and as specific to the ID number. Here’s the full list of tags:

https://codex.wordpress.org/Conditional_Tags”

Reduce Impact of Javascript on the Critical Rendering Path – “With speed of web page delivery becoming more and more critical, you must pursue all options to minimize the impact of technologies used to display pages. Javascript is one of these technologies.

Using Google Speed test you can parse your webpage to review issues with JavaScript. For now, let’s focus on critical request chain and render blocking issues. Once you identify Javascript issues, you first want to define your critical assets and load them as early as possible. Then decide to eliminate, defer or load async non critical assets.

Critical Request Chains

This has to do with how many directories the code must traverse to fetch and execute. This is an easy solution to implement. Bear in mind you have to update the directories and all pages that point to the code.

EX:
/scripts/videos/videoscript.js
Vs
/scripts/videoscript.js [Better]

Render Blocking Scripts

When Javascrpt is used, it actually blocks the parsing of the HTML document. The main thing you have to understand is that during script fetch and script execution; nothing else is being handled. Even when you have minified the code, it still has to be fetched and executed.

Eliminate Scripts that are not Necessary

Many developers load Javascript libraries which contain code not used for the current web page. The entire library will be parsed and compiled. Of course this wastes precious milliseconds of time to get your site to the First Contentful Paint.

In order to enhance page speed loading you will want to groom your scripts to eliminate calls that are not used on the page. Easy Peasy…

Run the Javascript using the Async Attribute

Using the async attribute is super helpful if you are using externally located script files. The result will allow html code to continue parsing, while the script is being fetched. The parsing will stop again as the script executes. Simply add the async attribute in your code.

Run the Javascript using the Defer Attribute

Using the defer attribute gives you the ability to continue parsing during script fetch, just like async. Additionally, it allows you to defer script execution once the HTML is fully parsed. When you defer parsing you want to be sure that the asset is not critical to a function of the webpage. Keep in mind not all browsers utilize the defer attribute.

When to use these attributes depends heavily on how they are used in the HTML code. One strategy is to place all Javascript at the end of your document. This will essentially defer parsing of the Javascript to the last step. This can be problematic when critical assets are needed for content display. Evaluate the wisdom of pulling critical assets and running them inline as needed.”

Use SPA to Improve User Experience – “Single Page Applications are becoming more popular now-a-days. There are so many good reasons why a SPA will be better than MPA in terms of making the overall user experience much faster and seamless. SPA is an evolution of the MPA+AJAX design pattern, where the only core page is generated on the server and all UI is rendered by browser based JavaScript code.

With the advent of AJAX, web apps started to refresh only the relevant portion of the page when a user submits new data or requests. For example, if a user selects county = Cornwall, then the web app can immediately use an AJAX request to validate whether the entered post code is valid for the county of Cornwall. However, once the user submits a form typically the web app takes the user to a new HTML page.

– Some or most of the data validation activity can occur on the client.
– The MVC implementation is on the server.

SPA are quick, as the majority of the resources they use (HTML / CSS / JavaScript) are only loaded once throughout the user session. The only thing that is transferred and changed after user activities are just data in the form of JSON.

So this improves user experience because the view is already loaded locally and the data will be asynchronously loaded in the background from the server. Even during development, you can reuse the same back-end API for web application as well as native mobile applications that rely on API based flow.

Another advantage is leveraging the use of Offline & Caching. SPAs are more efficient in caching any local storage. It works as follows: a web application sends just a single reflex, collects the required data, and can function even offline at that point.”