How to Eliminate Render-Blocking JavaScript and CSS on WordPress – The Complete Guide

Last Updated on February 12, 2026 by Jessie Connor

Ever landed on a website that took forever to load, leaving you tapping your fingers and maybe muttering a few choice words? Yep, we’ve all been there. And chances are, the culprit behind that sluggish experience was something called render-blocking JavaScript and CSS.

Now, if you’re running a WordPress site, this can be a double whammy. Not only does it frustrate visitors, but search engines also don’t look too kindly on pages that drag their feet. Slow load times can hurt rankings, bounce rates, and ultimately conversions.

In this deep dive, we will walk through everything you need to know about eliminating render blocking JavaScript and CSS on WordPress. We will start by breaking down what these intimidating sounding terms actually mean, then move step by step into practical, hands on solutions you can implement right away. From understanding why these files slow down your pages to learning how to optimise and fix them properly, this guide is designed to cover it all. And don’t worry, we will keep things clear and conversational, with no unnecessary jargon along the way. Ready to get started? Let’s dive in.

What Does It Mean to Eliminate Render-Blocking JavaScript and CSS on WordPress?

Alright, let’s break this down because “render blocking JavaScript and CSS” sounds far more intimidating than it actually is. In simple terms, render blocking resources are files your browser must load before it can display the visible part of your page to visitors. Until those files are processed, the page just sits there, waiting.

Think of it like a chef preparing a meal. If the sous chef insists on chopping every single onion before the main dish can even touch the pan, dinner gets delayed. That is exactly what render blocking scripts and styles can do. They force the browser to pause and handle certain files first, even when parts of the page could already be shown to the user.

The result? Slower perceived load times, frustrated visitors, and potentially weaker performance signals in search results. The good news is that once you understand what is actually happening behind the scenes, fixing render blocking issues becomes far less scary and far more manageable.

Why It Happens

When someone visits your WordPress site, their browser starts reading the HTML from top to bottom. Ideally, it would show the user something meaningful as quickly as possible—text, images, buttons, maybe a hero banner. But here’s the hiccup: if the HTML references JavaScript or CSS files in the head section, the browser has to pause and download those files first. Only after those files finish loading can it render the content on the screen. This pause is what slows down your site’s “first paint,” the moment your user actually sees something.

Even a delay of half a second can feel sluggish to users. And when you stack multiple render-blocking scripts—like Google Fonts, sliders, analytics, and custom plugins—the cumulative effect can add several full seconds to your page load time. On mobile devices with slower connections, this problem becomes even more noticeable.

Common Culprits

Some of the usual suspects include:

• Theme CSS files: Especially heavy themes that load dozens of CSS files for fonts, icons, and styling.

• Plugins: Sliders, pop-ups, and page builders like Elementor often enqueue scripts that load site-wide, even if they’re not needed on every page.

• Third-party scripts: Analytics, ads, social sharing buttons, and embedded videos. These are notorious for blocking rendering because the browser waits for them to respond.

How It Affects WordPress

WordPress is flexible, but with flexibility comes complexity. Each plugin or theme feature might add its own JavaScript or CSS. If these files aren’t optimized, your visitors experience slower load times, and search engines notice too. In other words, your rankings, bounce rates, and conversion rates can all take a hit.

Moreover, not all render-blocking resources are bad. Some are critical for your site to function correctly. For example, your main navigation CSS and menu JavaScript are essential for interaction. The trick isn’t to remove everything—it’s to eliminate or defer only the non-critical files while keeping essential resources intact.

What “Eliminate” Really Means

When we say “eliminate render-blocking JavaScript and CSS on WordPress,” we’re not necessarily deleting these files. Instead, it’s about:

• Deferring JavaScript: Load scripts after the page content has started rendering.

• Adding async attributes: Let non-essential scripts load in parallel without stopping the page render.

• Inlining critical CSS: Ensure that essential styling appears immediately, while the rest of the CSS loads later.

• Conditional loading: Only load scripts on pages that actually need them.

In short, eliminating render-blocking resources is about prioritizing speed without breaking your site. You want the content to appear fast, the interaction to remain smooth, and the underlying code to stay intact.

Real-World Example

Imagine a WordPress blog with a hero image, navigation bar, and a slider. Without optimization, the browser has to load:

1. Theme CSS (10+ files)

