Ecommerce performance engineering
Find what is making the store slow before paying for another generic speed fix.
I investigate ecommerce performance as a system: theme code, media, fonts, third-party scripts, tracking, app behavior, network conditions, and the pages customers actually use. The output is measured evidence and a prioritized implementation, not a promise built around one laboratory score.
A score is a clue, not the diagnosis
PageSpeed Insights and Core Web Vitals are useful, but a single number does not explain which code path, asset, vendor, or loading decision produces the experience. I preserve the page, device, network, and test conditions behind each finding. That makes improvements comparable and prevents a desktop homepage score from standing in for the mobile product page that matters.
Third-party cost needs business context
Analytics, advertising, reviews, personalization, and support tools may be commercially necessary even when they add work to the browser. I identify their measured cost, loading behavior, duplication, and ownership before recommending a change. The decision can then weigh operational value against performance instead of deleting scripts blindly.
Performance work should survive the next release
A one-time cleanup loses value when the team cannot see regressions or understand why a constraint exists. I document the important budget and dependency decisions, keep fixes in maintainable source, and define the checks appropriate to the project. The objective is not a screenshot of a score; it is a better engineering path for the live storefront.
Ecommerce performance engineering
Performance work tied to evidence
The engagement can begin with diagnosis or include implementation, but every recommendation names the observed bottleneck and tradeoff.
Core Web Vitals investigation
Page- and device-specific review of loading, responsiveness, and layout stability with reproducible test conditions.
Theme and rendering analysis
Inspection of templates, component behavior, CSS, JavaScript, fonts, media, and rendering work tied to visible bottlenecks.
Third-party and tracking review
Inventory of analytics, advertising, app, and vendor scripts with ownership, duplication, timing, and commercial context.
Prioritized implementation plan
A ranked path from verified cause to code change, including expected tradeoffs, validation method, and regression checks.
View related proof
Performance work inside an operated product
The most relevant public proof is a current product where development, analytics, search, and ongoing operations meet.
Sítio Raiz: ongoing performance responsibility
For Sítio Raiz, my verified scope includes the application, speed work, Core Web Vitals, GA4 and GTM, search landing pages, weekly SEO audits, new features, bug fixes, and continued operation rather than a one-off score exercise.
Performance and tracking in professional roles
The verified career record includes current speed, UX, performance, GA4, GTM, and pixel work, plus earlier agency experience with custom themes, reporting, tracking, custom events, and testing.
How performance work moves from symptom to source
Measurement stays attached to an exact page and condition so the implementation can be verified against the same evidence.
Establish the baseline
I identify representative routes, devices, user states, field data when available, and repeatable laboratory conditions.
Trace the bottleneck
The investigation links observed delay or instability to theme code, assets, vendors, data, network behavior, or platform constraints.
Implement and compare
Changes are released with their tradeoffs documented and checked against the baseline, key storefront behavior, and regression risks.
Ecommerce performance questions
These answers set realistic boundaries around measurement, third parties, and outcomes.
Can you promise a specific PageSpeed score?
No. A score depends on the page, device, test conditions, platform, content, and third parties, and it can change outside one developer’s control. I can establish a repeatable baseline, implement verified improvements, and report the measured result without turning it into a guarantee.
Will you remove every third-party script?
No. A script may support analytics, advertising, customer service, reviews, or another necessary function. I identify measured cost, duplication, timing, and ownership, then explain the tradeoff. Removal is a business and technical decision, not an automatic performance tactic.
Do you work with Shopify and BigCommerce performance?
Yes. My verified professional work includes both platforms as well as speed, UX, analytics, and tracking responsibilities. The exact intervention depends on the access each platform and third-party integration provides, so the audit separates controllable code from external constraints.
Can performance work include implementation?
Yes. I can move from diagnosis into theme, frontend, asset, loading, or tracking changes that fall within the agreed scope. When a bottleneck belongs to a vendor or a platform layer I cannot change, I document the evidence and the action required from that owner.
Start with the slow path
Send the page, device, and moment that feels slow to your customers.
Include any reports you already have and what changed before the problem appeared. I will begin by making the symptom reproducible.