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.
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.
- Pre-optimisation tracking
- Page analysis
- Consultation with submitter
- Selecting optimization strategy
- Optimization itself
- 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.
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.
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
- 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)
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.
5. Optimization itself
5.1 Resources optimization
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.
- 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
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.
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>
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.
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.
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
- Adjustment of loading priorities: 1.5hour
- 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.