Written by Richa
on 

Case Study on Web Performance Optimization

Recently, I completed Web perfomance optimization course from udacity to make things more clear in my head I analysed the webcompat.com. Webcompat is an add-on feature which helps in reporting any bug in a website.

As part of my analysis I consulted Lighthouse and Pagespeed Insights to measure performance of www.webcompat.com. I have noted down my findings based on each resource under a different heading. I have also included a list of fixes wherever it was possible for me to suggest an optimization. I have also made some changes and pushed on my own fork of the code to check how the resolution of some of the issues would look like.

Analysis of Lighthouse reports (Chrome web-dev tool)

Large difference in FCP b/w Localhost and Live version On investigating the reports attached in the below comment, I see that there is a significant difference in FCP, FMP etc between localhost and live website. This is primarily because in the localhost the server doesn’t serve compressed test resources and doesn’t load minified JS. These two issues are not present in the live version of the site.

Issues in Live version

  1. An issue which is present in both the versions is the wait-time for render blocking resources.

    • Essentially components like google.fonts is preventing rendering of the website before this resource is fetched. Here I see that in layout.html we are linking – href= https://fonts.googleapis.com/css?family=Open+Sans:400,600|Source+Sans+Pro:300,400|PT+Mono To prevent this from blocking the rendering I used style element inside the body to load the fonts asynchronously. This helps with reducing the FCP, FMP and TTI by shaving off 0.4s on my localhost Lighthouse reports. One issue of this approach is that users might face FOUC (flash of unstyled content) while the fonts are still being loaded and can see a flicker. Some discussion on this: https://stackoverflow.com/questions/25230264/how-to-keep-css-from-render-blocking-my-website

      I have created a new branch (LoadFontAsynch) on my fork and we can see the code changes at: https://github.com/14Richa/webcompat.com/tree/LoadFontAsynch

    • webcompat.min.css is also a render blocking resource according to the Lighthouse reports. In order to remove/reduce the rendering time we can use critical CSS (above the fold) in in-line fashion and load non-critical CSS asynchronously.

      I have found a nice collection of resources which I can explore to address this issue: https://github.com/addyosmani/critical-path-css-tools

  2. Unused CSS rules: webcompat.min.css has some unused rules which can be removed to further increase performance. [Homepage, Issuelist, Issuepage] On reading more on this I find some tools mentioned here would be helpful to find the unused css rules. Chrome web-dev tools also has a coverage option which checks for unused CSS/JS. More details: https://stackoverflow.com/questions/135657/how-to-identify-unused-css-definitions

  3. Making text visible during webfont load using font-display CSS feature. [Homepage, Issuelist] We can use font-display attribute to change fallback logic or decrease block time of the fonts to display the fonts. More details: https://developers.google.com/web/updates/2016/02/font-display

  4. Excessive DOM Size –> This issue is present in Issueslist page where it lists many issues in one page. This creates ~1100 nodes in the DOM tree. From what I understand, we can take a look at nodes which are displayed when the page loads and send only these nodes at first call, can render other nodes on user’s gesture. [Issuelist]

Best Practices flaws

Some best practices flaws identified by Lighthouse

Analysis of Pagespeed Insights

Pagespeed is another google-supported tool used to understand which resources/best-practices can be checked into while understanding website performance. I have listed down somethings which I want to try to improve rendering performance of webcompat.com