2. Slider JavaScript

3. Google Fonts

4. Analytics script

Before the user sees the first heading. That could take 3–5 seconds. By deferring the slider JS, inlining the critical CSS for the hero section, and asynchronously loading analytics, you can reduce the perceived load time to under 1 second, giving users a snappier experience immediately.

Why Is Eliminating Render-Blocking JavaScript and CSS on WordPress So Important?

Picture this: a visitor clicks on your WordPress site and waits… waits… waits. The screen stays blank or partially loaded, maybe showing a loading spinner. Their patience wears thin, and before you know it—they’ve already clicked back to Google. Ouch.

This scenario happens far more often than you might think, and it all comes down to speed. In today’s fast-paced web, users expect pages to appear almost instantly, especially on mobile devices where network speeds can fluctuate. That’s why eliminating render-blocking JavaScript and CSS on WordPress is not just a technical tweak—it’s a business-critical move.

Speed Directly Impacts User Experience

A slow site frustrates users. Even small delays can increase bounce rates dramatically. For instance:

• 1-second delay → 7% drop in conversions

• 3-second delay → 50% of visitors leave

• 5-second delay → most users have already abandoned your site

If your JavaScript or CSS files block the browser from rendering content, you’re essentially forcing visitors to wait longer than necessary, damaging the first impression of your brand.

SEO and Core Web Vitals

Google’s Core Web Vitals make it clear: site speed matters for search rankings. Metrics like:

• Largest Contentful Paint (LCP) – how quickly the main content loads

• First Input Delay (FID) – responsiveness of your site when a user interacts

• Cumulative Layout Shift (CLS) – stability of content as it loads

…all can be negatively affected by render-blocking files. Even if your content is top-notch, slow loading can prevent you from ranking as high as you deserve.

Revenue and Conversions

For eCommerce or service sites, speed is money. Imagine a WooCommerce store where the cart page takes 5 seconds to appear because of render-blocking scripts. Users abandon their carts. That’s lost revenue.

Even for blogs or affiliate sites, slow pages reduce engagement. Less engagement → fewer clicks → lower ad revenue or affiliate commissions. By eliminating render-blocking JavaScript and CSS on WordPress, you’re not just improving load time—you’re protecting your bottom line.

Real-World Example

Let’s take an example: a WordPress blog uses a popular page builder like Elementor and has multiple sliders, social sharing buttons, and embedded videos.

• Without optimization: PageSpeed Insights reports render-blocking CSS and JS causing 4-second delays before the first meaningful paint.

• After eliminating render-blocking resources: Critical CSS inlined, JS deferred, unnecessary plugin scripts disabled → load time drops to under 1.5 seconds. Users see the content almost immediately, engagement spikes, and bounce rates drop.

It’s almost like opening the front door instantly instead of making your visitors wait outside in the rain.

Before you start waving your virtual magic wand to eliminate render-blocking JavaScript and CSS, you’ve got to know exactly where the problem lies. It’s like trying to fix a leak—you need to find the drip before you can patch it. Thankfully, WordPress makes this easier than you might think, and there are several tools at your disposal.

Step 1: Use Google PageSpeed Insights

Google PageSpeed Insights is your first line of defense. Simply enter your WordPress site URL, hit “Analyze,” and wait for the magic to happen. The report will highlight:

• Eliminate render-blocking resources: Lists CSS and JS files that delay the first paint.

• Opportunities: Suggestions for deferring or inlining scripts.

• Diagnostics: Additional insights, like unused CSS or heavy fonts.

Pro tip: Look for the “Render-blocking JavaScript and CSS” section. Google even tells you the exact files causing the slowdown, making it easy to target them.

Step 2: GTmetrix for Waterfall Analysis

GTmetrix is like the forensic tool for website speed. Once you run your WordPress site through it, head to the Waterfall tab. This shows every file your browser loads and the order it loads them.

You can quickly spot:

• Scripts that load in the head and block content

• Large CSS files that delay rendering

• Third-party scripts causing bottlenecks

By reading the waterfall, you can make strategic decisions: defer, async, or conditionally load the files.

Step 3: Lighthouse via Chrome DevTools

If you’re a bit more hands-on, open your WordPress site in Chrome, press F12, and navigate to the Lighthouse tab. Run an audit for Mobile or Desktop, and check Performance.

