I’ve recently found myself reaching for Eleventy (aka 11ty) above all other tools when I want to develop a website. It’s hard to beat a static site generator that provides advanced templating opportunities while otherwise getting out of your way and allowing you to just create.

One of those sites is Style Stage, a modern CSS showcase styled by community contributions. Eleventy was perfect for this community-driven project in several ways:

• Its exceptionally fast builds locally and on a production host
• It’s un-opinionated about how to construct templates
• Its ability to create any file type with complete control over how and where files are rendered
• Its ability to intermix templating languages, such as HTML, Markdown, and Nunjucks
• It’s highly performant because it compiles to static HTML with no required dependencies for production

The number one reason Eleventy is a great choice for creating a community-driven site is the ability to dynamically create site pages from data sources. We’ll review how to use this feature and more when we create our sample community site.

What goes into creating a community-driven site?

In the not-so-distant past, creating a community-driven site could potentially be a painful process involving CMS nightmares trying to create contributor workflows. Armed with Eleventy and a few other modern tools, this is now nearly fully automatable with a minimum of oversight.

Before we get to inviting contributors, we’ve got some work to do ourselves.

1. Determine what content contributors will have access to modify

This will guide a lot of the other decisions. In the case of using Eleventy for Style Stage, I created a JSON file that contributors can use to create pull requests to modify and provide their own relevant metadata that’s used to create their pages.

Perhaps you also want to allow access to include additional assets, or maybe it makes sense to have multiple data files for the ease of categorizing and querying data. Or maybe contributors are able to add Markdown files within a particular directory.

Consider the scope of what contributors can modify or submit, and weigh that against an estimate of your availability to review submissions. This will help enable a successful, manageable community.

GitHub actions can make it possible to label or close a pull request with invalid files if you need advanced automated screening of incoming content.

2. Create contributor guidelines

Spending time upfront to think through your guidelines can help with your overall plan. You may identify additional needed features, or items that can be automated.

Once your guidelines are prepared, it’s best to include them in a special file in your GitHub repository called CONTRIBUTING.md. The all-caps filename is the expected format. Having this file creates an automatic extra link for contributors when they are creating their pull request or issues in a prompt that ask them to be sure they’ve reviewed the guidelines:

How to handle content licensing and author attribution are things that fall into this category. For example, Style Stage releases contributed stylesheets under the CC BY-NC-SA license but authors retain copyright over original graphics. As part of the build process, the license and author attribution are appended to the styles, and the authors attribution metadata is updated within the style page template.

You’ll also want to consider policies around acceptable content and what would cause submissions to be rejected. Style Stage states that:

Submissions will be rejected for using obscene, excessively violent, or otherwise distasteful imagery, violating the above guidelines, or other reasons at the discretion of the maintainer.

3. Prepare workflow and automations

While Eleventy takes care of the site build, the other key players enabling Style Stage contributions are Netlify and GitHub.

Contributors submit a pull request to the Style Stage repo on GitHub and, when they do, Netlify creates a deploy preview. This allows contributors to verify that their submission works as expected, and saves me time as the maintainer by not having to pull down submissions to ensure they meet the guidelines.

All discussion takes place through GitHub. This has the added advantage of public accountability which helps dissuade bad actors.

If the contributor needs to make a change, they can update their pull request or request a re-deploy of the branch preview if it’s a remote asset that has changed. This re-deploy is a very small manual step, and it may not be needed for every PR — or even at all, depending on how you accept contributions.

The last step is the final approval of the PR and merging into the main branch. Once the pull request is merged, Netlify immediately deploys the changes to production.

Eleventy is, of course, a static site generator, and several hosts offer webhooks to trigger a build. Netlify’s build plugins are a good example of that. But if you need to refresh data more often than each time a PR is merged, one option is to use IFTTT or Zapier to set up daily deploys, or deploys based on a variety of other triggers.

It’s worth noting that what we’re talking about here does limit your contributor audience to having a GitHub account. However, GitHub contributions can be done entirely via the web interface, so it’s very possible to provide guidance so that other users — even those who don’t code — can still participate.

4. Choose a method for contributor and community updates

The first consideration here is to decide how critical it is for contributors to know about updates to your site by evaluating the likely impact of the change.

In the case of Style Stage, the core will be unchanging, but there is some planned optional functionality. I went with a weekly(-ish) newsletter. That way, it is something folks can opt into and there is value for contributors and users alike.

Matthew Ström’s “Using Netlify Forms and Netlify Functions to Build an Email Sign-Up Widget” is a great place to learn how to add subscribers to your newsletter with a static form in Eleventy. It also covers a function for sending the subscriber’s email to Buttondown, a lightweight email service. For an example of how to manage your Buttondown email template and content in Eleventy, review the Style Stage setup which shows how to exclude the newsletter from the published site build.

If you’re only expecting low priority updates, then GitHub’s repo notifications might be sufficient for communication. Creating releases is another way to go. Or, hey, it’s even possible to to incorporate notifications on the site itself.

5. Find and engage with potential contributors

Style Stage was an idea that I vetted by tossing out a poll on Twitter. I then put out a “call for contributors” and engaged with responders as well as those who retweeted me. A short timeline also helped find motivated contributors who helped Style Stage avoid launching without any submissions. Many of those contributors became evangelists that introduced Style Stage to even more people. I also promoted a launch livestream which doubled as promotional material.

This is what it means to “engage” with contributors. Creating avenues for engagement and staying engaged with them helps turn casual contributors into “fans” who encourage others to participate.

Remember that the site content is a great place to encourage participation! Style Stage dedicates its entire page to encouraging submissions. If that’s not possible for you, then you might consider using prompts for contributions where it makes sense.

6. Finalize repo settings and include community health files

Finally, ensure that your repository is published publicly and that it includes applicable “community health” files. These are meant to be documents that help establish guidelines, set good expectations with community members, define a code of conduct, and other information that contribute to the overall “health” of the community. There are a bunch of examples, suggestions and tips on how to do this in the GitHub docs.

While there are a half dozen files noted in the documentation, in my experience so far, the three files you’ll need at minimum are:

• a README.md file at the root of the project that includes the project’s name and a good description of what it is. GitHub will display the contents below the list of files in the repo.
• a CONTRIBUTING.md file that describes the submission process for contributions. Be explicit as far as what steps are involved and what constitutes a “good” submission.
• a pull request template. I wouldn’t exactly say this is a mandatory thing, but it’s worth adding to this list because it further solidifies the expectations for submitting contributions. Many templates will even include a checklist that details requirements for approval.

Oh, and having a branch protection rule on the main branch is another good idea. You can do this by going to Settings ? Branches from the repo and selecting the “Add rule” option. “Require pull request reviews before merging” and “Require review from Code Owners” are the two key settings to enable. You can check the GitHub docs to learn more about this protection.

Coming up next…

What we covered here is a starting point for creating a community-driven site with Eleventy. The point is that there are several things that need to be considered before we jump straight into code. Communities need care and that requires a few steps that help establish an engaged and healthy community.

You’re probably getting anxious to start coding a community site with Eleventy! Well, that’s coming up in the next installment of this two-parter. Together, we’ll develop an Eleventy starter from scratch that you can extend for your own community (or personal) site.

---

The post A Community-Driven Site with Eleventy: Preparing for Contributions appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

Agile is a procedure by which a team can deal with a project by separating it into a few stages and including steady coordinated effort with stakeholders and consistent improvement and emphasis at each phase of the task. It starts with clients laying out how the finished result will be utilized and what issue it will resolve.

