By
Building a performant website has become increasingly important in the last few years. The challenges even for small websites can be tricky to overcome. Performance requires very careful consideration and planning for large-scale websites spanning thousands of pages.
Overview
Good web user experience is about good design. It’s about making sure that we make a web user interface easy for people to make sense of, that we reduce clutter and noise, and that we make experiences that reflect whatever brand the business needs to communicate.
What people see isn’t the only part to the overall experience. We also need to think about page responsiveness and speed. Timely response has always been a thing in web UX design, but this was more often about providing cues that something was slow to load than it was about making that thing fast to load in the first place. Spinners, progress bars and warning messages rather than just making things faster in the first place.
服务器和后端响应时间是一个巨大的堵塞leneck for older, poorly cached websites where slow server-side code and huge database queries regularly hampered performance to the point where sites would become unusable. By comparison, slightly large image sizes or bulky css files paled into insignificance.
As web frameworks and web infrastructure have improved, the emphasis on frontend performance has increased. A huge factor was the advent a few years ago of Google’sPageSpeed Insightsand theincreased importance placed by Googleand other search engines on frontend performance for search results. Mobile device user experience became hugely important.Web Vitalsis a core part of this, and is “…an initiative by Google to provide unified guidance for quality signals that are essential to delivering a great user experience on the web.”
At Kent we have a very large overall website: many thousands of pages spanning multiple possible page layouts and functionality. We have employed a range of techniques to help us have more performant pages, particularly on key pages of the site. Details are below.
Images
TL;DR Images were a big problem for website speed, but that’s much less the case now.
Probably the biggest single issue with frontend website performance over the years has been images. Huge 4MB type things that would take ages to load. Mercifully for some years now most content management systems have taken care of automatic image resampling and resizing. The problem still remained, however, that images were built into the core of HTML, and would get loaded as part of the initial page load. So images further down a page would still need to be loaded, often pointlessly. All modern browsers now recogniseloading="lazy"so that problem has largely vanished.
Another issue was image resampling. JPEGs have long been the mainstay of websites. A newer standard – WebP – was introduced by Google over 10 years ago, and aimed to improve compression while keeping quality. Again, modern browsers have no problem with WebP so currently this is a no-brainer for performance. Relatively simple workarounds exist if you still need IE support.
Fonts
TL;DR There is no brilliant solution to this, just a few alternatives that are ok. Do you want users to see a flash of nothing, and then the right thing? Or a flash of the wrong thing, and then a jank as the right thing loads? That, essentially, is your choice.
Fonts are a key component of any website’s brand, but need to be loaded very quickly if we’re to avoid annoying jumps or changes to the user experience. Sadly, fonts can also be quite large. By the time you’ve included a standard, bold, italic, bolditalic for two or perhaps three brand fonts…
At Kent we’re fortunate to have only one type of font, but we need 400, 700 and 900 sizes. We’ve decided not to bother with any of the italics versions. Italics are used occasionally in text on the website, but it isn’t part of the core brand. The browser does a good enough job on those rare occasions it is used.
We load the fonts inline as part of our above the fold inline CSS. The fonts get loaded very early and we rely on FOUT to display a system font for a fraction of a second until the brand font is loaded. This gives us good results for layout shift (CLS) while making sure users get to see something very quickly. We tried preloading our fonts to get them to load even earlier, but really this didn’t give any better results.
CSS
TL;DR Ugh. This is complicated…
CSS perhaps poses the biggest problem for performance.
The whole point of this is to try to reduce the size of your CSS file(s) and to make more efficient CSS. This is not too bad if you have a simple site with a few pages, but much much harder if the site’s complex and large.
One issue to deal with is that Google Lighthouse performance audit will often tell you to…Reduce Unused CSS. It’s an easy thing to list in a series of audit checkboxes, but as Chris Coyierpointed out,this is a hard problem.
Yes there are tools such asPurifyCSSto help. Yes, CSS frameworks like Tailwind make sure your built CSS only contains the classes that are used in your HTML code.
However… in a way these miss the point, which is that on large complex websites you may have a lot of freedom about what components web editors might use on a page, and a lot of potentially unused but potentially useful CSS, depending on context.
For example on the Kent website we have 7 key brand colours. We therefore need to make sure that a range of panels and components can switch easily between these 7 colours. For any given dynamically built page in the CMS, we never know which range of colours might be used. So we have to include all 7 in the CSS. If an editor only chooses blue, we have the other 6 sitting there in the CSS, redundant.
The Lighthouse audit also is bad at working out what css is used at different breakpoints. You’ll likely have a lot of redundancy of CSS because of this. Not because of poor design or implementation, but simply because different breakpoints need to look different.
We could build the CSS based on exactly what’s published on a page, but we’d have to rebuild the CSS for each page. Add to that the fact that we have a very large number of optional components, colours, shapes, etc over many thousands of pages, and the problem gets very, very hard very quickly.
We have tried to use a solution which loads css for specific, larger components on a page as the users scrolls near that part of the page. This way we minimise the CSS that might be redundant on a page, or isn’t used at first load.
Above-the-fold CSS
TL;DR Inline CSS for very fast first experiences.
The key to optimized css is to realise that anything the user might see as the page first loads needs to be loaded very early. Basically the only reliable way to achieve this with your CSS is to load it inline. This guarantees it gets processed very early in the page lifecycle.
You therefore need to split your css into at least two sets.
- CSS用于折叠线以上内容。这个CSS需要s to be loaded very early on in the page load, and needs to be loaded very quickly. So it’s loaded inline in the
using a