google / oodle-demo Goto Github PK
View Code? Open in Web Editor NEWOodle - an unofficial Google Doodles web app
Home Page: https://oodle-demo.firebaseapp.com/
License: Apache License 2.0
Oodle - an unofficial Google Doodles web app
Home Page: https://oodle-demo.firebaseapp.com/
License: Apache License 2.0
Looking at the network panel for the initial route, we see two references to Web Font files. Both of these are referenced from gstatic:
some of our web fonts are flagged in the Lighthouse render-blocking stylesheet audit, delaying paints by ~1.5s:
Lighthouse's text visible during font-loads audit passes as well:
What are things we want to do here?
'Montserrat', sans-serif
appears to be in use for most of our text. Worth dropping Roboto entirely?font-display
on it ourselves? Per CSS Tricks "If you embed fonts using a third party service like Google Fonts or TypeKit, there's not much you can do at the moment. Third party services control the content of a @font-face they host, so perhaps consider hosting your own fonts"References:
<link rel="stylesheet" href="https://fonts.googleapis.com/icon?family=Material+Icons">
<link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Roboto:300,400,500" type="text/css">
<link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Montserrat:400,600|Teko:300,400,500,600" type="text/css">
<script src="https://use.fontawesome.com/releases/v5.0.10/js/all.js"></script>
Dropping Roboto will reduce the paint delays down to 740ms:
I spent the evening investigating ways to improve how quickly we load (which might affect some of the slides we still need to tweak like preloading).
The current version of our app in development
scores as follows on 3G/Moto G4 on WebPageTest:
https://www.webpagetest.org/lighthouse.php?test=180426_QT_fb3fc55d0f626c1dae9c0aaeef69a394&run=3
which is a little worse than our local tests have shown (but is expected).
To try bringing these numbers down before Friday, I'm going to try the following this morning:
From the development branch:
There are two possible fixes here: we can deploy to Firebase or GCP which will gzip by default. We'd need to do extra work to enable Brotli.
Deploying the app to Firebase we're able to pass this audit:
Deployed development to https://doodles-test.firebaseapp.com/
Perhaps we..
https://developers.google.com/web/tools/lighthouse/audits/blocking-resources
This might be a tricky one as a lot of the Doodles here are powered using JavaScript. We could have a fallback story that relies on <noscript>
for Doodle image versions instead as an MVP.
If we had time to do something more clever, we could aim for Puppeteer serving a server-rendered version of each page, but we might not have time for this (I could see the noscript
version taking an hour or two otherwise).
Filing an issue for us to think about this in a while.
Roughly:
If we're going to use Firebase for hosting, we can set our caching headers as follows https://firebase.google.com/docs/hosting/full-config#section-full-firebasejson
From @devnook
I'd like it to be our "offline strategy" take, like a Downosaur or a PWA offline crossword from Guardian, as in "hey, you have no connection, but you can at least play this!". We could touch a bit on PWA offline responsibility point, e.g. that it's not a great idea to save ALL the doodles to the user's device memory.
I like this idea. We just need to remove the links to the game from the main navigation and setup the particular path as what we offline. We still need to add in Workbox somewhere to accomplish this.
Unfortunately, Firebase Hosting's Brotli experiments got switched off. As GCP doesn't really support this either, our best bet might be using Cloudflare for Brotli just to show off the improvements with it.
Reminder: https://twitter.com/dassurma/status/924346557864054785?lang=en
Alternatively, we could just stick with gzip and remind folks that many large companies have managed to see strong wins with Brotli (e.g LinkedIn improved page load by 7% with it in India).
Another stat:
According to Http Archive data stats, for mid-Match'18 brotli replaced gzip in more than 15% responses. More and more CDNs and services (e.g. BunnyCDN, yandex, jsdelivr, addtoany) support brotli encoding.
This thread is to share design assets in case we need them for the future.
This should be fun ๐ฅ ๐ Consider these all bad ideas. We can keep adding to the pile and see what we like @devnook
The app doesn't content a lot of graphic design in the homepage. What I love about the current version is it's very Google.com like in simplicity. The downside is that it doesn't contain too many images we could optimize ๐ We could introduce an image header, similar to what is done for blog.google:
The app currently doesn't have a logo. If we didn't want to go for the image header approach, we could use a logo (uncompressed, too large) and use that to talk about optimizing images and remind folks to consider SVGs.
As a note: We're not allowed to use "Google Doodles" or "Doodles" in our app title but might want to come up with something short and fun before I/O. e.g "For legal reasons, this app is called Oodles because its oodles of fun and doesn't get us fired, which is also oodles of fun".
The way you've currently implemented the carousel is clever in that we don't go preloading the rest of the carousel entries ahead of time. One thing that could be optimized is the main Doodle that gets iframed in as interactive. If it's loading a lot of third-party content, we could suggest folks render a static image of the third-party content with "click to start".
We don't have a lot of editorial content in the app right now. If we wanted, we could have one or two "featured" Doodles where we even pull in some of the Google-created content for those games. One example is the content for the "Doodles Halloween" experience, which had lots of larger images:
https://www.google.com/doodles/halloween-global-candy-cup-2015
In the "browse by year" views, I've used the images returned by the JSON feed for each year's list of Doodles. We could do something where we lazily load those in that are below the fold (or say, only load in the top 3-4 and lazy-load the rest) if we think it would improve performance.
Some Doodles include a preview in an animated GIF form. We could use this to highlight how an MP4 using <video>
would have been more efficient (and we'll have a Lighthouse audit for this in time for the talk).
A common performance issue I see is folks embedding YouTube videos, which, while they don't autoplay can still load a lot of JavaScript in. We could show how to just use a static screenshot of a video with click-to-view to avoid a user paying for this upfront.
Starting from the development branch.
npm run dev
Our CSS is unminified, which Vue will do when we run a production build. Lots of unused CSS too (left over from MDC):
If we look at our theme file, we see that we're still importing MDC styles, which are bloating up the build:
/* theme.scss */
$mdc-theme-primary: #212121;
$mdc-theme-accent: #41b883;
$mdc-theme-background: #fff;
@import 'vue-mdc-adapter/dist/vue-mdc-adapter.css';
I don't think we're using these styles any more so let's drop them.
Our application CSS goes down to under 10KB:
Looking at our application again, the only real style change is there's a background color and different arrows in the slider:
We can introduce these back ourselves without requiring all of the MDC library.
We have almost no unused CSS and our CSS is minified since we ran it through npm run build
:
We can bring back this styling (roughly) in just a few extra lines of CSS we stole directly from MDC:
Unused styles are still minimal:
Overall we shaved 184KB from our CSS bundle just be remembering to remove resources we didn't really need any more. When in doubt, we can just use the exact styles we want from a library.
I thought it could be useful to take a look at how well some of the current Google Doodles perform and what performance opportunities they might have (in case we were going to import one or two directly).
Feel free to comment or add to these @devnook. Mostly looked at these out of curiosity :)
https://www.google.com/logos/2016/halloween16/halloween16.html?hl=en
Lighthouse
JavaScript Boot-up Time is high - 12s. TTCI takes 12s which aligns here.
Interestingly, even with the newer audits, little else was flagged. This is primarily due to the game not loading in the rest of the content until you hit play.
Site: https://www.google.com/logos/2015/ponyexpress/ponyexpress15.html?hl=en
WPT: https://www.webpagetest.org/result/180330DX26ade93eaa73b00353dcacee844ef9ee/ (LH audit failed)
As soon as you hit play, 2.6MB of content is requested overall.
2.5MB of these are images
The largest sprite is 634KB.
Code coverage tells us that 37% of the JS isnโt used upfront:
This stays steady of about 30% unused as we play the first level, so we could shave off about 10KB on the compressed bundle.
Most of the time spent on the main thread is in JavaScript
On mobile using real-world CrUX data, we see that Doodle-site content has an average FCP of 1.9s and there are plenty of opportunities to optimize content being loaded from this part of the site.
takeaway: If we're going to embed Pony Express, I'd suggest that we do the minimal amount to improve page load time before you press play, but note that after that it is a game and they appear to have done their best to compress assets. They probably could have broken up some of those sprites a little further but I don't know that we should spend as much time on that.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.