What is Scrum?

1. Scrum is a subset of Agile. It is a lightweight process framework for agile development, and one of the most widely used one.
2. It’s not a process or methodology.
3. Easy to understand.
4. Based on Empiricism which means that scrum artifacts should be transparent to everyone in the team.

Principles of Agile

1. To fulfil the client through right on time and continuous use of important software.
2. To cater to changing requirements, even late in app development.
3. Delivering working software frequently.
4. Stakeholders work with the scrum team together throughout the project so as to avoid any communication gaps.
5. The most efficient way of communicating information within the team is face-to-face conversation.
6. The progress of work is measured by working software.
7. Continuous attention is paid to technical excellence.
8. Due to the self-organizational team structure, the best architectures, designs, and ideas come up.

Empiricism

1. Transparency:- All artifacts of the process should be visible to the stakeholders and the scrum team. Due to transparency, they can inspect the current state of the project and take necessary action if needed.
2. Inspection:- Having regular inspections of artifacts will help the stakeholders to incorporate changes in order to achieve the goal.
3. Adaptation:- Improvements can be made by adjusting the process based on the inspection results.

Scrum is Iterative and Incremental

First one – Incremental
Second one – Iterative

Incremental:- This type of development is to build small increments of the entire product. Each increment adds more features to the product. After multiple increments, you will get the complete product.

Iterative:- This development is to build something, take some feedback, and then refining to make it better. This will keep happening until we receive the product of good quality.

The Scrum Team:

1. The Product Owner.
2. The Development Team.
3. The Scrum Master.

The Product Owner

The product owner is liable for augmenting the estimation of the product and work of the development group.

1. Clearly describing the Product backlog items.
2. Responsible for managing the product backlog.
3. To ensure the PBI is visible and clear to all.
4. To ensure the requirement is understood by all to the level it is required.
5. Accountable for building high-value products.
6. Ordering of Product backlog items to achieve the best goals.
7. Responsible for understanding and answering all questions pertaining to the product domain.
8. Responsible for tracking the release progress.
9. Liable for making and dealing with the release plans.
10. Liable for making and building up the product vision.
11. Enhancing the estimation of work done by the development team.

The Development Team

The Development Team comprises experts who accomplish crafted by conveying a conceivably releasable Increment of “Done” product at the end of each Sprint.

1. Cross-functional and self-organizing.
2. Participates in all scrum events.
3. Responsible for creating the product increment.
4. Collaborates with the Product Owner for optimal value.
5. Responsible for identifying and eliminating technical debts.
6. Liable for creating and coordinating the sprint backlog.
7. Responsible for implementing good engineering practices.
8. Helps product owners in backlog management by explaining the technical constraints.
9. Answerable for learning all the functions required to convey a product increment.
10. Answerable for following the advancement of the sprint.

The Scrum Master:

The scrum master is responsible for ensuring that Scrum is understood and enacted by all. He ensures that the scrum team adheres to Scrum practices and rules.

1. He is a servant- leader to the scrum team.
2. Responsible for building the product fast by eliminating impediments.
3. Goes about as a change agent that builds the productivity of the scrum team.
4. Mentors the development team for self-organization and cross-functionality.
5. Helps the product owners prioritize the work and teaches stakeholders value-based prioritization.
6. Facilitates Scrum events as requested or required.
7. Finds and teaches techniques for effective product backlog management to the product owners.
8. Enables workers and partners of the association to comprehend and institute Scrum and experimental product development.
9. Assists with streamlining the outside connection with the scrum group to amplify the value created.

Scrum Events

All occasions are time-boxed occasions, with the end goal that each occasion has a maximum duration. When a Sprint starts, its span is fixed and can’t be abbreviated or extended.

The remainder of the events may end at whatever point the explanation behind the event is accomplished, ensuring an appropriate proportion of time is spent without allowing waste at the same time.

The Sprint

The core of Scrum is a Sprint, a time-box of one month or less during which a “Done”, usable, and possibly releasable product Increment is made.

1. Sprint Planning:- A time-boxed event that occurs at the beginning of every sprint where the team determines the product backlog items they will work on during the sprint.
2. Daily Scrum:- It’s a brief time-boxed occasion for the development group to synchronize exercises and make an arrangement for the following 24 hours.
3. Sprint Review:- This is again a time-boxed event that occurs at the end of every sprint to inspect the increment and adapt the product backlog if needed.
4. Sprint Retrospective:- This occasion gives a chance to the team to review itself and make an arrangement for enhancements to be done in the following sprint

Scrum Artifacts

Scrum Artifacts speak to work or incentive to give transparency and chances to investigation and transformation. Artifacts have been planned with a reason that everyone has a similar comprehension of the artifact.

1. Product Backlog:- An arranged rundown of everything that may be required in the product which is the single wellspring of necessities for any progressions to be made to the item. The Product Owner is liable for the Product Backlog, including its content, accessibility, and ordering.
2. Sprint Backlog:- The arrangement of Product Backlog things chose for the Sprint alongside an arrangement for conveying the item increase and understanding the run objective.
3. Product Increment:- The whole of all the Product Backlog things finished during a Sprint and the estimation of the additions of every past Sprint is called item increase.
4. Product Backlog Refinement:- The ongoing product backlog refinement takes place within each sprint to refine items to be ready for future sprints.

Scrum Values

1. Commitment:- It is a team activity where you and your team are accountable to work together and confirm your team commitments. The scrum teams must be committed to progress and stick to the goal of the project.
2. Focus:- Once the requirements are clear and the target is set, one should be goal-oriented which motivates you for delivering faster and better.
3. Openness:- Colleagues ought to be open about their work, progress, what they realized and the issues they are confronting. Additionally, you ought to be available to work with partners, perceiving people to be people, and not resources, robots, or replaceable bits of equipment.
4. Respect:- As a piece of the Scrum group, you should regard partners, their choices, and their experience. You should regard your partners by not building anything in which individuals are not intrigued. You have to similarly regard your clients by settling their issues.

Courage:- Flexibility to change shapes the bedrock of any Scrum project and to acknowledge a change, fearlessness is required. Scrum is tied in with facing challenges and discovering an improved arrangement. The Scrum group is permitted to consider various ways to deal with the workshop the best and most proper arrangements. So as to execute new things to the undertaking, we have to disclose these new plans to the group for which you would require fearlessness.

---

Photo by Glenn Carstens-Peters on Unsplash

As you move forward in your career, your logo designing skills should be honed as well if you keep practising it. However, to come up with something extraordinary, that would create a striking impression; simply practising is not enough.

Listed below are 5 steps that can help you improve your logo designing skills and create a logo that leaves a lasting impression on the minds of your target audience.

1. Conduct In-depth Research

Logo design is not about mixing and matching a few colours and making it look pretty. It may sound clichéd but a logo is the face of your brand and thus it should have all the correct elements that would click with the audience. Thus, in-depth research is extremely important. From your client to their brands and their competitors, as a logo designer, you need to keep your game up and see what you can do to come up with a dynamic logo or may improve their existing one.

Thorough research means that you understand the company and the brand and what it does. Similarly, you need to be aware of the competition as well. Research of all the related sources from their website to social media platforms, everything should come under your scrutiny. You must be wondering why to study social media platforms? Well, it is the best place to learn about the targeted audience and what they want from your client.

2. Deep & Probing Questions

