Forem: Vue Storefront

Everyday Challenges of Responsive Web Design

Rohrig — Tue, 21 Nov 2023 16:44:02 +0000

Part 1: The Right Image for the Device

Responsive Web Design (RWD) is essential in today's multi-device world. A key challenge in RWD is choosing and loading the right image size based on the device's screen size. This ensures both the quality of the image and the performance of the website.

Using `<picture>` element example

The Role of the `<picture>` Element in RWD

Understanding the `<picture>` Tag

The <picture> element in HTML allows for more control over image resources in different scenarios.
It contains one or more <source> elements and a single <img> element.
The browser evaluates each <source> to find the best match for the current display and if none matches, or if the browser doesn't support <picture>, it falls back to the <img> element's src.

The Code in Action

Consider this Vue.js code snippet:

<picture>
  <source media="(min-width: 768px)" :srcset="item.largeImage">
  <source media="(max-width: 767px)" :srcset="item.smallImage">
  <img :src="item.defaultImage" :alt="item.altText">
</picture>

Dynamic Image Selection: Different images are loaded depending on the screen width. Larger images for screens wider than 768 pixels, and smaller ones for narrower screens.
Efficiency and Speed: This technique optimizes bandwidth usage and improves page load times by loading images best suited to the viewer’s display.
Fallback Mechanism: The <img> element is a backup if no <source> elements match.

Best Practices for Using the `<picture>` Element

Art Direction: Use <picture> to modify images for different conditions, like loading a simpler image with fewer details on smaller screens.
Format Flexibility: Offer alternative image formats, such as AVIF or WEBP, which may not be supported by all browsers, alongside more universal formats.
Optimized Bandwidth Use: Save bandwidth and improve page load times by loading the most appropriate image for the viewer's display.
High-DPI Displays: Use srcset on the <img> element for high-DPI displays. This allows browsers to choose lower-density versions in data-saving modes.
Positioning and Sizing: Utilize object-fit and object-position properties on the <img> element to adjust the positioning and sizing of the image within the frame.

The why

In responsive web design, effectively managing images is crucial. The <picture> element is a powerful tool that helps in loading the right image for the right device, enhancing both the user experience and the website’s performance. As we continue to navigate the challenges of RWD, understanding and utilizing these elements will be key to creating versatile and efficient web designs. Stay tuned for more insights in this series on responsive web design.

Considering alternative approaches

Why not just load images based on device detection?

Choosing the right method to load images on a website, especially in a responsive design context, involves considering both efficiency and user experience. While detecting the user's device server-side and then serving appropriate images based on that information is a possible approach, there are several reasons why using HTML's <picture> element or CSS media queries might be more advantageous:

Device Diversity: The range of devices used to access the web is vast and constantly evolving. It's not just about differentiating between a desktop and a mobile device; there are various screen sizes, resolutions, and even connection speeds to consider. Using the <picture> element or CSS media queries allows the browser to make real-time decisions based on the actual device characteristics.
Client-Side Flexibility: By using the <picture> element or CSS, the decision about which image to load is made client-side, based on the actual conditions at the moment the page is rendered. This includes not only the screen size but also the type of connection (e.g., Wi-Fi or cellular data), which can change even during a single session.
Performance and Bandwidth Optimization: Detecting the device server-side and serving different images based on this can lead to unnecessary overhead. The <picture> element allows for more efficient loading of images, as it can select the most appropriate image based on the current viewport and pixel density, potentially saving bandwidth and improving load times.
Scalability and Maintenance: Maintaining a server-side device detection system can be complex and require constant updates as new devices enter the market. In contrast, using the <picture> element or CSS media queries offloads this responsibility to the browser, which is regularly updated to handle new devices and screen sizes.
Future-Proofing: The web is continuously evolving, and so are web standards and browsers. Relying on current standards like the <picture> element ensures that your website is more likely to remain compatible with future devices and browsers without requiring significant rework.
SEO and Accessibility: Search engines prefer websites that use standard, semantic HTML. Using the <picture> element is in line with HTML standards and can be more easily interpreted by search engines, potentially improving SEO. It's also more straightforward for screen readers and other assistive technologies to interpret, improving accessibility.

While server-side device detection has its uses, for image loading in a responsive design, client-side methods like the <picture> element or CSS media queries generally offer greater flexibility, efficiency, and forward compatibility. These methods align better with the principles of responsive web design, focusing on the actual capabilities and conditions of the user's device at the time of access.

A more complex example

For this example, I'm using a Nuxt 3 project along with my favorite eCommerce UI library, Storefront UI.

The Challenge

What if I need to create something more than just a static image, what about something as complex as a carousel? And to boot, what if we want to load different images into that carousel based on the size of the browser window?

The Solution

The <picture> approach works quite well in this scenario. Let's use a Nuxt 3 App for example. We can create a component that will load the images based on the size of the browser window. There are many edge cases we're ignoring here so we can focus on the topic at hand.

Let's focus on the carousel:

~/components/Carousel.vue

<template>
  <div class="carousel">
    <div class="carousel-track" :style="{ transform: `translateX(-${currentIndex * 100}%)` }">
      <div class="carousel-item" v-for="(item, index) in items" :key="index">
        <picture>
          <source media="(min-width: 768px)" :srcset="item.largeImage">
          <source media="(max-width: 767px)" :srcset="item.smallImage">
          <img class="w-full h-auto md:w-auto" :src="item.defaultImage" :alt="item.altText">
        </picture>
      </div>
    </div>
    <div class="carousel-dots">
      <button class="dot" v-for="(item, index) in items" :key="index" :class="{ 'active': index === currentIndex }"
        @click="goToItem(index)">
      </button>
    </div>
  </div>
</template>

<script setup>
import { ref } from 'vue';

const currentIndex = ref(0);
const items = ref([
  {
    largeImage: '/images/large1.png',
    smallImage: '/images/small1.png',
    defaultImage: '/images/large1.png',
    altText: 'image 1'
  },
  {
    largeImage: '/images/large2.png',
    smallImage: '/images/small2.png',
    defaultImage: '/images/large2.png',
    altText: 'image 2'
  },
  {
    largeImage: '/images/large3.png',
    smallImage: '/images/small3.png',
    defaultImage: '/images/large3.png',
    altText: 'image 3'
  }
]);

let autoSlideInterval = null;

const startAutoSlide = () => {
  stopAutoSlide();
  autoSlideInterval = setInterval(() => {
    nextItem();
  }, 2000);
};

const stopAutoSlide = () => {
  if (autoSlideInterval) {
    clearInterval(autoSlideInterval);
    autoSlideInterval = null;
  }
};

onMounted(() => {
  startAutoSlide();
});

const nextItem = () => {
  currentIndex.value = (currentIndex.value + 1) % items.value.length;
};

const goToItem = (index) => {
  stopAutoSlide();
  currentIndex.value = index;
};

</script>

<style>
.carousel {
  overflow: hidden;
  position: relative;
}

.carousel-track {
  display: flex;
  transition: transform 0.5s ease;
  /* Smooth transition for sliding */
}

.carousel-item {
  flex: 0 0 100%;
  /* Each item takes full width of the carousel */
  /* Other styles for the item */
}

/* Enter and leave transitions */
.slide-enter-active,
.slide-leave-active {
  transition: transform 0.5s ease;
}

.slide-enter,
.slide-leave-to {
  transform: translateX(100%);
  /* Start and end state for sliding */
}

.slide-enter-to,
.slide-leave {
  transform: translateX(0);
  /* End and start state for sliding */
}

.carousel-dots {
  position: absolute;
  bottom: 10px;
  left: 50%;
  transform: translateX(-50%);
  display: flex;
  align-items: center;
  justify-content: center;
}

