pexels

The Baseline For Web Development in 2022

There have been many developments in 2021, but none were as momentous as the formal retirement of Internet Explorer (IE). There are no compelling reasons to continue to support Internet Explorer. However, this raises a new issue: Internet Explorer was the support baseline for many programs. Because IE’s development ceased a long time ago, the web standards it supports differ significantly from those supported by contemporary browsers. From using development to utilization of online automation testing platforms, the web development companies have adopted new strategies to keep up with the upgradations.

Internet Explorer is no longer supported by some of the most popular websites on the Internet.

Following Microsoft’s announcement, numerous other projects began to abandon support for Internet Explorer. Sites that the majority of internet users visit are among them.

In October 2021, for example, Google no longer support Internet Explorer.

JAPAN announced in September 2021 that Internet Explorer would no longer be recommended in Japan (website in Japanese).

Furthermore, WordPress, which is utilized by around 33% of the Internet, declared that in WordPress version 5.8, which will be released in July 2021, support for Internet Explorer would be removed.

There’s a reason why the announcements mentioned above didn’t wait until after Internet Explorer’s official demise. IE’s market share fell dramatically in 2021.

The current market share of Internet Explorer is less than 0.5 percent worldwide. Even in Japan, where IE has a larger market share than other countries, IE’s market share is only about 2% and falling.

Since Internet Explorer is no longer available, that baseline has become hazy. So, by examining the present state of our users’ gadgets, I’ll take on the duty of setting a new baseline.

Devices & Browsers Used By Users

The percentage of users who use certain browsers and operating systems. Let’s look at the market share of browsers in a different way.

As per the global market share:

  • Chrome stands at 64.06%
  • Safari stands at 19.22%
  • Edge stands at 4.19%
  • Firefox stands at 3.91%
  • Samsung stands at 2.80%
  • Opera stands at 2.34%
  • UC stands at 0.94%
  • Android stands at 0.67%
  • IE stands at 0.49%
  • Other stands at 1.36%

And as per the Japanese market share

  • Chrome stands at 49%
  • Safari stands at 30%
  • Edge stands at 10.50%
  • Firefox stands at 4.41%
  • IE stands at 2.22%
  • Samsung stands at 1%
  • Android stands at 0.70%
  • Opera stands at 0.52%
  • 360 safe browser stands at 0.34%
  • Other stands at 1.24%

The following are the points and trends to be highlighted:

1. We need to support three browser engines: Chromium, which is the foundation for 

  • Chrome, Edge, Samsung Internet Browser, and Opera.
  • Gecko is the foundation for Firefox.
  • Safari’s foundation is WebKit.

2. As compared to the rest of the world, Japan has a higher proportion of Safari users.

When looking at the following data, the reason for the latter of those points is obvious.

As per the global market OS share:

  • The Android accounts for 70.7% 
  • iOS for 28.5%
  • Others for 0.7%

As per the Japanese mobile market, OS share

  • Android accounts for 33.2 %
  • iOS stands for 66.5%
  • Other stands for 0.3%

As you can see, Android controls over 70% of the global mobile OS market, while iOS controls 28%. In Japan, on the other hand, Android has only 33% of the market share, compared to iOS’s 66%.

The Performance Disparity In The CPU

The variations in operating systems are not merely software-related; they also imply hardware variances. The CPU performance could be regarded as the most important.

It’s easy to say that iOS devices have had the greatest CPU performance rankings over the past ten years. High-tier Android devices perform similarly, but mid-tier and low-tier devices do significantly worse.

Alignment of The Browser With Web Standards

Different browsers’ implementation of various web standards has the greatest impact on web development. As previously said, there are three browser engines that we should be concerned about. Let’s have a look at how these various browsers handle web standards. The following data from the Web Platform Tests is the simplest way to check these differences.

  • Safari had 3524.825 failed tests
  • Firefox had 1473.036 failed tests
  • Chrome had 724.522 failed tests

This information shows how many Web Platform Tests fail in just one browser. To put it another way, how many features have already been added to the other two browsers?

One thing becomes clear: the number of web standards Safari hasn’t implemented is many times more than those implemented by Google chrome and Firefox. To be precise, 2.4 times as much as Firefox and 4.7 times as much as Chrome.