If you are working on your logo yourself or you have been asked to improve an existing logo of a brand, the second most important thing after the research is to ask deep and probing questions that would help you create their custom logo. Probe deeply and find out the vision behind the brand and what exactly do the leaders in the company perceive about it.

From the target audience to the ideas for growing the business, you need to ask everything. Ask about the brand’s competition, long-term goals and even if some questions seem irrelevant, it is essential that you ask the questions anyway as it will only add to the improvement in designing a custom logo.

3. Mobile-Oriented

The third most important step when it comes to logo designing or tweaking is; that it should be customized for the mobile phones. Whether you are designing a logo from scratch or improvising an old one, both should be customized according to the requirements of the mobile phones. When you are conducting the research, you will realize that many companies have simplified and flattened their logos to make it easier to see on the mobile screens. From Facebook, Instagram, Microsoft and eBay and many more have adopted this strategy and minimalized their logos.

The reason behind all tech giants adopting this element is that mobile phones have become more popular for online navigation than desktops and laptops and too complex designs can lose their impact on the mini-screens of cell-phones. To keep the logo recognizable, it is of utmost importance to keep the logo identifiable and minimal for the small mobile screen.

4. Step Out from Comfort Zone

Want to phenomenally improve your logo design or polish up your skills to an extraordinary level? Then, the font that you use can make all the difference. A unique and distinctive font can become your brand’s identity and set it apart from the competition. Take the example of the Harry Potter franchise. The unique font that was introduced in the first Harry Potter movie more than twenty years ago is a trademark for the brand. The audience automatically associates that particular font with everything that has to do with HP franchise. New fonts are being introduced every now and then, and you can also find one that really identifies with the brand you are working on.

If you think that you will have to pay for the new fonts, then it is a misconception. With tools like Adobe Illustrator, you can tinker with various font styles without having to spend money on them. Some others even offer trial services before you purchase the actual thing. So, go ahead and experiment with fonts for some inspiration. You don’t have to necessarily spend a lot of money to take advantage of new fonts, either.

5. Study the Maestros

When you go online, there is myriad of logo designs and there are galleries full of it. However, not all these designs are done by gurus in the field. In fact most of them are the creation of students and amateur designers. To get true inspiration, you must study the maestros in the field and only then will you be able to improve your logo design.

When it some to learning, do not compromise; learn from the most phenomenal maestros in the field – the big brand logos. Don’t settle for less than the best when it comes to logo designs and get your inspiration from those who have managed to persist even after the arrival of all the new technology. Whatever you do, you need to remember that when it comes to log design, your targeted audience will never pay attention to its minute details. On the contrary, they will just glance at it for milliseconds and that’s the time you have to make an impression. Keeping your designs minimal yet impactful, it needs to touch a chord with the subconscious human instincts at their most primal level. Whatever you do, always design or improvise the designs keeping the human audience in mind. They are no experts of all the intricacies in your design. They need to connect with the brand on a psychological level with a few milliseconds.

This is what you can see when it comes to the logos of famous brands like Nike, Coca-Cola, McDonald’s or even the tri-petal design of Adidas. Simply put, try to understand the psychology of the audience you are targeting and you will be able to establish yourself as an extraordinary logo designer and improve your logo designs phenomenally.

---

Photo by Diego PH on Unsplash

While a lot of the research for web designers that’s come out this year has to do with COVID-19, we’re starting to see a light at the end of the tunnel. Many of these reports aren’t just looking at the effects of the pandemic on business and marketing today. They’re now looking at what consumers plan to do once the pandemic is gone.

So, I have some very interesting research for you here today. Three of the reports have to do with coronavirus side effects — pertaining to ecommerce, market research, and freelancing — and one of them is just a really great argument against using PDFs on websites.

1. The Digital 2020 Survey Says Ecommerce Growth Will Continue Post-Coronavirus

Obviously, everyone is paying close attention to COVID-19’s impact on the world. For the purposes of the work you do as a web designer, you should be clued into what it’s doing to the business and marketing fields. Because, if those opportunities dry up or companies begin to pivot, you need to be ready to adapt.

The Digital 2020, a joint monthly report from we are social and HootSuite, brings interesting news about the state of ecommerce thanks to COVID-19.

Because the pandemic has forced consumers indoors, online shopping has increased. But, according to about half of those surveyed for this report, this isn’t some temporary solution. They plan on doing more online shopping even after the pandemic ends.

This means that web designers are sitting in an enviable position now and for the foreseeable future. If you’re not already helping businesses sell through their websites, now is the time to do so as more and more businesses are going to need reliable online stores to sell their offerings through.

2. eMarketer Shares Data on Social Listening

When conducting research at the beginning of a design project, what kinds of sources do you turn to for quick and reliable information? Your client provides you with information on their business, industry, and the competition, of course, but what else?

You can conduct user surveys and interviews, but those take time and resources. It also usually means working with clients who have existing businesses and user bases to tap into. Unless you’re working as a UX designer where that’s a big part of the work you do, you might not have the ability to do that level of research.

As reported by Gartner (via eMarketer), leading marketers are now learning about their target audiences through the following channels:

Thanks to the surge of traffic online right now, social listening platforms have become really useful resources for learning about one’s users, with 51% of marketing leaders using them.

If you feel as though your initial research and planning phases could use a boost, I’d recommend taking advantage of one of these social listening tools now.

If you build websites for a specific niche, you can set up keywords/hashtags that are universally relevant to (most of) your clients. By listening in on these conversations regularly, you can become more attuned to what the visitors of your websites actually need and you can proactively build better experiences for them as a result.

3. Upwork Reports Increasing Numbers of Freelancers Entering the Market

The main focus of the Upwork 2020 Future Workforce Report is on how employers are changing their approaches to hiring now and in the near future. And the basic premise is this:

• It’s long been predicted that more and more of the workforce would be allowed to work remotely.
• COVID-19 has escalated those predictions to the point where most of the workforce is remote right now.
• Businesses see the value in remote work arrangements, especially if it enables them to get work done more quickly and cost-effectively by freelancers.

While this is certainly great news for web designers looking for new clients, the report also provides us with this data:

64% of professionals in the top of their field work independently. That statistic alone means you’re up against some tough competition. But there’s also the 50% rise in signups on freelancer marketplaces that should have you worried.

Even though business demand for freelance talent is growing, this unprecedented rise in freelance competition may pose some problems. So, if you’re not already doing everything you can to position yourself as the web designer in your niche, get going on that now so you don’t get drowned out by the rising number of competitors.

4. NNG Says That PDFs Are Unsuitable for the Web

While I don’t have statistics to share with you from the Nielsen Norman Group’s post on why the PDF is “Still Unfit for Human Consumption”, I do have a ton of usability arguments against them that are worth summing up here:

1. PDFs are written in the style of print documents, which means that strategies we use to design content on websites — like making a page scannable and accessible — don’t apply.
2. They’re not designed to be as concise or attractive as a web page.
3. They don’t operate like a website, which disrupts the seamless experience you’ve worked so hard to create when one is opened up from your site.
4. The website navigation disappears and any sense of orientation (besides the browser “Back” button) goes out the window.
5. There’s no way to build an internal navigation in a PDF document, save for internal linking or a table of contents.
6. If they’re formatted for paper sizes, scrolling through them can be difficult for mobile users.
7. They load more slowly the bigger they get, so unless it’s something like a small and optimized menu, expect visitors to wait for the download to appear.

And those are just the arguments that came from NNG’s researchers. Take some time to read through real user complaints about PDFs and you’ll never want to include one on a client’s website again.