.dot {
  height: 10px;
  width: 10px;
  border-radius: 50%;
  background-color: #fff;
  margin: 0 5px;
  cursor: pointer;
  border: none;
  opacity: 0.5;
  transition: opacity 0.3s;
}

.dot.active {
  opacity: 1;
}
</style>

This carousel will fit nicely with the rest of my UI:

~/pages/index.vue

<template>
  <div class="flex-col align-middle">
    <Carousel />
    <NewsLetterForm />
    <div class=" flex justify-center">
      <Banner />
    </div>
  </div>
</template>

You can get your hands on the code here: https://github.com/rohrig/carosel-multisize-image-example

While it might be tempting to create components based on the device, it's more efficient and future-proof to design them responsively, allowing for seamless adaptation to different screen sizes and resolutions. This approach ensures a consistent user experience across all devices and reduces the need for device-specific code maintenance.

How to build accessible button component

Anna Musial — Fri, 11 Aug 2023 07:58:17 +0000

Intro

It is hard to imagine a website app without a single button. It is a key element of user interaction, providing a means for users to perform actions and navigate through the interface. However, not all users may be able to easily interact with buttons, particularly those with disabilities or impairments that affect their motor skills or vision. Together with the Storefront UI team we decided to provide the best accessibility possible for our components, starting with something as simple as a button.

In this article, we will explore the importance of button accessibility, the challenges that users with disabilities may face, and best practices for designing buttons that are accessible to all users.

Semantics as a starting point

We can’t have a conversation about accessibility without providing proper semantics. It all starts with HTML and if you would ask developers around the globe how to create a button, you may get completely different answers. So let’s review our options.

Using the `<button>` tag

The most recommended one is using <button> tag. It provides all behaviors and functionalities by default. Funny thing is, it is not the only accessible way to achieve our goals. For many years developers lacked awareness on why the quality of code is so important. As long as the solution works and the client is happy, why should we care about semantics? Well, in recent years accessibility has become a legal requirement in the US. It can also affect SEO, as Google is ranking the websites based on their HTML structure. So yes, it does matter.

Using a `<div>` or `<input>`

Legacy code can be a real pain, because it is not always so easy to change the code without causing breaking change. Unfortunately, using things like <div role=”button” /> or <input role=”button /> is still common among many web pages. However, it is a perfectly accessible element as long as you actually provide all the interactions to make it work exactly like a native <button />. You must treat the role as a promise, not a solution. This requirement and the human factor is the real reason why so many webpages are still not accessible enough. That is why I highly recommend riding on the coattails of others and using <button> wherever the element should trigger a click action. And that’s it. Accessibility is all about making your code smarter.

Design vs. Development

I cannot stress this enough - cooperation between developers and designers is essential for creating a product with good accessibility. I would say that two key focus areas for designers should be proper sizing and color contrast. This can really affect your project's accessibility. Buttons must have a sufficient (minimum of 37 px according to MIT Touch Lab) size to be easily clickable, especially on touch devices. Larger buttons are easier to target accurately, reducing the risk of accidental clicks.

Color contrast between the button's foreground (text or icon) and background colors is particularly important for users with low vision or color blindness. Ratio of at least 4.5:1 should be used for normal-sized text and 3:1 for large text. There are many online tools that allow developers and designers to find a perfect match.

However, it is essential to prioritize accessibility over design preferences and invest the necessary effort to ensure an inclusive user experience for all users, including those who rely on keyboard input or assistive technologies.

Accessibility properties

Sometimes a little help from HTML attributes is needed to make the button truly accessible.

Role vs. type

In the previous section I’ve briefly presented the usage of role attribute. Let’s dive deeper into this. From my personal experience, I can tell that role is commonly confused with another HTML attribute - type. The button role identifies an element as a button to assistive technologies. Simply speaking, it does not matter to screen readers whether you use <button> or <div> with role=”button”.

Whereas typeis specifying the context of usage. By using the proper type, you can create a button that behaves in a specific way, depending on the needs of your web page.

Here are the most commonly used button types in HTML:

type="button" - a simple button that does not perform any specific action.
type="submit" - commonly used in forms. It submits the form data for processing.
type="reset" - this type of button is also used in forms. It resets all form fields to their default values.

For most browsers, the default button type is submit, as in the early days of modern websites buttons were used mostly for building forms. Today they are used in many different contexts and it isn’t always clear at first glance at the markup. Therefore, it is a good practice to always declare the type of a button explicitly.

Aria Labels

ARIA attributes, such as aria-label, aria-labelledby, aria-describedby and aria-hidden, among others, allow developers to specify additional information about the purpose, state, and behavior of elements. Button is just one of them. No ARIA is better than bad ARIA - this is a quote taken from WCAG best practices and I couldn't agree more. While ARIA labels can be a powerful tool for improving web accessibility, it's important to use them judiciously and appropriately. Overuse of ARIA labels or incorrect usage can actually make web content more confusing or difficult to navigate for users with disabilities. And the truth is, for most cases, you don’t need it. ARIA can even act as a cloak and override original semantics of element i.e. <label>.

But in some cases aria-label is a must have to provide good accessibility. ARIA labels should be used for buttons when the text on the button itself doesn't fully describe the action that the button performs, or when additional information is needed to clarify the purpose of the button for users with disabilities. A great example of such an element is a button with an icon, but without any label inside. These can be found in menus, product cards, wishlists etc., as seen on the picture below:



<SfButton type="button" :square="true" aria-label="Add to cart">
  <SfIconAdd />
</SfButton>

Icon itself is not representative enough, at least not for someone with vision disability. When screen readers come across such a button without aria, it will not be read to the user. So how can anyone understand what the purpose of these buttons are? Therefore we need to provide a description using the aria label property.

Here are a few examples of BAD aria usage:


 html
<SfButton aria-label="button"><MyCoolIcon /></SfButton>


 html 
<SfButton aria-label="Add to cart">Add to cart</SfButton>

In StorefrontUI we took the full flexibility approach when it comes to arias. There is no specific prop for aria labels or disabled attributes. Instead, the template allows users to assign those properties as simply as binding them to the component. All of our copy-pasteable examples has aria-labels.

Preventing button click

Web Content Accessibility Guidelines (WCAG) requires that websites provide clear and consistent feedback to users, and that they do not present information or functionality in a way that is confusing or misleading. Using the disabled attribute helps meet these standards by clearly indicating the availability of functionality. When a button is disabled, it can also provide visual feedback that helps users understand the status of the associated functionality. For example, if a "Submit" button is disabled until all required form fields have been completed, this can help users understand that their form is not yet complete.

Button as a link or link as a button?

While both buttons and links serve interactive purposes, there are specific scenarios where choosing the appropriate element can enhance the user experience for individuals with disabilities who rely on assistive technologies.

When the interactive element primarily triggers an action or performs a function, it is generally more appropriate to use a button instead of a link. Buttons are typically associated with actions such as submitting a form, confirming a selection, or initiating a process.

So what can we do when we have a link that should look like a button? A real life example can be a “Continue to payment” button in checkout. Well, here is how we handled it at Storefront UI. Vue offers a tremendous feature that is dynamic components.

The SfButton component is built using the component is=”tag” and it is up to the user to decide what should be passed via tag prop. Therefore, you can render your component as a link by passing a, or as a button by passing button. It all depends on the context.

Keyboard a11y

Keyboard accessibility in button components is essential for achieving universal accessibility. While many users rely on a mouse or touch input for interaction, some individuals with disabilities may not have access to these input methods or may find it challenging to use them effectively. By ensuring that buttons can be fully operated using the keyboard, we can accommodate users who rely on alternative input devices, such as screen readers or assistive technologies, to navigate and interact with digital interfaces.

Such an important feature also happens to be the most “painful” one when it comes to implementation practices. So what is so tricky in the matter?

1. Focus outlines are ugly.