Furthermore, we must examine the intimate interaction between Safari and iOS. These two points in particular:

  • Other mobile browsers update independently of the operating system; however, Safari is updated only when iOS is updated. iOS devices that are no longer supported by later iOS versions cannot upgrade to the most recent version of Safari.
  • Webkit is the engine that powers all iOS browsers: there are iOS versions of Chrome and Firefox, but they use the same engine as Safari. This is because Apple has mandated that all iOS browsers run Webkit.

We must track how the market share of iOS versions changes with each major iOS version release because of the relationship between iOS and Safari.

Examine how the market share of iOS 12 has changed over the previous two years to have a better picture of how each iOS version’s market share changes:

  • The market share of iOS 12 climbed consistently from Q1 to Q3 2019, but it decreased once the iPhone 11 and iOS 13 were announced in Q3.
  • After that, iOS 12’s market share dropped below 20% for the rest of the year.
  • Then, in Q3 2020, when the iPhone 12 and iOS 14 were released, iOS 12’s market share plummeted to the point where it was practically non-existent by Q2 2021.
  • A similar pattern shown with iOS 12 was seen with versions 13 and 14 later.

Finally, we can confidently anticipate that major versions published in the last two years will continue to account for over 90% of the iOS market share. Put another way, we need to support Safari versions from the last two years.

Networks For Mobile Phones

So far, we’ve only discussed devices and browsers, but let’s look at one issue that potentially impacts the user experience: web developers have minimal control over network connections. The connection is usually stable when connected to a Wi-Fi network, but this is not the case with mobile networks. Let’s take a look at how mobile networks are currently doing.

Mobile Networks Are Classified As 3G And 4G

The network is tethered to replicate 3G while using lab tools like Lighthouse; however, mobile networks have lately altered. According to an Opensignal report from May 2020, the global average availability for 4G is 86.8%. As a result, we can confidently anticipate that most consumers worldwide will have access to a 4G network. Japan has the greatest 4G availability of the countries studied, at 98.5 percent.

5G

5G networks, on the other hand, are still a long way off. According to an Opensignal assessment from November 2021, South Korea had the highest 5G availability worldwide at only 29.1 percent.

What Is The New Benchmark?

Taking everything into consideration, the new web development baseline would be:

  • Safari is the gold standard in terms of web standards: the sites we build must work in Safari versions from at least two years ago.
  • Low-tier Android devices are the starting point in performance: We need to make sure our sites are lightning quick because low-tier Android handsets haven’t evolved much in recent years.
  • In terms of networks, 4G is the starting point: Mobile networks have become much quicker and more dependable worldwide in recent years.

How Well Do We Respond To User Demands?

We’ve figured out the three elements that make up our baseline, but that’s not enough. We need to assess how successfully we’re responding to user demands. On the other hand, a thorough investigation would yield different results for various projects. 

Performance

The most popular method of evaluating performance nowadays is to look at the Core Web Vitals (CWV). There are several reasons for this, the most important being that CWV is now used as a ranking factor in Google searches. Let’s see how the web performs in terms of CWV.

Excerpts from a few of these chapters show how closely the modern web resembles the baseline mentioned above.

In 2021, the average website will be 1,923 KB in size. When we look at the file types that make up the total, we can see that photos and JavaScript (JS) make up most of the whole.

Overall, the performance isn’t outstanding; more than half of the pages have poor CWV scores. Given the disparity in CPU power between devices, it appears plausible that mobile pages would score lower than desktop pages 12 percent of the time. This result is also in line with the fact that most websites have JS sizes that exceed the performance budget.

We can see that high CWV ratings correlate with many views. The fact that CWV is a Google ranking factor may have an impact. In terms of ideas, the top 1,000 websites have good CWV scores 37 percent of the time, compared to 32 percent overall. We can see that websites with more views perform better when looking at the top 10,000 or 100,000 websites. It’s hardly a leap to claim that one of the ways we may immediately increase income in our initiatives is to improve performance.

WIth such insights, we can realize the importance of analytical responsiveness and UX testing tools.

Frameworks And Libraries For JS

