[{"_1":2,"_67":-5,"_68":-5},"loaderData",{"_3":4},"post",{"_5":6,"_7":8,"_34":35,"_51":52,"_65":66},"content","\n_Pairing with [@Ester Martí](https://github.com/estermv)_\n\nEveryone has experienced how visiting a web site over a slow network connection\nusually takes ages to load, making the experience very painful or completely\nimpossible at all.\n\nWhen it comes to web development, we usually tend to forget about load\nperformance focusing more on adding new fancy features. But probably our users\nare not using the last brand new MacBook Pro connected to a 1Gps network. Is\nmore likely that they are using a mid-range or low-end mobile device with a\nnetwork connection that in the best case is a 3G connection.\n\n> [In 2018, 52.2% of all global web pages were served to mobile phones.](https://www.statista.com/statistics/241462/global-mobile-phone-website-traffic-share/)\n\nSo, taking care of performance is important and one of the most resource-consuming\nis media delivery. We are going to show how to adapt the media\ndelivery based on the network connection using the\n[Network Information API](http://wicg.github.io/netinfo/). This is an improved\nversion of an experiment I did with my coworker [@Eduardo Aquiles](https://twitter.com/eduaquiles)\nas a React component, similar to what [Max Böck](https://mxb.dev/) explains in\nhis article about [connection-aware components](https://mxb.dev/blog/connection-aware-components/)\nbut in this case, using service workers.\n\n## The Network Information API\n\nThe Network Information API is a draft specification that exposes an interface\nto JavaScript with information about the device connection.\n\nThe interface consists of a different set of attributes that gives us multiple\ninformation about the network. The most relevant for us in this article are:\n\n- **type:** The [connection type](http://wicg.github.io/netinfo/#dfn-connection-type)\n that the user agent is using. (e.g. ‘wifi’, ‘cellular’, ‘ethernet’, etc.)\n- **effectiveType** The [effective connection type](http://wicg.github.io/netinfo/#dfn-effective-connection-type)\n that is determined using a combination of recently observed [rtt](http://wicg.github.io/netinfo/#dom-networkinformation-rtt) and [downlink](http://wicg.github.io/netinfo/#dom-networkinformation-downlink) values. (_[see table](#effectivetype-values)_)\n- **saveData** Indicates when the user requested a reduced data usage.\n\n### effectiveType values\n\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n

Table of effective connection types (ECT)
ECT	Minimum RTT (ms)	Maximum downlink (Kbps)	Explanation
slow‑2g	2000	50	The network is suited for small transfers only such as text-only pages.
2g	1400	70	The network is suited for transfers of small images.
3g	270	700	The network is suited for transfers of large assets such as high resolution images, audio, and SD video.
4g	0	∞	The network is suited for HD video, real-time video, etc.

\n\n### Browser support\n\nThe API does not have a full browser support yet but is [supported by the most\npopular mobile browsers](https://caniuse.com/#feat=netinfo)\nwhich are the ones where this technique will have more impact.\n\n![Browser support for Network Information API](/images/caniuse.png)\n\nIn fact, 70% of mobile users have this API enabled on their device.\n\n## Adaptive Media Serving\n\nOur purpose will be to serve different media resources based on the information\nthat we get from the `effectiveType` attribute. When we talk about different\nmedia resources it could be a completely different media, like switching between\nHD video, HD image or low quality image, the approach suggested by\n[Addy Osmani](https://addyosmani.com/blog/adaptive-serving/).\n\nIn this example, we are going to use different compression levels for the same\nimage.\n\nFirst, we need to get the proper quality based on network conditions. This is\neasily reachable using the next snippet:\n\n```javascript\nfunction getMediaQuality() {\n const connection = navigator.connection || navigator.mozConnection || navigator.webkitConnection;\n\n if (!connection) {\n return 'medium';\n }\n\n switch (connection.effectiveType) {\n case 'slow-2g':\n case '2g':\n return 'low';\n case '3g':\n return 'medium';\n case '4g':\n return 'high';\n default:\n return 'low';\n }\n}\n```\n\nImagine that we have an image server where we can specify the quality of the\nimage that we want with a query parameter **quality** as `low`, `medium` or\n`high`. Therefore we can set the quality on the `src` attribute of the images\ntags as it follows:\n\n```html\n $\"Cute$ \n```\n\n```javascript\nconst images = document.querySelectorAll('img');\nimages.forEach(img => {\n img.src = img.src.replace('low', getMediaQuality());\n});\n```\n\nIt is important to notice that the default quality set on the image is `low`,\nwhich means that devices will load first the low quality image and then if it\nhas a high-speed connection will load the better quality one.\n\nThen the JavaScript snippet above will get all the images in the document and\nwill replace the quality parameter to the appropriate one based on what the\n`getMediaQuality` function returns. If the quality is `low` is not going to do\nmore requests, but if it changes it will do two requests: one with the `low`\nquality image when the browsers parse the `img` tag and another one with\n`medium` or `high` quality when the JavaScript code is executed.\n\nThis is not ideal but it will improve load times on slow networks. But for\nmedium/high connection networks, as we mentioned before, it will make two\nrequests for each image consuming more data than needed.\n\n## Using Service Workers\n\nThe problem mentioned regarding the two requests can be fixed using\n[service workers](https://developers.google.com/web/fundamentals/primers/service-workers/),\nintercepting the request made by the browser and replacing it with the\nappropriate quality for the image.\n\nFirst, we need to register our service worker:\n\n```javascript\nif ('serviceWorker' in navigator) {\n window.addEventListener('load', function() {\n navigator.serviceWorker.register('/sw.js').then(\n function(registration) {\n console.log('ServiceWorker registration successful with scope: ', registration.scope);\n },\n function(err) {\n console.log('ServiceWorker registration failed: ', err);\n }\n );\n });\n}\n```\n\nNext, we add a listener for the fetch event, which for all the images requested\nfrom the site will append the right quality parameter using the `getMediaQuality`\nfunction created in the previous section.\n\n```javascript\nself.addEventListener('fetch', function(event) {\n if (/\\.jpg$|.png$|.webp$/.test(event.request.url)) {\n const url = event.request.url + `?quality=${getMediaQuality()}`;\n event.respondWith(fetch(url));\n }\n});\n```\n\nAnd we don’t need to specify the quality parameter on the `img` tag anymore\nsince the service worker will be in charge of that.\n\n```html\n “Cute

\n```\n\n## The code\n\nYou can find the code of this post (a more complete, clean and with fewer bugs)\non [this GitHub repo](https://github.com/estermv/adaptative-media-serving).\n\n## Further Reading\n\n- [Network Information API](http://wicg.github.io/netinfo/)\n- [Network Information API - Web APIs | MDN](https://developer.mozilla.org/en-US/docs/Web/API/Network_Information_API)\n","frontMatter",{"_9":10,"_11":12,"_21":22,"_23":24,"_25":26,"_27":28,"_32":33},"wordCount",995,"readingTime",{"_13":14,"_15":16,"_17":18,"_19":20},"text","5 min read","minutes",4.965,"time",297900,"words",993,"title","Adaptive Media Serving using Service Workers","date","2019-06-17","spoiler","Everyone has experienced how visiting a web site over a slow network connection usually takes ages to load. We are going to explore how to load different media content using the Network Information API.","tags",[29,30,31],"javascript","service-workers","performance","slug","adaptative-media-serving-using-service-workers","prev",{"_9":36,"_11":37,"_21":42,"_23":43,"_25":44,"_45":46,"_27":47,"_32":50},752,{"_13":38,"_15":39,"_17":40,"_19":41},"4 min read",3.75,225000,750,"BLoC Pattern with React Hooks","2019-02-18","About how to extract the business logic from the components of a React application using the BLoC pattern from Flutter, the new hooks API, and RxJS observables.","featuredImage","bloc-schema.png",[48,49],"react","patterns","bloc-pattern-with-react-hooks","next",{"_9":53,"_11":54,"_21":59,"_23":60,"_25":61,"_27":62,"_32":64},1619,{"_13":55,"_15":56,"_17":57,"_19":58},"9 min read",8.085,485100,1617,"SOLID - Principles of Object-Oriented Design","2019-12-07","SOLID Principles are a valuable tool to write good object-oriented software. This article tries to put some light on the subject with simple explanations and examples for each principle using TypeScript.",[63,49],"typescript","solid-principles-of-object-oriented-design","lang","en","actionData","errors"]