Client says their office computers still run old systems and the website shows a blank screen—they insist on IE compatibility. Is it still OK to take this job now?

Conclusion first: In 2026, when building a corporate website, public sites do not support IE by default, and it is not recommended to make it a mandatory contract item. Only when visitors genuinely include intranet terminals, government and enterprise office computers, or industry-specific systems, and the client can provide access statistics for the most recent month, should limited compatibility be discussed. The position is usually set at pages being readable, core information not missing, and forms submittable—not pixel-perfect rendering. If the scope is clear, the job can be taken; if the scope is unclear, taking it easily leads to rework.

1. If IE compatibility is still being discussed in 2026, first clarify who is using it

Browser compatibility is not only a technical issue; it is also a switch for cost and scope. New versions of mainstream front-end frameworks, component libraries, and build tools generally no longer provide support for IE11; this can be checked against each project's official documentation and release notes. Once compatibility with old browsers is required, the delivery team often has to roll back the build chain, introduce compatibility scripts, and give up some layouts and animations—equivalent to maintaining two presentation logics on the same page.

More realistic is visitor distribution. Based on common project delivery experience in 2026, mobile usually accounts for the majority of corporate website traffic, and desktop is also basically on modern browsers; the cases where old browsers are still actually encountered are mostly intranet office computers, workshop terminals, and embedded browsers bundled with industry-specific software. So the focus of this requirement is not whether to support IE, but who is using it, where, and for what.

• Public marketing website: visitors come from search, ads, and WeChat, basically not involving old browsers; most compatibility requests can be politely declined.
• Intranet or government and enterprise integration site: the client's terminals are uniformly managed by the organization, and whether to install a new browser is not your decision, so compatibility requirements should be taken seriously.
• Mixed scenario: the same URL is used both for external campaigns and internal use; a common compromise is a degraded style tier that only guarantees readability.

2. Ask three things clearly before taking the job

Judging whether to take the job does not rely on guessing; it relies on asking. Clarify the following three things, and the scope and quote will have a basis; this also prevents being dragged into endless revisions after launch by a single sentence that it does not open on our side.

1. Who the visitors are. Is it a public site for unknown visitors, or only for a specific organization, internal employees, or distributors? The former can reject old-browser compatibility; the latter should be defined according to the client's actual environment.
2. Is there real data? Ask the client to provide browser statistics for the most recent month, or ask their operations team for a summary of access logs. If they cannot provide data and only rely on the claim that all our computers are old, it is generally handled under the public website position.
3. Is it a hard constraint? Clarify whether the intranet prohibits installing new browsers, whether there are centrally procured terminal models, and whether there is an industry system that must be shared. Only hard constraints justify spending engineering hours on compatibility.

The value of these three steps is to replace subjective feelings with verifiable conditions. In actual delivery, a common situation is: the client says many customers cannot open the site; after checking the statistics, old browsers account for less than 1% of visits, and a readable degradation tier solves it—saving money without affecting normal visitors. When data is unavailable, it is better to first deliver under the public website position and leave an option for adding degraded styles later.

3. Compatibility scope is divided into three tiers; cost and timeline are estimated by experience range

Disputes over compatibility are rarely about whether to do it; most are about how far to go. For the same page, the workload difference between only requiring content to be visible and requiring animations to be consistent can be several times. It is recommended to fix the scope to one of the three tiers at the quote and contract stage.

• Tier 1 · Readable: text, images, and links are not misaligned or overlapping; core information can be fully seen; navigation can be opened. Front-end hours typically increase by 5%–15%, and the supplementary work period is typically 3–5 working days. This tier is enough for most intranet scenarios.
• Tier 2 · Usable: on top of Tier 1, ensure forms can be submitted, phone numbers can be dialed, and attachments can be downloaded; carousel animations are not mandatory. Hours typically increase by 15%–30%, and the timeline is typically 5–10 working days. Suitable for sites used both internally and externally.
• Tier 3 · Consistent: pixel-level layout alignment, animations and interactions consistent with modern browsers. Hours typically increase by 30%–60% or more, and the timeline is typically more than 10 working days. Public corporate websites basically do not need this; only a few brand campaign pages are worth considering.

These are experience ranges, not quotation commitments; the number of pages, third-party components, and whether forms or payments are included will all change the range. A verifiable comparison: for the same roughly 10-page showcase site, doing only Tier 1 readable usually saves one front-end round compared with doing Tier 3 consistent; if the pages include CAPTCHA, maps, or video players, whether third-party components support old browsers must be tested first, otherwise the budget can easily get out of control. Writing the tier into the acceptance checklist is far more useful than vague wording such as compatible with mainstream browsers.