One common challenge in implementing keyboard accessibility is the perception that focus outlines are aesthetically unappealing or disrupt the visual design of a website or application. Some designers and developers may opt to remove or modify the default focus outline styles to achieve a specific look or to match the overall design aesthetics. However, it's important to remember that the focus outline serves a crucial accessibility purpose, providing a visual indicator for keyboard users. While it may not align perfectly with certain design preferences, it is essential to prioritize accessibility over purely aesthetic considerations.

2. Keyboard accessibility is more than just tabbing around the elements.

Keyboard accessibility involves more than just enabling users to navigate through elements using the Tab key. It’s much more, depending on the context. For menus and dropdowns you should also use arrows and optionally - Home/End keys.

Also, there is a difference in how we need to navigate through elements. Imagine using just a keyboard to navigate through the page. The problem is that tabbing relies on the DOM tree. Therefore opening fe. a modal, won’t even trigger the focus on its elements. We’ll keep on tabbing under the opened window which may cause confusion. Therefore it should not be surprising that there are so many open source solutions just for handling the keyboard navigation. In the case of the Button component, the solution is as simple as using focus-visible Tailwind class.

For more advanced components, like custom Input, we decided we decided to implement a custom solution to have full flexibility of how the outlines behave:

useFocusVisible - sometimes the CSS :focus-visible is not enough. In some of our components we wanted to style the wrapper element based on the nested input. That’s why we implemented a custom solution, as :has() pseudo class is not fully supported yet.

The following composable/hook is showing the focus outline only for the keyboard events. The user does not have to worry about the ugly outlines ever again. This simple yet powerful solution allows us to have both - great accessibility and nice design.

You can check the source code in our repo here.

Button a11y Checklist

Add descriptive text or aria label: Ensure the button has clear and descriptive text that conveys its purpose or action. Avoid using vague labels like "Click here". If button contains only icon add an aria-label with proper description.
Use proper HTML structure: Ensure the element is used instead of (anchor) or other elements for actions and interactions. This ensures semantic correctness.



<button type="button">Hello</button>

Ensure keyboard accessibility: Test the button's functionality using only the keyboard. Ensure it can be focused on using the "Tab" key. Make sure the focus indicator is visible and adequately styled.
Implement proper focus management: Ensure that the focus is moved to the button when it becomes visible or activated, and that it is not trapped or lost inappropriately.
Provide visual cues on interaction: Make sure the button visibly changes its appearance when hovered over or clicked, using CSS styles such as background color, border, or shadow. This helps users understand the button's interactive nature.

Consider color contrast: Ensure that the button's text color and background color have sufficient contrast to be easily readable, especially for users with visual impairments.
Use ARIA attributes if necessary: If the button performs a complex action or has dynamic behavior, consider using ARIA attributes like aria-expanded, aria-controls, or aria-pressed to provide additional context to assistive technologies.
Test with assistive technologies: Use screen readers or other assistive technologies to test the button's accessibility. Ensure the button's purpose, state changes, and any associated information are communicated effectively.

Summary

Prioritizing accessibility in button design is an essential step towards building inclusive websites and applications. It may seem like a lot at first but in the end it leads toward better code and better experience for all users.

Have some suggestions regarding accessibility? Feel free to contact me, follow on Twitter or contribute to StorefrontUI and help make the web a more friendly place for everyone.

A Framework-Agnostic Magento 2 Integration: The Next Step in eCommerce Frontend Development:

Rohrig — Mon, 12 Jun 2023 11:50:00 +0000

We're happy to introduce the latest Magento 2 Integration from Vue Storefront. This integration connects your frontend application smoothly with a Magento 2 backend, ensuring a seamless bridge between the two.

The Framework-Agnostic Design

A highlight of this Magento 2 Integration is its framework-agnostic design. This design includes an SDK and middleware that are framework-agnostic. What does that mean for you? It means you have the flexibility to use popular frameworks such as Nuxt and Next.js. If you choose, you can work without any framework at all. The SDK, built using TypeScript, is adaptable and can be installed in any application developed in JavaScript or TypeScript.

If your project could benefit from a UI library made with eCommerce in mind, Storefront UI may be a good fit. You can find more details via this link: Storefront UI

What's Next?

The Journey to Build the Next Storefront Boilerplate
We're proud of the SDK and see it as a significant step forward. It is particularly useful if you're aiming to create a new frontend application that pairs with your existing Magento 2 headless store. However, we're always looking for ways to push our products further, and that's why our next move is the development of a fully functional open-source boilerplate application.

This application will incorporate the new Magento 2 integration, the SDK and middleware, and of course, Storefront UI 2. We've chosen to use Nuxt 3 for this initial boilerplate due to its excellent performance, flexibility, and advanced features. As we move forward with this project, we'll document the process and share updates so you can follow along with our progress. Here's how you can stay informed:

Checko out the magento-integration repo

Check out our Youtube Channel

Inviting Collaborators

If you're interested, you're more than welcome to join us in developing this open-source storefront using the new Magento 2 SDK and Storefront UI 2. Whether you're an eCommerce expert, a beginner in open-source contributions, or simply curious to be part of an exciting project, we'd be delighted to have you on board. Everyone has something valuable to contribute, regardless of experience level. So, let's code together and see where this project takes us. We're excited about this journey and we hope you are too. Ready to start coding?