So far, we’ve witnessed how the quantity of JS we serve has a negative impact on the performance of our websites. Most JS-heavy projects will use a library or framework in some form or another. So, let’s take a look at the ramifications of that decision.

Use Of JS Libraries And Frameworks

According to Web Almanac’s JS chapter, jQuery is the most used library, with 84 percent usage. A major reason for this is that WordPress is used on 33% of the sites we discussed earlier.

With 8% of the votes, React is the most popular framework. However, when you consider that other frameworks don’t even reach 4%, it’s reasonable to state that framework usage is still in the minority.

Automation Testing

With the evolving internet space, the demand for more intuitive, robust, easy-to-use, and analytical website testing tools is evident.

You can find  automation and cloud testing tools like LambdaTest using which testing professionals can test their applications across 3000+ real browsers and operating systems.

Selenium is one of the most popular testing frameworks which can also be accessed using a cloud-based Selenium Grid through these tools.

Adaptability

As per the World Health Organization, more than one billion people are disabled somehow. There are numerous disabilities but many impacts on how users engage with their gadgets. We commonly refer to the measures required to ensure that impaired users can fully interact with our sites as accessibility (a11y).

However, a11y isn’t just for the disabled. Improvements in a11y have a favorable impact on the UX for all users. The main reason for this is because of situational constraints. Situational limits include trying to use your phone while eating or drinking with one hand and device settings that place a black and white filter on the screen after a certain hour to encourage sleep quality. Users with certain situational limitations will be able to access pages that have been developed with a11y in mind.

Furthermore, not being accessible can result in legal issues. Users may sue sites that do not consider a11y, depending on the law. For example, Beyonce and Domino’s Pizza have been sued for not being accessible to visually impaired consumers. As a result, not having proper a11y might also be costly.

Transforming Accessibility

Let’s take a look at how accessible the Internet is. We’ll extract some representative data from the Web Almanac’s a11y chapter. There are many more data points if you want to go deeper.

Furthermore, not being accessible can result in legal issues. Users may sue sites that do not consider a11y, depending on the law. For example, Beyonce and Domino’s Pizza have been sued for not being accessible to visually impaired consumers. As a result, not having proper a11y might also be costly.

29 percent of web pages use the role=”button” tag. Some may feel that having that role and a click listener is enough, but buttons must also respond to keyboard events and effectively handle the attention. While you could accomplish it using JS, you can do it without it if you only use the button element.

Input items with no accessible label can be seen on 32.7 percent of websites. They lack a label element, an aria-label attribute, and any other identifier. This is concerning because you may be losing money due to it. Customers may want to buy something but don’t know where to put their credit card information if a credit card input isn’t labeled.

Conclusion

Let’s look at the report card more closely.

  • We aren’t responding to the users’ needs, particularly performance and accessibility.
  • We overuse JS in both our dependencies and our code.
  • HTML and CSS aren’t used to their full potential: This is primarily due to support for Internet Explorer; however, now that IE is no longer required, many more features have become available.

For those looking for a place to start, here are a few general suggestions:

If you can achieve anything with CSS, do so: Many tasks that were previously only possible with JS can now be accomplished with merely CSS. You can somewhat minimize your JS code by doing so.

Examine your toolbox for the following items: Many modern tools have higher performance baselines than older ones, and SPAs aren’t required for every project. Hugo, Jekyll, or 11ty are non-framework-based SSGs that are excellent for certain use cases.

Created with contemporary browsers in mind: Set your build target to ES 2017 or perhaps 2018 instead of IE support. Simply doing so could result in a 20 percent increase in bundle size.

Consider a11y right from the start: The ideal scenario is to consider a11y from the beginning of the planning and design process. You can significantly improve contrast rates, font sizes, semantic HTML use, and keyboard navigation.

Low-spec Android smartphones, Safari from two years ago in terms of Web Standards, and 4G networks will be the performance baseline for web development in 2022.

 The web, in general, is failing to meet those expectations, particularly in terms of performance, where issues such as an over-reliance on JavaScript are slowing down our sites.

Sophia Jennifer

I'm Sophia Jennifer from the United States working in social media marketing It is very graceful work and I'm very interested in this work.

Leave a Reply

Your email address will not be published. Required fields are marked *