Merge pull request #14 from chicio/prevent-reflow 🚀

Prevent content reflow with <img/> lazy loading 🚀

Author: chicio

CHANGELOG.md

@@ -1,6 +1,14 @@
 # Change Log
 All changes to Chicio coding will be documented in this file.
 
+## [1.6.0](https://github.com/chicio/chicio.github.io/releases/tag/1.6.0)
+Release date: 2019-05-02.
+
+#### Added
+
+- Added svg placeholder to prevent content reflow for lazy loaded images
+- Updated gems
+
 ## [1.5.0](https://github.com/chicio/chicio.github.io/releases/tag/1.5.0)
 Release date: 2019-04-05.
 

Gemfile.lock

@@ -1,12 +1,12 @@
 GEM
   remote: https://rubygems.org/
   specs:
-    activesupport (4.2.10)
+    activesupport (4.2.11.1)
       i18n (~> 0.7)
       minitest (~> 5.1)
       thread_safe (~> 0.3, >= 0.3.4)
       tzinfo (~> 1.1)
-    addressable (2.5.2)
+    addressable (2.6.0)
       public_suffix (>= 2.0.2, < 4.0)
     coffee-script (2.4.1)
       coffee-script-source
@@ -16,7 +16,7 @@ GEM
     colorize (0.8.1)
     commonmarker (0.17.13)
       ruby-enum (~> 0.5)
-    concurrent-ruby (1.1.4)
+    concurrent-ruby (1.1.5)
     dnsruby (1.61.2)
       addressable (~> 2.5)
     em-websocket (0.5.1)
@@ -30,11 +30,11 @@ GEM
       multipart-post (>= 1.2, < 3)
     ffi (1.10.0)
     forwardable-extended (2.6.0)
-    gemoji (3.0.0)
-    github-pages (197)
-      activesupport (= 4.2.10)
+    gemoji (3.0.1)
+    github-pages (198)
+      activesupport (= 4.2.11.1)
       github-pages-health-check (= 1.16.1)
-      jekyll (= 3.7.4)
+      jekyll (= 3.8.5)
       jekyll-avatar (= 0.6.0)
       jekyll-coffeescript (= 1.1.1)
       jekyll-commonmark-ghpages (= 0.1.5)
@@ -82,7 +82,7 @@ GEM
       octokit (~> 4.0)
       public_suffix (~> 3.0)
       typhoeus (~> 1.3)
-    html-pipeline (2.10.0)
+    html-pipeline (2.11.0)
       activesupport (>= 2)
       nokogiri (>= 1.4)
     html-proofer (3.10.2)
@@ -97,7 +97,7 @@ GEM
     http_parser.rb (0.6.0)
     i18n (0.9.5)
       concurrent-ruby (~> 1.0)
-    jekyll (3.7.4)
+    jekyll (3.8.5)
       addressable (~> 2.4)
       colorator (~> 1.0)
       em-websocket (~> 0.5)
@@ -115,9 +115,9 @@ GEM
     jekyll-coffeescript (1.1.1)
       coffee-script (~> 2.2)
       coffee-script-source (~> 1.11.1)
-    jekyll-commonmark (1.2.0)
+    jekyll-commonmark (1.3.1)
       commonmarker (~> 0.14)
-      jekyll (>= 3.0, < 4.0)
+      jekyll (>= 3.7, < 5.0)
     jekyll-commonmark-ghpages (0.1.5)
       commonmarker (~> 0.17.6)
       jekyll-commonmark (~> 1)
@@ -195,7 +195,7 @@ GEM
       jekyll-seo-tag (~> 2.0)
     jekyll-titles-from-headings (0.5.1)
       jekyll (~> 3.3)
-    jekyll-watch (2.1.2)
+    jekyll-watch (2.2.1)
       listen (~> 3.0)
     jemoji (0.10.2)
       gemoji (~> 3.0)
@@ -215,11 +215,11 @@ GEM
       jekyll-seo-tag (~> 2.1)
     minitest (5.11.3)
     multipart-post (2.0.0)
-    nokogiri (1.10.1)
+    nokogiri (1.10.3)
       mini_portile2 (~> 2.4.0)
-    octokit (4.13.0)
+    octokit (4.14.0)
       sawyer (~> 0.8.0, >= 0.5.3)
-    parallel (1.14.0)
+    parallel (1.17.0)
     pathutil (0.16.2)
       forwardable-extended (~> 2.6)
     public_suffix (3.0.3)
