Hi everyone, i am currently working to create shopify store using the dawn theme and i am trying to integrate some custom feeature using custom liquid i wanted to ask that what is the best way to make sure that adding dynamic elements, stylesheet or custom script doesn’t effect mobilee responsive or slow down the stores landing speed and how do you debug liquid rendering issues?
I would be grateful for any advice.
I’d keep the custom stuff as light as possible, especially anything running on page load. If something can be handled in Liquid or CSS instead of JavaScript, I’d usually go that route first.
For anything that does need JS, I’d load it only where it’s actually needed rather than having every page run the same script. Same with CSS, keep it scoped to the section you’re changing so you don’t accidentally create weird mobile behavior somewhere else.
I’d also test on an actual phone, not just by dragging the desktop browser window around. Chrome DevTools with CPU and network throttling is useful for finding stuff that feels fine on a fast connection but gets sluggish on mobile.
For Liquid issues, Theme Inspector is really useful when you have loops or a lot of dynamic data. It can show you which parts of the Liquid rendering are taking time instead of guessing.
One other thing I’d do before adding more features is run the store through SiteGuru. It won’t replace the browser performance tools, but it’s a nice second check for the technical side and can catch issues you might not notice while focused on your custom code.
And definitely duplicate the Dawn theme before experimenting. Makes debugging a lot less painful when you know exactly which change caused something to break.
Put your CSS in a {% stylesheet %} block inside the section rather than a separate file or inline <style>, since Dawn bundles those automatically and you avoid an extra request.
For JS, always add defer so it never blocks rendering, and if it’s below the fold, only initialise it when the section scrolls into view.
The one that bites everyone on custom sections is images: use image_url with width and loading="lazy" on anything below the fold, since a full size image is what actually kills your mobile score, not the Liquid. And for debugging, add ?debug=liquid to your URL with Theme Inspector installed to see which parts are slow, and remember custom sections need re-initialising on shopify:section:load or they break in the theme editor.
Best,
Moeed
For styles, try to keep them in one place instead of scattering CSS across a bunch of custom liquid blocks, and for scripts only load them on the pages that actually need them, not sitewide.
For debugging, I’d do it in this order: add one change at a time, test on mobile after each change, and use Chrome DevTools plus Lighthouse to see whether the hit is from layout shift, script execution, or just too much extra markup.
If a section breaks, comment out half of the custom code, test again, then narrow it down from there. That’s slower than guessing, but it saves a lot of time when Liquid and JS are both involved.
One other thing, Dawn already handles a lot of responsive behavior for you, so if something looks off on mobile, I’d check whether the custom code is fighting the theme’s built-in spacing or flex rules before assuming Liquid itself is the problem.
Hey @angelina-new-user ,
One thing I’ve learned with custom Liquid is that it’s pretty easy to add something that works fine on desktop but creates problems on mobile or adds unnecessary load.
I’d keep the CSS & JS as small as possible and avoid loading scripts globally if they’re only needed for one section or one page. I’d also test the feature on an actual phone, not just the browser’s mobile preview.
For Liquid issues, I normally check the rendered HTML and browser console first. Shopify’s Theme Inspector can also help when you’re trying to figure out where the rendering or performance issue is coming from.
For performance, running PageSpeed Insights before and after adding the custom code is a good way to see whether the change actually made a difference.
In my experience, testing each custom feature separately makes debugging much easier than adding several things at once.
Thank You!
When working with Dawn and adding custom features, I always focus on performance and responsive architecture first. My approach would be:
For any custom section you create, keep its CSS and JavaScript within the section itself whenever possible. This keeps the code organized and prevents unnecessary global CSS/JS from affecting the entire theme.
Use Dawn’s existing CSS tokens/variables for colors, spacing, typography, etc. This avoids rewriting the same CSS repeatedly and keeps the custom section consistent with the theme.
For images, use Shopify’s built-in responsive image handling by default, such as image_url and image_tag. Shopify can then serve an appropriate image size based on the device and screen size.
Load JavaScript using an appropriate strategy such as defer, and avoid unnecessary third-party scripts.
Build the layout with mobile responsiveness in mind from the beginning, rather than fixing mobile issues afterward.
Lazy-load heavy sections, widgets, and non-critical content where appropriate.
After adding custom code, use Chrome DevTools, Lighthouse, and Shopify Theme Inspector to check Liquid rendering time, JavaScript execution, network requests, and Core Web Vitals.
For Liquid rendering issues, use Theme Check, the browser console, rendered HTML, and Shopify’s preview environment to isolate problems.
Try to work with Dawn’s existing architecture instead of unnecessarily modifying or duplicating core theme files.
For LCP and CLS specifically, pay close attention to hero/banner images, fonts, and above-the-fold content. Avoid using JavaScript to unnecessarily modify the DOM after the page has loaded, as this can negatively affect both CLS and overall performance.
This approach allows you to build advanced custom features in Dawn while keeping mobile responsiveness, loading speed, and Core Web Vitals under control.
Best regards,
Devcoder 
@angelina-new-user Dawn is a good base, and custom Liquid is fine if you treat every addition like it will still be there in a year.
Rules we use on Melbourne builds:
Maintenance matters as much as the first write. Revisit custom sections after app installs and theme updates. That is when orphaned scripts and broken selectors sneak in. Happy to look at a specific section if you paste it.