未加星标

What is an App Shell and Do You Need One?

字体大小 | |
[系统(linux) 所属分类 系统(linux) | 发布者 店小二05 | 时间 2019 | 作者 红领巾 ] 0人收藏点击收藏

What is an App Shell and Do You Need One?
What is an App Shell?

Serving fast web pages is a combination of art, development best practices and sleight of hand. This means you don't always need to load and render the full page initially.

Of course, your primary goal with a webpage is to give the user what they want and speed if a huge factor determining if you reach that goal.

You can load the 'important' parts of the web page first, providing a good first impression, and then load the balance of the page. The balance being copy, images, styles, scripts, etc.

Of course you can lazy load page assets , but there is an additional technique you may want to employ, an 'App Shell'.

App shells are nothing new. They really originated with the rise of single page applications. You may have heard them called core sites, which is the term I typically used.

Today they are gaining additional attention with progressive web applications. Part of this is due to the misconception that PWAs are SPAs. This does not mean your progressive web app can't benefit or use the concept of an app shell, it can, but you need to determine if it is the right strategy for your site.

The challenge is to determine what should be loaded initially and what can be lazy loaded.

Which of the following describes an App Shell?

It comprises of all page elements which are dependent of the specific page contents It discourages caching of content that overlaps across pages of the website It provides a fast first impression gracefully transitioning to a fully loaded page None of the above

The answer is it provides a fast, first impression gracefully transitioning to a fully loaded page.

The key there being 'gracefully transitioning' to the full page. You must be careful because some assets trigger rerendering and page refreshes. These are not graceful, they are jarring experiences.

The primary reason you want to utilize an app shell is to give the perception of a faster page load. I think the first thing you need to determine is does your web page need an app shell or not ?

Does Your Website Need an App Shell?

App shells are about perceived speed. We know when a page takes too long to load visitors either leave or get anxious. Either way it is not good for you when your page is slow.

While many developers stop measuring page speed withtime to first byte, the majority of time to render a page is after the TTFB.

The shell technique is way to reach a perceived rendered state as quickly as possible. Since the average web page takes 22 seconds or more to render today many sites might benefit from using an app shell.

I recommend measuring your page's actual speed and determine how long it takes to reach time to first interaction. This is when your page can be scrolled and interacted, which means the user is happy.

If the page takes longer than 5 seconds an app shell might be helpful. At the same time, use the reports provided by these tools to determine if there are other areas that should be addressed, like excess javascript .

If you are using a fast food framework like Angular and React you must use an app shell because these frameworks are so slow. So far, my experience with these frameworks is the way they are taught to developers is to use a overly empty application shell, which defeats the purpose of the shell rendering content fast.

The App Shell Skeleton

In its simplest form an app shell is the page or site's main header, footer and navigation. You can make it more encompassing, but that all depends on your site's layout.


What is an App Shell and Do You Need One?
App Shell Primary Components

The dynamic part of the app shell is what I call the page canvas, not to be confused with the CANVAS element. I call it that because it is simply a placeholder for the page's main content.

At some point in the page life cycle the primary content will be added to the rendered app shell to create the full-page experience.


What is an App Shell and Do You Need One?
Competed App Shell

But there is more to the core shell than just markup, There is also the hidden assets like CSS, scripts and images. For stylesheets and scripts I like to inline these to make them render really fast.

How An App Shell Helps Page Speed

Since the app shell should be very small, you can typically inline the required CSS and scripts along with the shell markup and be comfortably within the 14kb data packet size.

Why 14kb?

TCP works using a concept of 'slow start'. When you request a file using TCP/IP, like a web page, the content is returned in a series of data packets.

The first packet is 16kb, the second packet 32kb and this continues to increase up to roughly 4MB or so.

The first 2kb of the data packet is overhead data, which is not data or HTML in this example. So when you can contain your page's critical content within 14kb you only need a single packet and a single round trip. This means the network time is minimized as much as possible.

Gzipped HTML can compress tightly, which means you can even serve somewhat large files within this 14kb goal.

By inlining 'above the fold' CSS and scripts you are also eliminating extra file requests. Since more pages only use 2-5% of the CSS they load, think Bootstrap, you can optimize your shell's CSS using a tool like uncss.

I use this technique on every page in this site. It has really helped my page speed time and thus my SEO.

I won’t get into the details of applying the concept to JavaScript because that can get fairly complicated and spark a religious war LOL. But you can do that as well, it just takes planning.

Because a typical app shell can not only fit within the magic 14kb it provides the common user interface for the page or application the user see this render quickly and perceives the page is working and should relax and give you the extra seconds you need to complete the full page render.

What Does an App Shell Look Like?

Like I said you want to minimize the amount of markup and assets required to render an app shell. In its most basic form it would look something like this:

<!DOCTYPE html> <html lang="en"> <html> <head> <meta charset="UTF-8"> <title>title</title> <meta name="description" content="..content here..."> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <link href="favicon.png" rel="shortcut icon"> </head> <body> <!-- main content goes here --> </body> </html>

If you apply my inline technique I described in the previous section it would look like this:

