So I've been trying to make our Blog page responsive for when it's being viewed on mobile devices. The issue that I'm running into is that I can't figure out where and how to add the "@ media query" instructions for the specific s .
Hi . Anyone know what the dawn theme is like for mobile responsiveness ? My Supply theme is a bit old now and core vitals tells me my site is poor for mobile devices responsiveness and to minify and remove unwanted code etc (CSS and JAvascript) but am not that tech savvy and was wondering if one of the 2.0 themes might help ?
Most of the shopify themes are mobile responsive, it might be other issues like text too small or clicking areas has issues and to minify and remove unwanted code etc (CSS and JAvascript) you need to follow any online guide if you google you will find many how to do them. If you need help i can assist. Thanks.
In terms of mobile responsiveness, the Dawn theme has been optimized for a range of mobile devices and screen sizes. It is designed to automatically adjust the layout and content of your store to ensure that it looks great on any device, whether it's a smartphone, tablet, or desktop computer.
1. Optimize your images
Large images can significantly slow down your site's loading time and impact mobile responsiveness. Use an image optimization tool like Shopify's built-in image optimizer or third-party apps to compress and resize your images without losing quality.
2. Minimize and remove unnecessary code
Large and bulky CSS and JavaScript files can also slow down your site's loading time and impact mobile responsiveness. Use a code minified tool to compress and remove any unnecessary code from your files to improve your site's performance.
3. Use lazy loading
Lazy loading is a technique that delays the loading of certain content (such as images or videos) until the user scrolls to it. This can significantly improve your site's loading time and performance on mobile devices.
4. Reduce HTTP requests
Each time your site loads, it sends requests to the server for various files, such as CSS, JavaScript, and images. The more requests your site makes, the longer it will take to load. Use tools like GTmetrix or Google PageSpeed Insights to identify any unnecessary requests and reduce them.
5. Use Accelerated Mobile Pages (AMP)
AMP is an open-source framework that can help improve your site's mobile performance by optimizing your content for faster loading times. Consider using AMP for your blog or other content-heavy pages.
6. Optimize your checkout process
Make sure your checkout process is optimized for mobile devices, with large, easy-to-use buttons and a streamlined checkout flow. Use tools like Shopify's mobile app or third-party apps to provide a better mobile checkout experience.
Let's unpack those objectives. 1 and 2 seem to be competing, correct? How do we both make our images small but also not make them look degraded? Getting this balance right is the core of responsive image techniques and the focus of this article.
File format is arguably the most important thing to get right when it comes to images. The web started with GIF images, but not the animated ones you're thinking of. GIFs compress images in a naive way which in layman's terms makes them look bad. JPEGs, or JPGs, were created with a better compression algorithm more closely based on how the human eye works. Now, we have even newer file formats like WEBP and AVIF with JPEG XL on the future horizon.
Luckily, if you use image_url in Liquid, you don't have to worry about selecting the best file type. The Shopify image API will automatically select the best image format for you that is the right balance between size and quality.
For example, in the following image from the image_tag documentation, I've opened up the Chrome Dev Tools Network tab to show you the request for the example image. The request URL makes the image seem like it is a JPG, but in the Type column, we can see that it is AVIF. AVIF is a brand new image file format that can compress images well with less degradation. AVIF is not available on all browsers, but the Shopify image API can figure that out for us.
When it comes to simpler images like logos and icons, and the smiley face from above, it's better to use a vector format. Vector images are a set of drawing instructions. They can be scaled infinitely and will always look good. On the web, SVGs are the only vector image format. We won't cover SVGs in this post, but try to use them as much as possible for logos and icons.
Once we have the right image format, the browser needs to display the right size image. At this point, we need to better understand DPR, or device pixel ratio. A DPR of 1 means that a 100px width block on the screen (display width) could only display a 100px width image (natural width). Now, nearly all mobile devices and some laptop and desktop monitors have a DPR of 2 or more. For a DPR of 2, we would need an image natural width of 200px to look good at a 100px display width. Using x-descriptors, this would be called a 2x image.
As a developer, we know the width we want to display the image, but we do not know the DPR of the user's device. This is where the srcset attribute can help us. The srcset provides a set of candidate files. The browser knows the user's device screen size and DPR, so it can then pick the best image to download based on the candidate files we give it.
In the following code sample, I'm giving the browser 2 candidate files - one is 300px wide and the other is 600px wide. I'm also supplying the src attribute as a fallback for very old browsers like IE11.
In this example, the browser will assume the image display width is the same as the viewport width. Thus, a mobile phone user would likely download the 600px width image since most mobile phones now have 2x and higher DPR with a screen size of around 330px. This might be counterintuitive to what you would expect!
The reason we can't rely only on our CSS is that it takes more time for the browser to download and parse the CSS. We don't want to wait that long before downloading the correct image. So we provide CSS-like information in the HTML so the browser can make the best decision on which image size to download as quickly as possible.
As a reminder, both srcset and sizes are providing hints to the browser. We're no longer telling the browser exactly which file to download but giving it information about how the image will display and a set of file candidates. The browser will make the final decision on which to download based on the user's screen size and device pixel ratio (DPR).
Not all browsers support all image file formats. So how do we serve newer, better file formats while not breaking images for older browsers? The tag gives us even more power than an when it comes to providing file candidates.
The tag wraps around an element and then provides one or multiple tags that can modify the srcset. In the following example, our fallback for older browsers is to serve the pug_life.jpg file. Newer browsers that understand the and elements will instead read the attributes of the elements to determine which srcset to use:
In this case, we are providing the type attribute which refers to file type or format. If a browser can display AVIF images, it will use the pug_life.avif file. If not, it will check the remaining types and serve the first matching one. If it understands none of the types, it will serve whatever is in the tag.
Currently, when using the image_url filter, the Shopify image CDN will automatically select the best file format based on the user's browser. So luckily we don't have to worry about using the tag to provide file format fallbacks. #winning!
Art direction means a lot more in the design world, but when we use the term in the realm of web development and responsive images, we mean serving different files on different screen sizes. Maybe you want to show a zoomed-in and cropped version of an image on mobile or perhaps a different aspect ratio.
This is a more complex use case, so Liquid does not have a one-stop filter. Instead, we will wrap our image_tag in a element then use multiple image_url filters inside of the to create the srcset manually (demo):
Another great use-case for the is to prevent the browser from downloading 3x and higher images on mobile. Many mobile screens have a DPR of 3 or higher. Thus, we can get in cases where we want a very large image on desktop, say 1500px wide, and that same size will be downloaded on mobile. ?
One exception here may be product images that can be zoomed in (pinch in/out). Consider what type of product you're selling and what the image is showing. For example, with clothing, it might be important for a buyer to zoom in to see the fabric weave. Test which resolution looks good when zoomed in. At some point, you will get diminishing returns as the heavy file sizes will start to affect load performance and mobile data plans.
I would argue for most non-product images on your site, you probably don't need higher than 2x images. So how would we "DPR-cap" those images to 2x? For this example, I want my image to display 300px wide on mobile and 1000px wide on desktop. I only want to give 1x and 2x image options at each screen size (demo):
The code is very similar to our art direction example, we're just using the same image for both sources. However, I've switched to x-descriptors for my mobile srcset to force the browser to only consider DPR. You could simplify this example more by dropping the 1x option in the srcset since most mobile phones have 2x and higher screens. If your customers use feature phones, it may be smart to keep the 1x versions.
First, don't go overboard on the srcset. When you have too many files in a srcset, you're reducing the chance that an end-user would see the performance benefits of caching, meaning longer network delays. If an image is not yet in an edge server, the request will need to go back to the origin server to request it. Even worse, if that image size has not yet been generated from the image API, the request will be further delayed. Cache expirations are not infinite so too many sizes in the srcset means a higher likelihood of longer requests. To add insult to injury, if your website gets lower traffic, you're even less likely to have all those image options in the CDN cache.
c80f0f1006