It’s a widely known fact that WordPress dominates the Content Management System scene. The amount of websites that run on WordPress far outnumber those of its competition, totalling to about a third of all known sites.
That kind of ubiquity, of course, comes with severe exposure to cyber threats. WordPress is, unfortunately, the undisputed winner in terms of hacking, too. DataProt’s research into WordPress reveals that a whopping 90% of WP users request malware cleanups (while only 4% of Joomla or Magento users do).
It’s clear, then, that WordPress takes the lion’s share of the cyber danger. But what kinds of attacks on its websites are the most common? Knowing more about the most utilized types of cyber attacks can help WP website owners prepare for them.
To that end, let’s take a look at the most common WordPress attacks in 2020, as well as how to guard yourself against them.
1. Cross-Site Scripting
Cross-site scripting (XSS for short) is an injecting attack wherein the hacker inserts a malicious piece of code into a website. They usually manage to do this through an application that requires the user’s input to produce its output.
Once that nefarious piece of code creeps into the website, it can be used in a number of ways. The hacker may take session cookies and impersonate a user, access API’s that connect to other applications, spread worms, and more. That said, it’s most commonly leveraged to redirect people to websites where the hacker can snatch their data.
Protection against an XSS incursion varies depending on your circumstances. Here are a few suggestions for you to consider:
Whitelist values so that attackers have a harder time inserting harmful code (for example, don’t let people type in their date of birth; have them choose from a drop-down list).
Use an HTML sanitization library to block hackers from injecting scripts in their HTML submissions.
Make your cookies exclusively HTML so that it can’t be read or changed in JavaScript.
2. SQL Injecting
Much like an XSS attack, SQL injecting involves the insertion of a malicious code string into a website. The attacker does so by cramming structured language queries into cookies, forums, HTTP headers, or other web input pages.
The difference between the two lies in utility. XSS finds its purpose in sending unwitting users to malicious websites. Meanwhile, an SQL strike will tend to aim for the targeted website’s database, allowing modification and unauthorized access to data.
Beyond sanitizing input, one of the best precautions against SQL injection is to insist on prepared statements in your code. These strings set parameters for the user’s query before executing it so that it denies any unwanted input.
3. URL Hacking
A URL hack works on more or less the same principles as an SQL or XSS injection. Here, the hacker can relay a malicious piece of code through the URL bar. They can thus reveal sensitive data and edit the code.
From there, the attacker may opt for many different ways to damage your site. For instance, they could create a redirect that leads to one of their websites. Maybe they would insert malware into your website or reveal sensitive info.
Logically, the remedy for this threat is in the same vein as the previous two. Sanitizing (AKA escaping) user input and relying on parameterized statements will go a long way to ensuring that attackers can’t pull off a successful URL hack.
4. Brute Force Attack
For hackers striving to find your username and password, brute force attacks are a fairly handy tool. It’s a pretty straightforward idea: simply guess the correct string or phrase through trial and error until you get it right.
As you can expect, this method takes thousands of attempts to pay dividends. It’s like trying to guess a word someone’s thinking of by going through every single word that exists. Naturally, hackers use computer programs to make this process much faster, but it still takes plenty of time, sometimes years, even.
Despite the needed effort, brute force attacks are nevertheless a very real threat. Luckily, there are practical steps you can take to stop this kind of attack dead in its tracks. Here’s some useful advice:
Keep your passwords strong (long, with numbers, not just one word, not directly related to you).
Take advantage of Captcha to catch bots attacking your website.
Implement two-step authentication that demands human responses (like one-time passwords sent to phones).
Limit the number of login attempts so that bots can’t keep guessing your login details.
5. DDoS Attack
A very common cybercrime tactic, a DDoS (Distributed Denial of Service) attack serves to put your website out of working order. The plan is to send so much traffic your way that your site can’t deal with all the requests it’s getting, effectively shutting it down.
The attacker employs a (sometimes massive) group of malware-carrying computers (dubbed a botnet) to accomplish this. They may carry out the attack for a variety of reasons, ranging from financial gain to simple bragging rights. However, a DDoS invasion tends to come hand-in-hand with other forms of attack, usually serving as a distraction while the real operation takes place.
DDoS attacks are preventable with the proper security measures. A content delivery network (CDN), for one, can spread traffic across a multitude of servers. There’s also the intrusion prevention system (IPS) or web application firewall (WAF) that monitor incoming traffic and look for anomalies indicative of a DDoS operation.
6. Malware
Malware is a sort of umbrella term that describes a diverse sort of software. What they all have in common, though, is their purpose. Their general goals are to, in some way, disrupt, manipulate, or damage a database or system.
To these ends, hackers will utilize an array of worryingly creative programs and strategies. Trojans, worms, spyware, ransomware, adware – the list goes on, and this malware can do anything from spying on you to stealing your data or encrypting it and demanding money to give it back to you.
Given the broad scope of the danger, there are also plenty of ways to ward off the malware menace:
Have a backup of your site.
Periodically reset your passwords.
Keep all plugins and software updated.
Run routine virus scans.
7. Privilege Escalation Attack
Through a privilege escalation attack, a hacker will take any steps they can to accumulate the privileges they have on your website. Their objective is to gain access to as much information as they can, constantly trying to attain higher authorization. They may go about this by manipulating access tokens or bypassing user account control (UAC), for example.
Two types of privilege escalation attacks exist. Vertical focuses on gaining as much clearance possible, the higher the better. Horizontal, on the other hand, takes advantage of comparatively lower privilege levels spread across a number of accounts.
The problem with this kind of attack is that it can come from anywhere in your network (typically its weakest spot). The best way to ward off privilege hoarders is to constantly monitor your systems (MalCare would be helpful here). Deleting old plugins and themes will also wall off easier points of entry for hackers.
Wrap-up
To sum up, these are the most common attacks plaguing WordPress users:
Cross-site scripting
SQL injecting
URL hacking
Brute force attack
DDoS attack
Malware
Privilege escalation attack
While there are certainly many of them to worry about, they are all preventable to a great degree. As long as you stay on top of the right prevention measures, you won’t have to worry about these attacks any time soon.
It’s a widely known fact that WordPress dominates the Content Management System scene. The amount of websites that run on WordPress far outnumber those of its competition, totalling to about a third of all known sites.
That kind of ubiquity, of course, comes with severe exposure to cyber threats. WordPress is, unfortunately, the undisputed winner in terms of hacking, too. DataProt’s research into WordPress reveals that a whopping 90% of WP users request malware cleanups (while only 4% of Joomla or Magento users do).
It’s clear, then, that WordPress takes the lion’s share of the cyber danger. But what kinds of attacks on its websites are the most common? Knowing more about the most utilized types of cyber attacks can help WP website owners prepare for them.
To that end, let’s take a look at the most common WordPress attacks in 2020, as well as how to guard yourself against them.
1. Cross-Site Scripting
Cross-site scripting (XSS for short) is an injecting attack wherein the hacker inserts a malicious piece of code into a website. They usually manage to do this through an application that requires the user’s input to produce its output.
Once that nefarious piece of code creeps into the website, it can be used in a number of ways. The hacker may take session cookies and impersonate a user, access API’s that connect to other applications, spread worms, and more. That said, it’s most commonly leveraged to redirect people to websites where the hacker can snatch their data.
Protection against an XSS incursion varies depending on your circumstances. Here are a few suggestions for you to consider:
Whitelist values so that attackers have a harder time inserting harmful code (for example, don’t let people type in their date of birth; have them choose from a drop-down list).
Use an HTML sanitization library to block hackers from injecting scripts in their HTML submissions.
Make your cookies exclusively HTML so that it can’t be read or changed in JavaScript.
2. SQL Injecting
Much like an XSS attack, SQL injecting involves the insertion of a malicious code string into a website. The attacker does so by cramming structured language queries into cookies, forums, HTTP headers, or other web input pages.
The difference between the two lies in utility. XSS finds its purpose in sending unwitting users to malicious websites. Meanwhile, an SQL strike will tend to aim for the targeted website’s database, allowing modification and unauthorized access to data.
Beyond sanitizing input, one of the best precautions against SQL injection is to insist on prepared statements in your code. These strings set parameters for the user’s query before executing it so that it denies any unwanted input.
3. URL Hacking
A URL hack works on more or less the same principles as an SQL or XSS injection. Here, the hacker can relay a malicious piece of code through the URL bar. They can thus reveal sensitive data and edit the code.
From there, the attacker may opt for many different ways to damage your site. For instance, they could create a redirect that leads to one of their websites. Maybe they would insert malware into your website or reveal sensitive info.
Logically, the remedy for this threat is in the same vein as the previous two. Sanitizing (AKA escaping) user input and relying on parameterized statements will go a long way to ensuring that attackers can’t pull off a successful URL hack.
4. Brute Force Attack
For hackers striving to find your username and password, brute force attacks are a fairly handy tool. It’s a pretty straightforward idea: simply guess the correct string or phrase through trial and error until you get it right.
As you can expect, this method takes thousands of attempts to pay dividends. It’s like trying to guess a word someone’s thinking of by going through every single word that exists. Naturally, hackers use computer programs to make this process much faster, but it still takes plenty of time, sometimes years, even.
Despite the needed effort, brute force attacks are nevertheless a very real threat. Luckily, there are practical steps you can take to stop this kind of attack dead in its tracks. Here’s some useful advice:
Keep your passwords strong (long, with numbers, not just one word, not directly related to you).
Take advantage of Captcha to catch bots attacking your website.
Implement two-step authentication that demands human responses (like one-time passwords sent to phones).
Limit the number of login attempts so that bots can’t keep guessing your login details.
5. DDoS Attack
A very common cybercrime tactic, a DDoS (Distributed Denial of Service) attack serves to put your website out of working order. The plan is to send so much traffic your way that your site can’t deal with all the requests it’s getting, effectively shutting it down.
The attacker employs a (sometimes massive) group of malware-carrying computers (dubbed a botnet) to accomplish this. They may carry out the attack for a variety of reasons, ranging from financial gain to simple bragging rights. However, a DDoS invasion tends to come hand-in-hand with other forms of attack, usually serving as a distraction while the real operation takes place.
DDoS attacks are preventable with the proper security measures. A content delivery network (CDN), for one, can spread traffic across a multitude of servers. There’s also the intrusion prevention system (IPS) or web application firewall (WAF) that monitor incoming traffic and look for anomalies indicative of a DDoS operation.
6. Malware
Malware is a sort of umbrella term that describes a diverse sort of software. What they all have in common, though, is their purpose. Their general goals are to, in some way, disrupt, manipulate, or damage a database or system.
To these ends, hackers will utilize an array of worryingly creative programs and strategies. Trojans, worms, spyware, ransomware, adware – the list goes on, and this malware can do anything from spying on you to stealing your data or encrypting it and demanding money to give it back to you.
Given the broad scope of the danger, there are also plenty of ways to ward off the malware menace:
Have a backup of your site.
Periodically reset your passwords.
Keep all plugins and software updated.
Run routine virus scans.
7. Privilege Escalation Attack
Through a privilege escalation attack, a hacker will take any steps they can to accumulate the privileges they have on your website. Their objective is to gain access to as much information as they can, constantly trying to attain higher authorization. They may go about this by manipulating access tokens or bypassing user account control (UAC), for example.
Two types of privilege escalation attacks exist. Vertical focuses on gaining as much clearance possible, the higher the better. Horizontal, on the other hand, takes advantage of comparatively lower privilege levels spread across a number of accounts.
The problem with this kind of attack is that it can come from anywhere in your network (typically its weakest spot). The best way to ward off privilege hoarders is to constantly monitor your systems (MalCare would be helpful here). Deleting old plugins and themes will also wall off easier points of entry for hackers.
Wrap-up
To sum up, these are the most common attacks plaguing WordPress users:
Cross-site scripting
SQL injecting
URL hacking
Brute force attack
DDoS attack
Malware
Privilege escalation attack
While there are certainly many of them to worry about, they are all preventable to a great degree. As long as you stay on top of the right prevention measures, you won’t have to worry about these attacks any time soon.
Web performance advocates have often advised to add dimensions to your images for best performance to allow the page to be laid out with the appropriate space for the image, before the image itself has been downloaded. This avoids a layout shift as the image is downloaded — something Chrome has recently started measuring in the new Cumulative Layout Shift metric.
Well, a dirty, little, secret — not that well-known outside the hard-core web performance advocates — is that, until recently, this actually didn’t make a difference in a lot of cases, as we’ll see below. However, adding width and height attributes to your markup have become useful again after some recent changes in the CSS world, and the quick adoption of these changes by the most popular web browsers.
Recommended Reading
The CSS contain property gives you a way to explain your layout to the browser, so performance optimizations can be made. However, it does come with some side effects in terms of your layout. ?
Why Adding Width And Height Were Good Advice
Take for example this simple page:
<h1>Your title</h1>
<p>Introductory paragraph.</p>
<img src="hero_image.jpg" alt=""
width="400" height="400">
<p>Lorem ipsum dolor sit amet, consectetur…</p>
This might render in two stages, first as the HTML is downloaded, and then second once the image is downloaded. With the above code, this would cause the main content to jump down after the image is downloaded and the space needed to display it can be calculated:
Layout shifts are very disrupting to the user, especially if you have already started reading the article and suddenly you are thrown off by a jolt of movement, and you have to find your place again. This also puts extra work on the browser to recalculate the page layout as each image arrives across the internet. On a complex page with a lot of images this can place a considerable load on the device at a time when it’s probably got a lot of better things to deal with!
The traditional way to avoid this was to provide width and height attributes in the markup so even when the browser has just the HTML, it is still able to allocate the appropriate amount of space. So, if we change above example to the following:
<h1>Your title</h1>
<p>Introductory paragraph.</p>
<img src="hero_image.jpg" alt=""
width="400" height="400">
<p>Lorem ipsum dolor sit amet, consectetur…</p>
Then the render happens like below, where the appropriate amount of space is set aside for the image when it arrives, and there is no jarring shift of the text as the image is downloaded:
Text should not shift if image dimensions are provided so appropriate space can be allocated. (Large preview)
Even ignoring the annoying impact to the user in content jumping around (which you shouldn’t!), the impact on the CPU can also be quite substantial. The below screenshot shows the performance calculations performed by Chrome on a site I work on which has a gallery of about 100 images. The left-hand side shows the calculations when width and height are provided, and on the right when they are not.
Performance calculations with and without dimensions. (Large preview)
As you can see, the impact is considerable — especially on lower-end devices and slow network speed, where images are coming in separately. This increases load time by a noticeable amount.
How CSS Interacts With Element Widths And Heights
Widths and heights on an image can cause issues when you try to alter them using CSS. For example, if you want to limit your images to a certain width you might use the following CSS:
img {
max-width: 100%;
}
This will override the width of the image and constrain it when necessary, but if you have explicitly set the height on the image tag, then we are not overriding that (only the width) and you will end up with a stretched or squashed image, as we have no longer maintained the aspect ratio of the image:
Image dimensions clashes between HTML and CSS can create stretched (or squashed!) images. (Large preview)
This is actually very easily fixed by adding a height: auto line to the CSS so the height attribute from the HTML is overridden too:
img {
max-width: 100%;
height: auto;
}
However, I find it still catches people by surprise and sometimes leads to them not specifying image dimensions in the HTML instead. With no image dimensions, you can get away with just specifying max-width: 200px in the CSS without having to specify height: auto and the browser will automatically figure out the height itself — once it has the image.
So, once we add the dimensions and that the height: auto trick, we get the best of both worlds, right? No layout shifts, but also the ability to resize images using CSS? Well until very recently you might have been surprised to find out the answer was in fact: no (I was — hence why I decided to write this article).
Layout shifts happen when height: auto is used in CSS. (Large preview)
Wait, what’s going on here? We’re back to the first problem. I thought I said that by specifying the image dimensions in the HTML you could avoid this layout shift problem? Well, this is where it gets interesting and will lead on to the main point of this article.
The problem is that, unless you were giving explicit widthandheight CSS values to your images — and who wants to limit themselves like that in a responsive world where you want the image to expand or shrink to fill up the available space — then CSS will need the dimensions from the image file itself to figure out the auto part of the dimensions. It ignored any width and height attributes set in the HTML.
The implication of all this is that specifying width and height attributes on images often wasn’t actually that useful in a lot of cases. Yes, when an image is being shown at full size, without any CSS changing any dimensions, it is useful to resolve the layout shifting problem. However, when you use CSS like below to ensure images do not overflow their available space, then you run into problems as soon as the available width becomes smaller than the actual image size.
img {
max-width: 100%;
height: auto;
}
This affects any page where we constrain the image size in a responsive manner — i.e. small screen mobile devices. These are likely to be the very users suffering with network constraints and limited processing power that will suffer most from layout shifts! Of course, we ideally should be delivering appropriately sized images for the screen size, but you cannot cover every device size, so often images will need some resizing by the browser, particularly on mobile.
Many websites may not bother to specify widths and heights on their tags. That could be because they weren’t aware this was useful, or because they were all too aware of what we talked about here and knew it actually wasn’t that useful in a lot of cases. Whatever the reason is beside the point, they are frequently not provided. (How can we even evangelize putting the effort into using them given what I’ve just described?) Even the popular Lighthouse auditing tool doesn’t flag when you don’t do this (though in light of some of the things we’re about to talk about, that is under discussion again).
Working Around The Problem
The limitations for responsive images have been known for a long time and many workarounds, including the so-called padding-bottom hack, have been created to work around the issue. This uses the fact that padding percentages (including padding-bottom ) are always based on the container width (to ensure a consistent padding even if height and width differ). This fact can therefore be used to create a container with where the height is set based on a ratio of the width. For example for, let’s say we have an image with an aspect-ratio of 16:9, then the following CSS code will create the appropriately sized space for the image:
The three main downsides of this technique are the following:
It requires a hard-coded ratio to be calculated (56.25% — 9÷16 — in this example), so it potentially requires custom CSS for each different image.
The CSS code is not exactly easy to remember — forgetting or removing a single line of the above CSS code will break the whole thing. Not to mention this technique requires all images to be wrapped in an extra container element.
This is a more advanced technique that not all web developers know about or use.
And, let’s be honest — it’s a bit of a hack! So, we really should fix this properly, shouldn’t we?
Fixing The Resizing Problem
The issue has been tackled from a few different directions by a number of different standards organizations.
The CSS Working Group (CSS WG) proposed the aspect-ratio property that Rachel wrote about previously. This would tackle the complexity problem (issue 2) once it becomes available, and simplify the above code to just this:
Much nicer! This is particularly useful for video where we usually have a set number of commonly used aspect-ratios, so we could create a few classes like above for each size. It’s perhaps less useful for images where dimensions are much less standardized, as it doesn’t solve issue 1 (custom CSS code required per image), nor issue 3 (website developers will need to remember to set this). So, it’s a step forward, but not a full solution.
Separate to this, the Web Incubator Community Group (WICG) — a group of browser developers and other interested parties that can experiment on technologies to see if they work before formal standardisation — also created a proposal to fix this. They proposed the intrinsicsize attribute, that would look like this:
<img intrinsicsize="400x400" style="width: 100%">
As this is an HTML attribute, it can be set per image (solving issue 1), and is relatively easy to code (solving issue 2), but was still likely to suffer from adoption issues (issue 3) unless it became very well-known with a big push from the whole community.
We already have a common, well-known method of setting the width and height on elements (even if they are not used as much as they should be!) so anything new, other than that, is going to suffer from the adoption issue. And that is where the (now seemingly obvious!) answer presented itself.
Rather than hard-coding the aspect-ratio, this uses the attr CSS function to create the appropriate aspect-ratio based on the image width and height attributes provided by the HTML. The attr function has been around for a while, but has been very limited in scope — it’s supported forcontentby all browsers, but not for the wider use case of any other attribute like width and height, which is what is needed here.
If attrwas able to be used for the well-known width and height attributes from img elements, then it could use be used to automatically calculate the aspect-ratio as per above. This would solve issue 1 (no hard-coded aspect ratio needs to be set in the HTML nor the CSS), issue 2 (very simple to add) and, as we shall see, there is a very simple answer to issue 3 (adoption).
Basically, this solution means if the following four conditions are true, then the correct image dimensions could be calculated without needing to wait for the images to download, and so without the need of a content layout shift:
height is set on the element in HTML
width is set on the element in HTML
height (or width) is set in the CSS — including using percentage values like max-width: 100%;
width (or height) is set to auto in the CSS.
If any one of these were not set, then the calculation would not be possible, and so would fail and be ignored and have to wait for the image to be downloaded.
So once browsers support using the HTML width and height to calculate the aspect-ratio we can solve our problem very simply with no change in practice to HTML and one line of CSS code! As mentioned above, this is also something many web developers may have already assumed was happening anyway.
Driving Adoption Of This Solution
Because this is just a CSS attribute, the proposal contained a further twist — it could be added to the user-agent stylesheet used by browsers so would not even require any changes from web developers to benefit from this.
The user-agent stylesheet is where default CSS definitions are set (e.g. what font-size the h1 element uses), which can be overridden by your own CSS if you want. By adding the above aspect-ratio one-liner to this we don’t need to drive adoption — we basically turn it on automatically for all sites that meet the above four conditions!
However, this does depend on the attr function having access to the width and height HTML attributes, and also the upcoming aspect-ratio CSS property to be completed — neither of which has happened yet. So instead, as an easier fix, the browsers could implement the equivalent logic deep in rendering code rather than exposing it via the user-agent stylesheet, but the effect is the same. This alternative implementation approach was even suggested as part of the proposal.
When introducing a change in behavior, there is always a concern about backwards compatibility and this feature was no different. In theory, as long as the four attributes were appropriately set, there should be no breakage with this.
However, when Firefox initially experimented with it, they discovered problems for those setting the width and height incorrectly in their HTML. Whereas previously these incorrect values would be ignored if the CSS overrode them, now they were being used when auto was set and the images were not displayed correctly and led to squished or stretched images. Now you could argue that web developers shouldn’t set these values incorrectly, and in some cases, it would be already broken even without this change (the case above when you didn’t set height: auto), but still, breaking sites is never a good thing. That is also something the web tries very hard to avoid — and is mostly very good at avoiding that (it’s one of my favorite things about the web as a platform).
The solution to that problem, however, was relatively simple: have the actual image aspect-ratio of the image override any CSS calculated aspect-ratio. This way the (incorrectly) calculated aspect-ratio can be used for initial layout, but then can be recalculated when the image is downloaded, so the image is displayed as it was before. This does cause a layout shift (since the incorrect space was allocated initially) but that was happening before anyway, so it’s no worse. In fact, it’s often a lot better as an incorrect aspect ratio will often be closer to the truth than a zero aspect-ratio.
Rollout To Other Browsers
After Firefox’s successful experimentation, Chrome also decided to implement this (again using the layout coded method for now rather than default user-agent stylesheet), and rolled it out by default in Chrome 79. This also took care of the other chromium-based browsers (Edge, Opera and Brave, for example). More recently, in January 2020, Apple added it to their Tech Preview edition of Safari, meaning it should hopefully be coming to the production version of Safari soon, and with that, the last of the major browsers will have implemented this and the web will become better and less jolty for a huge number of sites.
Limitations
There are a few limitations to be aware of with this feature, including issues with:
Art Direction
Lazy Loading
Non-Images
Art Direction
The fix works great to calculate the aspect-ratio based on a fixed width and height, but what about when those change? This is known as art direction and an example is shown below:
‘Art direction’ uses different photographs depending on the available space. (Large preview)
In this case we are using a wide image for desktop, and then a square, cropped image for mobile. Responsive images can be implemented using srcset attributes on an element:
Currently, both these elements only allow the width and height to be set once on the main, fallback element and not on the individual alternatives. Adding these has been proposed but until then, this is currently a limitation of the solution, and using images with different dimensions will still experience a layout shift.
Lazy Loading
This feature would be perfectly suited for use with lazy-loading. Ideally, all lazy-loaded images are loaded off-screen as you scroll down the page before the lazy-loaded image enters the viewport, but often this is not the case depending on how fast the user scrolls and the network, so having the image area correctly set would at least avoid the layout shift after loading does occur. Additionally, even when loading is happening off-screen, layout shifts can be costly in terms of CPU time, as we have shown above.
However, lazy loading techniques may involve not using an element, or at least one without a src (to prevent the browser from downloading the image by default). Therefore, it may not be able to benefit from this recent change depending on how your browser handles the element used or src-less elements. Though if the CSS version of this solution becomes available, then website developers will have greater control over specifying aspect-ratio themselves.
Perfect! Well, unfortunately, I discovered this height and width solution is not compatible with the recently released native lazy-loading functionality as can be seen on this test page. I’ve raised a bug for this issue and hopefully the Chrome team will fix this soon.
Non-Images
Currently, the browsers that have implemented this, have only done for the element, but it would also be useful for , and elements to name a few, and this under discussion. Again, if the CSS version of this technique becomes available through the attr functions and aspect-ratio property, then that puts the power in the website developer to implement this for whatever elements they want!
Conclusion
I love improvements that just work without any effort required of website owners. That is not to ignore the hard work required by the browser developers and standardization teams, of course, but it’s often rolling out to websites that is the real difficulty. The less friction we can add to introduce these improvements, the more likely they will be adopted, and there’s no better friction than none at all! Fixing the impact of layout shifts on users for responsive images seems to be one such improvement and the web is all the better for it.
The one change that is required of us web developers is to ensure we are providing width and height attributes in our markup. It’s a habit we shouldn’t really have gotten out of, and many CMS and publishing tools make this relatively easy. I queried the tags havewidthorheights, which is way higher than I expected to be honest — but let’s try to increase that statistic even more now we have a reason to again. So, I implore you to check that you are doing this on your sites and, if not, start to. It will improve the experience for your users and ultimately make them happier, and who doesn’t want that?
While it’s important to know about the latest research and surveys impacting web design, I think it’s just as important to stay informed about news that may affect your work as a designer.
As such, this roundup of the latest research for web designers includes a mix of reports along with some news and facts about something that people are talking about all around the world: the coronavirus.
A Better Lemonade Stand Analyzes the Best Remote Working Locations
While finding a place to live can be a very subjective matter (for instance, some people prefer colder locales or warm ones), this list takes into account factors that can have a serious impact on the work of a freelancer. For example, this is why Auckland, New Zealand ended up taking the #1 spot for remote work:
The other cities to round out the top 10 are:
Bengaluru, India
Budapest, Hungary
Buenos Aires, Argentina
Chiang Mai, Thailand
Dubrovnik, Croatia
Hanoi, Vietnam
Ho Chi Minh, Vietnam
Krakow, Poland
Lisbon, Portugal
I’d argue that it’s high scores on factors like the following that make them the best spots to work remotely from:
Cost
Internet speed
Free wifi in the city
Places to work from
Walkability
Happiness score
Quality of life
If you’ve been considering a move and you want it to not only be a place you love but that’s good for your business, one of these nomad-friendly spots might fit the bill.
Hubspot Gives Us a Comprehensive Look at the State of Marketing
As always, there’s almost too much information to digest in Hubspot’s annual State of Marketing report. But that’s not going to stop me from highlighting the points you can use to bring more money into your business:
Website Upgrades Needed
According to the survey, 63% of respondents are looking to upgrade their websites in 2020. If you have experience in and enjoy doing website redesigns, hop on this opportunity as soon as you can.
When asked which tactics have been the most beneficial for improving a website’s performance and search ranking, here’s what respondents had to say:
You could easily create a recurring revenue stream around these maintenance tasks.
Visual-Heavy Content Marketing is a Must
Marketers use a wide variety of content in their marketing strategies:
If you’re in the business of building websites, you should also be helping your clients create graphics for the media above. For instance, you could provide ongoing design services for:
Blog (and promotional social media) graphics
Videos or just video cover images
Infographics
Templates for case studies, ebooks, and white papers
Just because your job is primarily to build high-converting websites for clients doesn’t mean you shouldn’t be looking for other ways to serve them.
The Coronavirus’s Impact on Freelancers
With so much news about the coronavirus out there, it’s hard to know what to focus your attention. If you’re a freelancer, then these are the statistics and research you should focus on:
Conferences Around the World Are Being Cancelled
Business Insider and the LA Times rounded up lists of conferences that have been cancelled, rescheduled, or restructured because of the coronavirus:
Adobe Summit (it’ll be online instead)
Facebook’s F8
Facebook’s Global Marketing Summit
EmTech Asia
Shopify Developer Conference
Google I/O
Google Cloud Next ‘20 (rescheduled as an online event)
And for those of you who work with WordPress, WordCamp Asia was cancelled.
Considering how expensive and time-consuming professional design conferences can be to attend, these cancellations might not be as big of a disappointment to the freelance community. In fact, it might bring a change to the professional conference landscape, with more of them hosted virtually so that it becomes cheaper, more practical, and now safer to attend.
Some Freelance Gigs Are Drying Up
In particular, it’s Singapore’s population of freelancers that are feeling the effects of the coronavirus, according to a report from Vice.
It makes sense. As businesses close down their offices or their operations altogether, the contract workforce who works behind the scenes for them is going to be impacted as well. This is especially problematic for those who build ecommerce and retail websites. With many products manufactured in China (31.3% of all apparel and 37.6% of textiles are manufactured there, for instance), inventories are waning and many retailers are having to wait out the virus to resume operations.
The Singapore government recently announced plans for its 2020 budget, which included contributing SG$800 million towards curbing the effects of the virus on the country. Additional support is to be given to industries the most severely affected by it as well.
While the country’s budget doesn’t account for freelancers (as I’m sure will be the case in other countries), the freelance community itself is stepping up.
Nicholas Chee, who runs a video production company in Singapore, started a Facebook group for freelancers who’ve been dealing with lost gigs as a result of the coronavirus. It’s called SG COVID-19 Creative/Cultural Professionals & Freelancers Support Group and is giving the freelance community a way to support each other through this crisis.
Web Designers May Be Able To Help Stop The Spread of Coronavirus
It’s not just Facebook groups that are going to help freelancers get through the coronavirus crisis in one piece. According to Dr. Stephanie Evergreen, web designers might actually be able to help slow down or stop the spread of the virus itself.
In an article she wrote for Fast Company, Dr. Evergreen, a data visualization specialist, demonstrates how more eye-catching graphics can better educate the public on what’s going on and what they can do.
While it more effectively lays out this data than a wall of text would, it’s not going to do much to capture anyone’s attention.
It’s more important than ever for public health agencies to use data visualization to communicate with the masses, as the public is bombarded with more information each day and in need of a way for the most pressing issues to cut through the noise.
It does both a good job of capturing attention and informing the public of what’s going on.
Bottom line: if your website is tasked with communicating critical data to the public, see if there’s a way you can lend your design skills to it. While a writer can clearly communicate what’s going on, graphics are more likely to grab and hold their attention.
Wrap-Up
While annual “State of” reports always tend to wind down around February/March, we still have a wealth of data coming in that not only affects your design strategy but your business strategy too.
Keep your eyes peeled for the next edition of the latest research for web designers as we’re sure to see the first quarterly reports come out for design, marketing, SEO, and more.
Every day, but today especially, we want to honor women the way that they deserve.
Women contribute a billion and one things to society every single day, whether you realize it or not, and deserve to be celebrated and treated as such.
Without women, our world would be bland.
Without women, we wouldn’t know our world as we know it today.
Women make our world a better place.
By women, for women.
That’s why, today, I want to shine the spotlight on the talented and amazing women who created art to share on this International Women’s Day.
Here are 19 designs to celebrate Women’s Day and to appreciate the women in our lives and the ones that change the world each day for the better.
We see you killing the game, hustling, climbing to the top, running a business, being a mom, taking care of others, fighting for freedom, protecting others… basically, being a woman.
I love it when people redesign “in the open” and write about it. I’d just like to shout out to our own Geoff who has been doing this for 3 months now. He started in late December last year. He’s been sharing stuff like his dev tooling choices, considering performance, considering accessibility, that moment where you question everything, and then getting back on with it by evolving choices, like how he’s handled dark mode.
Every week users submit a lot of interesting stuff on our sister site Webdesigner News, highlighting great content from around the web that can be of interest to web designers.
The best way to keep track of all the great stories and news being posted is simply to check out the Webdesigner News site, however, in case you missed some here’s a quick and useful compilation of the most popular designer news that we curated from the past week.
Note that this is only a very small selection of the links that were posted, so don’t miss out and subscribe to our newsletter and follow the site daily for all the news.
Windows OS Redesign on Behance
Stop Using Material Design Text Fields!
Introducing Alpine.js: A Tiny JavaScript Framework
State of Website Builders 2020
5 Reasons to Apply Digital Illustration in Web Design
Undiscoverable UI Madness
Why the Next Paradigm Shift May not Be Technological
Sharing Design Knowledge and Experience Through Design Islands
Behavioral Design 2020 and Beyond
Pantone Unveils 315 New Colors in Digital Expansion
The 5 Forgivable Sins of a Freelance Designer
Adobe Summit Cancelled
Facebook Now Lets You Turn any 2D Photo into a 3D Image Using AI
How to Create Design System Components
11 Types of Gradients for Creating Stunning Backgrounds
User Interface (tiny) Annoyances
Great Side Hustle Ideas for Graphic Designers
Guide to Qualitative UX Research
3 Things You Probably Didn’t Know About Design Thinking
Firefox is Showing the Way Back to a World That’s Private by Default
Dissecting the Qualities of Design Leadership
Cross-Cultural Design
Why Startups are Afraid to Invest in UX Research
UI Design for a FinTech App: 6 Handy Practices
Creating Virgin Atlantic’s Digital Design System
Want more? No problem! Keep track of top design news from around the web with Webdesigner News.
I see Google Fonts rolled out a new design (Tweet). Compared to the last big redesign, this feels much more iterative. I can barely tell the difference really, except it’s blue instead of red and this one pretty rad checkbox: Show only variable fonts.
An option to only show variable fonts is a pretty bold feature for the main navigation up there. That’s a strong commitment to this feature. With Google Fonts having about 90% of the market share of hosted web fonts and serving trillions of requests, that’s going to spike interest and usage of variable fonts in a big way. Web designers and developers have been excited about variable fonts for a while, but I’d bet this is the year we start seeing it in the wild in a much bigger way.
Something about variable fonts inspired the micro-site. See v-fonts.com and Axis-Praxis. Here’s come another one: variablefonts.io! Like the others, it also has interactive examples, but it’s also full of direct up-to-date advice and links to resources.
Another thing that’s really great that Google Fonts has done somewhat recently is allowed for the usage of font-display. It’s got a good default (swap), and is easily changable as a query param. Matt Hobbs has a recent article about what it is, how important it can be, and how to use it.
And while we’re talking Google Fonts, I ran across the browser extension Snapfont the other day. It’s a pay-what-you-want thing (I tossed them a fiver).
It just hard-replaces every font on the site with one you pick to get a quick taste of it. There are no options, so it’s not for fine-tuning any choices. The “Heading” button didn’t even work for me. But I like how simple and easy it was to get a taste for a site with a new font.
You might reach for when you’re, you know, trying to collect a number in a form. But it’s got all sorts of issues. For one, sometimes what you want kinda looks like a number, but isn’t one (like how a credit card number has spaces), because it’s really just a string of numbers. Even more importantly, there are a variety of screen reader problems.
That last attribute is interesting and new to me. It means you get this super extra useful experience on browsers that support it:
There are other autocomplete values, as Phil writes:
There are many autocomplete values available, covering everything from names and addresses to credit cards and other account details. For sign up and login there are a few autocomplete values that stand out as useful hints: username, email, new-password, current-password.
Browsers and password managers have very good heuristics to find login forms on web pages, but using the username and current-password values make it very obvious.
Funny timing on this I was just looking at the website for Utopia (which is a responsive type project which I hate to admit I don’t fully understand) and I came across some CSS they show off that looked like this:
See anything weird there? That code is using mathematical operators, but there is no calc() function wrapped around it.
Just as my curiosity set in, Trys Mudford, a creator of Utopia, blogged it:
The value after the : in the CSS custom property does not have to be valid CSS. It won’t cause any errors, nor invalidate the custom property. It won’t be evaluated in the browser until used, or more specifically, placed in a calc() function.
Here’s a contrived example:
:root {
--padding: 1rem;
/* These are meaningless alone */
--padding-S: var(--padding) / 2;
--padding-L: var(--padding) * 2;
}
.module--large {
/* But they evaluate once they are in a calc() */
padding: calc(var(--padding-L));
}
In my limited understanding, currying is like functions that return functions. I suppose this is sorta like that in that the alternate padding properties above are sort of like derivative functions of the main padding function (if you can call it that), and you only call them and execute them as needed.
every 