<!DOCTYPE html> <html lang="en"> <html> <head> <meta charset="UTF-8"> <title>title</title> <meta name="description" content="..content here..."> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <link href="favicon.png" rel="shortcut icon"> <style>[inline styles, minified of course]</style> </head> <body> <!-- main content goes here --> <script>[inlined minimal script, minified of course]</script> </body> </html>

The only difference is inlined styles and scripts.

I will note, I typically use the inlined script to dynamically or lazy load scripts and extra CSS. Sort of a controlled asynchronous loading mechanism.

This example shell is very barren. This is not where I typically leave the story. I also include basic header, footer and navigation markup.

<!DOCTYPE html> <html lang="en"> <html> <head> <meta charset="UTF-8"> <title>title</title> <meta name="description" content="..content here..."> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <link href="favicon.png" rel="shortcut icon"> <style>[inline styles, minified of course]</style> </head> <body> <div class="main-header"> <div class="navbar"><!-- main navigation here --></div> </div> <!-- main content goes here --> <div class="main-footer"> <!-- footer content here --> </div> <script>[inlined minimal script, minified of course]</script> </body> </html>

What your shell includes is up to you. But I recommend carefully evaluating how different parts of your layout are used across multiple pages.

Here are some of my app shell best practices:

Inline Primary CSS Include Primary Navigation Include common header and footer markup Use a pre-rendered layout with content placeholder Minimize JavaScript & CSS impact during page rendering cycle
What is an App Shell and Do You Need One?
App Shell Critical Path Assets App Shells and Progressive Web Apps

Many think progressive web applications must have an app shell. This is not true but can be beneficial.

I think the real key to determining if you need an app shell in your PWA is to decide how much dynamic application functionality does your app have?

Are you mostly static content, like my site, or are you dynamically updating the same area over and over in response to user activity. And is that dynamic content truly rendered from fresh data or is the content relatively static?

What I am getting at is don't think your PWA requires an app shell. Implementing a true app shell is not a trivial task.

You also need to realize progressive web applications are not single page applications. They can be, but do not have to be.

Single page application architecture benefits from the concept of an app shell and this is one of the reasons why they require so much client-side JavaScript.

But I tend to think PWAs and service workers can in essence replace the primary tasks SPAs require because the service worker can now be used to render web pages on demand, without accessing the network.

App Shells and Service Workers
What is an App Shell and Do You Need One?
App Shell & Service Worker

A more advanced technique I use in some sites is to render a page in the service worker. I demonstrate this in my Progressive Web Application book and in thePhilly Code Camp PWA.

The basic idea is to hold a cached copy of the page's app shell in the service worker cache. When the page is requested you can follow one of several workflows to compose or render the actual page within the service worker.

For the Code Camp application I used this technique to dynamically render the schedule and session details. This was a good choice because the event's schedule data was not very large, so it could also be cached when the application was first accessed.

self.addEventListener('fetch', event => { if (event.request.mode === 'navigate') { // Always respond to navigations with the cached app-shell.html, // regardless of the underlying event.request.url value. event.respondWith(caches.match('app-shell.html')); } });

You can think of this technique as moving the rendering pipeline from the traditional server engine like ASP.NET orphp to the service worker.

Best practices with these type platforms is to maintain 'master pages' and 'includes' that contain common markup used by multiple pages. For developers this means there is a single source of code that needs to be maintained and you rely on the rendering engine to compose the final page markup.

The typical way pages are composed on the server is to retrieve data and then merge it into page templates, including merging page components together to create the final HTML returned to the browser.

That is essentially what the code camp app is doing, just inside the service worker. This means the request never needs to hit the network, making the PWA completely self-contained.

Is the App Shell the Best Solution?

As with all things technical, it depends.

I typically don't use app shells for content pages, like this blog. But for a real application, like a line of business application, it makes more sense.


What is an App Shell and Do You Need One?
Should You Use an App Shell

I like to think of an app shell as a canvas to paint the interactive story that is the application experience. The shell provides the common accoutrements required to make the application multi-dimensional and not limited to a single monolithic process.

Don't limit your shell scope to just navigation and logos, you need to think about possibly multiple shell combinations. Different parts of your application may have common tools or sub navigation features. What you need to think isolate is what is unique to a specific page and what is common across two or more pages.

Isolate the common functionality to layouts and components and use these to compose a shell. Maybe you have the top-level shell defined and render that first, then add layouts and common components in steps, as soon as they are available.

The only thing I recommended is testing your overall experience on low powered devices with network constraints. This will make sure your user experience is optimized and not janky. I recommend this for any web development, but when you are building the page in pieces this becomes more important.

Do not feel you must have an app shell. In fact, I would argue in the modern web, where a service worker is used, you can probably by pass this technique, at least for most websites. Instead you can use the service worker to compose the page and cache the response for future use.

If organic search traffic is important , then an app shell is not your friend . That's because Google wont bother executing the JavaScript it takes to render your page's content. You need the content to be instantly available, not just the app shell.

As always, the simplest solution is probably the best solution for most sites. App shells add complexity to websites, so you want to be careful before you use this technique.

本文系统(linux)相关术语:linux系统 鸟哥的linux私房菜 linux命令大全 linux操作系统

分页:12
转载请注明
本文标题:What is an App Shell and Do You Need One?
本站链接:https://www.codesec.net/view/628405.html


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 系统(linux) | 评论(0) | 阅读(42)