4. Delivery scene experience: how to implement when scope cannot be contained

Here is a delivery scene: the constraints are only two weeks left in the schedule, a limited budget, and the materials are still images forwarded by the client via WeChat; then the client suddenly adds a requirement to support old browsers. The approach is to narrow the scope to Tier 1 readable, first covering three pages—home, product list, and contact us; the form degrades into a prominent email and phone number, and carousel animations are hidden under old browsers. As a result, delivery happens on the launch date; the cost is that these three pages temporarily give up the homepage hero animation, and later supplementation is not mandatory. Similar supplementary work has a typical range of 3–10 working days, depending on the number of pages and interactive modules. Explaining the trade-offs in advance is easier than explaining after launch.

5. Three common pitfalls: materials, third-party components, and test environments

• Image format fallback: the page uses newer formats such as webp and avif, and old browsers may show blank areas directly. Before delivery, confirm whether jpg and png fallback images are retained; the cost is larger image size and a slightly slower first screen.
• Incompatible third-party components: external scripts such as CAPTCHA, online customer service, maps, and video players often have support scope determined by the service provider, and the delivery team cannot change them. Test in advance and, if necessary, switch solutions or hide the module under old browsers.
• Testing environments are tested separately: the client tests on their own computers, the delivery team tests on modern browsers, and each side says something different at acceptance. The approach is to list a test environment checklist at project kickoff, and both sides check against the same list.

These three pitfalls share one common point: they all occur after the compatibility requirement has been agreed orally, yet no one checks materials and third-party components, and finally the problems pile up one week before launch. Writing the test environment, image fallback, and third-party support scope into the requirements confirmation sheet will reduce later disputes significantly.

6. Applicable and non-applicable boundaries

One boundary that can be quoted independently: compatibility with old browsers is an optional item determined by the visitor environment, not a default item in corporate website delivery; when there is no real access data to support it, deliver for modern browsers by default.

• Worth doing: intranet office, government and enterprise integration, manufacturing workshop terminals, distributor-only entry points; the visitor environment is uniformly managed by the client and cannot be changed in the short term.
• Not necessary: public marketing corporate websites for unknown visitors, sites mainly accessed by mobile, and pages that acquire customers through search and advertising after launch.
• Can compromise: the same site is needed at both ends; implement a Tier 1 readable degradation and add a note on the page suggesting a modern browser for a better experience.

When boundaries are unclear, according to common project delivery practice, write on the requirements confirmation sheet that this delivery does not include pixel-perfect compatibility with old browsers; this is more effective than arguing at the acceptance meeting. If it really must be done, first obtain access data, then set the tier, and start work only after the scope is written into the contract attachment.

FAQ

If the corporate website shows a blank screen in an old browser, is the code broken?

Most of the time it is not broken code; rather, the page uses script syntax or image formats unsupported by the old browser, and after the script fails, the whole page does not render. First check console errors, then decide whether to add fallback scripts or only provide readable styles.

If the client insists on compatibility, can we just change the homepage to get by?

Changing only the homepage is not recommended. Visitors often click from the homepage into product or contact pages, so changing only the homepage pushes the problem later. A common approach is to first select three to five high-traffic pages for readable degradation and clearly state the coverage scope in the delivery notes.

Will old-browser compatibility slow down page load in modern browsers?

A little. Extra compatibility scripts and fallback images increase size, and the typical range is a few hundred milliseconds added to the first screen. On-demand loading can control this, loading degraded resources only for old browsers.

If the client only asks for compatibility after launch, is there still time to supplement it?

There is still time, but the scope and timeline must be reassessed. The typical range is three to ten working days, depending on the number of pages and whether interactive modules such as forms and payments are involved. Supplementary work should also start by setting the tier, to avoid adding requirements while making changes.

If there are no access statistics and the client only says their computers are old, should we accept it?

Generally, do not accept it directly. First deliver under the public website position, and leave an option in the requirements sheet for adding degraded styles; if the client can later provide statistics for the most recent month, then set the tier and supplementary fee based on the data.

If you are stuck on this kind of requirement, it is recommended to do two things first: ask the client for browser access statistics for the most recent month, and write the compatibility scope into the requirements confirmation sheet as Tier 1 readable or Tier 2 usable. If you still cannot decide after getting the data, organize the site type, visitor composition, and launch time into a one-page explanation and hand it to the delivery team for evaluation. This judgment applies to projects with clear constraints on the visitor environment; for purely public marketing websites, putting budget into content quality and loading speed usually gives more direct returns.