This content originally appeared on Web Performance Calendar and was authored by Keerthana Krishnan
There was once a farmer who wanted his chickens to lay more eggs. His friend, a physicist, said – “I can give you a solution for your problem if you have a spherical chicken kept in vacuum” Looking at performance problems in the real world often reminds me of this scenario.
Here’s a map from bsky.app/@anniesullie.com from CRuX data about average LCP scores around the world with historical data –
Although things are definitely moving in the right direction, there are large pockets of the world where users start at a disadvantage when it comes to performance metrics. Some other contributing factors include –
- Disruptions in connectivity and power outages
- Lack of infrastructure to accommodate the scale of new devices added to the network
- Increasing usage of low end android phones which take a longer time to parse and compile JS
Mobile-first markets are emerging where users have skipped PC adoption entirely and use inexpensive low-end mobile devices to connect and use the internet. But these challenges reveal the weakness of using Core Web Vitals.
If I expect the internet connectivity to take time anyway, how long will I wait before I give up on this website?
According to Anna Migas at Perf.now() 2024, the new performance metric in this scenario is patience.
Render the most important information ASAP
Make sure that the most critical info that the user is looking for is loaded first. The goal is to optimize the initial render so that the browser gets the minimum number of resources it should wait for in order to avoid presenting an obviously broken experience. In this case, the date of the next delivery is the critical data for the user so it is prioritized over order history.
Your user analytics should point you towards what the critical data is for each page the user accesses. Make sure that the user can access the MVP first before you add the fireworks.
Keep the users visually updated on the status of their requests
It is imperative that users feel in control during any interactions they have online. Make sure that users are updated with –
- What is going on
- How long it will take
- Intuitive calls to action
- What to do when an error occurs
Communicate clearly to users what the system’s state is. Present feedback to the user as quickly as possible. No action with consequences to users should be taken without informing them.
Take into account the digital literacy of the target user and use simple terms that the user is already familiar with. Follow real-world conventions, making information appear in a natural and logical order, especially when explaining the consequences of actions or requesting a call to interaction from the user. Here’s some great design rules on how to do this.
Discourage damaging actions
In situations with poor connectivity, sometimes users may lose patience and engage in dangerous behaviour. Ex, multiple clicks to submit a form that can reset the values before the backend has finished processing. Make sure your design and testing process accounts for these and prevent the users from doing dangerous actions that cost more bandwidth in the long run.
Ex: Not allowing a user to log out of a web application while it’s updating data.
Leverage methods to reduce number of requests
The HTTP Cache’s behavior is controlled by a combination of request headers and response headers. In an ideal scenario, you’ll have control over both the code for your web application (which will determine the request headers) and your web server’s configuration (which will determine the response headers)
With back/forward cache (bfcache), instead of destroying a page when the user navigates away, we postpone destruction and pause JS execution. If the user navigates back soon, we make the page visible again and unpause JS execution. This results in a near instant page navigation for the user.
When an app requests a resource covered by the service worker’s scope, the service worker intercepts the request and acts as a network proxy, even if the user is offline. It can then decide if it should serve the resource from the cache using the Cache Storage API, serve it from the network as if there were no active service worker, or create it from a local algorithm. This lets you provide a high-quality experience like that of a platform app, even when your app is offline.
Utilize resource hints properly
Resource hints, when used correctly, can decrease the number of round trips needed to load the resources in your website. I highly recomment Paul’s talk at Perf.now() 2024 where he dicusses these instances in details but here is a quick overview some of the common mistakes you can make with resource hints –
- If you omit the
crossoriginattribute, the browser opens a new connection when it downloads the font files, and doesn’t reuse the connection opened with thepreconnecthints. For example, if you are using a Google Font,
<link rel="preconnect" href="https://fonts.googleapis.com"> <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
- Use the correct
asattribute when loading a resource
<link rel="preload" href="/font.woff2" as="font" crossorigin>
- Use
preloadsparingly. Resources downloaded using the preload directive are effectively downloaded at high priority, and—if overused—preload may create bandwidth contention in a way that negatively affects page load speed.
- Rely on your analytics or other data sources for your website’s usage patterns to decide for yourself if using
prefetchis a good idea.
<link rel="prefetch" href="/next-page.css" as="style">
- Use
preconnectfor a domain used in the same page, otherwise, usedns-prefetch
Optimize optimize optimize (your resources)
It’s way out of scope in this article to outline all the ways to optimize your resources. Images are usually the biggest culprits. Optimizing the different resources like stylesheets, fonts, videos and others with techniques like compression and minification goes a long way in reducing package sizes. Here’s a link to an article about image optimization techniques.
Summary
Improving performance is a constant journey more than an end point. It will impact users not only in global pockets that are at a disadvantage, but also anyone in rural areas with limited access as well as those who use old/ low-end devices.
As the internet becomes more critical in everyday life, access to goods and services in reasonable time is becoming a critical requirement. These strategies are simply a jumping off point to this discussion.
If all else fails, test your application in low network speeds on some crappy devices and see how you can improve that experience!
Acknowledgements to Paul Calvano, Anna Migas, Addy Osmani, Annie Sullivan and the peeps at web.dev whom I have referenced and linked in this article
This content originally appeared on Web Performance Calendar and was authored by Keerthana Krishnan
Keerthana Krishnan | Sciencx (2024-12-31T19:50:02+00:00) Designing websites for bad performance. Retrieved from https://www.scien.cx/2024/12/31/designing-websites-for-bad-performance/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.