It’ll highlight:

• First Contentful Paint (FCP) delays

• JavaScript execution times

• CSS render-blocking warnings

You’ll also see suggestions like “Consider inlining critical CSS” or “Defer offscreen JavaScript.” These insights are gold if you want precise optimization.

Step 4: Identify Common Culprits

On a typical WordPress site, the usual suspects include:

• Theme CSS files: Especially multipurpose themes that load dozens of CSS files.

• Plugins: Sliders, pop-ups, contact forms, and page builders. Many of these load scripts site-wide even when not needed.

• Fonts and icons: Google Fonts and icon libraries can block rendering if loaded in the head.

• Third-party integrations: Analytics, social sharing buttons, and ad scripts often add significant delays.

Knowing what’s causing the problem is the first step toward eliminating render-blocking JavaScript and CSS on WordPress.

Step 5: Manual Inspection (Optional)

For developers or hands-on users, inspecting your site manually can be enlightening:

1. Right-click on your page → View Page Source.

2. Look at <link> and <script> tags in the <head> section.

3. Identify which files are loaded before the content renders.

If you notice plugins or scripts that aren’t critical above the fold, those are prime candidates for deferring or async loading.

Step 6: Document Your Findings

Keep a small spreadsheet or checklist of:

• File name / URL

• Plugin or theme source

• Critical vs non-critical

• Suggested optimization (defer, async, conditional, inline)

This will make the next steps of optimization much smoother.

Real-World Example

Imagine a WordPress blog using Elementor and several plugins. PageSpeed Insights flags:

• elementor-frontend.css (render-blocking)

• contact-form-7.js (render-blocking)

• font-awesome.css (render-blocking)

GTmetrix waterfall confirms these files load before the main content, causing a 3-second delay. Documenting them lets you:

• Inline critical parts of Elementor CSS

• Defer contact-form-7.js until the contact page

• Load font-awesome.css asynchronously

Once done, your first meaningful paint time drops significantly, and the site feels snappy.

Methods to Eliminate Render-Blocking JavaScript and CSS on WordPress

Now that we’ve spotted the culprits, it’s time to roll up our sleeves and actually fix the problem. The goal here is clear: speed up your site without breaking anything. Think of it like clearing traffic jams on your website highway—let the important cars (content) go first, and let the heavy trucks (scripts and CSS) follow behind.

Here’s how to do it, step by step.

1. Use a Performance Plugin

If you’re not a code wizard, this is your shortcut. Performance plugins automate most of the heavy lifting:

• WP Rocket: The gold standard for WordPress. Features include:

  • Deferring JavaScript

  • Inlining critical CSS

  • Minifying CSS and JS

  • Lazy loading images and videos

• Autoptimize: Free and beginner-friendly. It allows you to:

  • Aggregate CSS and JS files

  • Defer scripts

  • Inline critical CSS

• Asset CleanUp: Perfect for fine-tuned control. You can selectively disable CSS/JS on specific pages to avoid unnecessary render-blocking.

Pro tip: Always test your site after activating a plugin. Some plugins can conflict with page builders or custom themes, so check that everything—menus, sliders, forms—still works.

2. Defer JavaScript Loading

Deferring JS is like telling your browser: “Hey, load this later; the user can see the page now.”

• Add defer to your <script> tags:

  <script src="example.js" defer></script>


• In plugins like WP Rocket, simply check “Load JavaScript Deferred”, and it handles this automatically.

When to defer: Non-critical JS, like sliders, galleries, or plugin scripts that aren’t needed immediately.

3. Use Async JavaScript

Async is slightly different from defer—it tells the browser to load scripts while continuing to render the page.

• Add async to your <script> tags:

  <script src="example.js" async></script>


Best for: Analytics, tracking scripts, social sharing buttons—anything that doesn’t affect immediate page functionality.

4. Inline Critical CSS

Critical CSS is the minimal styling required for above-the-fold content. By inlining it in the <head>, you allow the browser to paint the page immediately.

• Example:

  <style>