@@ -232,14 +232,14 @@ GEM
     ruby_dep (1.5.0)
     rubyzip (1.2.2)
     safe_yaml (1.0.5)
-    sass (3.7.3)
+    sass (3.7.4)
       sass-listen (~> 4.0.0)
     sass-listen (4.0.0)
       rb-fsevent (~> 0.9, >= 0.9.4)
       rb-inotify (~> 0.9, >= 0.9.7)
-    sawyer (0.8.1)
-      addressable (>= 2.3.5, < 2.6)
-      faraday (~> 0.8, < 1.0)
+    sawyer (0.8.2)
+      addressable (>= 2.3.5)
+      faraday (> 0.8, < 2.0)
     terminal-table (1.8.0)
       unicode-display_width (~> 1.1, >= 1.1.1)
     thread_safe (0.3.6)
@@ -248,7 +248,7 @@ GEM
     tzinfo (1.2.5)
       thread_safe (~> 0.1)
     unicode-display_width (1.5.0)
-    yell (2.0.7)
+    yell (2.1.0)
 
 PLATFORMS
   ruby

_css/main.scss

@@ -37,6 +37,10 @@ canvas {
   background-color: $primary-color;
 }
 
+.lazy {
+  background-color: $divider-color;
+}
+
 @mixin keyframes($animationName) {
   @-webkit-keyframes #{$animationName} {
     @content;
@@ -55,10 +59,6 @@ canvas {
   }
 }
 
-.lazy {
-  visibility: hidden;
-}
-
 .break {
   display: inline
 }
