 I'm Vadim Sapitsky, I'm a VP of Engineering at Forbes, and I'm gonna talk about how we rebuild our mobile templates, how we optimize them, and what challenges we face along the way. So first I'm gonna showcase the high-level architecture of our website and publishing platform. So here you can see that WordPress and other CMSs, video and media kind of publishing is happening here, and all the data and events get pushed to our APIs. Now APIs process that data and convert it into messages and push it to the queues. On the other hand, we have mules, which are services that we use to process the data, convert it to specific types, and then we store it into MongoDB and our solar index. So that's the publishing platform architecture on the high level. And then on the front end, pretty straightforward, again API connects everything all the data, it gets the data from MongoDB and solar index, and on the front end, we render the templates using Node.js server. What challenges are we facing overall with our mobile templates? Well, we have a lot of them, and we surface them on a lot of different platforms. Platforms like AMP, Apple News, Forbes Canonical templates, as well as Facebook Instant Articles. And that many platforms introduces problems and issues to support. It increases time to market, it requires more developer time, requires more QA time, also between the templates, there are some inconsistency, potential inconsistencies, and it increases probability of bugs. So the solution we came up with was to combine our Canonical Forbes mobile templates with AMP. And we created something that we called AMP+. So what's AMP+, and why did we create it? Well, originally we wanted to go with Canonical AMP, but we realized that we need a few features that our stakeholders require that AMP Canonical does not support yet. So what we did, we used 95% of AMP templates, and AMP components, and AMP features, and their performance optimizations, and then we added a few features of our own. Those features were our custom add implementation, as well as our custom infinite scroll. So what technologies did we use for to create our mobile templates? One, we use Node.js as I mentioned before for server-side rendering. We use Express server as a server. We used Docker to make it easy to deploy. We used AMP libraries and components for simplicity and for performance, and we used vanilla JavaScript Node frameworks to add custom features that were required by the stakeholders that AMP did not support at the time. And we also focused on performance. We had to make sure that our new mobile template was a lot more performant than the legacy one. And here I'm gonna illustrate how it did, how it performed. You'll see that it renders much faster. Start render time is more than a second faster than the old one. Time to interactive is much faster, as well as full page load is also much better here. But it came not without challenges. As you know, on Google, AMP pages render extremely fast. And the reason that that happens is because Google pre-caches everything. All the critical AMP libraries are pre-cached. All the content, everything is pre-cached. And by the time you go to the actual article page, it's all there, it's instant. But when you run it locally on your own domain as a canonical AMP, it's not as fast. The reason for that is that for AMP page to render, it needs the critical AMP library to be already loaded. And only then, or if eight seconds passes, then it will show up to the user. We couldn't wait that long and we had to optimize it. So what we did, we removed the visibility hidden from the page layout right away. And what it allowed us to do is to show the page to the user as soon as it rendered. As soon as the server rendered the page, it was visible. So that optimization was critical for us to run AMP canonical or AMP plus on our domain. And here I'm gonna showcase the difference between unoptimized AMP on your local domain and AMP or AMP plus with optimizations. As you can see, at least half a second improvement for start render because we are not waiting for the critical AMP libraries to load. We just show what server rendered right away. There is more, we implemented more optimizations here. And one of them is to preload or prioritize the critical assets on a page. Load them as fast as high as possible. All you need to do to get that optimization is add one meta tag called preload with a specific asset and it will show up as fast as possible. The browser will prioritize it. It's a very easy improvement and fast and you'll see a huge difference on your site. So here you can see without preload on my test page the AMP library loads as number six script. And if I add that and prioritize the script to load faster, the browser, in this case Chrome, will load it as a second highest request on the page right after the actual page itself. You can do the same with images. For example, if you have a hero image or featured image on a page, you should preload it and prioritize it so the user sees it as soon as possible. The same you can do with custom fonts that are critical to the user if you wanna render a headline that requires a custom font preloaded. Here's an experiment that I ran. There are two different basically pages. They render three images one at the same time and on the other one I prioritize the third image to load first. I basically tell the browser I wanna see the image number three as the first thing on the page. And you'll see that that's exactly what's happening. So you have the power to orchestrate how your page loads and you can optimize your page load any way you want with minimal dev involvement. You just add a meta tag to the page and it changes how the layout happens. So here you can see a canonical AMP page non-optimized versus the optimized one. And the only difference here is two meta tags to preload hero image and to preload AMP critical libraries. So you can see that the optimized one loaded much, much faster. And that's about it. Thank you. Thank you.