Ecommerce Website Development in Pune: Why Your Shopify or WooCommerce Store Is Slow, and the Fixes Worth Paying For
A Shopify or WooCommerce store is usually slow on mobile for a short list of reasons: oversized or wrongly loaded hero images, too many third-party scripts (apps, pixels, chat and review widgets), a heavy theme, and on WooCommerce, weak hosting or caching that is set up badly. The fixes worth paying for are the ones that move the three Core Web Vitals, which Google asks you to keep at 2.5 seconds or less for Largest Contentful Paint (LCP), 200 milliseconds or less for Interaction to Next Paint (INP) and 0.1 or less for Cumulative Layout Shift (CLS), measured at the 75th percentile of real visits. In ecommerce website development in Pune, the first job is not to buy a "speed package". It is to find out which of those three numbers fails, on which page type, and why.
This article is for owners and marketing leads of Indian online stores deciding what to fix and what to pay for. It covers diagnosis, the usual causes on each platform, a prioritised table of fixes, an audit sheet and how to scope the work. It does not cover payments, shipping or tax. Thresholds come from Google's web.dev and Search Central, Shopify's developer documentation and WooCommerce's documentation, read in October 2026; they change, so check current versions before briefing a developer.
What "slow" actually means: the three numbers
Google's web.dev guidance defines the three Core Web Vitals and their "good" thresholds. A page is treated as passing when all three are good at the 75th percentile of page loads, split by mobile and desktop.
| Metric | What it measures | Good threshold (web.dev) | What a shopper notices |
|---|---|---|---|
| LCP, Largest Contentful Paint | When the biggest visible element (usually the hero or main product image) finishes rendering | 2.5 seconds or less | Blank or half-built screen after tapping an ad |
| INP, Interaction to Next Paint | How quickly the page responds visually after taps, clicks and key presses | 200 milliseconds or less | Tapping a size or colour and nothing happens for a moment |
| CLS, Cumulative Layout Shift | How much content jumps while loading | 0.1 or less | Tapping a button just as the page shifts, and hitting the wrong thing |
The 75th percentile matters: three in four visits must meet the threshold. A store that feels quick on your new phone over office Wi-Fi can still fail, because the slowest quarter are on older Android phones and patchy 4G. See also our article on website speed optimization for Indian mobile users.
Field data versus lab data
Google's PageSpeed Insights documentation explains the split. Field data comes from the Chrome User Experience Report (CrUX) and reflects real users over the previous 28 days; this is what the Core Web Vitals verdict uses. Lab data is a Lighthouse simulation on one emulated device (the documentation describes a Moto G4-class phone on a mobile network). It is repeatable and good for debugging, but it is a test, not a report on your customers.
They often disagree. A poor lab score with good field data is common when most visitors are returning customers with cached assets; a good lab score with failing field data happens when real users do things the lab never does, such as opening a cart drawer. web.dev also notes that Lighthouse cannot measure INP, because it loads a page without a user interacting; Total Blocking Time is only a proxy.
PageSpeed Insights shows URL-level field data only when that URL has enough traffic, otherwise it falls back to the whole origin. And because the window is 28 days, a fix takes up to a month to show fully. Do not judge a deployment after two days.
What to open first: a 30-minute diagnosis
- Google Search Console, Core Web Vitals report. With enough traffic it groups URLs as poor, needs improvement or good for mobile and desktop and names the issue, such as "LCP issue: longer than 2.5s". Note which URL groups fail; on most stores it is product or collection pages, not the home page.
- PageSpeed Insights on one URL per template: home, collection, product and cart. Read the field panel first, then the lab diagnostics, and write down the LCP element it names.
- List every script and app the store loads: the app list, the theme code, the plugin list and the tag manager container.
- Record a baseline in a sheet: template, LCP, INP, CLS, date, who tested.
If Search Console shows no Core Web Vitals data, the store may not have enough traffic for CrUX. Rely on repeated lab tests then, and do not draw conclusions from one run, because lab scores vary.
Why Shopify stores get slow
Shopify handles hosting and the CDN, so slowness is mostly about what is added on top. Shopify's theme performance guidance names server render time (driven by Liquid), LCP, CLS and INP, and tells developers to audit third-party app scripts.
App bloat. Every app that touches the storefront can add JavaScript, CSS and requests to every page, even where it does nothing. Review apps, wishlists, pop-ups, upsell widgets and size guides are the usual list. Uninstalled apps sometimes leave snippets behind in the theme, and overlapping apps (two pop-up tools, say) are common. The fix is an audit: for each app, record what it does, what it loads, which pages need it and what it earns, then remove, replace with theme features or restrict it.
Theme code. Shopify's guidance lists the highest-impact practices: never lazy-load the LCP image, mark it with high fetch priority, avoid animations that hide it, render critical content in Liquid rather than JavaScript, and avoid deeply nested Liquid loops, which it says grow quadratically with catalogue size. If the theme is old and heavily edited, ask whether a current theme with light customisation would be cheaper than patching, and ask the developer to show script weight as evidence.
Tags, review and chat widgets. Pixels and analytics tags load through Tag Manager or app embeds. Typical faults are duplicate tags, tags firing on every page and tags for finished campaigns. Review widgets inject content late, which can hurt INP and CLS, and chat widgets are heavy; load them after the page is interactive and reserve space for late blocks. For support, a plain click-to-chat link is lighter than a widget script; deeper automation is covered under WhatsApp Business API.
Why WooCommerce stores get slow
WooCommerce runs on your own hosting, so slowness can come from the server, caching, plugins and the database.
Hosting and PHP. WooCommerce's server recommendations page currently lists PHP 8.3 or greater, MySQL 8.0 or greater or MariaDB 10.6 or greater, and a WordPress memory limit of 256 MB or more, with older versions only for legacy setups. Check it for current figures. An old PHP version or a crowded shared plan raises Time to First Byte before any page code runs, and web.dev notes that nothing on the front end can happen until the first byte arrives. Ask your host which PHP version runs, whether object caching exists and how fast an uncached product page responds.
Caching exceptions. Full-page caching is the biggest gain for a catalogue, but WooCommerce's documentation says the Cart, Checkout and My Account pages must be excluded because they show customer-specific information, and lists session and cart cookies caching must respect. Cache them and customers see stale or wrong cart state; exclude too much and you lose the benefit. A developer should say exactly what is excluded and why.
Plugins. Page builders, sliders, mega menus and add-on packs often load CSS and JavaScript on every page. See our WordPress plugin audit guide for what to remove and how to test on staging.
Database. Expired transients, large autoloaded options, old sessions and logs slow uncached requests such as cart, checkout and filtered searches. Clean on staging with a backup first.
Images and CDN. Themes and builders sometimes output full-size files instead of responsive sizes. A CDN speeds delivery but does not fix the wrong image at the wrong size. For the WordPress angle see Core Web Vitals optimization for WordPress.
Image handling: the same rules on both platforms
Images are usually the heaviest bytes on a store page and often the LCP element.
- Modern formats. WebP and AVIF generally give smaller files than JPEG at similar quality. Check the Network panel to confirm they are actually served.
- Right dimensions. Use responsive
srcsetandsizesso a phone gets a phone-sized file; Shopify recommends itsimage_tagandimage_urlfilters with size attributes. - Width and height. web.dev's CLS guidance says to set them, or CSS aspect-ratio, so the browser reserves space.
- Never lazy-load the LCP image. web.dev says this causes unnecessary resource load delay and hurts LCP. Speed plugins that lazy-load every image, hero included, cause it often. Lazy-load below the first screen only.
- Prioritise it. Add
fetchpriority="high"to the likely LCP image, as web.dev and Shopify both advise, on one image rather than several.
web.dev splits LCP into time to first byte, resource load delay, resource load duration and element render delay, and says most time should go on the first byte and the image download. Ask which part is largest on your product page.
Third-party script governance
Many stores are slow for no obvious reason because nobody owns the script list. A short process helps more than a one-off cleanup:
- Keep an inventory: vendor, purpose, requester, pages, date added.
- Name one owner who approves new tags.
- Load by page type: checkout pixels need not run on blog posts, and review widgets are not needed on the cart.
- Defer chat, heat-mapping and recording scripts until after the page is interactive.
- Put an end date on temporary campaign tags.
- Test a template with and without a script on staging and keep the result.
Be honest about trade-offs: removing a pixel can reduce what ad platforms optimise on, so involve whoever runs your Google Ads or Meta Ads before cutting.
INP: when the page looks loaded but feels sticky
INP is the metric stores most often fail without knowing, because lab tools do not measure it. web.dev splits each interaction into input delay, processing duration and presentation delay.
- Input delay: the main thread is busy with a long task, often from load-time scripts or third-party code. Break up tasks, defer or remove scripts.
- Processing duration: slow handler code, such as a variant selector recomputing everything, a filter re-rendering the whole grid or a cart drawer rebuilding the cart in JavaScript.
- Presentation delay: time to paint afterwards, which web.dev links to large DOMs and heavy client-side HTML rendering. Collection pages with hundreds of cards and mega menus with thousands of links are typical.
Test by hand on a mid-range Android phone: open the menu, pick a variant, add to cart, open the drawer, apply a filter. web.dev notes INP work is iterative, since fixing the slowest interaction exposes the next. Ask the developer to name the interaction and show the long task in a trace.
Prioritised fixes: effort versus impact
The ratings below are qualitative and describe typical stores. They are not predictions of percentage gains, because results depend entirely on what is currently wrong. Always measure first.
| Priority | Fix | Platform | Effort | Likely impact | Main metric |
|---|---|---|---|---|---|
| 1 | Stop lazy-loading the hero and set fetch priority on the LCP image | Both | Low | High if the hero is the LCP element | LCP |
| 2 | Resize and compress hero and product images, serve WebP or AVIF with correct dimensions | Both | Low to medium | High on image-heavy pages | LCP |
| 3 | Remove unused apps or plugins and their leftover code | Both | Low to medium | Medium to high | LCP, INP |
| 4 | Third-party script audit: remove duplicates, restrict by page, defer chat and review widgets | Both | Medium | Medium to high | INP, LCP |
| 5 | Correct page caching with cart, checkout and account exclusions | WooCommerce | Medium | High on slow uncached stores | LCP, TTFB |
| 6 | Upgrade PHP and hosting plan, add object caching | WooCommerce | Medium | Medium to high if the server is the bottleneck | TTFB, LCP |
| 7 | Fix slow variant selector, filter or cart drawer code | Both | Medium to high | High for INP failures | INP |
| 8 | Theme replacement or rebuild | Both | High | High only when the theme is the root cause | All |
The top rows cost little and often address the actual problem; a rebuild is the last resort. If a quote opens with one before any diagnosis, ask for the evidence.
Before paying a developer: the audit sheet
Complete this yourself and attach it to any brief; it makes quotes comparable.
Baseline: Search Console status for mobile with failing URL groups; PageSpeed Insights field and lab results for home, collection, product and cart with the LCP element named; test dates.
Inventory: apps or plugins with purpose and last use; tags in Tag Manager and the theme; theme name, version and whether edited directly; on WooCommerce, PHP version, host, plan and cache exclusions.
Business context: which pages earn revenue and paid traffic; which scripts marketing cannot lose; any redesign or platform change planned within six months, since patching a theme you will replace is wasted money.
Ask each developer: which metric fails on which template and what the evidence is; which fixes are low effort; what access they need; how they will prove improvement given the 28-day window; what is excluded; and what happens if the numbers do not move.
Budgeting ecommerce website development in Pune: scope units, not guesses
We will not quote prices here because stores differ widely and we cannot defend one number. What helps is comparing quotes by scope unit.
| Scope unit | Typically includes | Usually excludes |
|---|---|---|
| Diagnosis and report | Field and lab tests across templates, app or plugin inventory, ranked fix list | Code changes |
| Image and media pass | Resizing, formats, correct LCP handling, dimensions | Reshooting photography |
| App or plugin clean-up | Removal, replacement, leftover code, testing | Replacing features you depend on without agreement |
| Script governance | Tag review, loading rules, documentation | Ongoing marketing changes |
| Template fixes | Targeted code for product, collection or cart pages | Full redesign |
| Hosting and caching (WooCommerce) | PHP upgrade, cache rules, object cache, staging test | Hosting fees, host migration unless stated |
| Theme rebuild | New or heavily rewritten theme | Content entry, app subscriptions |
Market rates in India vary by city, seniority and store size, and we have not found a published benchmark we can defend, so get at least two written quotes against the same audit sheet. A scoped diagnosis costs far less than a rebuild and tells you whether a rebuild is needed. Also budget for app subscriptions, hosting upgrades and your own team's time. If you are weighing platforms, see Shopify vs WooCommerce for Indian D2C brands; speed alone is rarely a reason to switch.
What to expect from speed work
For shoppers. A faster store feels better on mobile. We know of no trustworthy universal figure linking a speed gain to a revenue gain; be wary of anyone quoting one without naming the store and test, and run your own before-and-after comparison.
For search. Google's Search Central documentation says it highly recommends good Core Web Vitals for success with Search and a great user experience, and that this aligns with what its core ranking systems seek to reward, as part of the wider page experience rather than a standalone factor. Read speed as a supporting factor, not a substitute for relevant content and strong product pages; see our SEO services.
Scores are not the goal. Aim for passing field data on the templates that earn money, not a perfect Lighthouse number.
Keeping it fast: a performance budget and a monthly review
Stores regress because they change: a new app, banner or campaign tag. Two habits prevent most of it.
A performance budget is a set of limits agreed in advance, with numbers chosen after measuring your baseline: a maximum hero image size, a cap on third-party scripts, approval and a test for every new app, and dimensions and correct formats on every new image.
A monthly review, thirty minutes: check Search Console for new failing groups; re-run PageSpeed Insights on the four templates and log field data; remove apps and tags added since last month that are unused; test the five key interactions on a mid-range phone; note what changed alongside any drop.
If you are rebuilding, put the budget in the brief; it is cheaper than retrofitting. For the content side of the page, see our product page checklist.
Working with Govindani Infotech
Govindani Infotech Pvt. Ltd. is a web design and development company in Pune. If you want an independent view of why your Shopify or WooCommerce store is slow, we can start with the diagnosis described above and tell you what is worth fixing and what is not. Our ecommerce services and website creation services pages describe how we approach store builds and improvements.
To discuss your store, message us on WhatsApp or use the contact page. Please send your store URL and platform.
Frequently Asked Questions
Why is my Shopify store slow on mobile even though the theme is new?
A new theme is only the starting point. Apps, tracking pixels, review and chat widgets and large unoptimised images are added afterwards and usually account for most of the delay. Check the LCP element, list every app and script, and look at field data in PageSpeed Insights rather than only the lab score.
What are the Core Web Vitals thresholds for an ecommerce store?
Google's web.dev guidance sets good values at 2.5 seconds or less for LCP, 200 milliseconds or less for INP and 0.1 or less for CLS, measured at the 75th percentile of real page loads. The same thresholds apply to every site, ecommerce included, so check the current documentation in case they are revised.
Why does PageSpeed Insights show a low score but Search Console says my pages are good?
They measure different things. The score comes from a simulated lab test on one emulated device, while Search Console uses real-user data collected over 28 days. The field data is what Google uses for the Core Web Vitals assessment, so use the lab score for debugging and the field data to judge the result.
Does a faster store rank higher on Google?
Google says good Core Web Vitals align with what its core ranking systems reward and recommends them for Search success, but they are one part of page experience, not a standalone factor. Expect speed to support your rankings and user experience, not to replace relevant content.
Should I switch from WooCommerce to Shopify, or the other way round, to fix speed?
Usually not. Most speed problems come from images, scripts, plugins or apps and hosting, which move with you to a new platform if you do not fix them. Diagnose first, and consider a platform change only for reasons beyond speed, such as running cost, control or your team's skills.