SGEN site performance explained
How to make your SGEN site fast for visitors
Site performance affects visitor experience, conversion rate, and search ranking. SGEN handles the heavy lifting on the platform side — efficient page rendering, fast static delivery, smart image handling — but the speed your visitors experience also depends on choices you make: how big your images are, how many third-party scripts you embed, how well your design works on slower networks.
This page explains the performance work the platform does, the levers you control, and how to measure whether your site is fast enough. The plain version: most SGEN sites are fast by default. If yours is not, the cause is usually identifiable and fixable.
This guide also covers how to set realistic performance expectations for your team and customers. Performance is a moving target — what counted as fast three years ago is now too slow. Stay current with the basics and your site stays competitive.
What is this for?
Customers ask several performance questions:
- How fast should my site be? What are reasonable targets?
- What does the platform do to make sites fast? What is automatic?
- What can I do to make my site faster? What levers are mine?
- How do I measure performance? Tools and metrics.
- What if my site is slow despite my best efforts? Troubleshooting path.
- Do third-party scripts hurt performance? How much does each one cost?
The right answers shape your content choices. A media-heavy news site has different performance considerations than a brochure site. A site selling to mobile-first audiences has different priorities than a desktop-only B2B site.
The platform makes the baseline fast. Your decisions either keep the baseline or erode it. Most performance regressions come from a small set of patterns — oversized images, too many third-party scripts, layout that loads slowly — and most fixes involve recognizing one of those patterns and addressing it.
Performance is not just about happy visitors. Search engines factor speed into ranking; conversion-rate studies routinely show slower sites converting worse. A fast site is a competitive advantage that compounds over time.
Good use cases
Reading this page before launch sets expectations and surfaces the pre-launch performance check.
Performance is one of several common causes for traffic or conversion drops. The page covers how to test the hypothesis.
Performance under load matters; the page covers what to expect.
Mobile-specific performance considerations are part of the guide.
Translating tool reports into actions is part of the work; this page provides context.
Performance is often a side-effect of content choices.
Customer conversations about performance happen regularly; having answers ready prevents stalling.
Before-and-after measurement is how you avoid silently slowing the site.
What NOT to use this for
Run real-world tests of your specific site, not just rely on platform defaults.
Adding 12 third-party scripts and 5MB hero images will slow any site. The platform's optimization has limits.
Optimizing images before upload is still the single most impactful thing most operators can do for speed.
Page speed depends on content, network conditions, and visitor device. Variation is normal.
Speed matters, but it is one of many priorities. Trading off content quality for an extra 50ms is usually a bad deal.
How this connects to other features
Images upload to the media library; smart compression and format selection happen automatically.
Third-party scripts you embed via Custom Codes affect page speed. Use sparingly.
Font choices affect speed. Custom fonts add weight; system fonts are zero-cost.
Analytics includes page-load timing data. Use it to track performance trends over time.
Performance and backups are independent. Restoring from backup does not change performance baseline.
Reliability is about uptime; performance is about speed. Both contribute to visitor experience.
Aggregate performance trends across sites in a portfolio.
Before you start
A short checklist:
- Run a baseline measurement. Use a public speed tool against your most-trafficked page. Note the score so you have a comparison point later.
- Inventory your third-party scripts. Look at Custom Codes. Each script is a potential speed cost. Decide which are essential.
- Check your image sizes. A page hero at 2MB is the most common preventable speed issue. Optimize before upload.
- Review your fonts. Many sites use too many custom fonts. Two is usually enough.
- Test on mobile. Mobile experience often differs significantly from desktop. Run mobile-specific measurements.
- Set a target. Pick a speed target for your most-trafficked page. Without a target, "fast enough" is impossible to define.
Where to go
The relevant locations:
- Site → Analytics → Performance. Page-load timing data per page, per device type.
- Site → Media → Library. Where you upload and manage images. Compression and format selection happen here.
- Site → Custom Codes. Where third-party scripts live. Audit periodically.
- Site → Design → Theme Editor → Typography. Font choices that affect speed.
- Site → Settings → Performance. Some plan tiers expose performance-specific settings.
Steps — Get your site fast and keep it fast
1. Run a baseline measurement
Open a public speed tool (Google PageSpeed Insights, WebPageTest, similar) and run it against your most-trafficked page. Note the metrics:
- Largest Contentful Paint (LCP). Time to render the biggest visible element. Target: under 2.5 seconds on mobile.
- First Input Delay (FID). Time before the page responds to taps or clicks. Target: under 100ms.
- Cumulative Layout Shift (CLS). How much the layout shifts during load. Target: under 0.1.
These are the Core Web Vitals. They are the industry baseline and what most measurement tools focus on.
Save the baseline. You will compare against it after each change.
2. Optimize your images
Open your media library. For each large image:
- Check the file size. Hero images over 500KB are usually too big.
- If too big, regenerate the image at the right dimensions. The platform's automatic compression helps but cannot fix an oversized source.
- Use Web-friendly formats. PNG for graphics with sharp lines, JPG/JPEG for photographs, WebP/AVIF for both (where supported).
- Set explicit alt text. Important for accessibility and SEO; does not directly affect speed but is part of good practice.
Most sites can cut total page weight by 30-60% by optimizing images. It is the highest-impact performance work.
3. Audit your third-party scripts
Open Custom Codes. List every active script. For each:
- What does it do? If you cannot answer, it is a candidate for removal.
- Is the script async/defer? If not, it blocks rendering. Most modern scripts can use async or defer.
- Could you replace it with a lighter alternative? Many full-feature scripts have lightweight alternatives that do 80% of the work.
Removing one heavy script from a site can save several hundred milliseconds. Audit annually.
4. Trim your font choices
Open Theme Editor → Typography. List your custom fonts. For each:
- Is the font essential to the brand? System fonts are zero-cost and often look fine.
- How many weights are you loading? Often a site loads four weights and only uses two.
- Is the font subset to your language? Loading the full international glyph set when you only need Latin characters wastes bandwidth.
Two fonts at two weights each is plenty for most sites. Five fonts at five weights is a speed problem.
5. Enable lazy loading
Lazy loading defers image loading until the image is about to enter the viewport. Open Site → Settings → Performance → Lazy load images below the fold and turn it on if not already.
Lazy loading is one of the highest-impact, lowest-effort performance wins. Visitors who never scroll past the hero never download the gallery below. Pages feel faster because above-the-fold content arrives first.
6. Pre-load above-the-fold images
For images that visitors see first — the page hero, navigation logo — pre-loading hints help the browser prioritize them. Enable Pre-load above-the-fold images in Site → Settings → Performance if available on your plan.
The setting tells the browser "load these first." LCP improves because the largest visible element starts loading sooner.
7. Set up performance monitoring
Pick a tool that runs scheduled checks against your site. Options:
- Site → Analytics → Performance for the platform's built-in trending.
- External monitoring services that run automated checks from multiple geographies.
- Google Search Console → Core Web Vitals report for the visitor-experience view from search.
Watching trends is more useful than watching point-in-time scores. A site that scored 90 last quarter and 75 this quarter has a regression worth investigating.
8. Performance test major content changes
Before publishing a new homepage, a new landing page, or any major content update, run a performance test against the new version. Compare against the old version's baseline. If the new version is significantly slower, identify the cause before publishing.
Many performance regressions come from new content that nobody checked.
9. Schedule a quarterly performance audit
Quarterly, walk through the steps above:
- Run baseline measurements.
- Check for new oversized images.
- Audit Custom Codes.
- Check font choices.
- Review performance monitoring trends.
The audit takes about an hour. Catching small regressions early prevents big regressions later.
What success looks like
A team handling performance well feels like: For a small operator: image optimization plus monthly speed checks is enough. The default performance is already good. For a content-heavy site: regular audits, careful third-party script choices, and mobile-focused testing matter most. For an ecommerce operator: performance directly affects conversion. Treat it as a revenue lever, not a vanity metric. For a multi-site operator: maintain consistent performance practices across sites. One slow site can drag down the portfolio's perceived quality.
- The site scores well on Core Web Vitals. Most pages pass on mobile and desktop.
- New content goes through a quick performance check before publish.
- The team has a target for the most-trafficked pages and meets it.
- Image and script audits happen quarterly. No silent regression goes unnoticed.
- Performance trends are tracked. A drop triggers investigation.
- Mobile experience is good, not an afterthought.
What to do if it does not work
Less-obvious cases:
Could be a tool-specific quirk. Run from multiple tools and locations to confirm. Visitor-experience metrics from your own analytics may differ from synthetic tool scores.
Mobile networks and devices are slower. Optimize for mobile specifically — smaller images, fewer scripts, lighter design.
Run the speed tool against that page only. Identify what is unique about it — large images, embedded third-party content, heavy custom code.
Compare the current page against the change you made. Most regressions come from new content. Roll back the change as a test; if speed returns, you have your answer.
Variation of 5-15 points between runs is normal. Run 3-5 times for an average. Treat single-run scores skeptically.
Use async or defer attributes. Load it after the page is interactive. Some scripts also offer a lightweight version designed for performance.
Reduce font weights, subset the font to your language, or fall back to system fonts.
Check the original file size — the platform compresses but the source size still matters. Re-upload optimized images.
Worked example — Acme Coffee speeds up its homepage
Acme Coffee's homepage was scoring 65 on PageSpeed Insights mobile. The team's audit:
- Identified the hero image at 1.8MB. Re-exported at 280KB. Saved 1.5MB on every visitor load.
- Found six Custom Codes loading. Reviewed each. Removed two no-longer-used analytics scripts. Switched a chat widget to load on visitor interaction instead of on page load.
- Audited fonts. Reduced from four custom fonts to two.
- Re-tested. Score moved from 65 to 86 on mobile. LCP dropped from 4.2 seconds to 1.9 seconds.
- Documented the audit. Steps taken, before-and-after scores, dates. Future audits start from this baseline.
Total work: about three hours. Outcome: a noticeably faster homepage with measurable business impact (conversion rate on the homepage's primary CTA improved 8% over the following month).
Worked example — Acme Studio performance-audits a client site
Before a major launch, Acme Studio audited a client's site for performance:
- Ran baseline measurements. Mobile LCP at 3.8 seconds — too slow.
- Identified the cause: a 4MB carousel image and a non-essential chat widget loading synchronously.
- Optimized the carousel images. Down to 350KB each.
- Deferred the chat widget. Now loads after the page is interactive.
- Re-tested. Mobile LCP at 2.1 seconds. Within the target window.
- Made the optimizations part of the launch checklist. Future client launches include the performance audit by default.
The launch happened on schedule with a fast site. The carousel images and chat widget changes took 90 minutes of work — modest investment for a significant improvement.
Notes on the performance model
A few details worth knowing:
The platform handles efficient delivery automatically. You do not need to configure how pages are served. The defaults are tuned for speed.
Image optimization is automatic but bounded by source size. Compression helps; it cannot turn a 4MB original into a 100KB rendered image without quality loss. Optimize sources where possible.
Third-party scripts are mostly outside platform control. Your speed depends on the scripts you choose. Choose carefully.
Fonts have an outsized impact. Custom fonts add bandwidth and rendering work. Pick fewer fonts and fewer weights.
Mobile is the primary canvas. Most traffic on most sites is mobile. Performance optimization should prioritize mobile experience.
Search ranking factors in speed. Google's Core Web Vitals are part of the ranking signal. Fast sites tend to rank better.
Visitor experience compounds. A 200ms speed improvement does not just make one visitor happier — it makes thousands happier over the course of a month.
Performance work is iterative. A site is fast or slow depending on its current content. Re-test periodically.
Common questions
What is a good speed score for a SGEN site? On Core Web Vitals: LCP under 2.5s, FID under 100ms, CLS under 0.1, on mobile. Desktop tends to be faster.
Does SGEN have built-in image optimization? Yes — compression and format selection are automatic. Source image size still matters.
How do third-party scripts affect speed? Each script adds work for the browser. Synchronous scripts can block page rendering. Use async or defer where possible.
Can I use a CDN? The platform handles fast delivery globally; additional CDN setup is usually not needed.
Why is my mobile score lower than my desktop score? Mobile devices have slower CPUs and slower networks. Optimization for mobile requires more aggressive choices than for desktop.
What is the single highest-impact thing I can do? Optimize hero images. Most preventable speed issues trace back to oversized images.
How often should I performance-test? Run a baseline monthly. Run a full audit quarterly. Test before publishing major content changes.
Does the platform support AMP? AMP support depends on platform feature roadmap. Check current documentation. For most sites, well-optimized standard HTML is now competitive with AMP.
Can I disable image compression for specific images? Some plans support per-image compression overrides. Check your plan documentation.
Will adding a feature slow my site? Possibly. Test before-and-after to know. Most platform features are performance-conscious.
How do I report a performance bug? Contact support with the page URL, the measured metrics, and the tools you used.
Does the platform optimize for accessibility too? Accessibility and performance are related but separate. The platform supports accessibility-first practices but the choices are yours.
Can I set per-page performance targets? Different page types have different baseline expectations (a media-heavy gallery vs a text-only article). Set page-type-specific targets if useful.
Related reading
Performance is a continuous practice, not a one-time setup. Run audits, optimize what you find, measure trends, repeat. The compound effect over a year is a noticeably better visitor experience.
How SGEN handles platform updates — performance improvements in the changelog.
SGEN reliability and uptime explained — uptime and performance are different signals.
SGEN data security and privacy — privacy choices that affect performance.
SGEN backups and disaster recovery — recovery does not change performance.