Page speed optimization

Loading speed really matters. You can read this information everywhere from official Google sources to all blog posts written by gurus over SEO (search engine optimization) and UX (user experience from browsing a website).

In a nutshell, speed optimization is must-have thing today. Theoretical informations how to optimize a page to make it faster for load are written on many websites. If you do not want to optimize your page on your own, you can hire GameArter for this job. GameArter's main focus are its own projects - providing complex services for game developers and running websites as e.g. PacoGames.com or Games44.com. We deal with all common web-based, game-based and data-related issues on daily basis which provides us opportunity of getting great experience which we are happy to use further in client-based orders. Here's example of optimization processed by us.

When we talk about importance of page performance, it is obvious, that it is as twice as important on mobile devices. After all, this is clear also from Page speed insight by Google. This tool offers tracking for mobile and Desktop device separately while Desktop device usually gets far better score. Page speed insight was also reason why our colleagues from PacoGames asked us for a help to become “more green” in terms of speed.

Optimization process

1. Pre-optimisation tracking
2. Page analysis
3. Consultation with submitter
4. Selecting optimization strategy
5. Optimization itself
6. Results
7. Price and order duration

1. Pre-optimisation tracking

Page Speed Insight report is a good start and sufficient resource in most cases. However, to be able to report benefit of our optimization better for our colleagues at PacoGames, we did additional checks which will allow us to track and see benefits of the page speed optimization in real-time.

First tool we used is NewRelic.This tool allows us to track our app performance on backend as well as frontend on real users visiting the app.

Firstly we were interested in backend and infrastructure part. Usually, all problems at this side should be solved before the start of any speed optimization and adjustments on client side.

Backend part of PacoGames did not indicate any problem which could affect speed on client side (in browser) so we could continue in next checks with sufficient certainty that we get undistorted data.

Complete time of page loading is sum of times required by web application, network, DOM processing and page rendering. This page is different for various types of pages.

For more complex times instead of average, here’s histogram graph of individual numbers of loads in certain loading time.

As a last step, we checked loading time in Google analytics (Behaviour / Site speed / Page Timing) and set regular tests from various part of world in StatusCake.

2. Page analysis

By quick check of the page, we found out following

• Page is using up to date PHP, serving over http/2 protocol
• Static resources (images, styles, javascripts…) are served over CDN, with right cache settings, in minified and compressed format.
• Page is using simple DOM to render.
• Page is using many images. They are in modern format webp (if possible), images are compressed and have optimized size and file-size. However, without lazyload practice.
• TTFB (time to first byte) is not ideal in most geo locations
• Although there is a visible effort for setting priorities of loading resources, it’s not optimal.
• All ads on page are loaded immediately, not until in a time when a user can see them. (lazy load for ads)
• Some javascript powered features can be replaced for more efficient css based features (e.g. smooth scroll)
• Most used elements on the web - images and rating counters uses inefficient styling requiring higher number of DOM elements
• Website uses own template including styles and javascripts, however their usage is not high and pages usually load some libraries which could not be necessary.

3. Consultation with client

On basis of found opportunities we could start talk about scope of the contract. As a usually, we recommended to use effective Pareto principle - get 80% of result in 20% of time. In next sections of this post, we will always mark what work would be done within the pareto principle, and what work we would did if we optimized the web for 100% performance.

4. Optimization strategy

• Optimization will improve page speed + reduce operation costs.
• Optimization will take in account used technologies on the website.
• Optimization will be made by adjusting time of resources loading and optimization of core javascript and style files.

5. Optimization itself

5.1 Resources optimization

The website was using 1 global style and few global javascript libraries. The result of this was that a browser had to load, parse and execute big files with mostly unused resources at every page. Statistics of used resources of every loaded file is possible to get via Coverage tool in developer tools of Google Chrome.
Pacogames was coded with respect of modern principles. Individual template parts are separated, built to final format via streaming build system Gulp.

Styles, using Stylus preprocessor, has separated file for every class. This allows to make manual, alternatively automatic segmentation of classes on basis of pages they are used on and on basis of the results to select new format of page-based styles.

JavaScripts, written in separate modules based on their purpose are associated to one file via webpack. Again, based on real usage on a level of pages, there is a possibility to split this one javascript to more files and more memory efficient files.

Option 1 - Cost (time) effective optimization strategy (pareto principle)

Styles and javascripts would be split into 4 separated files.

• 1 base style and javascript file contains base functionality required at all pages of the website. Style file-size of this file is 10.9KB and js file-size is 1.9KB, loaded asynchronously. These 2 files are loaded via network on the first page only, all other pages load them from cache.
• 3 Individual style and javascript files extending base files about style and javascript components required at individual pages.
  • Shared CSS and JS for main page and category pages
  • CSS and js file for game pages
  • CSS and JS file for all remaining pages
• Website further contains separate scripts for other required features such as lazy loading, GDPR bars, notifications or worker services.

Option 2 - Complex optimization strategy

Website still uses 1 core css and javascript files with additional page-related style and javascript files, however, all these files are lighter, extended for multiple other javascript and style files which are being placed or loaded into a page in a time of their need. This way reduces weight of resources which must be loaded and processed furing a page load.

5.2 Elimination of resources

Every website uses resources for backward functionality, minor functions and many monetization and tracking scripts. There is always need to ask yourself, what is needed, what is worth of page slowdown. Pacogames required to preserve all functionality and resources (except on this website useless synchronously loaded Modernizr library in the header) so we skipped to a customization of loading priorities.

5.3 Customization of loading priorities

Option 1 - Cost (time) effective optimization strategy (pareto principle)

5.4 Asynchronous load of nor-critical css

After our splitting of 1 global css file to 1 shared css file and other page-type based files we have option to apply asynchronous load of non-critical css files to prevent blockation of rendering (usually 180ms per every style file).

There is more ways of applying asynchronous load for styles, differing in browser support, form of implementation and required libraries. More about this topic is well explained at article Modern Asynchronous CSS Loading or on Google Page Speed insight help page.

All variants of asynchronous css loading requires javascript. Fortunately, support for browsers with disabled javascript is possible by keeping the same style line inside <noscript> attribute.

After some tests in various browsers, with a goal to keep way of loading css as affective as possible, we used this way of asynchronous css loading:

<!-- Critical css loaded synchronously -->
<link rel="stylesheet" href="/css/general.css" media="screen">

<!-- Non-critical css loaded asynchronously -->
<link rel="stylesheet" href="/css/... page related css ..." media="none" onload="this.media='all'">
<!-- support for browsers with blocked js -->
<noscript>
    <link rel="stylesheet" href="/css/... page related css ..." media="screen">
</noscript>

<!-- Chrome native loading -->
if(ChromeNativeLazyLoad){ (cannot be used for ads)
	// use chrome native lazy load
} else if(interactionObserverSupport){
	// use lazy load via interactionObserver
	// this is performance efficient comparing way with getBoundingClientRect()
	// it works well also in Iphone
} else {
	// classic most used way over getBoundingClientRect()
}