Google Lighthouse Tips: Importance of web page speed

Google Lighthouse tips

Mobile Focus 

  1. 75% of global mobile users were on 2G and 3G as of 2016 (Source: GSMA Mobile) 
  2. 1MB takes minimum of 5 seconds to download on a typical 3G connection. (Source: WebPageTest & DevTools 3D definition) 
  3.  19 seconds is the average time a mobile web page takes to load on a 3G connection. (Source: Google DoubleClick blog) 
  4. 70% of mobile pages take nearly 7 seconds for visual content above the fold to display on the screen. (Source: Think with Google) 

UX & UI Performance 

  1. As the number of elements on a page increases from 400 to 6000 the probability of conversion drops 95%. (Source Think with Google) 
  2. Site takes >1 sec to become interactive, users lose attention, and their perception of completing the page task is broken. (Source: Google Developers Blog) 
  3. As page load time increases from 1 sec to 7 secs, the probably of mobile site visitor bouncing increased 113%. (Source: Think with Google) 
Proven Results 

  1. Walmart saw 1% increase in revenue for every 100ms improvement in page load. (Source: WPO Stats) 
  2. Rebuilding Pinterest pages for performance increased conversion rates by 15%. (Source: WPO Stats) 
  3. By reducing the response size of JSON needed for displaying comments, Instagram saw increased impressions (Source: WPO Stats)

Comments

Post a Comment

Popular posts from this blog

Is Rendered Item Valid XHtml Document Could not find schema information warnings during publish item Sitecore 7.2

Image
Note: Since we now live in the HTML5 world, the simple resolution to any XHtml validation errors is to remove the XHtml validation rules on  System->Settings->Validation Rules->Global Rules item. Sitecore should update it's validation rules to be relevant to HTML5. This make the rest of this post obsolete :). I created a simple approval workflow in Sitecore 7.5 and tried to approve an item for publishing and found a bunch of validation errors in the Validation Results. Most of them were related to the "Is Rendered Item Valid XHtml Document" section which looked like this: The problems were related to violations of the W3C HTML5 recommendation An important note here is: The element containing the character encoding declaration must be serialized completely within the first 1024 bytes of the document. Adding the following xmlns attribute to the Html tag fixed most of the errors: <html lang="en" xmlns="http://www.w3.org/1999/
Read more

Sitecore Tabbed Select Rendering dialog

Image
If you aren't already doing this, you should be! Found an interesting module (unable to find it on Sitecore Marketplace) to show renderings grouped into tabs while using the Select Rendering dialog from page editor. The idea is to go from this: To: The approach is promising with a few updates: Tried implementing it by inheriting from SelectRenderingForm and it did not work. No rendering items were being listed. Had to decompile Sitecore.Client.dll and copy the code from Sitecore.Shell.Applications.Dialogs.SelectRendering.SelectRenderingForm Had to comment the following line in OnLoad  this.Renderings.InnerHtml = this.RenderPreviews((IEnumerable<Item>)renderingOptions.Items); Found a few issues with the styles, could have be an updated style sheet for Sitecore 7.5, but had to add the following attributes to the tabstrip Background="white" Padding="0px" style="position:absolute; width:100%;top:0px" Here is a detailed description of my implementati
Read more

RESOLVED: Solr Exceptions - Document contains at least one immense term in field

If you implemented Solr with Sitecore using Solr 5.x, you may run into the following error when indexing extremely large content in string fields: org.apache.solr.common.SolrException: Exception writing document id <xxxuniqueid> to the index; possible analysis error. Caused by: java.lang.IllegalArgumentException: Document contains at least one immense term in field="<xxxfieldname>" (whose UTF8 encoding is longer than the max length 32766), all of which were skipped. Please correct the analyzer to not produce such terms. The prefix of the first immense term is: '[10, 9, 9, 10, 32, 32, 32, 32, 32, 32, 82, 84, 82, 83, 32, 70, 97, 99, 105, 108, 105, 116, 121, 32, 10, 32, 32, 32, 32, 84]...', original message: bytes can be at most 32766 in length; got <intgreaterthan32766> Caused by: org.apache.lucene.util.BytesRefHash$MaxBytesLengthExceededException: bytes can be at most 32766 in length; got <intgreaterthan32766> This is due to the fa
Read more