@@ -337,6 +337,7 @@ footer {
       box-shadow: 1px 1px 6px rgba(0, 0, 0, 0.375);
       border-radius: 3px;
       border: 1px solid #d4d4d4;
+      width: 100%;
   }
 
   .project-info {

_drafts/2019-05-10-intersection-observer.md

@@ -18,7 +18,7 @@ authors: [fabrizio_duroni]
 In the last few months I worked hard to improved the page speed of my website (yeah, the one you're visiting right now). I improved all my client side code in order to be able to reach a performance score above 90 points on [Lighthouse](https://developers.google.com/web/tools/lighthouse/), the offical Google Chrome tool to measure performance, accessibility, progressive web apps compliance and more on your web application.
 One of the last thing that was contained in the report was a warning about offscreen images, like the one contained in the following screenshot:
 
-{% include blog-lazy-image.html description="intersection observer offscreen audit" src="/assets/images/posts/intersection-observer-offscreen-audit.jpg" %}
+{% include blog-lazy-image.html description="intersection observer offscreen audit" width="1518" height="193" src="/assets/images/posts/intersection-observer-offscreen-audit.jpg" %}
 
 So I followed the link contained in the report that points to a page where are contained the [official Google Guidelines about loading offscreen images](https://developers.google.com/web/tools/lighthouse/audits/offscreen-images). The main topic of the page is the [Intersection Observer API](https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API) and how it can help you to load specific content only when it becomes visible in the viewport. I found also anothe article on the official Google developer website that explains in details how to leverage the power of Intersection Observer to lazy load the images in your web applications. So as you may imagine I "accepted the challenge" (like only [Barney Stinson](https://en.wikipedia.org/wiki/Barney_Stinson) in how I met your mother is used to do :stuck_out_tongue_winking_eye:) and I started to implement the lazy load of images for my website.
 

_drafts/2019-06-15-google-play-store-publish-pwa.md

@@ -36,12 +36,12 @@ So as you can read above, a Trusted Web Activity let you integrate web content t
 
 Let's start to see the real action: how I publish my blog PWA to the Google Play Store using TWA. First of all, I created a nw android project. This was a standard Android project with minimum API level 16. This let me cover the 99.6% of the Android user base. I choosed to create an empty project without any activity/fragment in it.
 
-{% include blog-lazy-image.html description="pwa app create project" src="/assets/images/posts/pwa-app-01-create-project.png" %}
+{% include blog-lazy-image.html description="pwa app create project" width="1500" height="1236" src="/assets/images/posts/pwa-app-01-create-project.jpg" %}
 
 Then I added the TWA support as a dependecy of the app. The TWA implementation is contained inside the custom tabs client library published on [Jitpack](https://jitpack.io/ "Jitpack") (because unfortunately at the moment of this writing the custom tabs client library contained inside Jetpack doesn't have the TWA support). So I added Jitpack as repository to the project level gradle file. Then I added the custom tabs client library as dependecy inside the module gradle file. This last dependecy points to the custom tabs client library published on github and exposed through Jitpack. I had also to specify a specific commit hash in order to be sure that the library version downloaded contains the TWA support.
 
-{% include blog-lazy-image.html description="pwa app jitpack" src="/assets/images/posts/pwa-app-02-jitpack-configuration.png" %}
-{% include blog-lazy-image.html description="pwa app custom tab library" src="/assets/images/posts/pwa-app-03-java8-and-custom-tab-dependecies.png" %}
+{% include blog-lazy-image.html description="pwa app jitpack" width="1500" height="889" src="/assets/images/posts/pwa-app-02-jitpack-configuration.jpg" %}
+{% include blog-lazy-image.html description="pwa app custom tab library" width="1500" height="889" src="/assets/images/posts/pwa-app-03-java8-and-custom-tab-dependecies.jpg" %}
 
 After the depencies setup I added the TWA Activity. To do this I just had to modify the Android app manifest file by declaring a new TWA activity inside it. For the readers that are not mobile developer, the Android app manifest is a file contained in all the Android apps. Its main function is to present essential information about the application to the Android system including:
 
@@ -55,7 +55,7 @@ The declaration of the TWA inside the Android app manifest must include some imp
 * an `intent-filter` that adds the TWA to the Android Launcher
 * another `intent-filter` that allows the TWA to intercept Android Intents that open https://airhorner.com. The `android:host` attribute inside the data tag must point to the domain being opened by the TWA and specified in the `meta-data` tag. 
 
-{% include blog-lazy-image.html description="pwa app twa declaration" src="/assets/images/posts/pwa-app-04-twa-activity-declaration.png" %}
+{% include blog-lazy-image.html description="pwa app twa declaration" width="1500" height="889" src="/assets/images/posts/pwa-app-04-twa-activity-declaration.jpg" %}
 
 Now I had to establish the link between our PWA website and our PWA app. This is a two way operation because I had to:
 
@@ -79,11 +79,11 @@ Let's start from the first association, from the app to the web site. To do this
 </resources>
 ```
 
-{% include blog-lazy-image.html description="pwa app Digital AssetLink statement" src="/assets/images/posts/pwa-app-05-associate-app-to-web-1.png" %}
+{% include blog-lazy-image.html description="pwa app Digital AssetLink statement" width="1500" height="889" src="/assets/images/posts/pwa-app-05-associate-app-to-web-1.jpg" %}
 
 Then I linked this string resource statement inside the Android app manifest by adding a new `meta-data` tag as a child of the `application` tag (NOT inside the TWA declaration).
 
-{% include blog-lazy-image.html description="pwa app Digital AssetLink statement manifest" src="/assets/images/posts/pwa-app-05-associate-app-to-web-2.png" %}
+{% include blog-lazy-image.html description="pwa app Digital AssetLink statement manifest" width="1500" height="889" src="/assets/images/posts/pwa-app-05-associate-app-to-web-2.jpg" %}
 
 It is possible to test that the association from app to the website has been completed. To do this I had to:
 
@@ -108,7 +108,7 @@ keytool -list -v -keystore <your keystore jks file> -alias <your alias> -storepa
 
 With both pieces of information at hand I was able to generate a web `assetlink.json` statement using the [assetlinks generator](https://developers.google.com/digital-asset-links/tools/generator). The `assetlink.json` generated must be served from the PWA domain from the URL `<your PWA domain>/.well-known/assetlinks.json`.
 
-{% include blog-lazy-image.html description="pwa app Digital AssetLink generator" src="/assets/images/posts/pwa-app-07-assetlink-generator.png" %}
+{% include blog-lazy-image.html description="pwa app Digital AssetLink generator"  width="1500" height="888" src="/assets/images/posts/pwa-app-07-assetlink-generator.jpg" %}
 
 After publishing the `assetlink.json` to my PWA domain my app was ready to be published to the store. So I followed the standard procedure [to upload an app to the Google Play Store](https://developer.android.com/studio/publish/upload-bundle).
 If the two ways association fails, it is possible to check for error messages using the the Android Debug Bridge, by launching from the terminal the following command with the test device connected (or the emulator running).