Automated testing is a very important part of testing a website; as this is able to detect any errors within the website that will cause issues. Furthermore, automated testing tools can detect the issues then inform the developer on how to resolve them.
mobiReady, which will be discussed in this article.
mobiReady
This tool is verified by https://www.w3.org/TR/mobile-bp/
The importance of this tool to test the websites mobile readiness cannot be underestimated, as it tests thirty- eight different aspects of the site from DNS lookups to caching control. Once the site has been processed, mobiReady has three grades:
Major fail: the website has failed to meet the required criteria for this category.
Minor fail: the website does meet some of the criteria and does not hinder overall performance but improvements to be made.
Pass: the website has met the required criteria for this site.
Along with grading each category, mobiReady provides specific evidence as to why the site was graded one of the above and a resolution. This tool is very helpful for the development of the site. (see initial grades in comments).
As you can see below, the first test was a success with twenty-nine categories passing, seven minor fails, and two major fails.
Firstly I focused on the major fails(two) as these need immediate attention:
DNS lookups: eight special domains, criteria state there should only six domains as this affects page loading time.
Solution: adapted CSS of footer positioning thus not needing bootstrap CDN, also adapted the maps inline code thus popper CDN not needed. This reduced special domains down to six, which meets criteria.
CSS measurements: Absolute dimensions and positions in CSS directives should be avoided as they will not render correctly on all device types; for example, avoid px and use em.
Solution: change CSS rem measures to em, then re-ran the test and there was no difference. The issue appeared to do with the domains W3S schools& font-awesome directly, future iterations to explore other libraries that do not flag any major errors.
This left the seven minor fails:
Favicon: The favicon will be downloaded automatically so it should be less than 2kb in size and should have a far-future Expires header.
Solution: I explored potential CDN's such as the latest JQuery or google Ajax library but this was not a solution as adding another special domain created an error. (See DNS lookups)
investigated favicon file size, 32x32 file size was 3KB which is too big(2KB is the limit) so changed this to favicon 16x16 which the file size is 1KB. Reducing the file size from 32x32 to 16x16 which resolved this error.
CSS sprites: CSS image assets should be combined into sprite files to avoid expensive HTTP overhead.
Solution: This is a difficult issue to resolves as images are a major feature of the website and organised in a certain way that is appealing. Plus the solution provided by mobiReady to use image sprites which combine multiple images together, however in this case is not fit for this project.
Future iterations of the site to look into more effective ways to include images.
Internal CSS directives: CSS should be applied in an external file.
Solution: This error stemmed from applying style="100%", this is due to the framework adapted from W3S school example. Attempts to place the width of the slide in the external document did not work. Future iterations of the site will look into other slideshow frameworks that do not require inline CSS.
Edit - Further investigations resolved the inline css& placed in style.css file.
Popups: Link targets of _self, _parent or _top should be avoided as only desktop fully supports the tabbed browsing experience.
Solution: Removed target=_blank from social media icons and changed links inside the homepage that were crediting the resources I used. The error has been resolved.
Inline JavaScript: Javascript to be applied in an external minified file.
Solution: this issue has been the subject of major investigations throughout this project, as the verified documentation such as Google developer https://developers.google.com/maps/documentation/javascript/tutorial show that the effective method to implement maps is inline. I discussed with the code institute tutor and my mentor how I could implement maps dynamically without success. See #13 for further discussion on Google maps implementation. There was not a solution to move the maps JavaScript into a dynamic file that works, future iterations to investigate further.
HTML minimise: HTML markup should be minimized to reduce file size and to speed up transit time between server and browser.
Solution: Attempted to reduce HTML mark by cutting unnecessary comments and using https://www.freeformatter.com/html-formatter.html#ad-output to ensure clean indentation. The main issue is the inline maps JavaScript which as discussed cannot be moved. Future iterations to investigate further.
Image Specify size: images should include height& width attributes to speed up rendering time.
Solution: this was a confusing issue, see CSS directives above which specifically states that CSS should be applied in an external file. But this error was that height& width should be directly inside the document rather than external, the decision was to leave this error as this would create additional errors.
See the final test results in the comments below.
Summary
Overall this tool proved useful as it highlighted issues within the website that hindered user experience on mobile devices. Although there is still one major fail and six minor fails, this will allow the developer to focus on these specific areas in future iterations of the website.
Automated testing:
Automated testing is a very important part of testing a website; as this is able to detect any errors within the website that will cause issues. Furthermore, automated testing tools can detect the issues then inform the developer on how to resolve them.
I have used three automated testing tools:
Lighthouse, which is discussed here: https://github.com/michodgs24/Somerset-Trails/issues/10#issue-634894703
Google mobile-friendly testing, which is discussed here: https://github.com/michodgs24/Somerset-Trails/issues/14#issue-639764387
mobiReady, which will be discussed in this article.
mobiReady
This tool is verified by https://www.w3.org/TR/mobile-bp/ The importance of this tool to test the websites mobile readiness cannot be underestimated, as it tests thirty- eight different aspects of the site from DNS lookups to caching control. Once the site has been processed, mobiReady has three grades:
Major fail: the website has failed to meet the required criteria for this category.
Minor fail: the website does meet some of the criteria and does not hinder overall performance but improvements to be made.
Pass: the website has met the required criteria for this site.
Along with grading each category, mobiReady provides specific evidence as to why the site was graded one of the above and a resolution. This tool is very helpful for the development of the site. (see initial grades in comments).
As you can see below, the first test was a success with twenty-nine categories passing, seven minor fails, and two major fails.
Firstly I focused on the major fails(two) as these need immediate attention:
DNS lookups: eight special domains, criteria state there should only six domains as this affects page loading time.
Solution: adapted CSS of footer positioning thus not needing bootstrap CDN, also adapted the maps inline code thus popper CDN not needed. This reduced special domains down to six, which meets criteria.
CSS measurements: Absolute dimensions and positions in CSS directives should be avoided as they will not render correctly on all device types; for example, avoid px and use em.
Solution: change CSS rem measures to em, then re-ran the test and there was no difference. The issue appeared to do with the domains W3S schools& font-awesome directly, future iterations to explore other libraries that do not flag any major errors.
This left the seven minor fails:
Favicon: The favicon will be downloaded automatically so it should be less than 2kb in size and should have a far-future Expires header.
CSS sprites: CSS image assets should be combined into sprite files to avoid expensive HTTP overhead.
Internal CSS directives: CSS should be applied in an external file.
style="100%"
, this is due to the framework adapted from W3S school example. Attempts to place the width of the slide in the external document did not work. Future iterations of the site will look into other slideshow frameworks that do not require inline CSS. Edit - Further investigations resolved the inline css& placed in style.css file.Popups: Link targets of _self, _parent or _top should be avoided as only desktop fully supports the tabbed browsing experience.
target=_blank
from social media icons and changed links inside the homepage that were crediting the resources I used. The error has been resolved.Inline JavaScript: Javascript to be applied in an external minified file.
HTML minimise: HTML markup should be minimized to reduce file size and to speed up transit time between server and browser.
Image Specify size: images should include height& width attributes to speed up rendering time.
See the final test results in the comments below.
Summary
Overall this tool proved useful as it highlighted issues within the website that hindered user experience on mobile devices. Although there is still one major fail and six minor fails, this will allow the developer to focus on these specific areas in future iterations of the website.