Frequently Asked Questions - Websites

Lighthouse runs in a controlled environment, but server response time, network conditions, outside services, and the timing of page features can still vary. Use a repeatable process:

1. Test the same page, device type, location, and general conditions.
2. Run a small set of tests and compare the middle result instead of choosing the best or worst score.
3. Look for repeated findings, then check real-user performance data in the Chrome User Experience Report or Search Console before making a major decision.

A changing score is not automatically a problem. Consistent patterns and real-user results are more useful than one isolated run.

“WordPress thinking” is Smithworks' shorthand for making website decisions around what a tool makes easy instead of what visitors and the business need. It can show up as unnecessary plugins, excessive animation, bloated page builders, decorative sections, or unclear messaging. The same mindset can affect a HubSpot site when modules, scripts, forms, animations, or integrations are added without a clear purpose. The platform is not the problem. Tool-first decisions are.

You need both, but they answer different questions. Lab data comes from a controlled test and helps identify what may be slowing a page down. Field data summarizes how real Chrome users experienced the site. The Chrome User Experience Report uses a rolling 28-day window, and page-level data may be unavailable when a page is not public or does not have enough visits. Use lab data to investigate and test changes, then use field data to confirm whether the real experience improved over time. See the Chrome User Experience Report methodology for details.

Do not remove a script just because it may slow a page. First confirm what it does and what depends on it:

1. Identify the script’s purpose and the person or vendor responsible for it.
2. Check whether it supports consent, forms, analytics, attribution, automation, or another integration.
3. Measure how much it affects performance instead of assuming it is the main problem.
4. Test the change on a test page or in a preview and confirm the affected features still work.
5. Remove it only when it is redundant or the responsible owner approves the change.

This protects the business functions behind the script while still giving you a practical path to improve performance.

No, but every animation should earn its place. Before keeping it, check that it:

• Guides attention, explains a change, or supports the message.
• Respects a visitor's reduced-motion preference.
• Does not block access to content or controls.
• Works well on mobile and with touch input.
• Does not create an avoidable performance problem.

If the motion is only decorative and adds distraction or delay, simplify it or remove it.

Use a simple decision process:

1. Purpose: Identify the visitor or business goal the feature supports.
2. Evidence: Check analytics, conversion behavior, feedback, or testing for signs that it helps.
3. Usability: Confirm that it works clearly and accessibly across devices.
4. Performance: Compare its value with the speed or distraction it adds.
5. Maintenance: Consider the time, cost, and risk required to keep it working.

Keep it when the value is clear, change it when the idea is useful but the execution creates friction, and remove it when the cost outweighs the evidence.

No. Sprocket Rocket is not only for developers. One of its strengths is that it gives marketers a more practical way to build and manage HubSpot pages without needing to write code for everyday page updates.

Developers may still be helpful for setup, customization, integrations, theme configuration, and advanced needs. But the day-to-day editing experience is designed to make page creation and maintenance more manageable for marketing teams.

That balance can be valuable for SMBs that need a professional HubSpot site but do not want every content change to become a development project.

Neither option is automatically better. Compare the decision against the way your team needs to build and manage the site:

• Time: A framework can shorten the path to launch; a custom theme usually needs more discovery and development.
• Marketer control: Decide how much control marketers need without developer help.
• Design: Confirm whether the brand fits a flexible visual system or requires a highly custom design.
• Integrations: Document any unusual data, application, or workflow requirements before choosing.
• Maintenance: Decide who will support the theme and make future changes.
• Budget: Compare licensing, implementation, support, and future development—not just the initial build.

Choose the option that meets those requirements without creating complexity your team does not need. The Sprocket Rocket overview provides more context for evaluating the framework.

Yes, Sprocket Rocket can support many full business websites, including home, service, about, contact, landing, and blog pages. It is a strong fit when the available modules and theme settings can support your content, brand, visitor paths, and expected growth. You may need additional apps or custom development when the site requires unusual interactive features, specialized data, complex connections to other systems, or a visual system the theme cannot reproduce cleanly. Review the current Sprocket Rocket documentation before deciding whether the standard capabilities cover your requirements.

Sprocket Rocket can help provide a cleaner and more structured starting point, but it does not automatically solve every HubSpot performance problem. Performance still depends on the choices made while building and maintaining each page.

Large images, unnecessary scripts, embedded tools, tracking code, animations, module overuse, and poor page-building habits can still slow down a site. A good theme reduces some risk, but it does not remove the need for disciplined implementation.

Think of Sprocket Rocket as a strong foundation. The finished site still needs thoughtful content, efficient assets, and practical performance decisions.