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 a must-have today. Theoretical informations how to optimize a page to make it load faster 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. We deal with all common web-based 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.

Practical example: Page speed optimization of PacoGames mobile version.

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 a 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.

PageSpeed insight statistics before page speed optimization PageSpeed insight score before page speed optimization

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 part. Usually, all problems at this side should be solved before the start of any speed optimization on client side to have option to adjust technology and kind of page rendering - e.g. switching to React, Vue.js or a different modern library / framework. Interesting alternative for certain use-cases is also use of AMP.

NewRelic - Server app speed statistics Speed of server application

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.

NewRelic - Client side application speed statistics Page load speed on a level of all pages

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.

NewRelic - Client side application speed statistics - Histogram Page load speed histogram on a level of all 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 some 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)
  • 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.
Page resources coverage useage Page resources coverage useage

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. PacoGames agreed so we could start.

4. Optimization strategy

  • We will focus on page speed on a client side. Network speed (TTFB) is sufficient, improvement in this layer would bring big additional costs for operating the website due to its nature. See more in our post Price of speed and data.
  • Optimization will be made based on website usage by users. Most time will be invested into most visited pages.
  • 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 practices. 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.

Styles and javascripts are newly splitted into 4 separated files.

  • 1 base style and javascript contain 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

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 customization of loading priorities.

5.3 Customization of loading priorities

Based on pageviews we got from Google Analytics, we mainly focused on the mainpage. By default, there was loaded group of libraries for searching. Importance of such libraries is easy to detect - on pressing search icon. Thus, we removed all the libraries from the main thread and added a dynamic load for them, only for a time when they are really necessary. For simple management, we loaded a shared javascript file for this purpose which is then cached for all other pages.
After setting dynamic loading for libraries intended for searching and all its features (3 libraries + jQuery in total), there was time effective to remove also jQuery with rewriting a small part of javascript using it. After this work, homepage does not require any library by default and all scripts were set to be loaded asynchronously.

Other pages use shared javascript file, same as file dynamically loaded for purposes of searching on mainpage, and possibly individual javascript files for page-bases functionality.

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 in <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="'all'">
<!-- support for browsers with blocked js -->
    <link rel="stylesheet" href="/css/... page related css ..." media="screen">

5.5 LazyLoad

For image and ads loading we implemented own lazyload library. This solution saves number of requests on server which results in loading less files and consuming less bytes. Data are newly being downloaded only when a user needs them. Because of PacoGames had selection between webP and jpeg images format made by Cloudflare according to sent supported image formats by a browser in request header, we had to make light adjustment also on app side to keep support of webP image format on.

6. Result

With all these changes, we received following improvements (tracked for homepage)

  • Saved 47% of request at server
  • Transfered (compressed) filesize reduced under 1 mb
  • DOM content loaded within 1 second
StatusCake statistics StatusCake loading speed tracking
Page speed before optimization Page speed after optimization
New Relic data - page speed comparration. Graphs display page speed reduction about 1.5 seconds, which is 20%.
Result image Result image
New Relic data - page speed histogram comparration. As you can notice, median of loading speed is now more associated in range 2-4 seconds.

Finally, page speed insight. Page speed and thus also PageSpeed insight score mostly depend on presence of ads and their load settings. By placing them to a page by classic way, ads cost substantial resources and thus loading time dramatically grow while PageSpeed Insight score falls.

As mentioned, we implemented lazy load mechanism also for ads which gave us option to optimize time of loading ads. The most important setting is especially for first - most visible ad.

Page speed insight score PageSpeed insight score with first ad loaded at the start. Final score after optimization is 75. It means increase by 41% (increase from 53 → 75).
Page speed insight score PageSpeed insight score with modified first ad loading timing. The ad is loaded later, shortly before the user sees it. The final score after the optimization is 99, an increase of 87% (increase from 53 → 99). If we would look at the impact of the 1 ad only, then it's increase from score 75 to 99 → +32%. This configuration is currently active on PacoGames.

7. Price and order duration

  • This optimization cost us 10 hours.
  • Setting tracking: 0.5 hour
  • Analysation: 1 hour
  • Consultation of options: 0.5 hour
  • Splitting styles 1.5 hour
  • Splitting javascripts: 1 hour
  • Adjustment of loading priorities: 1.5hour
  • Rewriting javascripts 2 hours
  • Final testing (optimization + functionality): 1.5 hours
  • Report: 0.5 hour
  • Price: $800
  • Discount: 15% (client uses also other GameArter services)
  • Client would pay $680 for this optimization.

For individual calculations for your website, contact Vladimir via contact form.