Performance Optimization
Backend vs. Frontend Optimization
Performance optimization involves two crucial areas: backend and frontend. Both are very important.
Backend optimization focuses on server resources, service settings (e.g., PHP opcode cache), reverse caching proxies (Varnish, Fastly), optimized SQL queries, and efficient data loading (avoiding loops).
Backend optimization is critical for uncached pages. Once a page is cached by a proxy like Varnish, backend performance becomes less relevant as Varnish serves the response directly, often achieving ~200ms Time to First Byte.
Slow backend performance affects Core Web Vitals and Google Lighthouse for uncached pages. However, for cached pages, only frontend optimization impacts these scores.
If a cached page loads in ~200ms but scores below 100 on Google Lighthouse, the remaining issues are frontend-related and often easily optimizable.
Frontend optimization covers many areas, similar to backend.
Key areas include image resolution and compression, layout stability, main thread blocking time, UI responsiveness, interactivity, accessibility, and indexability.
Historically, performance optimization focused heavily on backend, which is more mature. Frontend optimization is a rapidly evolving field.
Achieving high Google Lighthouse scores or passing Core Web Vitals requires optimizing both. While Hyvä impacts both, its primary focus is frontend optimization.
Tooling
Many frontend optimization tools exist, which can be overwhelming due to rapid evolution and subtle differences.
The following free tools are used daily by us, and we highly recommend learning them.
Chrome DevTools: Google Lighthouse
Google Lighthouse tests a given URL (public or private) directly within the browser.
Its benefit is early-stage testing and actionable improvement suggestions. However, Lighthouse uses "Lab Data" (developer's browser), not real user data. Scores can vary significantly based on developer hardware/network vs. actual users (e.g., mobile on slow 3G). Browser extensions can also skew results; always run reports in a private browsing window without extensions for a clean baseline.
To generate a report: Open a private browsing window, open Chrome DevTools (F12), go to the "Network" panel, set bandwidth to "Slow 3G". Then, navigate to the "Lighthouse" panel, select "Mobile Device", and click "Analyze page load".
Lighthouse reports include links to documentation for understanding and applying performance recommendations.
To read more about Google Lighthouse and learn how to use the recommendations, please visit developer.chrome.com/docs/lighthouse/overview.
Chrome DevTools: Performance Panel
The Performance panel records detailed browser activity over several seconds, allowing deep analysis. It's a versatile profiling tool, usable during or after page load. The downside is the sheer volume of data, requiring a deep understanding of browser internals to interpret.
Like Lighthouse, Performance reports use "Lab Data" (in-browser process), not real user data.
While useful for Core Web Vitals analysis, this tool is most beneficial for developers building full JavaScript applications.
To read more about the devtools Performance panel, please visit developer.chrome.com/docs/devtools/performance.
Chrome DevTools: Performance Insights Panel
This experimental Chrome DevTools panel focuses on page load optimization for Core Web Vitals. Unlike the "Performance" panel, it aims to provide actionable recommendations, simplifying bottleneck identification.
Reports are based on "Lab Data" (in-browser process).
To generate a report: Open a private browsing window, open Chrome DevTools (F12), select the "Performance Insights" panel. Click "No Throttling" to configure network (Slow 3G) and CPU (4x slowdown). Then click "Measure page load".
The report displays a Performance-like timeline on the left and a Core Web Vitals-focused "Insights" timeline on the right. Click items for details and improvement recommendations.
The recording can be replayed at the bottom of the panel.
Reports link to valuable documentation on performance aspects.
To read more about the devtools Performance panel, please visit developer.chrome.com/docs/devtools/performance-insights/.
Google PageSpeed Insights
This incredibly useful tool can be accessed for free at pagespeed.web.dev.
Unlike Lighthouse or Performance Insights, PageSpeed Insights combines "Lab Data" with real user monitoring data from the Chrome UX Report (CrUX). This provides insights into actual visitor performance, reflecting usage patterns (e.g., mobile vs. desktop).
Lab data is useful for debugging issues, as it is collected in a controlled environment. However, it may not capture real-world bottlenecks. Field data is useful for capturing true, real-world user experience - but has a more limited set of metrics.
Real user data reports require sufficient visitor data. Otherwise, a Lighthouse lab-based report is generated, similar to DevTools but run on Google servers with a baseline Chrome browser, which can differ from high-end developer machines.
Full reports include useful links to frontend performance topics.
To read more about Google PageSpeed Insights, please visit developers.google.com/speed/docs/insights/v5/about.
Hyvä Performance Tips
The tools above offer valuable, general recommendations for image compression, styling, DOM size, and third-party scripts. For Hyvä stores, consider these specific tips:
Avoid huge Alpine components on catalog or CMS pages
Alpine is powerful, but large components on catalog/CMS pages can significantly increase main thread blocking time during initialization, harming performance. Refactor such components to use vanilla JavaScript or minimize DOM manipulation (e.g., avoid x-bind:class/:class and setAttribute).
Constraints can be relaxed on less performance-critical pages like customer accounts or checkout.
Use x-defer to defer Alpine components
Defer initialization of below-the-fold Alpine components with x-defer="intersect" to improve page interactivity. Use judiciously; indiscriminate use can re-introduce main thread blocking. Test its impact. See the x-defer documentation for details.
Use Speculation Rules for Faster Navigation
Since release 1.4.0, Hyvä includes a stable implementation of the Speculation Rules API.
This feature allows the browser to prefetch or prerender pages in the background before a user even clicks on a link,
which can result in a near-instant navigation experience.
This is currently supported by Chromium-based browsers like Google Chrome and Microsoft Edge, which make up the majority of browsers used on most websites.
For detailed information on how to configure this feature, please see the Speculation Rules documentation.
Lazy load images below the fold
Simply add loading="lazy" to all images below the fold on mobile.
Do not use alpine classes within selectors in .css files
Avoid using Alpine classes within CSS selectors; this significantly bloats styles.css.
Excessive DOM Size
Template tags
If Lighthouse flags excessive DOM size, wrap sections in Alpine.js <template x-if=""> tags. The browser ignores these tags initially, excluding their content from the initial DOM until Alpine injects them. While effective, this hides content from search engines, so use with caution.
AJAX injection
Alternatively, remove below-the-fold content and load it via AJAX on scroll. This reduces document size and bandwidth. However, like <template> tags, this content is hidden from search engines.