Resources / Learn
A starting library for understanding performance, CSS and technical website health. FIXEEM’s searchable knowledge base and blog are planned; these guides are available now as introductory reading.
A lab test runs under a controlled setup. Field data reflects the experience of real visitors in real conditions. Use the first to diagnose a change; use the second to understand what people experienced.
Read the guideWhen a page scrolls sideways on mobile, inspect wide images, fixed-width components, long unbroken text and elements positioned outside their containers before changing global styles.
Read the guideCapture the current state, isolate a small change, compare the result at relevant viewport sizes, and keep a rollback path before applying a fix to production.
Read the guide01 / Performance
Lab measurements run in a controlled environment with a defined device and network profile. They are useful for reproducing conditions and inspecting technical bottlenecks. Field data is collected from real users and varies with their devices, networks and visit patterns.
When reading a report, check which kind of data a metric represents and what time period it covers. A lab improvement does not automatically prove that real-user experience improved; a field trend may also need time to reflect a release.
A responsible audit should label the source of each measurement and explain what it can—and cannot—tell you.
02 / CSS
Start by reproducing the issue at the affected viewport width. Inspect wide images or tables, fixed-width cards, long strings without break opportunities, transforms, absolutely positioned elements and nested containers that exceed the viewport.
Prefer correcting the element that causes the overflow over adding a global overflow-x: hidden rule. Hiding overflow can conceal content and make a layout problem harder to discover.
After a change, review the page at nearby viewport sizes and check keyboard focus, sticky elements and any content near the edge of the screen.
03 / Repair safety
Record the original state and the exact symptom. Make one narrow change at a time, preview it in a staging environment or isolated browser session, and compare relevant pages and screen sizes.
Before production changes, confirm that a backup and rollback path exist. Ask who approves the change, what success looks like, and how the issue will be verified afterward. If the evidence is uncertain, stop and investigate rather than claiming a fix.
FIXEEM is being designed around this principle: detect, diagnose, propose, preview, approve, apply and verify.
Keep learning with FIXEEM
Join the early-access list. Submissions share your interest with the FIXEEM site owner; they do not start a scan.