Check out the magento-sdk-storefront Repo, (it's brand new.)

Investing in Developer Experience Could Be The Best Growth Hack for Your Business

Filip Rakowski — Wed, 19 Apr 2023 11:17:52 +0000

It was November 2017 when we pushed the very first version of Vue Storefront to GitHub. At that time, there were only two of us working on it after hours. One year later, we had been invited to almost every Magento event and podcast. Vue Storefront had almost 100 agencies around the world implementing it, and more than 4000 people were on its Slack. New live stores were popping up every week, and SAP had even approached us, asking for help to build its own Enterprise product.

As crazy as it sounded, this was a real story. What was our secret ingredient to success? Developer Experience. Despite having no investment or marketing budget, we managed to leverage Developer Experience to our advantage. The mechanisms that led to our success can be used by other IT companies, both building and consuming developer tools to greatly increase their chances of success.

Developer Experience is User Experience

For a company building tools for developers, developers are their users, so Developer Experience is just User Experience. It’s not a secret that improving the experience of your users can be a great way to increase revenue. A survey by UserTesting found that 86% of buyers are willing to pay more for a better customer experience.

Some companies, like Amazon, have become completely obsessed with their customers and their experience. It works the same way with developers - we have companies like Vercel, Netlify that are known from their obsession with great DX! By the way - we're obsessed about it in Vue Storefront too!

Developer Experience drives web tools adoption

Developers are constantly looking for new and better tools that will allow them to perform tasks more efficiently or decrease the chances of failure.

The reason we became so successful with Vue Storefront was quite simple - we identified a pain point of a huge amount of developers and shipped something that improved their experience. They lifted it up because our success was in their interest.

Developers often look for tools that are easy to use, provide the required functionality, have good documentation, and have good community support. If a tool lacks these qualities, developers are more likely to switch to an alternative tool that provides a better experience.

In our case, we gave Magento 2 frontend developers a way to use a modern frontend framework like Vue, and decouple their work from the PHP world. It was in their interest to advocate for Vue Storefront and convince the companies they worked for to use it. This way, they could learn a new, exciting technology that is much more enjoyable and efficient to work with than what they were used to.

Let’s take another example from the web dev tooling courtyard. Webpack, a tool that was fueling almost all modern JavaScript projects with 6 000 000 daily downloads was almost completely replaced by Vite in most of the modern frameworks and starters last year. Of course, Webpack won’t die any time soon, with its massive adoption, but Vite is now a go-to for the new projects on Vue, React and Nuxt.

Speaking of which - Nuxt and Vue also became a market standards because of their amazing DX. They had no marketing budget, but happy developers advocating for their products were all they needed to get where they are now.

I know what you’re thinking right now - is it really worth investing time in a migration just to make my developers happier? As a leader, or a business owner, should I even listen to their whims?

Developer Experience improves the efficiency of your team

Using a developer tool with great developer experience is like driving on a well-maintained highway, where you can smoothly and efficiently cruise at high speeds towards your destination.

On the other hand, using a tool with a poor developer experience is like driving on a bumpy and pothole-filled road, where you constantly have to slow down and maneuver around obstacles, causing delays and frustration. Ultimately, the former allows you to get to your destination faster and with less stress, while the latter can slow you down and impede your progress.

Developers spend most of their time coding, designing, and testing software applications. The experience they have while doing these tasks can have a significant impact on their performance. Good developer experience can make them more productive and more efficient, leading to timely delivery of high-quality software.

While a bad developer experience can lead to inefficiencies, delays, and ultimately, higher costs. This can also impact the end-user experience, leading to unhappy customers, bad reviews, and lost business opportunities.

A report from McKinsey shows that companies prioritizing developer velocity have four to five times the revenue growth of their counterparts.

It’s not always worth migrating to the next big thing

Investing in tools that can provide better developer experience is an excellent decision, especially for large teams. However, it's essential to consider that not all migrations are worthwhile. If your current tool is already delivering good developer experience, then it's highly unlikely that migrating to a new tool will bring significant benefits that justify the costs.

For example, people migrated from webpack to Vite in large numbers because webpack was incredibly slow in larger projects, leading to a significant waste of time.

However, Vite has addressed this problem by being fast enough, so replacing Vite with an even faster build tool may not provide the same benefits as migrating from webpack to Vite.

Therefore, it's crucial to make a well-informed decision before making any changes to your current toolset.

Developer Experience attracts talent

Good developer experience can also impact employee retention and recruitment. Developers want to work for companies that provide the best tools, technologies, and working environments. Often they switch jobs just to be able to work with the new technology they’re excited about.

According to a survey by Hired, a job search platform for tech talent, outdated technology is one of the top reasons why developers look for new jobs. In their 2021 State of Software Engineers report, they found that 39% of software engineers surveyed cited outdated technology as a reason for leaving their job, making it the second most common reason behind compensation.

By providing good developer experience, businesses can retain and attract top talent, leading to better results and growth opportunities.

Summary

Investing in Developer Experience (DX) can be a game-changer for IT companies building and consuming developer tools. *DX is simply User Experience (UX) for developers, and improving it can increase revenue, drive adoption, and increase team efficiency. *

However, not all migrations are worthwhile, and it's crucial to make a well-informed decision before making any changes to your current toolset. Good DX can also impact employee retention and recruitment, leading to better results and growth opportunities. Overall, businesses should consider DX as a growth hack that can drive success and take them to the next level.

I share how we build best Developer Experience on the market in Vue Storefront every month in my newsletter! Follow me on Twitter or Linkedin to stay in the loop and learn something new!

Using Custom Queries in Vue Storefront 2

Jakub Andrzejewski — Mon, 14 Nov 2022 07:18:59 +0000

Vue Storefront uses default GraphQL queries under the hood to fetch and modify the data in a certain e-commerce platform (or any other third party service). This is a very useful feature that can speed up your development but what if you would like to customize it to make it work a bit different?

You can do so by utilizing the concept of Custom Queries. These custom values will replace the default ones to achieve completely new result. If you would like to see this on a real example, I have recorded a video some time ago, where I am showing how to use these Custom Queries in a real Vue Storefront 2 application.

Apart from this video, I would highly recommend you to check out following links to learn more about composables and how to extend Vue Storefront 2 application to match your needs best:

What is URL Resolving?

Jakub Andrzejewski — Mon, 07 Nov 2022 11:27:00 +0000

When building a custom storefront for your e-commerce, you eventually will run into a situation where you will need to map the products in your e-commerce platform to certain pages in the storefront. So you may ask yourself: “How should I map them then?”. This is a common problem in all e-commerce websites, especially considering the growing amount of possible attributes a product can have like sizes, colors, fabric, etc. The combination of attributes is often referred as variants. To help with that problem, you can utilize the concept of URL Resolving.

As a start, we should first get a better understanding of what actually is a URL. Knowledge about this concept will allow us to dive deeper into the second section where we will be discussing the pros and cons of certain URL Resolving approaches so that you can choose and implement the one that best suits your business needs. Finally, an example of implementing Dynamic Routing in Vue Storefront 2 will be shown and discussed.

What is an URL?

A Uniform Resource Locator (URL) is the web address that we enter into a browser to access a web page. Web URLs are also called links and users will use them to access your website directly.

URLs can have a different structure, but the most popular one can be seen below:

Let’s discuss each individual part of it:

Protocol - thanks to it, the browser will be able to get information by using the appropriate HTTP protocol (HTTP or HTTPS which stands for secure).
Sub Domain - you can have multiple subdomains like docs, prod, stage, test, etc. They can be useful for creating organized content that is related to your root domain.
Root Domain - it is a unique address where a website is located.
Top Level Domain (TLD) - usually .com, .org, .io
Path - exact location of a certain page, subpage, or a file

The structure of an URL can depend on several aspects and unique needs and I will explain some of them later in this article.

What is a URL Resolving?

URL Resolving concept allows you to connect certain products in your e-commerce platform with a certain page and URL in your storefront. This means that whenever a customer on your online store will click on the product card to see more details (and possibly add this product to the cart) he/she will be redirected to an appropriate URL.

Let’s take a look at the example from our Vue Storefront playground.

Category Page - https://demo.vuestorefront.io/c/household-items - the path consists of /c, which stands for the category, and /household-items which is a category slug or category name.

Product Page - https://demo.vuestorefront.io/p/77/fog-linen-chambray-towel-beige-stripe - the path consists of /p, which stands for product, /77, which is a product ID, and /fog-linen-chambray-towel-beige-stripe which is a product slug or name.

Vue Storefront also supports international e-commerce so when we switch the language of our website, it will automatically update the URLs to include the correct locale, i.e. https://demo.vuestorefront.io/de/c/household-items, where /de is a language/region/locale.

Implementing custom dynamic routing in both Vue Storefront 2 and Nuxt 2 is pretty straightforward and it is explained really well in the following articles:

In Vue Storefront, if you want to manually add your custom routes or modify some already provided, use the extendRoutes function in the nuxt.config.js. This function has two properties:

routes — an array of already registered routes. You can push or delete entries from it.
resolve — helper function for resolving Vue.js components based on their paths in the project.

For the sake of example, let's assume that we created a pages/AboutUs.vue component, but we want to use the /company/about-us route instead of auto-registered /aboutus. There are two approaches we could take.

The first approach is to delete the existing route and register a new route with a different path.

// nuxt.config.js

export default {
  router: {
    extendRoutes(routes, resolve) {
      // Delete automatically registered route
      routes.splice(
        routes.findIndex(route => route.path === '/AboutUs'),
        1
      );

      // Re-register the same component but with different path
      routes.push({
        name: 'AboutUs',
        path: '/company/about-us',
        component: resolve(__dirname, 'pages/AboutUs.vue')
      });
    }
  }
};

Comparison of URL Resolving patterns

URL Resolving can be achieved in many different ways. Let’s compare some of the popular URL Resolving patterns that can be used in e-commerce websites. Depending on your website requirements, you may implement some or all of the following patterns.

For the comparison, let’s assume that before the slash there is something like my-awesome-store.com and ${product} is a unique product slug or ID. These are the patterns that I have found being used in several e-commerce applications:

/[p/c]/${product} - In this approach, the first part of the URL path is a business domain, for example, a category/collection or a product with only the first letter from the domain. After it, there is a unique product ID or a slug. This approach allows easily distinguish the certain part of the website (i.e. I am currently in the category X and the ID is Y)
/${product} - In this approach, the only part of the URL path is the unique product ID or slug. This approach may not be the best if you prefer to have meaningful URLs because your URL in this approach might look like this my-awesome-website/123-abc
/p-${product} - In this approach, the only part of the URL path is the unique product ID or slug and a prefix of a business domain. While this might look good, both creating links and fetching data about certain pages can be more difficult as you would have to respect add and strip a domain prefix to get a product ID. Not a big deal, but you would have to remember about it.
/${product}-p - Similar pattern as the one above but in this case, we are adding an appendix with a business domain. It shares similar issues as the one above.
/any-text-p-${product} - In this approach, the only part of the URL path is the unique product ID or slug, a prefix of a business domain, and some text. By going with this pattern, you will have even more unique URLs but at the cost of hard-to-read and navigate links, i.e. my-awesome-store/some-text-p-123abc
/any-text-p${product} - Similar to the one above but there is no hyphen between a product letter and the product ID. It might be even harder to work with from the frontend.
/category/product/${product} - In this approach, the URLs are created adequately to the actual page path so that we will have a product with a certain ID that is a part of a certain category. This may be too complex for some long names.
/category/subcategory/product/${product} - Similar approach to the one above but even more nested. This kind of URL paths could work as breadcrumbs but in some cases might be too complex.

These are some of the most popular URL resolving / Dynamic Routing patterns I have observed in several e-commerce websites.

If you need internationalization in your website you can also implement the following pattern:

/en_US/* - in it, as the first part of the URL path you will be adding an appropriate locale and then category/product and a product id. With this approach, you can configure different languages and locale in the frontend application and you don’t have to worry about domains (i.e. .pl/.de).

However, if you do not want to implement routing in the frontend of your website, you can also implement third-party (i.e. Content Management System - CMS) based URL Resolving. It can take the whole routing issue out of the frontend but it will be a single point of failure (if CMS will be down, your whole website will be down as well). Below, you can see a visual representation of this approach:

Why the right URL structure is important?

URL Structure is important for two main reasons; User Experience and Google Search Position.

The first aspect is especially important for making your URL’s be logically structured and easy to navigate by the users of your website. URLs such as the one below are easy to understand for the users and include content keywords that are useful for SEO:

https://docs.vuestorefront.io/commercetools/guide/ssr-cache.html

URLs such as the one below are not descriptive and can be indexed by Search Engines as duplicates:

https://www.my-awesome-website.com/index.php?id_123

The second aspect is even more important for SEO. Good URL structure can put your website higher in Google search results. You can read more about it here → https://www.semrush.com/blog/pagerank/. Root domains have the most PageRank but it does not mean that you have to add all-important keywords there. Too many keywords will make your website difficult to read and crawl by Google. Instead, make sure to include what is necessary and place it under the path.

Remember to create and update the sitemap.xml file so that your website will be correctly crawlable so that Google could keep Search Engine Results Pages up to date. If you are interested in how to add sitemap.xml to Vue Storefront 2 project, check out the following module that you can add to your project and control the sitemap easily → https://sitemap.nuxtjs.org/

The right URL structure can help Google crawl and index your website better but also mitigate the following problems:

Getting the same content multiple times - in some scenarios, two different websites can lead to the same product and it is also how Google will index it. Let’s take a look at the following example:
- /p/dress and /p?id=456
Both URLs can lead to the same product page and Google will index it incorrectly.
For some dynamic parameters or queries (like timestamps) Google Crawler may think that our store contains an infinite number of pages. Let’s take a look at the following example:
- /checkout?expiresAt=10:20pm and /checkout?expiresAt=10:30pm
These URLs can be then treated as different pages even though the only difference is a parameter.
When using fragment identifiers (#fragment) Google may not see the difference between the two URL and because of that, the content can be missed. Let’s take a look at the following example:
- p/dress#red and p/dress#green
These two URLs even though is meant to display different products, will be indexed by Google as the same.

Working with product variants has also proven to be quite difficult in terms of correct URLs and Google searching algorithms. Variants can be implemented purely in JavaScript as a selection that will be then passed as a param or query for a request that will fetch the data from the e-commerce platform or can be accessed from the current URL. For the second approach, you can choose either of the following approaches:

A path segment, such as /dress/black
A query parameter, such as /dress?color=black

In this situation, to show Google which variant is the best to show, you can use canonical URL’s. For example, if the default value of the color query parameter for a Dress is red, then:

Use /dress as the canonical URL for all Dress variants
For a red dress, use /dress (and not /dress?color=red)
For a black dress, use /dress?color=black with canonical URL <link rel="canonical" href="https://my-awesome-store/dress" />

URL Best Practices

Below, I am listing some URL best practices for you to use in your website. No matter what kind of application you are building, most or all of these recommendations should make your website more crawlable and user-friendly.

Construct a good URL structure - as explained in previous section, URL’s that are simple and self-explanatory are best for both the users and the search engines.
Use hyphens to separate words - If your path is constructed out of several words, make sure to divide them by using hyphens.
Don’t use stop words - Words like and, or, for are not meaningful for the SEO so make sure to avoid them.
Use lowercase - pretty self-explanatory, instead of /About use /about.
Redirect old URLs - In the case of out of date URLs, you can add a redirect to them so that users will be redirected to the new and up-to-date page.
Don’t use dates in the Path - If you are building a blog or your products contain dates, do not put them into the URL path.
Spell out numbers - If your website URL contains the number, i.e. example.com/3-best-tools you can instead spell out the number like example.com/three-best-tools
Use HTTPS - Using a secure protocol will ensure security for your users and result in better trust.
Hide www prefix - If your website is using this prefix, you can safely hide it. Nowadays, the majority of the websites are known for being a World Wide Web resource.
Use country domain or subdirectory - If you are building an international website, you can use a country domain (example.pl) or subdirectory (example.com/pl/)

Resources

How to deal with caching and dynamic content in Nuxt?

Filip Rakowski — Wed, 05 Oct 2022 13:10:19 +0000

The cache is one of the most powerful weapons when you want to make your web application fast. Delivering static, pre-rendered pages from the closest location can result in a great performance, but setting it up on the server without making your frontend application ready to be cached can lead to unpleasant outcomes. In the best-case scenario, you will annoy your users by breaking the app. Worst-case scenario, you will violate GDPR rules. This is certainly a situation that none of us want to experience! Don't worry - from this article, you will learn everything you need to know to make your Server-Side or Statically generated Single Page Applications ready to be cached (and hopefully distributed through a CDN)!

⚠️ Side Note: I use Nuxt.js in code examples, but the concepts and solutions are not tied to any framework.

We cache HTML templates to improve performance.

Let's learn some theory first and familiarize ourselves with the concept of full-page caching. I found a very good one on Branch CMS documentation:

"Full page cache" means that the entire HTML output for the page will be cached. Subsequent requests for the page will return the cached HTML instead of trying to process and re-build the page, thus returning a response to the browser much faster

When you open a Server-Side Rendered application, the JavaScript code first runs on the server to generate the HTML file containing all your components and data rendered. This static file is then sent to the browser. Single-Page Application framework like Vue takes control over it and makes it dynamic. This process is called hydration. At this stage your application is fully interactive.

Generating the static HTML file on the server can take a few seconds. A few seconds when your user sees a blank screen and potentially leaves your website. According to Google's study, 1-3 seconds of load time increases the bounce rate probability by 32%!

To deal with this significant performance downside of Server-Side Rendering, developers started caching the first generated response and sending it to others. Thanks to that, we perform the time-consuming rendering step only once and send its outcome immediately to all users requesting it.

The cached template has to be generic.

When we cache an HTML page generated by a SPA SSR framework like Nuxt.js it contains both the generated HTML and application state as inlined JavaScript object after the server-side code execution.

Because of that you need to ensure that there is no session-specific content in both template and application state after server-side code execution. Otherwise, it will be cached and served to all users.

A session-specific content contains data and markup that can be different depending on a user or device - for example: displayed user or device name, conditional rendering statement for specific devices etc.

If you don’t remove session-specific content from the cached template, everyone will see a page with the data of the first user.

Execute session-specific content in the browser

Our applications are rarely entirely generic in the real world, though. There is nothing wrong with it - almost every website has some content that is dynamic and depends on a current user session.

it’s important to make the dynamic content rendering happen in an environment that is isolated for each user like their browser.

This way the generic content, generated on the server is distributed immediately to all of your users and then, in their browsers, parts that make the experience tailored specifically for them are injected.

How to deal with session-specific templates

The first thing that comes to mind when thinking about session-specific content is the one of the currently authenticated user. We obviously don't want other users to receive a page that is filled with someone else's data.

Let’s see an example of excluding session-specific parts of AppHeader component from rendering on the server.

In Nuxt.js you can skip the server-side rendering of components wrapped with a built-in ClientOnly component.



<!-- components/AppHeader.vue -->
<header>
  <AppLogo />
  <!-- Keep the elements that are session-specific as client-only -->
  <ClientOnly>
    <button v-if="!isLoggedIn" @click="LogIn()">Log in</button>
    <button v-else @click="logOut()" >Log out</butt>
    <AppCart />
    <AppWishlist />
  </ClientOnly>
</header>

The server-side-rendered code of the above component will look more or less like this:



<header>
  <img src="./assets/logo.png">
</header>

Then in the browser, the rest of the elements are added dynamically.

Improving the user experience with loading indicators and placeholders

Usually, the hydration happens in milliseconds, but on some devices, it could take even more than 10 seconds. Seeing empty elements on the template can be misleading and deliver a bad user experience. Users can feel that the website is broken, or they could miss some important elements that are loaded later. We should let them know that some elements are not there yet.

The most common and effective technique of indicating yet-to-be-loaded content are skeletons.

Skeleton screens **are blank pages that are progressively populated with content, such as text and images, as they become available.* (from ***uxdesign.cc)

Skeletons are much better option than spinners because they give user a hint of what content they can expect.

Let's take a look at a practical example of Linkedin. When you enter the page, not everything is loaded yet. You immediately receive a cached skeleton home screen, and the data is loaded progressively in the browser:

The Nuxt.js ClientOnly component has a placeholder slot we can use to display a skeleton for the content that will gradually load on the client side. I used SfSkeleton component example from Storefront UI - eCommerce UI library we’ve built in Vue Storefront for our users.



<!-- components/AppHeader.vue -->
<header>
  <AppLogo />
  <!-- Keep the elements that are session-specific as client-only -->
  <ClientOnly>
  <!-- Display a placeholder until the page is hydrated -->
    <template #placeholder>
      <SfSkeleton type="paragraph" />
    </template>
    <button v-if="!isLoggedIn" @click="LogIn()">Log in</button>
    <button v-else @click="logOut()" >Log out</butt>
    <AppCart />
    <AppWishlist />
  </ClientOnly>
</header>

💡 Sometimes it is better to just use the generic state of the component as placeholder

What about the data?

Until now we talked only about the session-specific templates but what about data fetched inside components?

Most of the SSR frameworks like Nuxt or Next send the server-side state at the bottom of index.html file that comes with the rendered HTML, so you don’t have to fetch the data twice - on the server and then on the client.

If you inspect your Nuxt or Next SSR response, you will see a similar piece of code injected at the end of the body tag:



<script>window.__NUXT__={layout:"default",data:[{},{posts:[{userId:1,id:1,title:"sunt aut facere repellat provident occaecati excepturi optio reprehenderit",body:"quia et suscipit\nsuscipit recusandae consequuntur expedita et cum\nreprehenderit molestiae ut ut quas totam\nnostrum rerum est autem sunt rem eveniet architecto"},{userId:1,id:2,title:"qui est esse",body:"est rerum tempore vitae\nsequi sint nihil reprehenderit dolor beatae ea dolores neque\nfugiat blanditiis voluptate porro vel nihil molestiae ut reiciendis\nqui aperiam non debitis possimus qui neque nisi nulla"},{userId:1,id:3,title:"ea molestias quasi exercitationem repellat qui ipsa sit aut",body:"et iusto sed quo iure\nvoluptatem occaecati omnis eligendi aut [...]"}]}],error:null,serverRendered:!0}</script>

Because of that, we have to ensure that no session-specific data is in the cached HTML just like we did with the templates.

The data can be fetched from two places:

Inside the component

When the data is fetched inside the component, the case is simple. If the whole component is wrapped with ClientOnly like in the example above the execution of the component code is completely skipped on the server, so the data is fetched for the first time when its executed in the browser.



<!-- components/AppHeader.vue -->
<header>
  <AppLogo />
    <!-- None of the code from components inside ClientOny will execute on the server -->
  <ClientOnly>
    <!-- ... -->
    <AppCart :items="user.cart.items" />
  </ClientOnly>
</header>




<!-- components/AppCart.vue -->
<template>
  <!-- cart template -->
</template>

<script setup>
import { ref } from 'vue'

const cart = ref({})

async function fetchCart () {
  const res = await fetch('...')
  return res.json()
}

cart.value = await fetchCart()
</script>

If you’re REST APIs and have multiple requests on your page, executing the fetching logic inside the components is best. It’s much harder to miss the session-specific data if it’s not all around your app.

In the parent component

If you follow a smart/dumb components pattern aka. presentational/container (explained well by Dan Abramov here, and no longer a go-to approach since the introduction of React Hooks/Composition API) and fetch all the logic in the parent component, you have to take care of the session-specific data separately in the parent component.



<!-- components/AppHeader.vue -->

<AppHeader>

  <AppLogo />

    <!-- None of the code from components inside ClientOny will execute on the server -->

  <ClientOnly>

    <!-- ... -->

    <AppCart :items="user.cart.items" />

  </ClientOnly>

</AppHeader>

<script>

import { ref } from 'vue'

const cart = ref({})

async function fetchCart () {

  const res = await fetch('...')

  return res.json()

}

// onMounted runs only in the browser (client context)

onMounted(() => {

 cart.value = await fetchCart()

})

// ...other logic

</script>

Summary

To make your app cacheable and CDN-ready you have to avoid session-specific content in the cached content rendered on the server.

You have to render your application in a few steps - a generic one that renders most of the page and a session-specific one that injects dynamic parts.

Liked the article? Follow me on Twitter to get daily tips about web development.

Welcome to the new Vue Storefront Developer Portal

Heitor Ramon Ribeiro — Mon, 05 Sep 2022 02:13:22 +0000

Have you ever wondered why educational material and documentation cannot have a nice DX?

Why can't companies create a concise experience throughout their material and make it easy to understand what is needed to start developing or simple tutorials to help your daily tasks?

I also feel the same, and dang; this sucks 😟 - Heitor Ramon

That's why we, the community team at Vue Storefront, decided to create a developer portal to combine all the information you need to start developing with Vue Storefront and help you with those pesky questions, which sometimes require a lot of research and Googling.
We’d like to introduce the new Vue Storefront Developer portal, https://developer.vuestorefront.io.

Our portal concept is a unique place for all the Vue Storefront developers to find answers, acquire new knowledge, get the latest news related to the Vue Storefront community and develop even faster with Vue Storefront.

Do you like open-source projects? So do we. We made the portal open-source and chose the best future-proof tech stack for a Vue ecosystem project. Using Nuxt 3, nuxt-content, and more.

As an open-source project, you are more than welcome to participate in the decisions regarding the roadmap, features, enhancements, translation, and much more. We want to create a friendly and welcoming place for our community members.

Right now, our portal has a documentation hub , an easy link to our community, and a video section. All to help our developers find the information they need, quickly.There is more to come, full cross documentation search, certifications and badges, an integrated community area, user area, events area, a single stop for all the docs (yes, all the docs will be available in the portal), and much more.

As an open-source project, we are happy to have your participation in the decisions and coding of the portal. The portal being open-source is a way for our community to empower it and choose what is best for it.

There will be an open roadmap with the features planned by the community team, but we are always available for new features, enhancements, fixes, and more. Check the code of the portal at https://github.com/vuestorefront/developer.vuestorefront.io.

Come visit our portal, and let's share this amazing news with all of your developer friends and community.

How to add custom API methods to Vue Storefront 2

Jakub Andrzejewski — Mon, 29 Aug 2022 05:50:08 +0000

Vue Storefront allows you to scaffold your next E-Commerce website in minutues. You can choose from a variety of platforms like Magento, Shopify, Commercetools, and many more!

In this tutorial, I would like to guide you through the process of adding a custom API method to create a new function for your E-Commerce. It will allow you to have a completely new endpoint extension that could send a new request, a GraphQL query/mutation, or something completely different as well.

For this tutorial, I will be using Vendure integration, but you are free to choose any E-Commerce integration you want. The process is the same for all these integration with a small difference depending on the API client that the integration is using (either Apollo GraphQL or Axios REST).

Code

First of all, you would need to register a new extension in a middleware.config.js file:

module.exports = {
  integrations: {
    vendure: {
      location: '@vue-storefront/vendure-api/server',
      configuration: {
        api: {
          uri: process.env.GRAPHQL_API,
          // to be used later with authentication
          tokenMethod: process.env.TOKEN_METHOD
        }
      },
      extensions: (extensions) => [
        ...extensions,
        {
          name: 'test',
          extendApiMethods: {
            testApiMethod: async ({ client, config }) => {
              const result = await client.query({ query: gql`
              query products {
                products {
                  items {
                    id
                    customFields
                  }
                }
              }
              `, fetchPolicy: 'no-cache' })
              console.log(result)
            }
          }
        }
      ]
    }
  }
};

Let's focus on the part from the extensions as everything else is just a default value for the certain integration to work properly.

Extensions will accept a parameter called extensions, and it is important to return a spread extensions in the final return. Otherwise, the default extensions in the integration may stop working so just please remember to return them as well. Next, we can see the structure of a new extension. Let's take a look at it with more details:

{
  name: 'test',
  extendApiMethods: {
    testApiMethod: async ({ client, config }) => {
      const result = await client.query({ query: gql`
      query products {
        products {
          items {
            id
            customFields
          }
        }
      }
      `, fetchPolicy: 'no-cache' })
      console.log(result)
    }
  }
}

First of all, we need to name our new extension. It is advised to give it some unique name (i.e. fetch-multiple-products) but in this case, I am just showing a test example. Next, we will have an extendApiMethods object where each property can represent its own new or extended API method. Each API method have access to the destructured client parameter. This parameter can then be used to call certain requests, queries, or mutations really easily from the frontend. This example shows how to fetch the multiple products from the GraphQL API by using the custom API method (the new one as Vendure does not have this query implemented - products are being fetched by using different query)

Then, you can use the newly created API method in your component or a page like following:

const { $vendure } = useVSFContext();

onSSR(async () => {
    await $vendure.api.testApiMethod()
});

If everything worked correctly, you should see a result of a products query in the console where the project is running.

Summary

Well done! You have just implemented a completely new API method in your Vue Storefront 2 project. This knowledge will allow you to customize it even more to suit your business needs better.

Everything you need to know about Web Performance (in 5 Minutes)

Filip Rakowski — Thu, 23 Jun 2022 15:00:53 +0000

I hear a lot of people saying that web performance is hard. Honestly, I don't think that's true. It could feel complex and intimidating at first glance because there is a lot of domain-specific naming, metrics, etc but to build a fast website you don't need to know them. You only need a basic understanding of what influences the speed of your website the most and make sure you have it under control. Believe me or not, you can learn this in about 5 minutes. Let's see if I'm right!

What influences your app performance?

Let's start with identifying all the aspects that influence your app performance. I find this mental model most useful when thinking about web performance:

There are essentially three "steps" that sum up the overall loading performance of your app

Server-side execution - First the HTML document has to be generated on the server. In some cases, this step costs us nothing because it's already generated (static sites).
Network - The generated HTML document has to travel through wires and routers to arrive in the user's browser.
Client-side execution - The document needs to be parsed, and dependencies (CSS, JavaScript) have to be downloaded and executed. Once it's all done our page is fully loaded.

Optimizing server-side execution

If you're building a SPA (Single Page Application) there is a high chance you're also adopting SSR (Server-Side Rendering). In that case, the same code will run both on the server and the client sides.

The best code is the one that never has to run so you should first consider SSG (Static Site Generation). If it's not an option and you're sticking to SSR, make heavy use of full-page caching and distribute cached content through CDN.

Some pages will have to be generated on the server during runtime and just cannot be cached. Of those, make sure to fetch only fast, essential data on the server and make less important, and slower API calls on the client-side. This way you will significantly improve your Time to First Byte.

Optimizing Network

Optimizing the networking part boils down to 4 main rules:

Ship the smallest possible assets. The bigger they are, the longer it takes to download them.
Avoid chaining network requests (making one request depending on another) and try to download them in parallel.Avoid using multiple external domains in the critical path. Establishing a connection with all of them will take more time than downloading everything from one source.
Cache static assets (HTML, CSS JS) through a Service Worker.

Source: https://developer.chrome.com/blog/app-shell/

If you take care of that there is a much smaller chance you will run into performance bottlenecks on the network part.

Optimizing client execution

This is where we, frontend developers, have the most power and where we also make a lot of mistakes! From my experience, 90% of frontend performance bottlenecks are around rendering time (that one can be easily solved with cached SSR and SSG output) and interactivity (that one can be solved by reducing amount of JavaScript in so-called critical rendering path through code splitting, lazy loading and being cautious with adding new libs to the clients).

The thing that usually leads to the biggest number of performance bottlenecks is JavaScript. In SPAs it's very easy to lose control over your JS bundle size. Here's what you can do to prevent it from growing into a Brontosaurus:

If you're using SSR/SSG it means that many of your components are already rendered on the server and they don't need interactivity on the frontend. You can drastically increase the speed of your hydration by hydrating only the components that need to be interactive and only when they need to become ones. You can use Astro.build or vue-lazy-hydration plugin if you're using Nuxt to control the hydration process and exclude the components that don't need it.
Split your app into multiple lazy-loaded chunks (start with routes!). Every sidebar, modal or expensive widget can be loaded lazily on interaction.
Your website could seem fast when you're building it but once the marketing team puts all the analytics there I guarantee it will slow down. You can use web workers to run the non-critical code asynchronously. I strongly recommend Partytown - it's integrated with all major frameworks from the Vue ecosystem. Source: https://partytown.builder.io/

Optimizing images

Surprising amount of developers does a rookie mistake of not optimizing their images. To make sure images aren't the bottleneck simply adjust their size to the screen and use next-gen formats like webp. You can automatically resize and optimize your images using and/or Cloudinary. Also, load your below-the-fold images last. You can use native <img loading="lazy" /> property for that.

Measuring performance

If you can't measure – you can't say if there was any improvement. Measuring your performance constantly is as important as optimizing it regularly.

The performance metrics that have the biggest impact on user experience are called Core Web Vitals (CVV):

Largest Contentful Paint (LCP): measures loading performance.
First Input Delay (FID): measures interactivity.
Cumulative Layout Shift (CLS): measures visual stability.

Source: https://web.dev/vitals/?gclid=Cj0KCQjw2MWVBhCQARIsAIjbwoN567MYvlge9gXipQmZGvQG-9WZddKuQXRto_NiuIaHaTXStrjNFx0aApY9EALw_wcB

If you want to quickly check how your website is performing, try Page Speed Insights. It will run a Lighthouse audit on your website using the closest Google Data Center.

You should also incorporate performance checks into your CI/CD pipeline. Use Lighthouse CI to run a synthetic Lighthouse test on each PR (PS: Learn why you shouldn't believe the Lighthouse score alone) and bundlesize package to raise alerts if your bundle size exceeds a certain threshold. For more nuanced data you should use WebPageTest.

Believe me or not but that's all you need to know to have your performance under control!

If you liked the article and want to learn more about web performance through articles and tips you can follow Vue Storefront profile here or follow me on Twitter

How to enable Cache in Vue Storefront 2

Jakub Andrzejewski — Mon, 06 Jun 2022 06:24:06 +0000

Cache is a really important concept in modern web development that allows to greatly improve the second load of the certain page and in general, improve the User Experience. If you are not yet familiar with it, I have published an article about it some time ago that you can read here.

In Vue Storefront cache can be enabled on both browser and the server. The first one will be using a Cache-Control response header to cache the response on the browser, while the second, will be using a cache driver like Redis to cache all pages.

Browser Cache

To enable Cache on the browser level, we will be using a http-cache package from Vue Storefront that you can check out here.

Installation

This package handles adding http-cache header to document after render for caching capabilities

First, install the dependency

yarn add @vue-storefront/http-cache

Next, add it to the modules array in your nuxt.config.js:

['@vue-storefront/http-cache']

And that's it. Thanks to this module, homepage, category page, and product page will be automatically returning a response header Cache-Control with a certain default value that will enable your browser to cache it properly. Check out the following section to see some configuration options.

Configuration

The package allows you to configure certain properties of it to make it work differently and suit your needs best.

`default`

This property allows you do override default value of http-cache header which is initially set to max-age=60

['@vue-storefront/http-cache', {
  default: 'max-age=120'
}]

`matchRoute`

Customize http-cache values for selected routes. you can use * for a wildcard. To remove http-cache header use none value.

['@vue-storefront/http-cache', {
  matchRoute: {
    '/': 'max-age=240',
    '/p/*': 'max-age=360',
    '/c/*': 'none'
  }
}]

Server Cache

To enable Cache on the server side, we can also use the packages provided by Vue Storefront, namely @vue-storefront/cache and @vue-storefront/redis-cache.

First, let's install the required dependencies

yarn add @vue-storefront/cache
yarn add @vue-storefront/redis-cache

Next, let's add required configuration for the packages to work correctly

// nuxt.config.js

export default {
  modules: [
    ['@vue-storefront/cache/nuxt', {
      invalidation: {
        // Invalidation options
      },
      driver: [
        '@vue-storefront/redis-cache',
        {
          defaultTimeout: 86400,
          redis: {
            host: 'localhost',
            port: 6379,
            password: 'password'
          }
        }
      ]
    }]
  ]
};

Check out the following docs to understand better the process of using server cache with Vue Storefront:

Summary

Well done! You have just enabled the Cache on both browser and server environments of your Vue Storefront application. This should improve the performance of you e-commerce website by a mile!

How to add TailwindCSS to Vue Storefront 2

Jakub Andrzejewski — Mon, 30 May 2022 06:37:27 +0000

TailwindCSS is becoming a number one CSS framework on the market. Whether you like it or not, it is being used in more and more applications and it is also coming as a default for some popular projects. Due to its simplicity and many Developer Experience improvements, Tailwind joined a DX Gang and has a safe position there.

In this article, I would like to guide you through the process of adding TailwindCSS to your Vue Storefront project. It can be used as an alternative to Storefront UI styles or be used with it.

Vue Storefront

If you are not yet familiar with Vue Storefront, it is Lightning-Fast Frontend Platform for Headless Commerce. Boost your site performance, shape the customer journey and free your developer's creativity with Vue Storefront, the last frontend you will ever need.

You can check out more about it here:

Storefront UI

Vue Storefront uses by default a really useful UI Library called Storefront UI. It was designed based on Google for Retail report and specifically for E-Commerce. It is really customizable and allows to accelerate the development of your e-commerce application by a mile!

You can read more about it here:

Adding TailwindCSS to VSF

As Vue Storefront uses Nuxt.js under the hood, the process of adding it to your project is relatively simple. Especially with the recent release of a new version of Tailwind Module for Nuxt that you can check the code here. In this version, you do not need to register tailwind config nor postcss config in your nuxt application in order to make it work. How briliant is that?

In order to install the Tailwind module in Vue Storefront application we need to run:

yarn add @nuxtjs/tailwindcss # npm install @nuxtjs/tailwindcss

Then, we need to register it in the modules array of our nuxt.config.js file:

  modules: [
    // Other modules
    '@nuxtjs/tailwindcss'
  ],

Finally, to test if it works, we can add some Tailwind styles to our wrapper component:

<div id="home" class="bg-blue-300">

And this should be a result:

Summary

Well done! You have successfuly added TailwindCSS to your Vue Storefront project. Keep in mind however, that Storefront UI wasn't designed to work with TailwindCSS out of the box so in order to replace the styles you would have to adjust several CSS variables and this process is described here

Forem: Vue Storefront

Everyday Challenges of Responsive Web Design

Using <picture> element example

The Role of the <picture> Element in RWD

Understanding the <picture> Tag

The Code in Action

Best Practices for Using the <picture> Element

The why

Considering alternative approaches

Why not just load images based on device detection?

A more complex example

The Challenge

The Solution

How to build accessible button component

Intro

Semantics as a starting point

Using the <button> tag

Using a <div> or <input>

Design vs. Development

Accessibility properties

Role vs. type

Aria Labels

Preventing button click

Button as a link or link as a button?

Keyboard a11y

1. Focus outlines are ugly.

2. Keyboard accessibility is more than just tabbing around the elements.

Button a11y Checklist

Summary

A Framework-Agnostic Magento 2 Integration: The Next Step in eCommerce Frontend Development:

The Framework-Agnostic Design

What's Next?

Inviting Collaborators

Investing in Developer Experience Could Be The Best Growth Hack for Your Business

Developer Experience is User Experience

Developer Experience drives web tools adoption

Developer Experience improves the efficiency of your team

It’s not always worth migrating to the next big thing

Developer Experience attracts talent

Summary

Using Custom Queries in Vue Storefront 2

What is URL Resolving?

What is an URL?

What is a URL Resolving?

Comparison of URL Resolving patterns

Why the right URL structure is important?

URL Best Practices

Resources

How to deal with caching and dynamic content in Nuxt?

We cache HTML templates to improve performance.

The cached template has to be generic.

Execute session-specific content in the browser

How to deal with session-specific templates

Improving the user experience with loading indicators and placeholders

What about the data?

Inside the component

In the parent component

Summary

Welcome to the new Vue Storefront Developer Portal

How to add custom API methods to Vue Storefront 2

Code

Summary

Everything you need to know about Web Performance (in 5 Minutes)

What influences your app performance?

Optimizing server-side execution

Optimizing Network

Optimizing client execution

Optimizing images

Measuring performance

How to enable Cache in Vue Storefront 2

Browser Cache

Installation

Configuration

default

matchRoute

Server Cache

Summary

How to add TailwindCSS to Vue Storefront 2

Vue Storefront

Storefront UI

Using `<picture>` element example

The Role of the `<picture>` Element in RWD

Understanding the `<picture>` Tag

Best Practices for Using the `<picture>` Element

Using the `<button>` tag

Using a `<div>` or `<input>`

`default`

`matchRoute`