Wrap-Up

Thankfully, the research for web designers and marketers is finally starting to move away from the confusion and speculation we saw a lot of earlier this year.

Just as with anything we do on the web, the more time you give it, the more data you can collect. And, luckily for us, the data suggests that there’s a pretty positive outlook for web designers if they position themselves the right way now.

Featured image via Unsplash.

Source

Many website owners falsely think that their websites are going to work perfectly forever. However, in reality, all websites eventually break. This happens because sites are running out of date, plugins stop working, or as a result of a cyberattack. If you want to avoid these issues altogether, the solution is rooted in regular digital health checks. In this article, I’ll focus on the simple and inexpensive website health check ways that will help your website run flawlessly!

What is a website health check and why do you need one?

A website health check implies breaking down the anatomy of your website to evaluate the functionality, performance, and design of your web pages. Here’s why it’s important to conduct regular website health checks.

Any change that you make on your pages somehow affects the overall health of your site. Let’s say, you’ve decided to add a second Spanish version of your website. This can influence the speed and overall performance of your site. That’s why designing and implementing a regular website maintenance check is an absolute must.

Not particularly sure where to begin your site’s health check? No worries, we’ve got you covered. Here’s a list of the four essential factors to make sure your website is healthy.

1. Performance testing

Did you know that 53% of users will leave your website if it doesn’t load within 3 seconds? Moreover, studies show that website speed directly impacts business’ profitability.

This way, your website’s speed and performance are the key factors contributing to the revenue generated and your overall success.

Performance testing is considered a part of a website’s health check and one of the most challenging testings. Performance testing is executed to test the responsiveness, speed, scalability, and throughput of your website.

There are many ways to carry out performance testing. For example, you can use dedicated online tools and browser extensions.

2. SEO testing

Search engine optimization (SEO) is another important aspect of your website. Your site’s ranking and discoverability in search engines can play a major role in the overall success of your website and your business in general. That’s why you want to ensure your SEO is in place as a part of the website health check.

Regular SEO testing will help you identify the best SEO tactics for your business. In the meantime, simple SEO practices will help you keep your site healthy. For example, by regularly updating your web pages and images, you can boost your ranking on Google and get rid of the outdated content.

3. Security checking

As more businesses are operating online, there is a growing threat of cyberattacks. In fact, studies show that 68% of business leaders feel that cybersecurity risks are increasing. That’s why ensuring security is a crucial step towards a healthier website.

As much as we all rely on the web, it’s not exactly the safest place. Your website may be exposed to cyberattacks by accident or by mistake. For example, you can install a plugin without even knowing that it’s carrying malware. In the meantime, the faulty plugin is infecting your website and puts the entire system at risk.

To keep your website safe and keep off cybercriminals, you need to check and update your website regularly. Use website security checking tools that can enable you to do the following:

• Detect viruses and malware
• Detect phishing attacks, ActiveX attacks, buffer overflow, and other vulnerabilities
• Check user IPs against various spammer databases
• Detect whether or not your SSL certificate expires soon
• Manage regular website updates

4. Broken links testing

Besides performance, SEO, and security checking, there is another aspect commonly overlooked when checking website health – links.

The web consists of a plethora of links that are used to locate and connect pieces of information. A single website can have hundreds and even thousands of links. However, when these links become broken, it will affect your website’s speed and overall performance.

Links do so much more than just sending users to your website. They are accountable for displaying graphics, data, and various applications.

Here’s a list of links you should keep an eye for when checking your website health:

• External links to other websites
• Internal links to your images
• Internal links to pages

Tools for website health checks

Gathering required information that can show you the problem areas is the first step of the website health checking. Once all of the needed data has been collected, the next step is to take the required actions to fix the problems.

Here are some tools you can use to check your website’s health.

Google Search Console

Google Search Console is a free tool that helps you monitor, maintain, improve your website’s presence in Google Search results. Since there are no clear guidelines on how Google’s ranking algorithms work, Google Search Console is an invaluable tool that can help you understand and advance how Google sees your website.

Google Search Console allows you to troubleshoot the following issues:

• XML sitemap errors
• Structured data errors
• Broken links
• Robots.txt errors
• Mobile usability issues

PageSpeed Insights

Google PageSpeed Insights is another free tool that allows you to check the page speed of your website. Besides, it shows you various factors affecting the speed, so you know what needs adjustment.

Ahrefs

Ahrefs is an SEO toolset that can help you monitor the status of your backlinks and referring domains. The tool enables you to record the number of backlinks and referring domains gained, broken, or lost. This way, you can contact the website to identify and solve the problem with backlinks.

Wrapping it up!

When you build a pro website, it’s important to keep it updated and conduct regular website health checks. Essentially, you have to follow a two-step process that includes collecting all health-check tools and then implementing required fixes.

Before you go, let’s quickly wrap up what you’ve learned today about the four essential ways to check your website’s health:

1. Performance testing is a fundamental part of any website health check and includes testing the website’s responsiveness, speed, scalability, and throughput.
2. SEO testing allows you to monitor the status of your site and improve ranking.
3. Regular security checking can help you identify and troubleshoot malicious threats to your site.
4. Broken links testing allows you to find faulty links and keep your website updated.

Keeping your website healthy doesn’t have to be rocket science. The key ingredient lies in regular health checks. By following these four practices and using dedicated tools, you can take it a step further and ensure your website’s health at all times!

---

Infographic vector created by katemangostar – www.freepik.com

I had someone write in with this very legit question. Lea just blogged about how you can get valid CSS properties themselves from the browser. That’s like this.

That gives you, for example, the fact that cursor is a thing. But then how do you know what valid values are for cursor? We know from documentation that there are values like auto, none, help, context-menu, pointer, progress, wait, and many more.

But where does that list come from? Well, there is a list right in the spec so that’s helpful. But that doesn’t guarantee the complete list of values that any given browser actually supports. There could be cursor: skull-and-crossbones and we wouldn’t even know!

We can test by applying it to an element and looking in DevTools:

But unless we launch a huge dictionary attack against that value, we don’t actually know what values it directly in-browser. Maybe Houdini will help somehow in browsers getting better at CSS introspection?

You can also use the CSS object to run tests like CSS.supports(property, value):

You’d think we could have like CSS.validValues("text-decoration-thickness") and get like ["", "", "auto", "from-font"] or the like, but alas, not a thing.

---

The post Can you get valid CSS property values from the browser? appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

I was working on a thing the other day that needed a visible timer. There was UI precedent for this type of timer on the project. People didn’t want to see numbers ticking downward; it was more ideal to see a “bar” drain away from full to empty. I mention that because there are tons and tons of ways you could approach a “timer” UI. This isn’t an exploration of all of those (a search on CodePen would be more helpful there), but an exploration of the one way that was useful to me.

The kind of timer I needed was what the project called a “round time” bar. An action is performed. It may cause a round time, and most further actions are blocked until the round time is over. So, a very clear red bar that ticks away was the right UI. It gives a sense of rhythm and flow where you can kinda feel the end of the timer and time your next action.

Setting this up is fairly easy…

Let’s give ourselves a parent/child thing, just in case we want to style the empty part of the container at some point.

<div class="round-time-bar">
  <div></div>
</div>

For now, let’s just style the bar inside.