body { font-family: Arial, sans-serif; }
h1 { color: #333; }
.hero { background-color: #f2f2f2; height: 400px; }
</style>


• Plugins like WP Rocket or Autoptimize can generate critical CSS automatically.

Why it matters: Without critical CSS, users might see unstyled content (FOUC), which feels broken and unprofessional.

5. Minify and Combine CSS/JS Files

Fewer files = faster page load. Minification removes spaces, comments, and unnecessary characters, while combining reduces HTTP requests.

• Use Autoptimize: Enable Aggregate CSS/JS.

• Use Fast Velocity Minify for more advanced control.

Pro tip: Some themes or plugins may break when combining files. Test page functionality after every change.

6. Conditional Script Loading

Not every script needs to load on every page. Conditional loading ensures scripts load only when needed:

• Example: Load contact form scripts only on the contact page.

• Use Asset CleanUp or Perfmatters to manage this.

Benefit: Reduces render-blocking files and improves performance site-wide.

7. Adjust via .htaccess (Advanced)

If you’re comfortable with server tweaks, you can eliminate render-blocking resources at the server level:

• Enable GZIP or Brotli compression

• Set Cache-Control headers

• Preload critical CSS or JS

Example .htaccess snippet to leverage browser caching:

Warning: Incorrect edits can break your site. Always backup .htaccess before changes.

8. Real-World Walkthrough

Imagine a WordPress site using Elementor, Contact Form 7, and a slider plugin.

• PageSpeed Insights flags: elementor-frontend.css, slider.js, contact-form-7.js as render-blocking.

• Steps to fix:

  1. Inline critical Elementor CSS for above-the-fold content.

  2. Defer slider.js using WP Rocket.

  3. Conditional load contact-form-7.js only on the contact page.

  4. Aggregate CSS/JS files via Autoptimize.

Result: The first meaningful paint drops from 3.8 seconds to 1.4 seconds. Users see content almost instantly.

Quick Checklist to Remember

• Install and configure a performance plugin

• Defer non-critical JavaScript

• Add async to third-party scripts

• Inline critical CSS for above-the-fold content

• Minify and combine CSS/JS files

• Use conditional loading for page-specific scripts

• (Optional) Optimize via .htaccess

2. Defer JavaScript Loading

Think of deferring as saying, “Load this later, buddy.” Non-critical JavaScript should be deferred so the browser can render the page first.

<script src=”example.js” defer></script>

This tells the browser, “Don’t block rendering, just load it once the HTML is parsed.”

3. Async JavaScript

Similar to defer, but with a twist. Async loads JavaScript files simultaneously as the HTML is parsed, not waiting until the document finishes.

<script src=”example.js” async></script>

When to use: Great for third-party scripts like ads or analytics.

4. Inline Critical CSS

CSS is a big culprit in render-blocking. Critical CSS is the styling needed for above-the-fold content. You can inline it directly in the HTML head:

<style> body { font-family: Arial, sans-serif; } h1 { color: #333; } </style>

The rest of the CSS can load later.

Plugins like Critical CSS Generator or WP Rocket’s Critical Path CSS feature make this easier.

5. Minify and Combine Files

Fewer files = faster loading. Minification removes unnecessary spaces, comments, and characters. Combining files reduces HTTP requests.

For example:

• Instead of loading style1.css, style2.css, and style3.css, combine them into one.

• Use Autoptimize or Fast Velocity Minify to automate this process.

6. Lazy Loading and Conditional Scripts

Why load a video script if there’s no video on the page? Conditional loading ensures that scripts are used only where needed.

For example, you can load the contact form script only on the contact page, not everywhere else.

7. Adjusting via .htaccess

A bit technical, but powerful. With the right rules, you can eliminate render-blocking JavaScript and CSS via htaccess. This usually involves caching headers, compression, and sometimes preloading.

While it’s advanced, it’s worth noting as an option.

Practical Example: Cleaning Up a WordPress Site

Let’s put theory into action. Suppose you’ve got a WordPress blog about https://greatasp.co.uk/. It loads slowly, and PageSpeed Insights shows 5 render-blocking CSS files and 3 JS files.

Here’s what you’d do:

1. Install Autoptimize and enable “Aggregate CSS” and “Defer JavaScript.”

2. Inline critical CSS using the plugin’s feature.

3. Set conditional loading so scripts like “slider.js” only load on the homepage.

4. Test again. Boom! The score jumps from 65 to 95.

Common Mistakes When Trying to Eliminate Render-Blocking JavaScript and CSS on WordPress

• Even seasoned WordPress users can stumble when trying to speed up their site. Eliminating render-blocking JavaScript and CSS sounds simple, but there are a few pitfalls that can turn a quick optimization into a headache. Let’s break them down so you don’t fall into these traps.

  1. Deferring Critical Scripts by Mistake

  A very common blunder is deferring or async-loading scripts that are essential for above-the-fold functionality.

  • Example: If your navigation menu relies on a JavaScript file and you defer it, visitors might see the content but can’t interact with the menu.

  • Solution: Identify critical JS files using Chrome DevTools or GTmetrix and only defer non-critical scripts.

  2. Overloading Plugins

  Some users try to solve every render-blocking issue by installing multiple performance plugins.

  • Issue: Running WP Rocket, Autoptimize, and Asset CleanUp together can cause conflicts, duplicate minification, and even break pages.

  • Solution: Pick one main optimization plugin and only use others for specific features if necessary. Test after each change.

  3. Ignoring Above-the-Fold CSS

  It’s tempting to just combine all CSS files and call it a day, but this can actually worsen the problem.

  • If critical CSS is buried inside combined files, your above-the-fold content still waits for the browser to parse everything.

  • Solution: Use a plugin or tool that inlines critical CSS for above-the-fold content while loading the rest asynchronously.

  4. Forgetting Third-Party Scripts

  Many WordPress sites rely on analytics, ads, or social widgets. Even if your own scripts are optimized, third-party scripts can still block rendering.

  • Example: A Facebook Like button JS loaded in the head can delay the first paint.

  • Solution: Load third-party scripts asynchronously or defer them to after the main content is rendered.

  5. Not Testing Changes

  Rushing through optimization without testing is a recipe for disaster. A tiny misstep can break layouts, sliders, or forms.

  • Solution: Always check pages after applying changes. Use multiple tools like PageSpeed Insights, GTmetrix, and Lighthouse to verify improvements.

  • Bonus tip: Keep a backup of your site or test on a staging environment first.

  6. Misusing .htaccess Tweaks

  Tweaking server files like .htaccess can be powerful, but it’s also risky. Mistakes can lead to server errors or a broken site.

  • Example: Incorrect caching rules or gzip directives can prevent scripts from loading properly.

  • Solution: Backup .htaccess before editing, make one change at a time, and test carefully.

  7. Expecting Immediate Perfection

  Optimization is a process, not a single fix. You might eliminate some render-blocking scripts but still see minor delays due to fonts, videos, or heavy images.

  • Solution: Continuously monitor performance, and treat speed optimization as ongoing maintenance rather than a one-time fix.

  Real-World Example

  A WordPress eCommerce store tried to eliminate render-blocking JS by deferring all scripts, including the WooCommerce cart scripts. Result: the site looked fast, but checkout buttons didn’t work. After careful testing, the store:

  • Deferred non-essential scripts only

  • Kept critical WooCommerce JS in the head

  • Inlined CSS for above-the-fold content

  Load time improved dramatically without breaking functionality.

  Quick Checklist to Avoid Mistakes

  • Identify critical vs non-critical JS before deferring

  • Use only one performance plugin for optimization

  • Inline critical CSS for above-the-fold content

  • Defer third-party scripts whenever possible

  • Test all changes on staging or live site

  • Backup .htaccess before server tweaks

  • Monitor performance continuously

Conclusion

Whew, we’ve covered a lot of ground. From figuring out what render-blocking even is, to learning how to actually fix it with plugins, defer attributes, critical CSS, and even htaccess tweaks – you’re now well-armed.

Remember, the goal isn’t just to chase a perfect PageSpeed score. It’s to deliver a lightning-fast, user-friendly website that search engines love and visitors enjoy. So take the time to test, adjust, and refine.

By learning how to eliminate render-blocking JavaScript and CSS on WordPress, you’re not just fixing a speed issue. You’re building trust, improving SEO, and creating a better experience for every click. And honestly, isn’t that the whole point of running a site?

FAQs

Q1: What’s the easiest way to eliminate render-blocking JavaScript and CSS on WordPress?

A: The quickest win is using a performance plugin like WP Rocket or Autoptimize. WP Rocket does the heavy lifting with one-click options like “Load JavaScript Deferred” and “Optimize CSS Delivery.” Autoptimize, on the other hand, is free and lets you aggregate CSS and defer JavaScript with minimal setup. Even if you’re a non-technical site owner, these plugins make it straightforward.

Q2: Can I eliminate render-blocking JavaScript and CSS without plugins?

A: Absolutely, but it’s not for the faint of heart. You’d need to manually add async or defer attributes to your script tags, generate and inline critical CSS for above-the-fold content, and conditionally load scripts based on page templates. This often means editing your theme’s functions.php file or even digging into child theme overrides. Doable? Yes. Beginner-friendly? Not so much.

Q3: Will eliminating render-blocking files break my site?

A: It can, especially if you accidentally defer or delay scripts that are essential for interactive elements above the fold. For example, if your navigation menu depends on a JavaScript file that you defer, users may see a broken menu until the file finishes loading. The trick is to experiment carefully and test each change. Always have a backup plan in case something breaks.

Q4: Do I need to eliminate all render-blocking JavaScript and CSS?

A: No. That’s one of the most common misconceptions. Not every file is bad. Some CSS is critical for rendering the top part of your page, and removing it can result in a “flash of unstyled content” (FOUC). The smart approach is to eliminate non-essential render-blocking files while keeping critical ones in place. Think of it like trimming the fat without cutting into muscle.

Q5: Does eliminating render-blocking JavaScript and CSS improve SEO?

A: 100%. Google has been loud and clear about site speed being part of its ranking algorithm. Core Web Vitals – metrics like First Contentful Paint (FCP) and Largest Contentful Paint (LCP) – are directly impacted by render-blocking files. By eliminating them, you’re sending positive signals to Google, improving both rankings and user satisfaction.

Q6: How do I eliminate render-blocking JavaScript and CSS via htaccess?

A: With htaccess, you can enable compression (like GZIP or Brotli), set cache-control headers, and even add preload directives. For example, preloading your critical CSS tells the browser, “Hey, grab this file first because it’s important.” That said, htaccess isn’t a magic bullet for everything. It’s more of a complementary approach alongside plugin optimization.

Q7: What about third-party scripts like Google Ads or Facebook Pixel?

A: Third-party scripts are notorious for slowing sites down because they can’t always be controlled directly. However, you can still defer or async load many of them. For example, you can load Google Analytics with the async attribute so it doesn’t block rendering. Ads and pixels are trickier, but conditional loading (only loading on pages that need them) can make a big difference.

Q8: I’m using Elementor. How do I eliminate render-blocking JavaScript and CSS there?

A: Elementor tends to load extra CSS and JavaScript, even on pages that don’t need them. Plugins like Asset CleanUp or Perfmatters allow you to disable Elementor scripts on specific pages. Another trick is to use Elementor’s “Experiments” settings, where you can enable improved CSS loading and inline critical CSS. Pair this with Autoptimize, and you’ll see major improvements.

Q9: I run WooCommerce. Can I safely eliminate render-blocking files without breaking checkout?

A: With WooCommerce, caution is key. Many of its scripts are essential for cart and checkout functionality. If you defer them blindly, you could end up with broken carts. The smart approach is conditional loading: keep scripts active on product, cart, and checkout pages, but disable them everywhere else. Tools like Asset CleanUp make this much easier.

Q10: My site uses a CDN. Do CDN settings affect render-blocking optimization?

A: Yes, CDNs like Cloudflare or BunnyCDN can help a lot. Cloudflare, for example, has “Rocket Loader,” which automatically defers JavaScript to reduce render-blocking. However, Rocket Loader sometimes clashes with complex plugins (like Elementor or WooCommerce). If you see broken functionality, try disabling it for specific scripts. The combination of CDN + plugin optimization is often the winning formula.

Q11: What’s the deal with CSS and JavaScript render blocking in HTML?

A: When you place CSS or JavaScript files in the head of your HTML, they often block rendering because the browser must fully process them before displaying content. That’s why moving JavaScript to the footer or adding async/defer attributes makes a huge difference. For CSS, inlining critical styles and loading the rest later is the standard fix.

Q12: Should I use preload or prefetch to handle render-blocking resources?

A: Preload is a neat trick. It tells the browser to prioritize specific resources like fonts or critical CSS. Prefetch, on the other hand, is better for anticipating resources users might need on the next page. When used correctly, preload can reduce the pain of render-blocking CSS. Just don’t overuse it, or you risk overwhelming the browser.