Short overview of page speed optimization of mobile gaming website PacoGames.com. If you are looking for free games to play or use in your service, PacoGames is great place for you.
For full updated article with advanced statistics comparation and better UX — check blogpost is How to speed up a website.
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. PacoGames.com. 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.
Optimization process
- Pre-optimisation tracking
- Page analysis
- Consultation with submitter
- Selecting optimization strategy
- Optimization itself
- Results
- 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 of page rendering — e.g. skipping to React, Vue.js or a different modern framework.
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.
- 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)
- 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. 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 style about style and javascript components required at individual websites.
- 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 get 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.
At the end, 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 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 images formats by a browser in header request, 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
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.
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).
PageSpeed insight score with modified first ad loading timing. The ad is loaded later, shortly before the user sees it. The final score after 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.