.round-time-bar div {
  height: 5px;
  background: linear-gradient(to bottom, red, #900);
}

That gives us a nice little red bar we can use for the time indicator.

Next we need to make it tick down, but here’s where we need to think about functionality. A timer like this needs to know how long it’s timing! We can give it that information right in the HTML. This doesn’t mean we’re avoiding JavaScript — we’re embracing it. We’re saying, “hey JavaScript, please give us the duration as a variable and we’ll take it from there.”

<div class="round-time-bar" style="--duration: 5;">
  <div></div>
</div>

In fact, this way is very friendly to modern DOM-handling JavaScript. As long as that --variable is correct, it is free to re-render that DOM element at any time and we can make sure the design handles that just fine. We’ll make a variation that does that.

For now, let’s make the animation happen. Good news, it’s easy. Here’s a one-liner keyframe:

@keyframes roundtime {
  to {
    /* More performant than animating `width` */
    transform: scaleX(0);
  }
}

We can “squish” the bar because the design of the bar doesn’t have anything that will look squished when we scale it horizontally. If we did, we could animate the width. It’s not that big of a deal, especially since it doesn’t reflow anything else.

Now we apply it to the bar:

.round-time-bar div {
  /* ... */
  animation: roundtime calc(var(--duration) * 1s) steps(var(--duration)) forwards;
  transform-origin: left center;
}

See how we’re yanking that --duration variable to set the duration of the animation? That does the heavy lifting. I’m also using it to set the same number of steps() so it “ticks” down. That “ticking” might be a visual UI thing that you like (I do), but it also accommodates the idea that JavaScript might re-render this bar at any time, and the ticks make it so you are less likely to notice. I used an integer for the duration value so that it could do double-duty like this.

If you want a smooth animation though, we could do that as a variation, like:

<div class="round-time-bar" data-style="smooth" ... />

Then not do the steps:

.round-time-bar[data-style="smooth"] div {
  animation: roundtime calc(var(--duration) * 1s) linear forwards;
}

Note we’re also using a linear animation, which seems to make sense for a timer. Time, as it were, doesn’t ease. Or does it? Whatever, it’s your call. If you want a timer that appears to speed up or slow down at certain points, go for it.

We can use the same variation data-attribute-driven API for things like color variations:

.round-time-bar[data-color="blue"] div {
  background: linear-gradient(to bottom, #64b5f6, #1565c0);
}

And one final variation is making each “second” a fixed width. That way, a 10 second timer will literally look longer than a 5 second timer:

.round-time-bar[data-style="fixed"] div {
  width: calc(var(--duration) * 5%);
}

Here’s the demo:

Notice the little trick in there for restarting CSS animation.

Oh, and hey, I know there is a element which is maybe a bit more semantic, but it brings it’s own UI which isn’t animatable like I wanted things to be here — at least not without fighting it. But I wonder if it’s more accessible? Does it announce its current value in a useful way? Would it be a more accessible timer if we were updating a in real-time with JavaScript? If anyone knows, I can link up a solution here.

---

The post Timer Bars in CSS with Custom Properties appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

Every business owner wants more conversions.

More conversions equal more sales, and more sales mean exponential business growth. But netting those conversions can prove challenging, especially if your website is not in the best shape.

This is where web design plays a major role.

The web design concepts you utilize directly impacts growth and how many of those coveted conversions your business racks up.

Let’s say your SEO is on point, but conversions are lacking. Yes, optimization is a must-do for your website.

Unfortunately, if you’re not converting site visitors, all is for not.

From New York to Houston, a web design agency could be useful to fix that conversion problem. But you can certainly develop a web design plan starting today.

This is why we compiled the following 6 web design concepts proven to increase conversions.

Let’s dive in!

1. Grab Attention In 8 Seconds Or Less

The human attention span has been compared to that of goldfish.

This may be a myth, but there is no denying that online consumers have a very short attention span.

To ensure you lead potential customers down the path toward conversions, you need to grab their attention fast.

The 8-second rule is a web design concept that can help you increase conversions.

This small window of opportunity is critical, so make it count, because you are on the clock.

For example, you can employ creative imagery to grab attention, like this example from Mailchimp:

This artistic image has little to do with email marketing, the core of Mailchimp’s business. However, it is so unique, it catches the site visitor’s eye quickly.

Other web design assets for grabbing attention in under 8 seconds include:

• Large signup and CTA buttons
• Power words and clever terms that are engaging
• Video and other interactive content
• Hover effect on buttons and links
• Animated transitions in sections
• Pop-ups that add value to the site visitor
• Big benefit headlines that are concise

Web design is not solely about making Google happy. A clever design that grabs attention quickly can have a serious positive impact on your conversion rate.

2. Encompass Speed And Increase Conversions

“Most industries are highly competitive, and to gain a competitive advantage in your market, you need to have a fast website. This is a search optimization (SEO) essential that is tethered to web design.

This is especially so for image search and compatibility with Google’s spiders. If images & design are slow to render, Google views that as an unfavorable compared to your competitors in a particular SERP” says Matt Bertram, co-host of BestSEOPodcast.

Let’s face it: A consumer’s attention span is pretty low. But not as low as his or her patience level. Did you know that a one-second delay in page loading can decrease your conversion rates by 7 percent?

Is your website fast enough to keep potential customers on-page and off your competitors’ pages? To find out, you can utilize a few different speed check platforms, such as Google PageSpeed Insights:

Pingdom is another good site speed platform you can use to get insight on just how fast your website is, on desktop and mobile, as well as info on what you can do to fix poor page load time.

3. The “Rule Of Thirds” Is Also A Web Design Concept

The Rule of Thirds is a very important photography concept that can also be used in web design.

What is the Rule of Thirds exactly?

This web design concept divides a screen by thirds horizontally and vertically.

The intersections created by this division become very important strategic points.

The Rule of Thirds looks like this for web design:

You can see that the intersecting lines are more enticing to the eyes. This could be why the Apple web design team placed the iPhone image directly in the middle of the bottom horizontal line.

The price point also sits strategically between the two top intersection points, just above the horizontal line:

The Rule of Thirds can help you design each section of your website with strategic focal points in mind. You can place CTAs on these intersection points, key marketing messages, product images, and more.

4. Maximize Conversions With Powerful Color Design

Color remains an essential part of quality web design, especially when it comes to increasing conversions. But choosing the right color scheme for your website, and subsequently, your brand can prove a bit difficult.

There are a ton of colors to choose from, but you should consider employing a bit of color psychology. That’s right, consumers are more motivated to buy from a website based on the color scheme used.

Here’s a color wheel you can use:

Most consumers don’t even know that color played a role in the purchase. For example, a HealthTech website will need to convey trust, empathy, and security on their website to increase conversions. The colors used could be:

Using this color psychology, a website in the HealthTech industry can convey confidence to buy or signup quickly using a subconscious psychological connection.

However, do not just pick a few colors and start developing your website. Quality web design using color means utilizing the power of contrast as well.

Contrast will ensure headlines, CTAs, and text standout against your primary brand colors.

Contrast looks like this in web design:

You can see how HubSpot used contrast and a mixup of their primary brand colors to create a visually aesthetic website that also serves up a psychological connection.

5. Employ The Law Of Similarity (Gestalt Principle)

The Law of Similarity, Gestalt Principle, is another web design concept worth employing to increase conversions.

How? The Law of Similarity states that the human eye groups similar objects, which enables the human brain to make sense and organize what we see.

This is important for web design since websites have multiple aspects. By grouping together these aspects using the Law of Similarity, site visitors can easily and quickly process website information and make a purchasing decision.

For example, you can group testimonials with CTA buttons to drive more conversions. Here’s how this looks on a website using the Law of Similarity:

You also serve up a powerful user experience when using the Law of Similarity as a web design concept. By having main aspects of your site grouped, like headline, paragraph text, and CTA, information is much easier to process for the visitor.

6. Increase Conversions By Using Real People In Images

To make your business more familiar, it is essential to put real people front and center.

Most consumers can tell a stock image from a unique one, so having the people of your business front and center on your website can make the difference between conversion, or lost customer.

This supports the current shift in marketing messaging for brands. In fact, a study found that 80 percent of consumers are more likely to make a purchase from a business that provides a personalized touch. Images of you and your team can achieve this.

A good example small businesses can draw from is this image from Paradise Service Technologies:

You can see the people that represent this small business. Having a personalized, real-life touch within your web design is paramount.

Videos are also exceptional for delivering these personalized moments consumers demand in today’s overly competitive market. The same website that served up the team image employed video content as well:

Are You Using Web Design Concepts To Increase Conversions?

Creating a website for your business is more than simply putting optimized text and images together.

You need to add that human element in order to net the conversions you want and need for growth and success.

The above 6 web design concepts can prove useful while revamping your website. You may choose a few to implement, or maybe even all.

Combining every web design concept, and more you find online can ensure that conversion rate continues to rise. Happy designing!

Read More at 6 Web Design Concepts Proven To Increase Conversions

Cutting to the chase: if you’re on a Business or Enterprise team on Netlify, you can click a build to make it run next in a queue. For example, if you have a really time-sensitive thing (e.g. a bug fix going to production), it can jump ahead of some random development branch building. Now I’ll elaborate.

Part of the rocketjuice of Netlify is that it runs your builds for you. Say you have a Jekyll site. The build command is probably jekyll build. You tell Netlify that’s the command you want it to run, and if successful, deploy it.

That build command is totally up to you. It could be npm run build and that calls the build command in your package.json which kicks off your custom scripts. Plus, with build plugins, you have a ton of control over the process (e.g. I got it to run Sass easily). That’s CI/CD!

Assuming you are linking up a Git repo, it’s not just pushing to your main branch where these builds runs — it’s on any branch. That’s great for a bunch of reasons. For one, your build is probably running tests too, so it’s keeping you honest. For another, Netlify gives each push a permalink to a deployed version of that exact set of code. That’s tremendously useful. It’s like staging on steroids. Anybody who needs it can get a preview of the site.

On certain projects, you might have a whole team of developers working on a bunch of branches, committing code, and running builds. So Netlify might be awful busy doing all that work. Your build might get stuck behind other people’s stuff. Maybe it absolutely doesn’t matter. Or maybe you have an important meeting in 2 minutes and you really need this deploy preview for everyone to see.

Now if you’re on a team (on a Business or Enterprise account), you can choose to hop the queue and have yours run next. People will be able to see it was you who did it so, ya know, ya gotta have a little courtesy.

---

The post Queue Jumping in Netlify appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

React is popular, popular enough that it receives its fair share of criticism. Yet, this criticism of React isn’t completely unwarranted: React and ReactDOM total about 120 KiB of minified JavaScript, which definitely contributes to slow startup time. When client-side rendering in React is relied upon entirely, it churns. Even if you render components on the server and hydrate them on the client, it still churns because component hydration is computationally expensive.

React certainly has its place when it comes to applications requiring complex state management, but in my professional experience, it doesn’t belong in most scenarios I see it used. When even a bit of React can be a problem on devices slow and fast alike, using it is an intentional choice that effectively excludes people with low-end hardware.

If it sounds like I have a grudge against React, then I must confess that I really like its componentization model. It makes organizing code easier. I think JSX is great. Server rendering is also cool—even if that’s just how we say “send HTML over the network” these days.

Still, even though I happily use React components on the server (or Preact, as is my preference), figuring out when it’s appropriate to use on the client is a bit challenging. What follows are my findings on React performance as I’ve tried to meet this challenge in a way that’s best for users.

Setting the scene

Lately, I’ve been chipping away at an RSS feed app side project called bylines.fyi. This app uses JavaScript on both the back and front end. I don’t think client-side frameworks are horrid things, but I’ve frequently observed two things about the client-side framework implementations I tend to run into in my day-to-day work and research:

1. Frameworks have the potential to inhibit a deeper understanding of the things they abstract, which is the web platform. Without knowing at least some of the lower level APIs that frameworks rely on, we can’t know what projects benefit from a framework, and which projects are better off without one.
2. Frameworks don’t always provide a clear path toward good user experiences.

You may be able to argue the validity of my first point, but the second point is becoming more difficult to refute. You might remember a little while ago when Tim Kadlec did some research on HTTPArchive about web framework performance, and came to the conclusion that React wasn’t exactly a stellar performer.

Still, I wanted to see if it was possible to use what I thought was best about React on the server while mitigating its ill effects on the client. To me, it makes sense to simultaneously want to use a framework to help to organize my code, but also restrict that framework’s negative impact on the user experience. That required a little experimentation to see what approach would be best for my app.

The experiment

I make sure to render every component I use on the server because I believe that the burden of providing markup should be assumed by the web app’s server, not the user’s device. However, I needed some JavaScript in my RSS feed app in order to get a toggleable mobile nav to work.

This scenario aptly describes what I refer to as simple state. In my experience, a prime example of simple state are linear A to B interactions. We toggle a thing on, and then we toggle it off. Stateful, but simple.

Unfortunately, I often see stateful React components used to manage simple state, which is a trade-off that’s problematic for performance. Though that may be a vague utterance for the moment, you’ll come to find out as you read on. That said, it’s important to emphasize that this is a trivial example, but it’s also a canary. Most developers—I hope—aren’t going to rely solely on React to drive such simple behavior for just one thing on their website. So it’s vital to understand that the results you’re going to see are intended to inform you on how you architect your applications, and how the effects of your framework choices could scale when it comes to runtime performance.

The conditions

My RSS feed app is still in development. It contains no third party code, which makes for easy testing in a quiet environment. The experiment I conducted compared the mobile nav toggle behavior across three implementations:

1. A stateful React component (React.Component) rendered on the server and hydrated on the client.
2. A stateful Preact component, also server-rendered and hydrated on the client.
3. A server-rendered stateless Preact component which was not hydrated. Instead, regular ol’ event listeners provide the mobile nav functionality on the client.

Each of these scenarios were measured across four distinct environments:

1. A Nokia 2 Android phone on Chrome 83.
2. A ASUS X550CC laptop from 2013 running Windows 10 on Chrome 83.
3. An old first generation iPhone SE on Safari 13.
4. A new second generation iPhone SE, also on Safari 13.

I believe this range of mobile hardware will be illustrative of performance across a broad spectrum of device capabilities, even if it’s slightly heavy on the Apple side.

What was measured

I wanted to measure four things for each implementation in each environment:

1. Startup time. For React and Preact, this included the time it took to load the framework code as well as hydrating the component on the client. For the event listener scenario, this included only the event listener code itself.
2. Hydration time. For the React and Preact scenarios, this is a subset of the startup time. Because of issues with remote debugging crashing in Safari on macOS, I couldn’t measure hydration time alone on iOS devices. Event listener implementations incurred zero hydration cost.
3. Mobile nav open time. This gives us insight into how much overhead frameworks introduce in their abstraction of event handlers, and how that compares to the frameworkless approach.
4. Mobile nav close time. As it turned out, this was quite a bit less than the cost of opening the menu. I ultimately decided not to include those numbers in this article.

It should be noted that measurements of these behaviors include scripting time only. Any layout, paint, and compositing costs would be in addition to and outside of these measurements. One should take care to remember that those activities compete for main thread time in tandem with scripts that trigger them.

The procedure

To test each of the three mobile nav implementations on each device, I followed this procedure:

1. I used remote debugging in Chrome on macOS for the Nokia 2. For iPhones, I used Safari’s equivalent of remote debugging.
2. I accessed the RSS feed app running on my local network on each device to the same page where the mobile nav toggling code could be run. Because of this, network performance was not a factor in my measurements.
3. Without CPU or network throttling applied, I began recording in the profiler, and reloaded the page.
4. After page load, I opened the mobile nav and then closed it.
5. I stopped the profiler, and recorded how much CPU time was involved in each of the four behaviors listed earlier.
6. I cleared the performance timeline. In Chrome, I also clicked the garbage collection button to free up any memory that may have been tied up by my app’s code from a previous session recording.

I repeated this procedure ten times for each scenario for each device. Ten iterations seemed to get just enough data to see a few outliers while getting a reasonably accurate picture, but I’ll let you decide as we go over the results. If you don’t want a play-by-play of my findings, you can view the results at this spreadsheet and draw your own conclusions, as well as the mobile nav code for each implementation.

The results

I initially wanted to present this information in a graph, but because of the complexity of what I was measuring, I wasn’t certain how to present the results without cluttering the visualization. Therefore, I’ll present the minimum, maximum, median, and average CPU times in a series of tables, all of which effectively illustrate the range of outcomes I encountered in each test.

Google Chrome on Nokia 2

The Nokia 2 is a low-cost Android device with a Snapdragon 212 processor. It is not a powerhouse, but rather a cheap and easily obtainable device. Android usage worldwide is currently around 40%, and though Android device specs vary greatly from one device to the next, low-end Android devices are not rare. This is a problem we must recognize as being one of both wealth and proximity to fast network infrastructure.

Let’s see what the numbers look like for startup cost.

Startup time

	React Component	Preact Component	addEventListener Code
Min	137.21	31.23	4.69
Median	147.76	42.06	5.99
Avg	162.73	43.16	6.81
Max	280.81	62.03	12.06

I believe it says something that it takes, on average, over 160 ms to parse and compile React, and hydrate one component. To remind you, startup cost in this case includes the time it takes for the browser to evaluate the scripts needed for the mobile nav to work. For React and Preact, it also includes hydration time, which in both cases can contribute to the uncanny valley effect we sometimes experience during startup.

Preact fares much better, taking around 73% less time than React, which makes sense considering how tiny Preact is at 10 KiB sans compression. Still, it’s important to note that the frame budget in Chrome is about 10 ms to avoid jank at 60 fps. Janky startup is as bad as janky anything else, and is a factor when calculating First Input Delay. All things considered, though, Preact performs relatively well.

As for the addEventListener implementation, it turns out that parse and compile time for a tiny script with no overhead is unsurprisingly very low. Even at the sampled maximum time of 12ms, you’re barely in the outer ring of the Janksburg Metropolitan Area. Now let’s have a look at hydration cost alone.

Hydration time

	React Component	Preact Component
Min	67.04	19.17
Median	70.33	26.91
Avg	74.87	26.77
Max	117.86	44.62

For React, this is still in the vicinity of Yikes Peak. Sure, a median hydration time of 70 ms for one component isn’t a big deal, but think about how hydration cost scales when you have a bunch of components on the same page. It’s no surprise that the React websites I test on this device feel more like endurance trials than user experiences.

Preact’s hydration times are quite a bit less, which makes sense because Preact’s documentation for its hydrate method states that it “skips most diffing while still attaching event listeners and setting up your component tree.” Hydration time for the addEventListener scenario isn’t reported, because hydration isn’t a thing outside of VDOM frameworks. Next, let’s take a peek at the time it takes to open the mobile nav.

Mobile nav open time

	React Component	Preact Component	addEventListener Code
Min	30.89	11.94	3.94
Median	43.62	14.29	6.14
Avg	43.16	14.66	6.12
Max	53.19	20.46	8.60

I find these figures a bit surprising, because React commands almost seven times as much CPU time to execute an event listener callback than an event listener you could register yourself. This makes sense, as React’s state management logic is necessary overhead, but one has to wonder if it’s worth it for simplistic, linear interactions.

On the other hand, Preact manages to limit its overhead on event listeners to the point where it takes “only” twice as much CPU time to run an event listener callback.

CPU time involved in closing the mobile nav was quite a bit less at an average approximate time of 16.5 ms for React, with Preact and bare event listeners coming in at around 11 ms and 6 ms, respectively. I’d post the full table for the measurements on closing the mobile nav, but we have a lot left to sift through yet. Besides, you can check out those figures yourself in the spreadsheet I referred to earlier on.

A quick note on JavaScript samples

Before moving onto the iOS results, one potential sticking point I want to address is the impact of disabling JavaScript samples in Chrome DevTools when recording sessions on remote devices. After compiling my initial results, I wondered if the overhead of capturing entire call stacks was skewing my results, so I re-tested the React scenario samples disabled. As it turned out, this setting had no significant impact on the results.

Additionally, because the call stacks were truncated, I was unable to measure component hydration time. Average startup cost with samples disabled vs. samples enabled was 160.74 ms and 162.73 ms, respectively. The respective median figures were 157.81 ms and 147.76 ms. I would consider this squarely “in the noise.”

Safari on 1st Generation iPhone SE

The original iPhone SE is a great phone. Despite its age, it still enjoys devoted ownership owing to its more comfortable physical size. It shipped with the Apple A9 processor which is still a solid contender. Let’s see how it did on startup time.

Startup time

	React Component	Preact Component	addEventListener Code
Min	32.06	7.63	0.81
Median	35.60	9.42	1.02
Avg	35.76	10.15	1.07
Max	39.18	16.94	1.56

This is a big improvement from the Nokia 2, and it’s illustrative of the gulf between low-end Android devices and even older Apple devices with significant mileage.

React performance still isn’t great, but Preact gets us within a typical frame budget for Chrome. Event listeners alone, of course, are blazingly fast, leaving plenty of room in the frame budget for other activity.

Unfortunately, I couldn’t measure hydration times on the iPhone, as the remote debugging session would crash every time I would traverse the call stack in Safari’s DevTools. Considering that hydration time was a subset of the overall startup cost, you can expect that it probably accounts for at least half of the startup time if results from the Nokia 2 trials are any indicator.

Mobile nav open time

	React Component	Preact Component	addEventListener Code
Min	16.91	5.45	0.48
Median	21.11	8.62	0.50
Avg	21.09	11.07	0.56
Max	24.20	19.79	1.00

React does alright here, but Preact seems to handle event listeners a bit more efficiently. Bare event listeners are lightning fast, even on this old iPhone.

Safari on 2nd Generation iPhone SE

In mid-2020, I picked up the new iPhone SE. It has the same physical size as an iPhone 8 and similar phones, but the processor is the same Apple A13 used in the iPhone 11. It is very fast for its relatively low $400 USD retail price. Given such a beefy processor, how does it deal?

Startup time

	React Component	Preact Component	addEventListener Code
Min	20.26	5.19	0.53
Median	22.20	6.48	0.69
Avg	22.02	6.36	0.68
Max	23.67	7.18	0.88

I guess at some point there are diminishing returns when it comes to the relatively small workload of loading a single framework and hydrating one component. Things are a little faster on a 2nd generation iPhone SE than its first generation variant in some cases, but not terribly so. I’d imagine that this phone would tackle larger and sustained workloads better than its predecessor.

Mobile nav open time

	React Component	Preact Component	addEventListener Code
Min	13.15	12.06	0.49
Median	16.41	12.57	0.53
Avg	16.11	12.63	0.56
Max	17.51	13.26	0.78

Slightly better React performance here, but not much else. Strangely, Preact seems to take longer on average to open the mobile nav on this device than its first generation counterpart, but I’ll chalk that up to outliers skewing a relatively small dataset. I certainly would not assume the first generation iPhone SE is a faster device based on this.

Chrome on a dated Windows 10 Laptop

Admittedly, these were the results I was most excited to see: how does an ASUS laptop from 2013 with Windows 10 and an Ivy Bridge i5 of the day handle this stuff?

Startup time

	React Component	Preact Component	addEventListener Code
Min	43.15	13.11	1.81
Median	45.95	14.54	2.03
Avg	45.92	14.47	2.39
Max	48.98	16.49	3.61

The numbers aren’t bad when you consider that the device is seven years old. The Ivy Bridge i5 was a good processor in its day, and when you couple that with the fact that it’s actively cooled (rather than passively cooled as mobile device processors are), it probably doesn’t run into thermal throttling scenarios as often as mobile devices.

Hydration time

	React Component	Preact Component
Min	17.75	7.64
Median	23.55	8.73
Avg	23.12	8.72
Max	26.25	9.55

Preact does well here, and manages to stay within Chrome’s frame budget, and is almost three times faster than React. Things could look quite a bit different if you’re hydrating ten components on the page at startup time, possibly even in Preact.

Mobile nav open time

		Preact Component	addEventListener Code
Min	6.06	2.50	0.88
Median	10.43	3.09	0.97
Avg	11.24	3.21	1.02
Max	14.44	4.34	1.49

When it comes to this isolated interaction, we see performance that’s similar to high-end mobile devices. It’s encouraging to see such an old laptop still keep up reasonably well. That said, this laptop’s fan spins up often when browsing the web, so active cooling is probably this device’s saving grace. If this device’s i5 was passively cooled, I suspect its performance might drop.

Shallow call stacks for the win

It’s not a mystery as to why it takes React and Preact longer to start up than it does for a solution that eschews frameworks altogether. Less work equals less processing time.

While I think startup time is crucial, it’s probably inevitable that you’ll trade some amount of speed for a better developer experience. Though I’d strenuously argue that we tend to trade too much toward developer experience than user experience far too often.

The dragons also lie in what we do after the framework loads. Client-side hydration is something that I think is far too often abused, and can sometimes be completely unnecessary. Every time you hydrate a component in React, this is what you’re throwing at the main thread:

Recall that on the Nokia 2, the minimum time I measured for hydrating the mobile nav component was about 67 ms. In Preact—for which you’ll see the hydration call stack below—takes about 20 ms.

These two call stacks aren’t to the same scale, but Preact’s hydration logic is simplified, probably because “most diffing is skipped” as Preact’s documentation states. There’s quite a bit less going on here. When you get closer to the metal by using addEventListener instead of a framework, you can get even faster.

Not every situation calls for this approach, but you’d be surprised at what you can accomplish when your tools are addEventListener, querySelector, classList, setAttribute/getAttribute, and so on.

These methods—and many more like them—are what frameworks themselves rely on. The trick is to evaluate what functionality you can safely deliver outside of what the framework provides, and rely on the framework when it makes sense.

If this were a call stack for, say, making a request for API data on the client and managing the complex state of the UI in that situation, I’d find this cost more acceptable. Yet, it’s not. We’re just making a nav appear on the screen when the user taps a button. It’s like using a bulldozer when a shovel would be a better fit for the job.

Preact at least strikes the middle ground:

Preact takes about a third of the time to do the same work React does, but on that budget device, it exceeds the frame budget often. This means opening that nav on some devices will animate sluggishly because the layout and paint work may not have enough time to finish without entering long task territory.

In this case, an event listener is what I needed. It gets the job done seven times faster on that budget device than React.

Conclusion

This is not a React hit piece, but rather a plea for consideration of how we do our work. Some of these performance pitfalls can be avoided if we take care to evaluate what tools make sense for the job, even for apps with a great deal of complex interactivity. To be fair to React, these pitfalls likely exist in many VDOM frameworks, because the nature of them adds necessary overhead to manage all sorts of things for us.

Even if you’re working on something that doesn’t call for React or Preact, but you want to take advantage of componentization, consider keeping it all on the server to start with. This approach means you can decide if and when it’s appropriate to extend functionality to the client—and how you’ll do that.

In the case of my RSS feed app, I can manage this by putting lightweight event listener code in the entry point for that page of the app, and using an asset manifest to put the minimal amount of script necessary in order for each page to work.

Now let’s suppose that you have an app that truly needs what React provides. You have complex interactivity with lots of state. Here are some things you can do to try and get things going a bit faster.

1. Check all of your stateful components—that is, any component which extends React.Component—and see if they can be refactored as stateless components. If a component doesn’t use lifecycle methods or state, you can refactor it to be stateless.
2. Then, if possible, avoid sending JavaScript to the client for those stateless components, as well as hydrating them. If a component is stateless, only render it on the server. Prerender components when possible to minimize server response time, because server rendering has its own performance pitfalls.
3. If you have a stateful component with simple interactivity, consider prerendering/server-rendering that component, and replace its interactivity with framework-independent event listeners. This avoids hydration entirely, and user interactions won’t have to filter through the framework’s state management logic.
4. If you must hydrate stateful components on the client, consider lazily hydrating components that aren’t near the top of the page. An Intersection Observer that triggers a callback works very well for this, and will give more main thread time to critical components on the page.
5. For lazily-hydrated components, assess whether you can schedule their hydration during main thread idle time with requestIdleCallback.
6. If possible, consider switching from React to Preact. Given how much faster it runs than React on the client, it’s worth having the discussion with your team to see if this is possible. The latest version of Preact is nearly 1:1 with React for most things, and preact/compat does a great job of easing this transition. I don’t think Preact is a panacea for performance, but it gets you closer to where you need to be.
7. Consider adapting your experience to users with low device memory. navigator.deviceMemory (available in Chrome and derived browsers) enables you to change the user experience for users on devices with little memory. If someone has such a device, it’s probable that its processor isn’t so fast either.

Whatever you decide to do with this information, the thrust of my argument is this: if you use React or any VDOM library, you should spend some time investigating its impact on an array of devices. Get a cheap Android device and see how your app feels to use. Contrast that experience with your high-end devices.

Most of all, don’t follow “best practices” if the result is that your app effectively excludes a part of your audience that can’t afford high end devices. Keep pushing for everything to be faster. If our daily work is any indication, this is an endeavor that will keep you busy for some time to come, but that’s OK. Making the web faster makes the web more accessible in more places. Making the web more accessible makes the web more inclusive. That’s the really good work we should all be trying our best to do.

I’d like to express my gratitude to Eric Bailey for his editorial feedback this piece, as well as the CSS-Tricks staff for their willingness to publish it.

---

The post radEventListener: a Tale of Client-side Framework Performance appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.