Building Apps for African Soil
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Alternative Title |
| |
| Title of Series | ||
| Number of Parts | 24 | |
| Author | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/46560 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
EmberConf 202011 / 24
2
5
8
10
11
13
15
16
17
19
20
23
24
00:00
Linker (computing)RhombusShape (magazine)CodeMobile appBuildingMusical ensembleSoftware engineeringBuildingShared memoryTwitterComputer animationJSON
00:57
Wide area networkMathematicsMobile appProcess (computing)Self-organizationComputer programmingCartesian coordinate systemStudent's t-testIntegrated development environmentLevel (video gaming)AdditionWater vaporSpacetime
02:30
Structural loadPower (physics)Computer fileExistenceTwitterPower (physics)MereologyMultiplication signPhysical systemFunctional (mathematics)Point cloudSlide ruleFood energyFrequencyBitCartesian coordinate systemInternetworkingGraph (mathematics)ResultantTowerChannel capacityShared memoryStructural loadComputer animation
04:01
Faculty (division)Source codeMobile WebNeuroinformatikInterface (computing)Student's t-testSmartphoneMereologyComputer animation
04:56
SmartphoneWeb browserMultiplication signLimit (category theory)FrequencyUtility softwareBefehlsprozessorStudent's t-testNeuroinformatikRevision controlSmartphoneTouchscreenMaxima and minimaSoftwareInternetworkingPay televisionBit rateComputer animation
06:14
Band matrixChainInternetworkingLogical constantCartesian coordinate systemMobile appSoftwareConnected spaceBit rateStatisticsLevel (video gaming)Revision controlMereologyComputer animation
07:10
Web applicationMathematical optimizationMeasurementWebsiteSemiconductor memoryPhase transitionCycle (graph theory)Band matrixMetric systemComputer animation
07:39
Price indexBefehlsprozessorMathematicsMeasurementWeb pageInternational Date LineMultiplication signWeb browserBitElement (mathematics)Touch typingMobile appPoint (geometry)Content (media)Level (video gaming)BefehlsprozessorPixelTouchscreenData structureMedical imagingGraph coloringWebsiteSheaf (mathematics)outputComputer animation
08:55
Service (economics)Fiber bundleService (economics)ImplementationNumberTerm (mathematics)Sheaf (mathematics)Right angleFiber bundleContext awarenessServer (computing)Fluid staticsComputer animation
09:30
Fiber bundleWeb applicationMultiplication signBlock (periodic table)SoftwareCartesian coordinate systemAdditionMessage passingThread (computing)Extreme programmingFrustrationInterface (computing)Web 2.0Sound effectSmartphoneParsingResultantComputer hardwareCrash (computing)Computer animation
10:34
Mobile WebFiber bundleComputer-generated imageryContext awarenessMultiplication signFrustrationComputer fileConnected spaceSoftwareStructural loadSubsetPixelComputer animation
11:16
Structural loadLengthAverageFiber bundleCodeHeegaard splittingNetwork topologyMultiplication signCodeHeegaard splittingStructural loadBuildingDependent and independent variablesWebsiteNumberComputer fileDefault (computer science)Product (business)Cartesian coordinate systemNetwork topologyLibrary (computing)Fiber bundleStatement (computer science)2 (number)Functional (mathematics)Connectivity (graph theory)Maxima and minimaBeta functionFluid staticsStandard deviationWeb pageMereologyUtility softwarePhysical systemMusical ensembleModule (mathematics)CodeMobile WebBit rateView (database)RoutingMobile appAverageCommon Language InfrastructureVariety (linguistics)International Date LineGroup actionJava appletScripting languageComputer animation
14:31
Fiber bundleDiagramCartesian coordinate systemFiber bundleSoftwareWeb pageComputer filePhysical systemFunction (mathematics)Visualization (computer graphics)Endliche ModelltheorieModule (mathematics)Source codeRow (database)Scripting languageWebsiteInformationBefehlsprozessorMeasurementBoss CorporationContent (media)Multiplication signElectronic mailing listBootingSingle-precision floating-point formatGroup actionComputer animation
16:50
Fluid staticsArtistic renderingServer (computing)Content (media)Fluid staticsTouchscreenContent (media)Single-precision floating-point formatWeb pageArtistic renderingJava appletMultiplication signInteractive televisionConnected spaceCartesian coordinate systemMereologyStructural loadInformationServer (computing)SoftwareMeasurementComputer animation
18:13
Server (computing)Fluid staticsArtistic renderingInstallation artBitWeb pageVolumenvisualisierung2 (number)FrustrationFluid staticsCartesian coordinate systemUniform resource locatorComputer fileMultiplication signResultantElectronic mailing listContent (media)System callPasswordComputer animation
19:25
Server (computing)Fluid staticsService (economics)Graphical user interfaceArithmetic progressionSoftwareService (economics)Web pageReduction of orderScripting languageCache (computing)Connected spaceShared memoryWeb browserStructural loadMessage passingAreaDependent and independent variablesCASE <Informatik>Process (computing)Multiplication signChainComputer animation
20:36
Service (economics)Point (geometry)InformationInternetworkingCartesian coordinate systemConnected spaceMobile appMultiplication signSynchronizationAsynchronous Transfer ModeSubject indexingWeb browserWeb pageService (economics)Dependent and independent variablesCache (computing)Structural loadException handlingCheat <Computerspiel>Semiconductor memoryMoment (mathematics)ImplementationBus (computing)IntServWeb 2.0SequelOrder (biology)AerodynamicsRegular graphInstallation artClient (computing)Group actionData storage deviceComputer animation
22:52
Service (economics)GoogolCache (computing)Metric systemAnalytic setService (economics)SoftwareComputer fileMotion captureStrategy gameComputer animation
23:22
SpacetimeComputer-generated imageryComputer wormPurchasingData conversionReduction of orderDependent and independent variablesAdaptive behaviorComputer networkBefehlsprozessorCore dumpRead-only memoryMedical imagingCartesian coordinate systemAxiom of choiceMedianReduction of orderConstraint (mathematics)Operator (mathematics)DeterminantCodeBit rateKey (cryptography)Data conversionComputer wormCountingWeb 2.0Web browserSoftwareStrategy gameIntegrated development environmentSoftware developerMathematical optimizationSource codePlanningMultiplication signPurchasingSemiconductor memoryAdditionWeb portalGraph (mathematics)SpacetimeInteractive televisionDependent and independent variablesUser profileBefehlsprozessorStructural loadParallel portDoubling the cubeFilm editingCore dumpScripting languageMobile WebSet (mathematics)Computer animation
26:32
Metric systemInteractive televisionStructural loadLimit (category theory)Social classWeb pageConnectivity (graph theory)2 (number)CalculationSoftware developerType theoryWebsiteMetric systemMultiplication signConnected spaceContent (media)Medical imagingCartesian coordinate systemComputer hardwareOrder (biology)BefehlsprozessorHome pageMobile WebWeb browserNumberWeightSemiconductor memoryStandard deviationSlide ruleProcess (computing)Series (mathematics)GradientContext awarenessGoodness of fitSoftware testingDifferent (Kate Ryan album)Forcing (mathematics)Mobile appoutputTheoryPresentation of a groupComputer animation
29:31
Error messageLine (geometry)DisintegrationProcess (computing)Real numberRobotSlide ruleFiber bundleObservational studyWebsiteError messageSoftware developerSoftware testingCartesian coordinate systemGraph (mathematics)CASE <Informatik>Computer configurationStatisticsWeb pageMobile appBit rateLine (geometry)INTEGRALLimit (category theory)Content (media)ResultantArtistic renderingMathematicsAdditionProcess (computing)Data conversionVirtual machineGraph (mathematics)Boss CorporationCurveRoutingFrequencyWeb 2.0Computer animation
31:24
Web pageData conversionBit rateMultiplication signBit rateSign (mathematics)Data conversionSoftwareMobile appWave packetScheduling (computing)NavigationVideo gameComputer animationLecture/Conference
32:01
Computer animation
Transcript: English(auto-generated)
00:03
I'm a senior software engineer. I currently work at a company called Dev. You may know
00:32
it better as dev.to or at the practical dev on Twitter and at Dev I've been putting my passion for coding, learning and sharing and building
00:43
communities. If you've not heard this accent before it's one of the many South African accents. I hope that some of you have been to South Africa particularly Cape Town which is beautiful. If not I hope that you'd visit sometime soon. In addition to my job I also run a nonprofit organization in
01:03
South Africa called Casimet. Casimet is an after-school program that exposes students in under-resourced communities to STEM. Working within the environment of Casimet has allowed me to appreciate the challenges that we as Africans face and it's inspired me to firstly write this talk to share my
01:24
experiences on a global level and secondly build my own applications with performance at the forefront of my mind to compensate for the challenges that we encounter in developing communities. On this map the countries
01:41
marked in purple are developing countries. The darker purple is the higher income developing countries unlike most of Africa but they nevertheless are still developing. So why am I showing you this map? The reason is because whatever the challenges that Africa experiences at least 80% of these
02:01
developing countries there is all these countries marked in purple they experiencing it too. Which means if you don't follow your apps to cater for emerging markets these are the people that will either not be able to use your apps at all or will have difficulty using them. Living on the
02:20
African continent I have a lot of exposure to the challenges that we experience here and I'd like to go through some. So the first challenge that I'd like to outline is load sharing and load sharing is just really the bane of my existence and other Africans existence too. For those who do not
02:43
know what load sharing is it's the deliberate shutdown of electrical power in part or part of a power distributed system generally to prevent the failure of the entire system when the demand strains the capacity of the system. I think they call it rolling black blackouts in the US but it's a little
03:02
bit more impactful here. The implications of these is that there's no power for a minimum of four hours in South Africa on most days rotating around the different parts of the city. This is a graph on the slide showing the plant breakdown of energy over the two months. It is absolutely insane to
03:22
think that our plants break down as much. In other African countries like Zimbabwe and Zambia as you can see from these tweets the power has turned off unexpectedly for like around 12 hours at the time. As a result of having no power we tend to have faint and no cell phone reception because the
03:42
cell phone towers are being overused and unable to handle this increased capacity during these periods. No cell phone reception means no 2G, 3G or 4G. Thus without internet access we are unable to use full functionality of applications. Another challenge that a large portion of Africans face is
04:06
that we have very basic digital literacy and this is probably due to the reasons that a lot of public schools have no computer labs and students don't have access to computers at home either. Hence complex and unintuitive interfaces prove to be a hurdle. Data costs in South
04:26
Africa are also extremely high and they're also high in other parts of Africa. South Africa on this chart fits between China and Canada with about $10 per gig. You may say this is not too different compared to
04:42
the US. However, this is not, $10 is not proportional to the earnings of South Africans who earn at least less than 50% as compared to employees in the US or Canada. While smartphones are common in Europe and Northern America, Sub-Saharan Africa leg in ownership. In South Africa
05:05
around 51% of people own a smartphone. However, this is below the premium of 59, whilst countries like Ghana, Nigeria, Kenya and Tanzania are even lower. There is still a huge population of Africa
05:23
that uses feature phones which is more affordable than smartphones because they sell between $20 to $25. Being low cost, feature phones tend to have slower CPUs, low RAM, lower storage, older OS versions and
05:41
some of these devices can even be restricted to just 2G or maximum of 3G networks. Many contain outdated browsers and they often don't even have touch screens. Instead, they have a keypad or Dpad for navigation. At Casimax, where most of the students have either no or low-end devices, they gave go to tech hubs in the
06:04
community where their desktop computers and internet is provided. However, there is a time limit for the utilization of these computers. The internet penetration rates are between 75% globally and
06:25
in South Africa, it's about just 49% whilst other African countries like again, Ghana, Kenya and Tanzania are below 40%. The infrastructure is lacking in under-resourced communities in South Africa and other parts of Africa. Hence, very few have
06:44
constant internet access. Instead, most people end up using 2G or 3G networks where they are able, but at some times, there's no connection at all. If we look at the statistics for the top apps that I downloaded in Africa, unlike something like the Google
07:01
Play Store, you will see that light versions of applications when available always end up being at the top of these statistics. We need to optimize for fast loading performance relative to devices. This means optimizing for CPU, memory,
07:21
battery and bandwidth usage. Before diving into some of these techniques to optimize performance, let's go over some important metrics typically used to measure performance of web applications or sites. These metrics can be measured at different phases of the loading cycle. So the first
07:41
one is the first paint. The first paint marks the point immediately after navigation when the browser renders some pixels to the screen. Depending on the structure of the page, this could be displaying the background color or it could be the entire page being rendered. It simply depends on how the app was structured and how intentful they
08:03
were about performance. We want to optimize most of the page being rendered. The first contentful paint is the point when the browser renders the first bit of content from the DOM, which must be text and image or just any element. For site visitors, this time signifies when
08:22
actual content has been loaded on the page and it wasn't just like any change. The first meaningful paint measures when the page appears meaningfully complete. The first CPU idle marks the first time at which the page is maintained is quiet enough to handle input.
08:43
And the time to interactive measures when a user can consistently interact, which means touch or click with all the page elements. So in the subsequent sections, I will provide a high level overview of some techniques that we can use to optimize for performance within emerging
09:02
markets. They will include firstly reducing the bundle size, secondly server side or static rendering, the implementation of service workers and number four, just some other smaller tips. In each of these sections, we will reference the metric that we are optimizing for
09:20
and we will also give examples within the context of where applicable. So let's dive right in. In modern times, most of our web applications are heavily, heavily reliant on JavaScript and we ship so much JavaScript to users that it has become one of the
09:42
most expensive resources on the web. We bloat our applications without thinking of the cost implication on both the hardware and the network of a user's device. The consequences of loading too much JavaScript on feature phones or low-end smartphones in emerging markets are substantial. On such devices, the
10:03
JavaScript can end up blocking the main thread for a significant amount of time, thus increasing the time to interact with the application. In addition, the parsing of the extra JavaScript can result in a breakdown of that thread, causing applications to sometimes just run out of memory or hang or crash.
10:23
This leaves the user with a feeling of extreme frustration where he or she ends up clicking around the interface without seeing any effect. According to Adios Mani's article, The Cost of JavaScript in 2019, which I recommend that every person reads, he
10:43
outlines how in mobile it takes three to four times longer for a median phone like a Moto G4 to execute Reddit's JavaScript compared to a high-end device like the Pixel 3, and it takes over six times as long on a low-end device like the Alcatel 1X. Similarly,
11:02
downloading bloated JavaScript and CSS files on a slow network connection increases the first meaningful pain time thereby leaving the user with exactly the same feeling of frustration. According to Google's DoubleClick, when comparing sites that
11:20
load in five seconds compared to sites that load in 19 seconds, the faster site had 70% longer average session links, 35% lower bounce rates, and 25% higher air viewability than the slower counterparts. That's a lot of increases. Knowing that the first
11:43
meaningful paint and the time to interact is too high. If it's too high, the users will leave our site and most likely not return, how can we then reduce the bundle site? So some very simple solutions include the first one is minifying and concatenating your JavaScript build. We can improve on
12:03
the overall performance of our sites and applications by minifying our JavaScript to reduce the file size and concatenating our relevant files to reduce the number of file requests. In everCLI, we are fortunate that the JS files are already minified by default in production using broccoli-uglyify.js and
12:24
that all our files are already concatenated into just one JavaScript file. However, we can improve on this even further with code splitting. So instead of shipping all the JavaScripted ones, we can split the JavaScript by page, root, or component. This means
12:42
that we can simply ship the minimum amount of JavaScript to prioritize what a user will need and thereafter, we can lazy load the rest. So we can fetch the additional bundles either in the background when the user is idle or in response to user initiated action. Whilst we haven't reduced the overall amount
13:03
of code in apps, we have avoided loading code that the user may not use and reduce the amount of code needed during the initial load. Another common way that we end up loading our JavaScripts is by importing loads and loads of errands. We just keep throwing it in
13:22
there and libraries into our applications. Instead, we could have simply gained the same functionality sometimes by writing just a small custom JavaScript function or by importing only a portion of that library. Importing only a portion of the library is now possible with tree shaking. With tree
13:45
shaking, we can take advantage of static import statements to pull in only the specific and relevant parts of ES6 modules, hence eliminating dead code. It's possible to utilize code splitting and tree shaking from the Embroider v2 package. For those that don't
14:02
know, Embroider is a modern, fully featured Perl system that works in tandem with Ember CLI. It also newly embraces the ECMA standard for importing ES6 modules, which makes tree shaking achievable. However, it is important to note that Embroider is currently in beta
14:21
and there are some risks to be aware of it using it in production. You can read more about Embroider on the status page. You can't improve if you don't measure. So some of the tools that we can use to audit our site include the Google Chrome Lighthouse tool
14:41
for performance audits. There are three audits that will be useful to look at while we're using our bundle size, and they are very aptly named. So the first one is JavaScript boot time is high audit, and that reveals how much CPU time each script on the page will consume along with its URL. Then the
15:01
unused JavaScript audit, which reveals the JavaScript downloaded by the current page, but it shows the JavaScript that is never used. The modified JavaScript audit which will compile a list of unmodified resources that it finds on the current page. From there, you can simply take action by modifying those files
15:21
manually or augmenting your build system to do it for you. So the second one that I can think of is the Ember CLI bundle analyzer. The Ember CLI bundle analyzer analyzes the size and the content of your Ember apps bundled output using a really cool and
15:41
easy to understand visualization. More specifically, we'll be able to see which individual models make it into your final bundle. So if you look at the picture, you'll be able to see that it shows which are the different packages that have gone into your bundle. We also can find out how big each contained
16:00
module is, including the raw source, the minified, and the gsub sizes. Finally, by looking at the diagram, we can kind of see which of the packages have made it into our bundle by mistake, and then we can optimize our bundle size. The third one is bundle phobia. And so before I actually install a
16:22
bundle to my application, I'd like to know how a bundle will impact my size. Bundle phobia does this by showing the cost of an npm package by providing the information on the size of the package, how fast it downloads on 2G, and how fast it downloads on a 3G network, and what percentage of other
16:41
dependencies that package comprises of. Thus, we can then make informed decisions on whether to edit or not. Whilst JavaScript single page applications can be quite snappy once they are fully loaded, there is this time between load and
17:00
time to interact, where users are usually presented with a blank screen. This is because for single page applications, the initial document returned by the server is empty, thus resulting in an increase in the first contentful paint. So what if you wanted the best of both worlds? A
17:20
quick initial load time, but also just snappy, successive interactions. This is achievable using server-side rendering or static rendering for all or most of the popular pages in your applications. This can result in an almost instant first contentful paint, which is particularly useful for developing countries where network connections
17:42
may be unreliable. Remember that the first contentful paint, which we discussed in one of the earlier slides, measures the time from when the page starts loading to when any part of the page's content is rendered on the screen. Using this technique, we are then able to display useful information that is content to the user
18:04
instantly. When our first contentful paint is less than a thousand milliseconds, the users are really happy. When the value is between a thousand to three thousand milliseconds, so one to three seconds, users are usually a little bit
18:21
less pleased, but still pretty happy. But over three seconds, so say three to five seconds, starts causing frustration. So over five seconds, users have just completely lost interest. It's really simple to server-side render pages
18:41
in Ember. And also, all we need to do is to just use instant install a password in Ember, which actually static renders the application and allows us to pre-render any list of URLs into static HTML files at build time. As a result, the
19:00
pages can be served statically, and it has a fast first paint of the HTML content from Fastboot. So all we do is we install Ember CLI Fastboot, we install Prembo, and then we can configure the URLs that we want to pre-render. Now that it's set up, we can simply even just see the
19:22
HTML via our call. Since the most important values here was the first contentful paint, we can run the performance audit once again, and we notice how the value decreases. We see the value from the Lighthouse Chrome tools. It's great
19:44
progress that we are able to render our assets and our content optimally, especially to ease the burden of slow network connections, high data costs, and cater for low-end devices. But what about taking it one step further? Service
20:00
workers in caching can reduce users' data costs even further, and they can render pages even faster with the least amount of processing time. Not only that, but we can also render our applications offline for those for ready connections during load sharing or whilst passing through poor network areas. A service worker is
20:21
essentially a background script that runs separately from the main browser thread, responding to events, including intercepting network requests, caching or retrieving resources from the cache, and delivering push messages. The implementation of service workers is pretty simple using Ember in its add-ons. So here's a very
20:42
brief look on how to integrate service workers into our application. The Dockyard Ember service worker documentation makes it really easy. We use the following commands. So you'll see the first one is ember install service worker, which just installs a service worker when the page loads. Then we do ember install service worker index
21:02
and the service worker access cache, which essentially caches our index and HTML page and all the other static assets. So at this point, if you have to disconnect your internet connection or turn into an offline mode in our browser's dev tools and refresh the page, our actions still load. Then we can do, we can take it
21:23
one step even further where we can install ember service worker cache fallback, which then caches any non-static resources like request to the API. And just like that, our service workers would be up and running. We just need to browse the app for a few moments whilst
21:41
online and we'll essentially be priming the fallback cache. And afterwards, we can put our browser into offline mode and try to load a page that we have visited before. And guess what? It should now serve your API responses from the cache. But can we, we can make our applications even more functional. I mean, if
22:04
I think about it, when I'm without internet during times of low chatting, I not only want to view data, but I might want to fill out forms or bookmark some data, or maybe even send some information through to the application. I have the memory of a goldfish and once I
22:22
close an app, I'm really not going to remember to come back to that app. So this is where Ember Pouch comes into play for us. And it basically is data persistence. Ember Pouch allows data to sync automatically once a connection is restored. In the background, the data is saved on the client side using
22:42
IndexedDB or Web SQL and we just keep using the regular Ember data store API. Once again, in order to test our improved performance and offline strategy, Lighthouse comes to the rescue. You can see your cache files and
23:00
you can use network requests to determine where a network request, where the request is getting answered from, is it from the cache or the API. And you can also use something like Google Analytics to track metrics that will help us to assess the impact of our service welcome. Finally, we
23:20
come to other performance tips. So there are a couple of techniques that I'm not able to explore as deeply, but I'd still like to list some of them out because I believe that when they are used appropriately, they will provide better accessibility for emerging markets. Some of them include, firstly, using SPGs, we
23:41
will be able to out optimizing images by using tools like Squoosh or Image Optimizer. HTML source sets are also really useful to serve different images to different visitors. A company called FernSpace reduce the image payload by 86% resulting in a reduction in load time of 65%. This improved user experience
24:04
helps double FernSpace e-commerce purchases conversion ratio, cut bounce rates by 20%, increase mobile revenue by 7% and dramatically improve SEO. Optimizing and sending through only the
24:22
necessary keys in our JSON payloads can really just optimize our network requests in our JSON. We should serialize and compress adequately as well. In addition, adopting a technology like GraphQL would automate the optimal parallelization of data
24:40
batches, thus increasing the performance. Instagram increased impressions and user profile scroll interactions by decreasing the response size of the JSON needed for displaying comments by 33% for the median and 50% for the 95th percentile. And finally, we can use
25:03
techniques like adaptive loading to tailor the experience based on the user's constraints. Adaptive loading uses signals to determine the network, CPU, core count and memory. And based on those values, we can then conditionally load more highly interactive components or run
25:20
computationally heavy operations whilst not sending these scripts down if you're on a slower device. However, it's useful to note that the web properties that are used to determine network, CPU, core count and memory are not available via the web API to all, especially older browsers. This unfortunately does not make it
25:41
extremely useful for African markets as yet, but it is a useful technique that most likely will be used more commonly in the near future. Using all or most of these strategies that I've outlined allows us to build more efficient applications that will deliver an improved experience within Africa. However, our professional
26:02
environments usually consist of teams that include multiple developers working on one application together. Within these teams, not all developers are knowledgeable or even mindful of performance. So how do we go about proactively maintaining a code base
26:21
with the team for just optimal performance? This is where performance budgets integrated with the CI tool become really useful. So what is a performance budget? A performance budget is a limit for the pages or components which the team are not allowed to exceed.
26:41
Adil Asmani, the performance guru, mentions the three important metrics that we should use in order to incorporate this budget. The first one is milestone timings which are based on the user experience when loading a page. So things like time to interact, a first contentful page, it's that first page of metrics that I showed you when I started the
27:01
presentation. We may need to pair several of these metrics together in order to represent our full story. Then there's quantity-based metrics. So these are based on raw values. So the weight of the JavaScript, the number of HTTP requests, these are directly correlated to a browser experience.
27:21
And finally we have rule-based metrics which are scores generally by tools such as Lighthouse or WebPagetest. They often just provide one single number on a series to grade the site. Furthermore we can apply different budgets to our mobile applications, first hour desktop applications, first device classes because the
27:40
underlying hardware like CPUs and memory and the connection capabilities differ across these different experiences. So an example budget on my personal website could include something like the home page must ship less than 170 Ks of kilobytes of JavaScript on mobile.
28:03
It should include less than two minutes of images on a desktop but maybe 500 kilobytes on mobile on page load and then we can lazy load the rest afterwards. It should load and get interactive in less than seven seconds on an Android Go which is one of the more popular devices in Sub-Saharan Africa
28:22
and also maybe the score needs to be greater than 80 on a Lighthouse performance audit. These are just some examples of what I could put into my performance budget. It is useful to note that there are some standards which we can adhere to like for mid-range mobile devices with slow 3G connections, a good target for first loads is to load
28:42
the page and be interactive in five seconds or less. For subsequent loads a good target is to load the page in under two seconds. This is where the developer has the opportunity to set the precedent to be inclusive to other emerging markets. But the most tricky thing about creating a budget is usually to come
29:01
up with the performance metrics themselves. One way to do this is to use a calculator like performancebudget.io to get some baseline and then configure the budget based on your knowledge of the type of application being created as well as your target market. This here on the slide is performancebudget.io
29:20
and it's a really good experience. Once we've crunched the numbers we want to also proactively stay away from numbers, stay aware of these numbers throughout the development process. This can be done by integrating something like webpack performance hints which issues command line warnings or errors when the bundle size grows over the limit. This is
29:41
perfect for your development process. Thereafter, once we start deploying we can integrate it with the CI to automatically enforce size limits on pull requests for teams. So if the test fails we can simply prevent the pull request from being merged. Some CI options that can be used is the bundle size CI
30:01
and lighthouse bot. Finally I recommend also using speedcurve for the reactive monitoring so that we can actually monitor some real users so that we can improve based on some baseline. As a result of using
30:21
a performance budget and these integration tools, developers on the teams have performance at the forethought of their minds and hence they tune their development practices accordingly. In conclusion, yes this graph again there are really no downsides to make your applications performance. There are only benefits. A performance
30:42
application opens you up to a whole new market. This is millions of additional people. It is also a proven fact based on statistics and case studies some of which I've cited in previous slides. Their performance increases traffic to your site and keeps users engaged for
31:01
longer periods. On a fast site users are known to consume more content. Some of these changes especially server-side rendering or even static rendering allows our apps to have enhanced SEO thus increasing our leads and sign up conversion rates.
31:21
In fact a study shows that rebuilding Pinterest pages for performance resulted in a 40% decrease in wait time, a 15% increase in SEO traffic and a 15% increase in conversion rate to sign up. Finally, for every travelers like myself
31:40
PWAs are hailed life savers. I mean who doesn't want to be able to check the train schedule or navigate around a city without any network? I know I do. With that being said I hope I've now convinced you to think about performance and expanding your apps to the African soil. Why not? Thank you so much.